Gamasutra: The Art & Business of Making Gamesspacer
A New Attitude To Game Engineering: Embrace Change, Re-Use, Fun
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All

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 Page 1 of 5 Next

[Massive Entertainment (Ground Control series) veterans Norneby and Olsson use this in-depth technical article to discuss how to radically improve your experience planning video games through applying software engineering processes to game development.]


This article describes and elaborates four best practices of software engineering in the context of game development. These practices are:

  • Iterative Development
  • Manage Requirements
  • Manage Change
  • Verify Quality

We urge game developers to realize that many of the software problems commonly encountered in game development have already been encountered and successfully addressed in traditional software development organizations. The article is intended as an inspirational starting point for applying best practices in your own projects.

Best Practices of Software Engineering

Software development is plagued with many serious problems. Complexity is increasing, time to market is decreasing and quality requirements are skyrocketing. This puts great strains on the software developing organization and the people therein. It is no longer possible to work harder; we must work smarter.

Best practices of software engineering are commonly observed, commercially proven approaches to successful software development. Developers that wish to compete on the bleeding edge of software technology should adapt these practices to the specifics of their own organization and projects.

Game Development

The most complex part of any computer game is the software behind it. The software needs to incorporate gameplay mechanics, artificial intelligence algorithms, network protocols, real-time physics simulations, decompression and playback of music, filtering and mixing of sounds, 3d visualization and more. In addition to all of this, multiple platforms must often be supported. The software must also be packaged with huge amounts of data in the form of textures, models, animations, sounds, scripts etc. to create something fun and entertaining; an elusive mix of technology and art.

Considering all of this, it is not surprising that many games are released with poor quality, often requiring fixes in the form of software and/or content patches from day one. All of these complexities cause games to exceed their budgets and miss time to market by not days, but months and years. As a result, many game developers are fighting a losing battle to survive.

We maintain that a large number of these problems are the very same problems "traditional" software developers have faced and conquered by implementing best practices in their organizations.

Best Practices in Game Development

Iterative development

Developing iteratively can be viewed conceptually as splitting up the development of the software into several miniature projects, called iterations. Central to this style of development is that each iteration continuously delivers a working executable that allows for proper assessment of current project quality and progress.

Each iteration is a micro version of the project as a whole, with each area of the final product represented at some level of abstraction, and as iterations progress, the quality of each aspect of the product increases. Each iteration incorporates the natural flow of working with requirements through analysis, design, implementation, test and final delivery of the product, as working software is the product of each and every iteration.

This flow repeats not only on a per-iteration basis but also on a project basis; the focus of the earliest iterations being more towards nailing down the fun of the game, often working in conjunction with focus groups and requirements, while later iterations focus more on detailing features of the product. This workflow can also be found on a daily basis, with a single developer's day starting with the acceptance of a task, investigation of the requirements of the task, perhaps doing some small analysis/design sketches, moving on to implementation, and finally testing and integrating the feature into the product.

The key driver behind iterative development is to reduce as much risk as possible as early as possible. In game development a major risk is that the gameplay is simply not entertaining enough. Iterative development enables the developer to discover such fundamental problems early in the project instead of towards the end, as a working executable (albeit at a very high level of abstraction) is available as soon as the first iteration is completed. The developer is thus able to change the design or even abandon the project before a huge part of the budget is spent.

As mentioned, a central aspect of each iteration is that it should result in a stable, functional, testable software system that should be delivered to the end user. In game development this could mean delivering the product to key stakeholders and focus groups and/or to the actual end user (perhaps represented by focus groups). The output of one iteration becomes the input of the next, with the most critical flaws and/or missing features becoming the goals of the next iteration. This way the developer has a chance to re-evaluate and steer the project in the most appropriate direction once per iteration, reacting to real experiences from a real working system.

One key effect of this procedure is that the game design and the understanding of the game design evolve with the project. In essence there is no longer any need for a complete design document before starting the project; indeed, creating such a document would most definitely be a waste of resources since the elusive property of fun simply must be tested and tweaked using a working software product. It is our continuing experience that no game design document survives contact with actual implementation, and accepting this fact and acting accordingly is essential.

Iterative development also lets you decide when the game is "good enough". In essence this means that you can stop the project when you feel that the resources spent each iteration do not yield sufficient return. The software is always "complete" at any particular time in development. This property of iterative development is very interesting and leads to the important realization that there is no point in worrying about unknowns in the project, you simply do the best you can to improve the game based on the state it is in today.

It is very common for projects to be completely unproductive and paralyzed by analysis if they start worrying over speculative possible future problems and issues. Worrying about problems that in 90% of the case actually never happen is a waste of resources when what you really need to do is solve the 10% that actually do occur. You deal with concrete problems that actually exist, not with abstract problems that might occur.

Another key benefit of working iteratively is team motivation. Always having a product that steadily evolves and moves in the right direction is very important. The opposite -- working months or even years without seeing any progress -- is a certain project killer.

Iterative development is also the basis of many other best practices, making it probably the most important practice to understand, implement and refine.

Article Start Page 1 of 5 Next

Related Jobs

Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Programmer
Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Artist/Designer — Hunt Valley, Maryland, United States

Lead UI Engineer — Chicago, Illinois, United States

Lead UI Engineer


