As software engineers, we would all like it if requirements never changed. We want to be told up front exactly what features the software must support and then we can build and deliver it.
Unfortunately, requirements change—always. This is a fact of life. More importantly, if the requirements don’t change, you have a real problem. No designer (sorry guys) can know up front exactly what it takes to make a game fun. It is a process of exploration. So instead of being frustrated by change we need to take responsibility to work with the designers to make sure we have the best possible requirements.
What does best mean in this context? Are the best requirements the ones that will change the least? No. In my previous blog (The Importance of Convergent Iteration) I talked about how iterative development processes should work. In line with that thinking, the best requirements are those that allow the team to converge in the fewest iterations. Another way to say this would be the ones that allow the designers to find fun the fastest.
In order to find this set of requirements, you need to answer a list of questions.
1) What purpose does the system serve?
It is easier to deal with internal systems, so let’s assume the system in question is player facing. How does the player interact with it? What does it do for the player’s game experience? By answering this question you get a good idea about what problem the designer is trying to solve. Knowing this can help you know what priority you should give to various features. It also helps you determine when you are finished.
2) What are likely changes and extensions to the system?
How will the system scale with player level? What other things might the system have to do? For instance, say you are building a spell system and the designer has asked for a spell that does direct damage. How will the system scale? Well, probably it will do more damage. It may cost more energy (or less). It may have an increased casting time. What about other capabilities? Maybe damage over time. Perhaps healing, or stunning, etc. Answering these questions gives you a framework for the overall technical design of the system. The system needs to have a design that is flexible and scalable enough to handle the likely extensions.
A good object-oriented design is one that accepts change without requiring refactoring. Combining this information with the answer to question 1 will help determine your iteration plan, that is, what constitutes the core system and in what order will additional features be added.
3) Which areas of the system are the riskiest in terms of fun?
These areas will need to be iterated on the most and are also likely to change. This means they must be designed for change and built first so they can be tested early and often.
With the answers to these questions you are in a position to design a good system and then to build an iteration plan that will deliver a solid framework followed by successively more features, and to do it in the order that will allow the most meaningful feedback from the designers as they test the system.
- Robert Marsa
April 2nd, 2008 at 10:15 am
[…] of every item in the game. The bulk of this document is a short and sweet bullet-point outline of the system requirements – and most of that is a list of the data we need to define for each bit of […]
April 23rd, 2008 at 2:08 am
Being a programmer, I can relate to this article! My boss is constantly asking for changes, and if I don’t plan ahead for these things, it makes my work a living hell. I’m sure the same thing happens to you guys all the time, and I just wanna say I feel your pain. But the worst thing a programmer can do is say, “no I can’t do that” or “that’s too complicated” because they are just limiting themselves. I think half the fun of programming is overcoming the challenge of doing something incredibly complex, but the end user is totally unaware of just how complex it actually is. Most of the time, your boss or the lead designer doesn’t have a clue about how challenging a programming task is, but they know (and you know) it needs to be done for the greater good of the project.
Anyways, I am totally looking forward to this game, and I’m reading through your blogs and responding cause rarely do players get to interact with the developers.
June 5th, 2008 at 1:39 pm
I agree with Kallen, I’ve never seen a game where you can communicate with the devs so early in the process. Though I think this is the first game I have known about so early in the process. It’s really neat to see what goes into game development. I hope you guys get a community board going soon. If there already is one, could you direct me to it?