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 12, 2021
arrowPress Releases
June 12, 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 3 of 5 Next
 

Manage Change

Change is inevitable due to a number of factors. Due to the ambiguity of requirements vs. the specifics of defining code it is very hard to deliver the perfect match to customer expectations in the first attempt (iteration). This leads to changes in the requirements, hopefully making them more concise and specific, and as a result the software must also change.

"...you can't stop the change, Anakin..."

However, change is natural, and should not be viewed with fear. The very point of software is indeed for it to remain "soft" (as opposed to the "hardness" of hardware) and thus enable modification. Being a game developer who is able to change your software as requirements change is a good sign; you have software that is resilient to change, you listen to the customer and the customer is committed to the project. Change should in many respects be embraced.

Software and Change

Studying software engineering at Blekinge Institute of Technology in the 1990s, we were taught that software was an engineering discipline, much like planning and constructing buildings. A big part of that was about finding the requirements, analyzing and understanding the problem, designing an optimal solution and finally actually implementing and testing.

After becoming involved in Massive Entertainment, we found that a lot of the things they taught us in school were of limited applicability. This wasn't something that we came to realize quickly or painlessly; indeed we tried our very hardest to apply all the nifty "architectural and design pattern stuff" that we had learned in school to the game we were creating (the first Ground Control).

As the years went by it became more and more obvious that the central concept of planning software systems flew very much in the face of our everyday realities at work, mostly due to the fact that there was no way to factor in the reality of constantly changing requirements.

For a long time we (the programmers) felt that the fault was that of the game designers. "They haven't done their job!" we would say, "They don't think things through!" Occasionally this was true, but for the most part we slowly came to realize that we, the programmers, were building artificial limitations into our software.

This was shocking, because we figured that our superior Swedish software engineering skills had allowed us to rise above and create systems that were truly adaptable and in essence "future-proof". In a way we had all come to think of this as the whole point of being "Object Oriented"; we were big on "systems", we were big on "engines".

The limitations were based on our assumptions about how the software was supposed to function. This was in turn based on early drafts of the game design and on the requirements we extracted from the same. However, it became obvious that no matter how much we prepared our shiny software "systems" for change (that we knew would be coming), no matter how much abstraction we introduced to be able to handle "holes" in the game design, we always came up short.

The Day Things "Changed" in The Trenches (pun intended)

One day in the latter stages of Ground Control II: Operation Exodus the lead programmer -- that's me, Johannes -- simply gave up on the old learning. The day-to-day situation at the office was such that requirements could change so quickly, the focus of the next big push could change almost daily, that we were gaining nothing by trying to adhere to an old plan and to anticipate where the software was going to go.

I didn't abandon my thoughts on what was good code on a small scale, and I don't think I totally abandoned the high-level architecture of the software either, but I know that I in general stopped trying to force earlier software designs to fit the changing requirements. It became OK to throw out code. It became OK to change interfaces that had been fixed for a long time.

In short order, a matter of days, something very wonderful happened. I started having more fun in my work, despite severe crunch-mode. The "pain" of having the game designers mess with my "software system" was quickly replaced with a joyful feeling of coding stuff that was "useful" and "to the point". I experienced a great resurgence of the sheer fun of programming, and I think that is very much due to me consciously letting go of my need to control the design of the software.

Instead of trying to be "future-proof", I could simply admit that I didn't and couldn't know everything beforehand, and let myself discover the way the software "wanted to be" in the same instant I coded it. Even more surprisingly and rewardingly, I started producing better code. It was smaller, it was more to the point, and it was even more optimized.

From that time onward, my approach to software engineering and to game development has changed in a fundamental way. I basically stopped trying so hard to anticipate the future, because I had learned that if something comes up that requires a change to the fundamental assumptions of the software I am writing, I am confident in my capability to be able to change that assumption. The result is code that is in better sync with the actual problem that I am trying to solve. And we all know that in the field of game development that problem is apt to change all the time.

In hindsight this is not so surprising. Not if you are prepared to remember one of the main points of software: it is supposed to be soft. We had been treating an early technical architecture as something that was fixed (i.e. hard) when we should have been taking advantage of the very core aspect of software as opposed to hardware: you are supposed to be able to change it easily.


Article Start Previous Page 3 of 5 Next

Related Jobs

Disbelief
Disbelief — Cambridge, Massachusetts, United States
[06.11.21]

Programmer
Disbelief
Disbelief — Cambridge, Massachusetts, United States
[06.11.21]

Senior Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States
[06.11.21]

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

Technical Artist - Pipeline





Loading Comments

loader image