Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun
View All     RSS
June 13, 2021
arrowPress Releases
June 13, 2021
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun

August 6, 2009 Article Start Previous Page 5 of 5

Local Optima

In a truly iterative project the natural state of the software is to be under maintenance and not hidden from end users in some "in development" state. Changes to and additions of requirements constantly flow in, and the game slowly but surely oscillates towards its optimal goal. In all of these changes it's also important to keep the game vision on your mind.

Some changes might at first lead to a game that evaluates more poorly than its predecessors. A big challenge is to realize if and when a change like this will be truly beneficial, or if it actually was a bad call to introduce the change .You need to be both courageous and humble to not get stuck in local optimum scenarios as well as have good traceability and tool support.

If You Don't Know Your History, You're Destined to Repeat it

As humans we tend to forget very quickly, and the permutations of implemented requirements quickly grow very large. This easily puts projects in a position where the same changes and requirements are tried and retried over and over, some iterations apart, with pretty much the same dismal result: a game design that runs in circles instead of moving forward.

Therefore it's very important to have a change backlog for the reasoning behind a particular change. This backlog provides very valuable information when selecting changes to push and what changes to drop. Being able to know if something has been tried and at what result is very powerful, yet often overlooked. Having access to the exact builds where the particular change was part of the game and being able to replay that particular version also provides valuable information.

Verify Quality

The earlier problems can be found, the better. It is therefore very important to verify quality as soon as possible. Software should be tested for functional and quality problems throughout the entire project. It is impossible to add quality as a separate testing phase.

Quality should be a major concern for everyone involved in the project every day. Continuously delivering top quality software is also a major contributor to team motivation, and lack of quality certainly drains the organization of commitment and courage to change.

Testing games is a particularly daunting task. Just consider functional testing of all possible permutations of different hardware, operating systems and API versions! Add to this specifically elusive quality requirements specific for games like measuring emotional response on test subjects and the fact that working in testing or quality assurance is regarded as a stepping stone in your career towards more highly regarded positions (i.e. it is a lowly and not so important task).

But is it FUN!?

The greatest risk of game development is the possibility of inadvertently developing a game that is not entertaining enough to be profitable. Game designers struggle to describe the entertaining aspects of the game in their game design documents, but "fun" is such an emergent aspect of a game that it can only be verified by actually playing the game, or a rough version of it.

If the game can be demonstrated to be fun without a lot of flashy content and special features, then it's a good bet that it will be even more fun and rewarding once these things are in place. On the other hand, if the core gameplay is boring or frustrating, no extra fancy content or functionality can save it. Game developers need to find out if their games are fun as early as possible.

Viewed in the light of being the primary means of verifying game "fun-ness", testing needs to be treated professionally and with great care. We propose that since testing is such an important part of development, every developer should be involved in testing and quality assurance should be under the guidance of a small professional testing team.

The testing team has the responsibility of monitoring testing quality and advising developers on how to apply different testing techniques. This will make quality assurance a more integrated and daily task for every developer. Also, when hiring for your QA department, you should be wary of people viewing QA as a stepping stone towards some other career.

As the software changes and evolves, the testing procedures must keep up. It is essential remember that testing is part of every iteration and a daily task for every developer on the project. Updating tons of testing documentation to keep up with the software can be a major task, and performing these tests over and over again is very time consuming if performed manually.

Good tools for automated test support and tracking are needed here, and ultimately you should only need the press of a button to test the entire software. This means that the actual implementation of the game needs to be testing friendly, testability could indeed be a quality requirement per se. This could range from using unit testing frameworks and test friendly software architectures to enabling recording and replay of user input to enable automatic creation of user scenarios.

Testing is not the only way of assessing quality in software. Code quality inspections, walkthroughs and other preemptive techniques should also be implemented and refined to suit the organization. Such techniques are also good for spreading knowledge in the project team.

Testing and Requirements

The requirements form the basis of different test cases to be executed, and when writing requirements, test cases should be written in parallel. This will both raise the quality of the requirements and also make testing activities a more integrated part in development. Care should also be taken not to duplicate information between requirements and test.

Games are often open ended and the amount of input options is more or less endless. Finding good test cases based only on requirements is very hard and techniques like exploratory testing should be used to find both test cases and important input sets to be considered.


Best practices of software engineering are observed approaches to successfully delivering software products. A software process for game development should therefore have the best practices of general software engineering as a base, and this base should then be tailored into a development process specifically aimed at the game development community. The process should also support further refinement on corporate and even inter-project levels.


Alan MacCormack "Product-Development Practices That Work: How Internet Companies Build Software", MIT Sloan ManagementReview, Winter 2001, Volume 42, Number 2

Raph Koster, "A Theory of Fun for Game Design", Paraglyph Press, ISBN: 1932111972,

Gamma et al. "Design Patterns Elements of Reusable Object-Oriented Software", Addison-Wesley, ISBN: 0-201-63361-2

Tom Hammersley, "Planning For Fun In Game Programming",

Extreme Programming: A gentle introduction.

Manifesto for Agile Software Development,

Martin Fowler,


UML Resource Page,


Title photo by ctsnow, used under Creative Commons license.

Article Start Previous Page 5 of 5

Related Jobs

Disbelief — Cambridge, Massachusetts, United States

Disbelief — Cambridge, Massachusetts, United States

Senior Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist - Pipeline
Insomniac Games
Insomniac Games — Burbank, California, United States

Technical Artist - Pipeline

Loading Comments

loader image