Back to front development

When push comes to shove, and milestones are looming, we often postpone small tasks until the morning after. A bigger hangover comes when we postpone larger parts of the development until the end, whereas in fact they belong at the beginning. This article covers those areas, and why they should occur sooner, rather than later.The Front EndWhen most people talk about graphics they invariable mean the super-whizzy 3D variety involving bump mapping and pixel shaders. They rarely think of the 2D functionality. This is a shame since the 2D component is very simple and can be comprehensively written within a day or so. (Remember that less use is made of 2D graphics and so doesn’t require such anal optimisation.) This allows another programmer to start work, in parallel, creating the menu system and GUI.Starting the GUI late will produce typical end-of-project code that HURTs. That is, something Hairy, Un-maintainable, lacking in Refinement, and inadequately Tested. An inflexible front end implementation usually means it will adopt a code-driven (as opposed to data-drive) approach which makes it very difficult to load alternate levels, or control game parameters without resorting to re-compilation, or modifying the data on-the-fly through a debugger.Finally, on a completely non-technical note, the GUI provides an identity for the game. By including this early on, it creates buy-in from other staff, and allows developers to visualise their focus more easily. And unsurprisingly, with the interface being the first point of contact with the player, you will want as much opportunity for polish as possible.Technical Requirements

For those not familiar, these are a set of rules to which every console developer must adhere. They describe the precise method of handling the memory card, reset button, and removal of controllers to ensure a consistent feel across all games for that console. Everyone who’s had at least one console game released can attest to the problems with passing the technical requirements stage, so this alone is reason enough to implement the technical requirements early. It also means that awareness of the issue is raised from day one, and so any new code can be written to perform within these constraints, saving time from re-implementation later. Additionally, some console manufacturers will -- if asked -- pre-test the game several months before final submission. So early development can save prevent slippage nearer the more crucial Christmas deadline should the game fail the initial technical requirements check.Optimisations

If your name is Knuth you can skip this section. If not, read on! There are two rules about optimisation: the first is “do not optimise your code prematurely,” the other is “do not optimise your code at the end of the project.” These ideas do not conflict. Optimisation is an iterative process that should occur whenever a performance drop has an adverse effect on gameplay, and not left as a ‘todo’ if there’s time at the projects end. A low frame rate makes the game unplayable, and as such should be considered a bug.The best method to optimise your game so that it runs at 60 fps is to make sure it never runs at anything less. You should begin development with each game level running at 60 fps, and utilise an automated test suite to periodically report any decrease in performance. Any issues with frame rate must be investigated immediately; with feature development continuing only after the frame rate has been restored. This ensures you spend only the necessary time on optimisations - and no more.As a side note, code should always be written for maintainability in the first instance, and speed in the second. Inefficient code has little chance to permeate since the weekly performance test will demonstrate the bottleneck early in the development cycle. Testing

Finally, the most dreaded word in a developers canon – testing. Like optimisation, this should be a continual and ongoing process by checking and signing off on work in small chunks as they are completed, throughout the lifetime of the project. This gives a greater feeling of accomplishment than the alternative ‘big bang’ approach. The process allows programmers to ask, “Is the main menu screen Ok?” before spending time implementing all the others. Similar questions can be asked of the control system, in-game heads up display or music score. This results in a ‘ship any day’ mentality.The programming staff have a more extreme method of early adoption, known as ‘test-first’ development. This is where the test suites are written before any code is implemented, and are designed to cover all eventualities within the code. It should act as if it were trailing the perfect module in the world, ever! And as such should cater for every case you would want the library to handle.By producing test code early it becomes part of the creative process, and not the forlorn drudgery at the end. This approach has the added benefit that once all your tests are satisfied the code is complete. You then won’t spend (or should that be waste?) time adding unnecessary features. This works better for engine and tools development, granted, but it still has a place within gameplay programming. The Author