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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.