Summary

Games are different from more normal engineering / developing as they require an extra element: fun!

Fun is impossible to measure or plan for; what seems like a fantastic idea on paper can be dull when you actually play it.  And every game needs refinement and tuning to get the very best out of it.

Why use Unity for Prototyping?

Unity is a great tool for rapid prototyping, it allows you to make changes quickly and build to a variety of different platforms without having to alter the code, which is handy too say the least.

We often build mobile games to HTML5/canvas which allows clients to play the game while development or changes are in progress without having to install APKs or Testflight.  This allows a tighter team interaction and allows producers to see changes and work with them quickly.

We find even where the finished game will use a different engine or be coded natively to a platform (for example Unreal Engine or iOS or Android native builds) then Unity allows us to move much much faster with a prototype and that iteration allows a better final product once we move from prototyping and design into the productionisation/realisation phase of the game.

Unity is great for proof of concept work as you can quickly make a scene, shove in a few objects and get them doing what you want pretty quickly. It might not look great, but getting the mechanics down is fairly quick and easy.

Fidelity

Simply designed 2-dimensional images can be easily mapped onto backgrounds (instead of having a full skybox or animated elements) but still gives a good representation of the game.

For most prototypes, we find that primitive shapes are good enough.  In the past we’ve had cylinders instead of football players, squares instead of a main character (if it’s good enough for Thomas was Alone then who are we to judge!), and spheres to represent just about anything else.  Yes, we could use a Unity’s marketplace or various 2D / 3D asset sites but often you can get the feel and mechanics of the game without needing to work hard.

Unity’s ability to create a landscape can be really handy in prototypes so it bears understanding how it works.  We find painting within Unity is good enough for prototypes (for polished games/high fidelity demos we’ll always modify the map outside of Unity of course).

Mixing unity with some basic Blender know-how, only improves the situation as you can make things look a little better so you can give yourself or clients a better idea of what things would actually be like. 

And, if you really need to show a main character(s) or avatar then we find using Blender to automatically generate a skeleton/rig then mapping spheres on top of the skeleton gives us a chance to animate and view incredibly simple movements without spending lots of time.

How to structure Unity for Prototyping

It’s important to realise that a prototype isn’t the first stage in a finished product: the main mechanics will be re-used but very little code will make it into the next stage.

Ignore the usual efficiency and tuning cycles, turn off shadows and anything else that’s superfluous and concentrate on the core of the game.  Don’t aim for re-usability but do allow flexibility.

Flexibility is really the opportunity to start playing the prototype and twiddling the dials, knobs and levers to get the feel you want.  To do this stick to best practise and externalise the variables/fields in your C# code so people can modify them directly in the Unity editor themselves.  In this way everybody can play with the power of gravity, the speed of the object, the impulse of the engine etc. without having to know how to code.

At Code Wizards we don’t tend to use sound in our prototypes unless we’re explicitly asked to.  This means we need to use other methods to show interactions or effects. Luckily Unity has a way to do this via particle effects.

We use particle effects a lot but we don’t tend to tune them too much; a small burst of particles (usually without gravity applied and flying towards the camera) is a good policy for showing something happening without having to work hard and we’ve got a few that we keep in reserve and change the colours to reflect different actions.  This has the advantage that If some of the guinea pigs/playtesters/producers hate one form then they can swap that out in the editor without needing code.

Building a Toolkit

Every prototype is different but there’s a bunch of things that you can re-use a lot.

We use a few scripts and setups to get us to a prototype quicker and some of these you may want to consider:

• Particle systems setups/variables (as mentioned above!)
• Camera tracking scripts (to follow the main actor/object)
• Path navigation scripts
• Some simple pre-fabs pre-setup (normally a few primitives together in a single gameobject)
• Incredibly basic Blender models with skeletons/rigs and animations of moving and jumping (one human + one animal is a good start!)

Closing words

All in all, unity is a fantastic platform to get an idea down into a 2D/3D space and see what it would actually play like. With basic visuals and the core parts of the game, you can at least see if an idea is worth progressing further or if you should mark it down as something that either won’t worth or needs further development and thought into its mechanics.

Once you’ve established that an idea is worth pursuing, using unity and basic knowledge of things like blender will enable you to take that basic concept and rapidly fill in the gaps and make each iteration of the prototype quickly and get to a stage where you can put something out to playtesters to see if your idea is fun for other people who haven’t been present for the whole process.