# When prototyping, how can I more easily explore game behaviour?

I build indie games myself, but I'm usually out of energy once I've taken a newly developed game to a level where it's possible to play with behavior, so I settle for refinement instead of exploration. With awful results.

(picture from the Intercom blog)

For example, I find that the iteration cycles for tweaking behavior (i.e. linking and restarting a C++ application) are so long that they kill all creativity. I'm building a tool to deal with this.

What other ways exist to quickly explore game behavior? I'm interested in the methodologies used by indie developers as well as larger companies.

• That's a very nice picture. Where is it from? – Superbest Apr 21 '15 at 18:36
• I think what you are doing is formally called "unit testing", especially if you want to tweak a small part of the game at a time. Unfortunately, games are hard to actually unit test, because it's hard to isolate components and hard to automate the test itself (so that it can decide on pass/fail). Reading about unit testing strategies might give you useful ideas, though. – Superbest Apr 21 '15 at 18:44
• @Superbest: I know unit testing inside out, and you can't compare behavior exploration to unit testing. When exploring behaviour you need most of your game engine loaded, along with relevant assets. Unit testing is only when you know where you're going; in this case nobody knows. That's why it's "exploration", not "refinement". Pic from Intercom blog. – Jonas Byström Apr 21 '15 at 19:08
• When you are testing in Debug mode, you can change your code, when you pause it (at least in visual studio). as long as you don't change to much (function headers etc), you can load it in your paused game with just a short compile time – Tobias B May 28 '15 at 9:50
• @TobiasB: in practice I've unfortunately found that useless. Especially as you normally have your game mechanic spread out in scripts, already instanced game objects, assets and so forth. I'm not even sure the free Visual Express supports it, haven't actually used it for 14 years! :) – Jonas Byström May 28 '15 at 10:39

As you've noted, when you're working on game mechanics, speed of iteration is critical. The longer the time between thinking of a modification and being able to test with that modification, the less productive you'll be, and the more distracted you'll become. As a result, you definitely want to be managing your iteration time.

For me, I find that my productivity really starts dropping off when the time to test a simple change exceeds about five seconds. So when you're experimenting to perfect the way the game feels, one of your goals has to be figuring out "how can I make a change and then be playing using that change in under five seconds". It doesn't really matter how you do it, as long as you can hold that iteration time down to about that level.

Lots of big modern engines (Unity, Unreal, etc) tend to do this by putting their editor inside the game engine, so you can make most modifications live, without ever restarting the game. Smaller engines/games typically focus work in the other direction; make the game compile and launch so quickly that it doesn't matter if you have to restart the game for each change; you'll still be in and testing before that five second period is up.

In my current project, it takes about ten seconds for me to do a small recompile, link, launch the game, and then reach gameplay (most of that is generating renderable world geometry when loading a saved game). And that's much too long. So I've created separate "testing" game modes which let me test different parts of the game without loading all the real game assets, so I can get in and out much, much faster; typically in about two to three seconds. If I want to test some UI, I can do that without loading into the real game. If I want to test rendering, I have a another mode where I can test that, again without loading up the whole game system.

I've seen other folks who have approached the problem by placing game logic into a DLL, and letting the already-in-memory game executable reload the DLL while the game is running, so you can rebuild the DLL and just reload it inside an already-loaded executable, so you don't need to reload/rebuild your game's art assets. This seems like madness to me, but I've seen it done.

Much simpler than that would be to specify game behaviours and/or configuration in scripts or data files, and provide a way to make your system re-load those files, either on demand, or perhaps just watching them for modifications, without needing to shut the game down, re-link it, and then start it up again.

There are plenty of approaches. Pick what works best for you. But one of the keys to successful refinement of game mechanic is extremely rapid iteration. If you don't have that, it almost doesn't matter what else you do.

• Could you elaborate on your "testing" game modes? Do you create a slice of the game here and there for each part whenever you want to iterate on it? How much time do you need to setup your "slice"? What is left out and how? Do you have a sort of "save game" and "load game" functionality for this type of thing, or is it less generic? – Jonas Byström Apr 21 '15 at 15:12
• @JonasByström I don't know about him, but when I have good control over my game states, I can often have alternative "Debug" versions (often literal IF DEBUG compiler directives) that go straight to my "testing" state (skipping the game menu etc.), which is just a bare bones play area with whatever assets I'm testing at the time. So I basically compile an alternate executable that automatically loads a very stripped down level (less assets to load+no mucking about with game menu every time). – Superbest Apr 21 '15 at 18:39
• @JonasByström I divide my games up into "modes". It's basically just a big state machine. So I will typically have a "Title Screen" mode, an "In Game" mode, a "Credits Scroll" mode, etc. They're like embedded games inside the executable. My "testing" modes are things like "UITest", which will simply load and draw a piece of user interface, without loading any other game content. Or "RenderTest", which will load and draw some particular object, without loading anything else. – Trevor Powell Apr 22 '15 at 1:30
• @JonasByström When I need to create a new testing mode, it will typically take a few minutes to write the code which sets up the particular thing I want to test, and any dependencies it might have. Or alternately, I can often adapt an existing test mode in a few seconds (For example. I'll generally modify my existing UITest mode to load a different piece of UI, rather than create a new one). It doesn't really matter much how long it takes to set up, though; the point is that once it's set up, I can iterate at absurdly fast speeds, which keeps me productive during that iteration time. – Trevor Powell Apr 22 '15 at 1:31
• @JonasByström It's also worth noting that "buy a faster computer" is a completely legal solution to the "how do I get my iteration times down" question, too. And often it can be the cheapest solution, when compared against investing your time into implementing special testing rigs. Getting your iteration time down is an investment that you put a lot of time/money/effort into up-front, but which pays a lot of dividends down the road. – Trevor Powell Apr 22 '15 at 1:43

To prototype well, reduce the cost of testing ideas.

My workflow is tuned for small games, but I've found these things helpful:

• Prototype-friendly tech I've found it helpful to use a dynamic programming language and framework, such as Lua (LÖVE is nice for 2D), JavaScript or Lisp/Scheme where getting the program to do something requires minimal keystrokes, even at the cost of everything else. Once you know what you want, and want to refine it, optimise or port to some other engine.
• Version control Keep prototypes in a revision controlled repository. Branch early, branch often. This keeps you comfortable trying things without worrying you'll lose or forget something. (Git has the cheapest branching model.)
• Build automation Make sure you need to do as little as possible to actually get the thing to run. In my opinion, even having to press a button is too much: I usually have a Makefile with a make watch target that runs inotifywait in a loop, reacting to file changes by automatically compiling/running the game. In an interpreted or JIT-compiled language, this is instant.
• Lua does not seem to support hotswapping code. Does that mean that you need to restart your game/prototype in order to test your changes? – Jonas Byström Apr 21 '15 at 15:07
• Hotswapping Lua code is definitely possible. – user1430 Apr 21 '15 at 15:28
• @JonasByström It is possible, but only under the right environment. If you can't find one, write one, Lua's source code is written in C so it's portable to anything that accepts C-style function calls. Mix it in with OpenGL, SDL 2 or some other graphics/harware wrapping library and build yourself a hotswapping IDE. – Pharap Apr 21 '15 at 18:32
• @JonasByström Here's how to do it with IDE support and without. – Anko Apr 21 '15 at 19:34
• @JonasByström: ...except getting back to the moon, apparently. :( – Mason Wheeler Apr 21 '15 at 20:57

As a developer focusing mostly on prototyping, here's a bit of advice from my experience.

1. Use an engine that allows you to make changes FAST. This includes things like "Not waiting for compilation", but also "changing things at runtime", "ease of debugging", "availability of test assets" etc. I personally love Unity3D, but it's not the best tool out there. Best tool depends on the game: for example, Unreal Engine compiles code way slower than Unity3D, but it can quickly launch multiple connected clients. For a networked game, this often offsets the compilation costs. Consider also familiarity. If you're a whiz with C++, even the best Javascript engine won't do much good, and vice-versa. Don't spend time struggling with unfamiliar tech (I mean, do learn other languages/frameworks, but not at the same time as making important prototypes).
2. Learn to scrap existing features mercilessly. Clinging to stuff that you already implemented is anathema to successful prototyping, but letting go of your work is hard.
3. If you don't work with a game designer, put a clear line between "wearing a programmer's hat" and "wearing a designer's hat". Adding a new cool gameplay feature seems very tempting, but don't do that when you're in the designer position. Rather try to create fun gameplay (preferably multiple variants) with what you have; make a list of features that would help and then implement (some of) them.
4. Rapid prototyping involves balancing between two opposites. You want to make stuff as fast as possible, so you write bad code. But you want to change stuff as much as possible, so you have to write good code! Learn to balance these two. Sorry, I can't think of any concrete advice on how to actually do this, but at least be conscious of this problem (-8

Look at how much time your prototyping requires. In my experience, you want to have a playable version of anything in two day max - starting from scratch; and you want to be testing one or two new features every day. If you're not meeting these targets, search for ways to be faster.

• I'm thinking that features are different from behavior exploration. I want to explore "the feel." Features are more like beautiful rendering to me: non-essential and not correlated to how fun the game will be. Minecraft, Candy Crush, Tetris and similar games prove that IMHO. – Jonas Byström Apr 21 '15 at 19:17
• @Jonas Byström To clarify: here by "features" I mean essential changes to the gameplay. I.e. specifically NOT beautiful rendering, but something like "add a way to craft blocks" or "add mobs that attack and kill player" when prototyping a Minecraft. – Nevermind Apr 22 '15 at 5:57
• The importance of your second point, "letting features go", cannot be overstated. Many exploratory phases fail because of not saying "no" to that failed feature that took 2 weeks to be implemented. – Kostas Apr 22 '15 at 9:02
• A note on point 4. I think the key to this is understanding what you are going to need to change in code quickly. Be sure to expose the values that you know you're going to want to tweak. Leave other sections of the code buried if you know they don't affect gameplay as much and expose them later when you need to. You do you have to work this out quickly, but if you can try to design your architecture from the word go so that the 'game design' stuff is front facing and clean where possible, the rest can be scrappy. – sydan Apr 22 '15 at 10:43
• @sydan the unfortunate truth is that your idea of what code is "front facing" is wrong. I mean, it ALWAYS turns out that something you though should never change is actually a very dynamic thing. When prototyping, you'd better be prepared to change literally every aspect, and do it fast. – Nevermind Apr 23 '15 at 10:12

One can split game development between these four phases:

• prototyping
• gameplay refinement
• development
• performance refinement

Gameplay exploration I believe happens mostly on the prototyping phase and these are some advice I try to follow:

• Begin designing with a paper prototype. After you have a clear idea of what the game could be, start coding it so that you can actually feel the interactions. Maybe this is useless for 3D games but personally it has helped me a lot in the past.

• Code knowing that you will throw away your code after you are done. This will allow you to be liberal when it comes to what game engine to choose.

• Fast iteration cycles are important (as others have pointed out previously). Choose a game engine based on its ability to quickly show you what you coded. You also don't have to care about performance or graphical fidelity at this phase.

• Limit your scope. If the actual gameplay is 2D (usual strategy game, JRPG), prototype in 2D. In this phase you only care about feedback on the gameplay.

• Don't waste time polishing or searching for assets. Scribble something on a paper, take a photo of it, cut it in Photoshop, maybe color it and use it as a sprite. Turn on your microphone and say "pew pew". Put two cubes and a sphere together and you have a robot. Always keep in mind, exploring gameplay possibilities is your first and only priority.

After deciding on a prototype that is fun, start refining it. I don't think there is a reason to switch technologies yet except if there is a gameplay element that needs it.

Later in the development phase, you'll keep the refined prototype at hand while developing a new, much better looking, much better sounding, much better feeling game. Here you have to choose the actual game engine to use.

In the end, take what you have and tune it to use less resources.

Most of what I describe above it common knowledge but putting it out on a list, compartmentalizing the whole development process, helps me put each step in perspective. I hope it helps you too.

• Paper pic and "pew pew" are excellent advice; and yes - lists help me too. "Identify your top three priorities. Throw away numbers two and three." :) – Jonas Byström Apr 23 '15 at 8:52

I agree with Trevor Powell's answer that speed of iteration is critical for you to stay in the creative mood instead of just polishing. A big source of inspiration for me is Bret Victor's talk, "Inventing on Principle". Unfortunately, it's hard to find real tools at that level. I tried to build one myself for Python development that lets me run my Python code while I'm typing it. It's called Live Coding in Python.

• I've seen the vid before, but forgotten about it. Hm. Immediate interaction is really something to strive towards; I'll try to act on your advice. Good job on the interesting Live Coding plugin btw! – Jonas Byström Apr 21 '15 at 22:30

I built a prototyping tool called Trabant which:

• is 3D and game mechanic ONLY (no UI, no text, nothing);
• requires extremely little code and no assets to build a prototype;
• 3D models are created in code using ASCII art;
• allows sub-second iterations;
• has rigid-body simulation support;
• works on Windows, Mac, Linux and iOS;
• uses a well-known general-purpose language, Python;
• has an IDE for Windows and iOS.

I built 30 test prototypes in it to verify the above.

As Trevor Powell emphasized iterations need to be <5 seconds, and I find <1s iterations almost five times as good. :)

