Slashdot Mirror
Game Architecture and Design
A Good Game Book
Authors Andrew Rollings and Dave Morris have penned something truly rare: a good book on game development. This is the first one I have seen that I felt served the topic well.
To be sure, this is most definitely not a book on coding. Rather, it is a book on game design, architecture, process, and the industry.
Overview
The book is divided into four main parts. The first covers game design, taking you from the germ of an idea to the description of a product ready to be developed. The second discusses the formal process that will provide the proper environment for this to happen effectively. The third covers the architecture, where everything fits together. The final part, the appendices, provides detailed sample documents which the reader is invited to study.
There are case studies throughout, some of which are real, and others imaginary but illustrative. The first three parts each end with a discussion of the future of that topic, as predicted by the authors. Only time will tell if they are correct, but their views are interesting to read nonetheless.
Game Design
This was my favorite part of the book. The authors focus not just on computer games, but on software entertainment as a more general concept. To that end, they discuss such diverse influences as Aristotle's elements of drama and provide analogies with films and literature.
However, the main focus is on games, and I particularly enjoyed the applications of math and game theory to gameplay and balance. A nice touch was the discussion of emergence as it applies to the interaction of game rules.
Team Building and Management
This next part is a mini-process book embedded in a game book. This puts us on holy ground, and while I don't agree with every point the authors raise, they are for the most part on the right track. If you've read any of the gurus, you won't be surprised here. They correctly assert that the game development industry lags behind the rest of the software development industry on these points.
Game Architecture
By far, this is the largest part of the book. Although the focus is not on coding, it is here where the technical detail abounds. There are plenty of class and object diagrams, state machines, and even the odd illustrative code fragment.
There is a nice discussion of design patterns; the authors apply half of the Gang of Four patterns to game architecture. This ties in nicely with the soft architectures that are becoming more prevalent in today's games. They discuss topics as diverse as localization for foreign markets, deploying patches, and properly conducting the postmortem after a project is completed.
Appendices
The first appendix contains a collection of sample game design documents. The first is a working architecture for a project. Next are two game treatments. The fourth is a technical specification. Finally, there is a code review form and a test script.
I found these documents interesting. My main complaint is that they are all lumped together without organization. The appendix needs to be broken down. The second appendix is nicely annotated, but has an incorrect attribution.
Caveats
Notwithstanding the publisher's "to the reader" message of quality, there are some glitches, typos, and occasional errors. The authors sometimes ramble, making a section too long, but that may be a side effect of having two authors.
The diagrams are not UML, but rather modified OMT and home-brewed notation. The authors recommend learning modified OMT as they believe it is the de facto industry standard, which is no longer the case.
The CDROM contains some sample/demo software for Windows and Macintosh. It includes Python, which is nothing new for Linux users, who are left in the cold using the CDROM. The authors seem to have a love/hate relationship with Microsoft throughout the book. There's no significant mention of Linux or open source game development, not even in the future ponderings.
The book is huge, and my copy already has a cracked spine.
Summary
This book does have warts, but all in all I think it was executed rather well, given its ambition. For a game book, I give it 8/10. Make it 7/10 when compared to other technical books.
Your interests may vary, but I'd recommend this book if you are interested in game development. I think it's worth the time and effort.
Pick this book up at ThinkGeek.
Table of Contents
Part I: Game Design
1. First Concept
2. Core Design
3. Gameplay
4. Detailed Design
5. Game Balance
6. Look and Feel
7. Wrapping Up
8. The Future of Game Design
Part II: Team Building and Management
9. Current Methods of Team Management
10. Roles and Divisions
11. The Software Factory
12. Milestones and Deadlines
13. Procedures and "Process"
14. Troubleshooting
15. The Future of the Industry
Part III: Game Architecture
16. Current Development Methods
17. Initial Design
18. Use of Technology
19. Building Blocks
20. Initial Architecture Design
21. Development
22. The Run-Up to Release
23. Postmortem
24. The Future of Game Development
Part IV: Appendixes
Appendix A: Sample Game Design Documents
Appendix B: Bibliography and References
Glossary
Index
making a game by yourself isnt that insane of a task... Most of the incredibly good, older classic games were designed and implemented by very few, sometimes just one, people.
IMHO, I think that since the game market has been turned into a corporate cash cow, the quality, in depth-ness and "experience" have all declined.
Yes, the audio-visual experience is more impressive, but the content is horrible... I cant remember the last new game that I coule get so involved in the characters and storylines that I fogot about the "real" world.
I mean, the classics - wasteland, bard's tale, Ultima III, IV, V were total immersion experiences.
Sigh... I long for the "good ole days" of games that made you use your brain instead of reflexes...
I also long fo rthe day when dying in an RPG was a really horrible thing...
oh well... let me get off this soapbox...
... hi bingo
Well, you can write the core engine in C++ for speed purposes and then use Python to wrap this code. Then you can use Python to do prototyping for the rules and game mechanics - rather than having to rebuild the whole project each time, just change the code and rerun it. Saves a lot of time. Once you have finalised the game mechanics you can then choose to code then in C++ if you want to.
Alternatively you can actually embed the Python interpreter within C++ code and use it to write custom scripts and/or extension modules using the wrapped game objects. Kind of like QuakeC IIRC. Or for a game like Civ you could write custom macros to do tasks you do regularly such as changing build orders in response to attacks.
The skills to write a game are pretty much the standard software engineering skills. Games are getting more complex, but technology is getting faster, and balancing the two is half the battle in making a great game. Look at Carmack's history: DOOM and Quake had scan-line renderers which he hand-tuned in assembler, but QIII just throws polygons to the 3D card (and it's corresponding hand-tuned driver). So instead of spending time getting a poly on the screen he spends the time figuring out how to make it look cool. Figuring out where to spend your time is an engineering call, and it's the same if you're writing a database or a first-person shooter.
Of course, if all the games out there were things people put together in a few hours after dinner, we wouldn't be paying $40 for them. They take a long time and lots of hard work, and so if you're going to revolutionize the industry you're going to need some financial backing so you can work full time on it for at least a year. And even Carmack doesn't code alone, and he's got a ton of artists helping out too. So you're not going to revolutionize the industry by yourself, but there's no reason you can't provide the vision to revolutionize it with a team.
JB
GollyGee Blocks -- 3D creativity software for kids.
One (or two) people CAN write decent games. "Elite", possibly the best game ever written, took only two people to write. Mind you, it took brilliance and a lot of patience on the part of the writers, but it CAN BE DONE!
Another good game, not written by a large team, was Tetris. Yip! A "trivial" game, cranked out by a Russian who seems to have mixed the vodka with children's blocks.
The original Adventure Game, Colossal Cave, took the awe-inspiring mass of brains known only as Don Woods and Pete Crowther.
One of the most bizare 3D realistic-movement shoot-em-ups, Zarch, was jotted down by David Braben, on his own. It's a game playable only by very sick people with 7 arms and brains the size of a planet. On the other hand, it's a phenominal game, and worth twisting one's brains round.
I see the next generation of fresh ideas coming from small teams (one or two people), because they are the ones least likely to be locked into the "formula sells!" mentality, and open to new ideas.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
..sadly always seem to lag some way behind current technology and methods, as this one appears to.
Most of them don't appear to be very insightful, almost as though 'those who can't do, write a book'. I often feel you can learn far more about game design by looking at someone else's coding methods, for example in Quake now the code has been Open Sourced.
Is this book any different ?
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
The authors focus not just on computer games, but on software entertainment as a more general concept. To that end, they discuss such diverse influences as Aristotle's elements of drama and provide analogies with films and literature.
This is the sort of thing which the game industry needs more of. I've lost count of the number of games which use predictable, tired storylines, or in which the storyline is totally unrelated to the game. A game with a great storyline in which your actions directly tie into this is extremely engrossing and keeps you coming back for more.
Of course this doesn't apply to all games. I doubt whether pure combat games would benefit from a finely wrought storyline :)
However, the main focus is on games, and I particularly enjoyed the applications of math and game theory to gameplay and balance. A nice touch was the discussion of emergence as it applies to the interaction of game rules.
Again, this is a good thing. The game engine requires a balance amongst its elements otherwise it's no fun to play. If one element of the game makes it rediculously easy to win then this spoils any kind of long-term enjoyment you could get out of it. Games should be extensively playtested before release to make sure this sort of thing it correct. And the programmers having a few quick goes before release doesn't count, unfortunately for some games companies.