Bryan Suchenski
profile image
These strike me as good things for non-programmers to be aware of, as well. Even those who prefer traditional methods, or like their design documents, need to recognize the potential pitfalls of their methods.

Anyway, good read.

Lance Rund
profile image
This addresses a pet peeve I've had for a while. Brace for incoming rant...

The game development industry has much to teach the "general" software industry, particularly with regard to managing multiple pipelines of dependencies (i.e. art and media assets). There seems to be a widespread viewpoint, though, that the "general" software industry has little to teach the game development industry. To paraphrase unflatteringly, but in a manner I have heard often, "people who haven't developed games don't know jack". What hubris! People with 20 years' experience developing non-gaming software are told they need to go get an entry-level game test position because they don't have anything to offer otherwise.

I beg to differ.

Many of the problems plaguing the game development industry have long-since been solved, but there seems to be an insistence upon a "not invented here" attitude. Not only does this doom many people to the task of reinventing the wheel (or having their wheel-invention shop fold because they can't ship a product on-time and within budget), it also alienates potential allies, angel capital sources, and people who can make a game developer's life easier. I've heard excuses about "game development isn't respected by the general software industry, so we're gonna do the same thing right back!" Again, what hubris. That kind of behavior pretty much guarantees that the general software industry will continue to (wrongfully) look down its nose at game developers... "after all, look at how game developers behave, standoffish, passive-aggressive, immature..."

We've seen column after column written about game developers (particularly programmers and QA) getting fed up with getting paid half of what the general software industry pays, being told that 60-hour weeks are normal and 100-hour weeks are acceptable, and being doomed to beaten-up offices in rusty industrial parks with 5-year-old computers. They leave the industry, but they are also leaving their dreams behind.

It doesn't have to be that way. And being open to changing "the gaming way" to leverage all the experience that the general software industry has accumulated, all the lessons the general software industry has learned, and all of the research into development techniques which the general software industry has spent billions of dollars upon and are willing to share FOR FREE. When game development and test techniques more closely match the rest of the software industry, so too will the working conditions (remember what a 40-hour workweek felt like?), and the pay will come up too as people become able to move back and forth between games and general software.

But it won't happen as long as the game development industry insists upon ghettoizing itself. Believe me, there's nothing noble about 100 hours a week at 10 bucks per hour. The only "prize" you get is poor health, a nervous breakdown, and bitterness towards a career you THOUGHT you'd love. That's one set of "achievements" we can all do without.

Rant over, you can come out now...

Jose Ortiz
profile image
Good article. I have to agree with Lance though. The major points of the article are things that for the most part have been in use in general software engineering for a long time. Most game developers/programmers tend to shun peers in the general software development community as if what they do is special. I know this first hand from trying to get into the game industry after spending 7+ years developing software for another industry. The same principles apply. Maybe this is one of the reasons the game industry has problems with quality of life and high turnover rates. Why work extremely long hours and earn a substandard pay when other fields pay more and have better hours? Only for the satisfaction of doing what you really love to do… sometimes that is not enough.

Jonathan Hartley
profile image
Good article, much needed. +1 what Lance said. I've seen seasoned game industry pros speak in meetings with non-game software developers, and alienate everyone by spouting silliness like 'writing specs for games is not straighforward and trivial like it is for non-games, because you can't quantify fun'.

Game programming does contain some thorny problems, which people have been iterating on for a while now, and have developed some very intelligent and advanced solutions to. This is true for many other fields of computer science. Gaming is not special. The sooner game developers get this into their heads, the sooner they will start listening and will catch up with the techniques everyone else has been using for years.

No wonder all those projects are on deathmarch. It's not because gaming is hard, it's because you're doing it wrong.

Elliot Green
profile image
Software is a design in progress as long as it is being used. The vast majority of the work on a program is done after it is released. Software obviously should not have changing requirements that waste what was already done, but it is ridiculous to think that somthing that is on paper will be perfectly copied into the real world.

The Brooklyn Bridge has one pillar which is not lying on bed rock, which was supposed to lie on bedrock like the other pillar. Because workers were getting nitrogen buildup, digging was terminated. It is still standing today.

Change is the only constant.

Frank Forrestall
profile image
This.... was incredibly informative!

I've been looking for just this kind of information since I started in games. I believe that GOOD project management is about creatively breaking down macro tasks into manageable micro tasks along their natural fault lines. This gives some clear indication of where to find those lines.

Many thanks!

Raymond Grier
profile image
I myself am using an iterative process, developing the documentation as I develope each iteration of my project and I find it works for me. Good article.

Ruthaniel van-den-Naar
profile image
One question.

How tools you use for automatic testing?

Tobias Olsson
profile image
Hey, thanks for the positive comments guys! I would have answered here sooner but I had some account problems :P

Ruthan van den Naar: Personally I simply make test cases in C++. It's much up to what tech you use how much support you can get in this area. The article roughly outlines some ideas to make your project more testable (both from an automatic and a manual standpoint) and you need to find what works for you and your team. Having some really professional testers to help guide you in this area is essential, sadly testing is most often overlooked.

I hope to be able to write more articles expanding and going deeper in some interesting areas. You can also follow the discussions in the forums at

Stephen Chow
profile image
It seems Agile, SCURM methodology can absolutly fit your requirement. I think you alreday used it well.

Monthly plan backlogs based on team velocity.

Empower the team to pursue the weekly or monthly goal.

Manage change in backlogs...........................