Anko mentioned that using a dynamic language is a good idea, I picked Python since it is one of the most widely used. Regarding build automation, testing in Trabant is as quick as pressing F5 in the IDE (or F6 to test it on your iPad), and since there is no build step involved it doesn't get more instant than this.

Throwaway code was one of Nevermind's takeaways. I totally agree, and Trabant enforces it.

In addition to Trevor Powell's iteration speed which is really important, here are some other useful considerations:

Its like good code...

A lot of IFs in there.

The more solid the concept the less you need to toy around. If you know what the meat of you are trying to do is, prototyping becomes - what to put and how to arrange things in relation to the central pillar (your main thing).

If you are starting out like many others - not quite sure what you want to do, you head in a direction and explore much in the way of the image you showed.

Either way commitment to a technology is irrelevant if what you are looking for can be simulated without much depth - prototype it on whatever you want/can.

Do not waste a single extra second on resources. Download everything off the internet. Proprietary or not. You are looking to get a feel of your concept at work - unless graphics is your main feature nobody's going to sue your for experimenting with other people's sounds, textures and everything, you're not putting it on the shelf in the store just yet. Unless you are already funded - convincing people the concept is worthwhile is the thing that is going to get you the money to get the resources you want. I've seen game studio folks present game concepts with modded versions of proprietary games that they have no rights to.

