Sponsored By

Feature: 'Planning For Fun In Game Programming - Part 1'

There is often talk about how to find the fun in design, but in programming it is less frequent. In <a href="http://www.gamasutra.com/view/feature/4031/planning_for_fun_in_game_.php">a new Gamasutra feature</a>, Tom Hammersley attempts to set things right

May 20, 2009

2 Min Read
Game Developer logo in a gray background | Game Developer

Author: by Staff

There is often talk of how to "find the fun" in game development from the design angle, but there tends to be less discussion as to programmers' roles and responsibilities in that area. In a new Gamasutra feature, programmer Tom Hammersley explains "Planning for Fun in Game Programming." One of the main issues, Hammersley says, is that developers frequently assume that when innovative or unusual concepts are designed for a game, it becomes more difficult to assign requirements to them -- but he argues that while it may not be possible to spell out the solution ahead of time, requirements can be easily set: "In games engineering we seek to push the boundaries of what is currently possible on our target platforms. We strive to build bigger and more complex worlds and introduce new ideas and concepts to a genre. "To build these kinds of games and features, we often employ new or novel implementation techniques. Consequently, these techniques are not fully understood. It is tempting to conclude that if we do not understand how a solution works, we cannot develop requirements for it. "However paradoxical as it may sound, we can still fully specify requirements for these solutions. Whilst we may not fully understand the novel solution we are implementing, or even know what solution we may choose, we can still specify what that solution should be able to do, and what properties it should have. "What we may not be able to do is describe in detail how this novel solution may work. But that would not be appropriate; we would be describing a specific solution, rather than the requirements for the solution. Our goal is to describe what functionality we need to build, and what that functionality should achieve, not how." Furthermore, Hammersley delves into the frequent confusion between requirements and solutions, the perceived differences (and actual similarities) between game development and other software development, the difference between functional and non-functional requirements, and more. The full feature article is now available to read.

Read more about:

2009
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like