Game Development Reference
In-Depth Information
At some point, designing the game became a separate job. Game mechanics were tuned to the interests of user groups
and were more and more based on principles from psychology and educational sciences. This required separate
expertise. Stories assumed a crucial role, leading to the inclusion of writers. And the teams were extended to include
producers, sound engineers, composers, and many other types of people. Today, teams for top games can consist of
hundreds of people. But without the programmers, nothing would work.
A Few Final Notes
In this part of the topic, you've created a game that is quite a bit more complicated than the previous
example game, Jewel Jam. You've probably noticed that the number of classes has become quite
large, and you're relying more and more on a certain design for the game software. For example,
you're organizing game objects in a tree structure and using a class to handle game states. On a
more basic level, you assume that game objects are responsible for handling their input, updating
themselves, and drawing themselves on the screen. You may not agree with some (or all) of these
design choices. Perhaps, after reading the topic to this point, you've formed your own ideas about
how game software should be designed. That is a good thing. The design I propose in this topic isn't
the only way to do things. Designs can always be evaluated and improved, or even thrown away and
replaced by something entirely different. So, don't hesitate to look critically at the design I propose
and try other designs. By trying different approaches to solve a problem, you can better understand
the problem and become a better software developer as a result.
What You Have Learned
In this chapter, you have learned:
How to group classes into a namespace
How to reset a level to its initial state and handle going to the next level
Search WWH ::
Custom Search