Its like you are building a scale model. While its awesome to have a miniaturized life replica of what you want. Sometimes its enough to cut it out of magazines, hand craft and glue the pieces together. Everybody with a smudge of imagination is not going to assume you will actually build the skyscraper out of the same cardboard you showed the scale model with. And in the creative industries - its kind of more preferable to work with people with some imagination. If they can't look past some draft problems to see potential behind a whole concept, they will rarely if ever appreciate a product. No appreciation means they are less willing to commit and thats a downward spiral. Its the difference between setting up your kid's attitude to conquer the world and instead telling "You can't even tie your shoes properly you little dipshit, whatever in the nine hells gave you idea you could succeed with making a kite?"

Whatever you may be doing always remember attitude alone is more than enough to ruin anything absolutely regardless of its technological or economic potential.

I once prototyped a game using exclusively gif images and giving them a little something to do with javascript. Its not dazzling but it served the purpose of showing what i wanted to show. Doesn't matter if you later develop it for Xbox exclusively.

If your idea is more complex than a simple prototype, then you are going to have to put research into the tech you'll use - since the prototype is going to the be scaffolding for the the final thing (simply because a lot is invested in it and it cannot be thrown away lightly) - if you get it approved obviously.

• Prototyping is only required if you're building something new, that's a given. Lack of tooling is like lack of pen and paper irl - and sure you can draw in the sand, but it's inefficient. I built Trabant to avoid having to go GIF+JS or Scratch. – Jonas Byström Dec 19 '16 at 7:56