Monday, March 22, 2010

Properties and Stage Design


Well tuned gameplay requires countless iterations of testing, and very careful mashing of all values related to gameplay systems. When developing it is useful to keep in mind the accessibility of values affecting gameplay and ways to keep testing iteration time as low as possible. Aim for less than 1 second turnaround between changing a value and being able to test it.

Given a typical game with Stages, Enemies and Weapons, you want most of the values to be accessible to programmers and non-programmers. Enemies and Weapons will have typical values; health, reload times, damage values, ammunition counts, projectile speed, et cetera. Make sure everything relevant to the feel of the element is exposed in an easily-editable property.

Having a set of readily tweakable values is the first step. Following that you need to be able to put your game in a state where you can try them out to get a real feel for the changes. This must be kept to a very (!) minimal procedure. Even with a fast game startup time, loading a stage and playing 15 seconds to get to the 'test' area is something you must avoid where possible.

Be sure to have an empty stage ready into which you can place relevant items and have a good test zone to begin tweaking values. Keyboard shortcuts in your tools will be the key to making this work well. For creating real levels, be able to start the player from any point in the level to allow iteration of particular segments without re-playing irrelevant sections.

The first phase of development and tweaking will be done on the programmer side, and often just  through the code itself and not via properties. On the programmer side it will be easier to tweak behaviour and state directly. Think well about what properties will be worth extracting for later tweaking by designers. 

On the designer side, there will be alot of adjustment of properties based on usage in actual game stages. It helps to have a very short feedback loop between programmers and designers so you can make sure all the relevant properties are editable, and to get behaviour and functionality changes implemented quickly so designer-side iterative testing can be efficient.

It can be easy to have too much editable in the properties such that only the programmer who wrote the entity can understand what everything means and how it will impact the entity. Try to keep the internals internal, so you can change functionality and keep only things that are relevant editable on the design side.

Quick feedback loop between programmers and designers, editable properties and countless iterations of testing and tweaking are what really makes the difference between a functioning game element and one that feels good and fun.