Tuesday, 3 August 2010

Mother of invention

Developing your game through a data and transform centered design philosophy leads to short cuts around things that have been ubiquitous in games development for some years.

Managers: Managers for tweakable variables, for resource loading, for inventories, bad guys, weapons and debris.
Setup functions: Setup functions or scripts for menu systems and user interfaces, for scene trees, for levels, for rendering subsystems, and shaders, and player input configuration.
Ticks: Ticks for entities, for pre render phases, for pre physics phases, for post frame memory defragging, physics, rendering, sound and asynchronous file IO.

These are artifacts of the coding style that C++ in games has given us. They, like their design patterns cousins, offer us an insight into what's wrong with the language as much as they help us get stuff done.

Managers vanish when making an item is a simple case of adding a row to a table, deleting the item is simply removing it, and getting a reference to an item is just holding it's primary key in another table. This explains why databases never had managers for their tables. They just had the tables. Everyone knew how to access the tables, and helpful people wrote helpers to access them in terms of stored procedures (which are like macros for databases) so that changing the access pattern was removed from the use of the data.

Setup functions seem to vanish as what was setup now becomes the main loop, or the set of transforms for a particular way of doing something. In SQL, you define the tables at the beginning, and after that you don't add new ones unless something major changes. In games development that's akin to having globals for all your tables, and the main loop has static functions coupling transforms to process the data on a frame by frame basis. the code is the design, and therefore doesn't need to change unless something significant about the game changes. After the rubbish has boiled off, you naturally end up with the real data driving the game, the scripts, the level data, but none of the unnecessarily dynamic schema changing code that plagues games development built by people with good intentions.

All the various ticks vanish as the very idea of a tick becomes quite obsolete in the face of transforming data over the designated frame or other interval. Tick functions and schedulers are for systems that don't know what they're ticking. If your design is in the code, you don't need a tick, you just need to perform the sequence of transforms to produce your frame output or update your network or game logic.

In conclusion, big helpful managers, setup functions and scheduling tick systems are all symptoms of object oriented development in C++ in games. They're not implicitly good or bad, but they do point to a problem because they are not necessary.

No comments: