 |
|
|
| |
Feature: Planning For Fun In Game Programming - Part 2
by Staff [PC, Console/PC]
|
|
| |
|
June 24, 2009
|
| |
How do you legislate for fun from a game planning and programming perspective? Following on from his analysis of the problem, veteran game coder Tom Hammersley proposes a solution that includes 'apprenticing', use cases, storyboards, and more.
In a new Gamasutra feature, Hammersley goes in great depth about "requirements engineering", and its importance in creating a solid foundation for game:
"Requirements engineering is the practice of determining what functionality and qualities or properties the game we are building needs to make it a success. Requirements engineering produces a comprehensive specification describing the game we need to build, why those features and qualities matter, and how to test the resulting game against that specification.
Perhaps unintuitively, this specification is not a design for the game; it specifies the problems we need to solve, the functionality we must have and the characteristics the game must have but not any prescribed solutions or implementations. The requirements specification represents a shared consensus and understanding of the game we are building; it communicates a common vision to the developers free of the restraint of specific technologies.
The individual requirements in the specification are statements of either functionality the game must have, or characteristics of how that functionality works. These types of requirements are known as functional and nonfunctional requirements respectively.
Ultimately, these requirements all come from stakeholders on the project. These stakeholders could be people such as artists, requiring functionality from the game to realize their vision, or designers, who have the creative vision of how the whole game will fit together.
These requirements are subsequently used in a number of ways:
- As a guide to implementation
- To estimate and schedule the work needed to complete the project
- To ensure the resulting implementation satisfies the goals of the requirement."
You can now read Hammersley's full feature at Gamasutra, where he explains the basic components of a requirement, requirements engineering practices and other topics (no registration required, please feel free to link to this feature from other websites).
|
| |
|
|
For example, you could have a major feature change in the polish phase that would result in certain things not getting as much polish. However, that was an acceptable consequence when the feature change was decided on.
Planning up front is helpful for making best guess estimates, but it's always ballpark. Trying to lock that schedule down is pointless and ridiculous. I favor a potentially constantly changing list of priorities with an understanding of the costs of change.