Game Architecture and Design 114
| Game Architecture and Design | |
| author | Andrew Rollings and Dave Morris |
| pages | 742 |
| publisher | Coriolis |
| rating | 7.5/10 |
| reviewer | SEGV |
| ISBN | 1-57610-425-7 |
| summary | A rather good game development book. |
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
Unhealable deep cut discount here (Score:1)
Re:Amen to that! (Score:1)
Unfortunately, in the days of Elite (and also Zarch/Virus, to an extent), putting out a game with wireframe/flat-shaded graphics was acceptable. The gameplay on its own justified the release, simply because you didn't need an armada of artists to provide Joe Public with eye candy before a game could be released.
At the time, wireframe grahics were so far ahead of the curve on a home/desktop class system of the time, it is hard to draw a comparison to a recent game release - most of the "revolutionary" steps in recent games are evolutionary. The graphics in Elite were stunning to most people, and constitued eye candy.
Admittedly, there were no elaborate cutscenes of movie-level quality. OTOH, I'd question where those are necessary for a game to succeed.
Re: Then ask him (Score:1)
The book is about game design and architecture (and also process). Not coding. I don't believe coding is the most important component in a game. I agree with you.
I'm only saying if Carmack's opinion is sought, then Carmack's the guy to ask. I can offer only my own opinion, which I did.
--
Re: Then ask him (Score:1)
They point out in the book that most game architectures are the same (even if the games themselves are wildly different). I've looked at the Quake engine, it's not that complicated. All the complexity is in the software renderer and the network code, from what I can tell.
I suspect most people don't need a book of Carmack's level, because they aren't writing games at that level. A corollary is that even if you aren't writing 3D/networking at Quake's level, you can still use its architecture for a simpler game.
--
I didn't agree with everything either... (Score:1)
Nonetheless, having a process, even one you don't agree with, is good. It makes things repeatable and scientific. It's one thing to have a hit game, and another to be able to crank out hit after hit, pleasing customers and shareholders. Not burning out employees.
I'm not a developer, but like yourself I've worked on large development projects, in my case in business applications and data mining. It's the same there. If we didn't have a process, we might get lucky and ship a good app, but the next revision would fail. I've seen such failure happen, and I've seen success with process. I prefer the latter.
The book isn't the be-all-and-end-all of game books. I believe that one has yet to be written. But it's a start.
--
Re:Liasing with the industry? (Slightly OT) (Score:1)
Capitalizing on youth dreams? (Score:1)
I did learn plenty of useful stuff from it, but...
--
Re:Making a game by yourself? (Score:1)
Re:Not only fun - but a lot of hard work (Score:1)
the hope of maybe someday getting a game together. It started of in good old Pascal and x86 asm on Turbo Pascal and Is now several thousand lines of C openGL code ( all my hand optimised inner loops in the asm gouraud shader gone for ever
Now i'm at the point where I need a good 3d modeller - Tried loads available for Linux and they didnt suit my needs so I've started writing one.
I'm glad I'm doing this for fun and I dont have a deadline. If you'd have asked me in 96 when I'd have something finished I'd probably have guessed at a year
will have the feature set I require
So my advice is - Go for it - But above all dont set yourself deadlines - Just have fun and learn something new.
Re:Making a game by yourself? (Score:1)
I also long fo rthe day when dying in an RPG was a really horrible thing...
"
At least you have d2 to look forward to (with the hardcore permanent death option).
Re:The Futility of Game Development (Score:1)
Back then it was about cool new software and hardware. That started to change to "business" only stores. I haven't been in a computer store in years because of it.
Makes me sad.
Oh, I still go to Best Buy and places like that.
Re:Game design (Score:1)
But I do see your point about gameplay. If the gameplay is lousy, it doesn't matter how great the story line is, because it'll be more frustrating than entertaining.
The conclusion I think we need to draw is this. There is a tradeoff problem here. If the story line lacks too much, the player will get disinterested in the game too quickly, and the game won't be as popular, because the users won't be addicted for long. But if the playablity lacks too much, the user will simply get frustrated with the game and tell his friends. I think there really needs to be a balance in computer game design.
Re:Writing Games (Score:1)
'gone are the days when two guys in a basement can make a good game. now you have to have a programmer, a modeler, a skinner, an animator, someone to handle business, and a webmaster, and a game designer.'
all of those become fulltime jobs. so like. basically, in reply to what you said:'no'.
Re:The Futility of Game Development (Score:1)
Actually, I was in CompUSA (the big computer store around here) and they had Playstation games, which surprised me. I honestly think that the shelf space could be better used for Pc games, since you can get Playstation games anywhere (like Walmart, blockbuster, etc.) but in a store that is primarily computer products I don't really consider that they fit.
Of course, this goes back to the days when the primary place to go in a mall to get video games was stores like Software, Etc. However, these days the gaming market has expanded incredibly.
I'm tempted to respond to the Troll (parent of this thread, Rev. Null), so I will. Of course games are a huge moneymaking business themselves, and the business of business is to make money. I mean, honestly I haven't needed a new wordprocessor since I bought Lotus WordPro '96, and I'm not really expecting to ever. What's the new wordprocessor going to have that's so great? New and better ways to pass viruses around? Memory hogging cute graphical Paperclip Guys? In my opinion the only thing that continues to sell new wordprocessing software is planned obsolescence. I don't know much about spreadsheets or accounting software (seems to me spreadsheets are accounting software), but I mean if everything is E-commerce right now, doesn't that mean that companies need something to sell? Aren't games something?
Oh well, not a bad troll, if Calvin Coolidge had risen from the grave, I imagine that's what he'd write.
Re:Middleware, was Re:Game programming/ design... (Score:1)
Umm, no. Half-life? StarCraft? I don't need to give further counter-examples. As you point out, gameplay and balance are the things that really build a game. Technology that 'knocks their socks off' is all well and good, but it is secondary. I would love to spend the time and money to research fantastic new technology, but it's not necessarily on the critical path to shipping a great game.
Middleware, was Re:Game programming/ design... (Score:1)
Definitely. One of the key arguments in this book is that research has no place in the critical path of game development. If you don't have existing in-house technology, and established middleware will meet your requirement, it's probably a good option - especially as most of the licenses are pretty reasonable in the scale of commercial development. Well-tested code and robust, useable tools are very helpful.
Unfortunately, the choices are limited and tend to the same architecture, e.g. BSPs. We'd love to use middleware on our project, but it becomes less attractive when you need to adapt either the design or the middleware code to fit. Besides, if we just did a bit of research...
Daniel, hiring good engineers, no games exp. necessary
Re:Game design (Score:1)
Actually, yes, I think they would. Take, for instance, Mortal Kombat, which was as pure a combat game as you get. Sure, there is no storyline per se, but there's the whole concept of background storylines and character developments. Perhaps it didn't change much of the game, but it sure brought a nice atmosphere to the game which, I believe, was part of MK's success.
For instance, Goro (was that his name?) came across as a perfect "boss" fighter, with its impressive look and multiple arms. That's characterisation any way you look at it, and that is what I consider to be a 'fighting game storyline'.
I agree with you totally when you say many games would benefit from having a killer storyline. I think, furthermore, that ALL games could benefit from clever and original writing, whatever the genre, and regardless of the quality of the FX.
No Disrespect to the Reviewer... (Score:1)
buy it at elgrande (Score:1)
its the cheapest online book source i've found
http://www.elgrande.com [elgrande.com]
they have this book for $28.49!
not to diss on ThinkGeek, but their price is $17 more...
Re:Making a game by yourself? (Score:1)
Q3 does NOT just throw polygons to a 3D card.
Visible Surface Determination is the hardest problem 3d graphics programmers currently have to face. We can't just shove 50,000 polys/frame to a 3d card and expect 120 fps.
"Maze" games have it a little easier as BSP and Portals work very well. For terrain rendering, heightfields, and Quad Trees work much better. i.e. Continuous LOD Terrain Meshing Using Adaptive Quadtrees [gamasutra.com]
> he [Carmack] spends the time figuring out how to make it look cool.
Once you have your rendering technology, thats the next step - adding all the eye candy.
I'm sure Corrine will jump in if she has anything to add
Cheers
Michael
3d games programmer
Re:Writing Games (Score:1)
You might want to take a look at Majesty [cyberlore.com]
The genre is "Fantasy Sim" which in this case means a cross between a RTS and a RPG.
Cheers
Making a game by yourself? (Score:1)
How do you really get all the skills necessary to do this?
Re:Making a game by yourself? (Score:1)
Seriously making a game is a very labor intensive process
Well, so is coding just about anything. Yet a lot of volunteer open source work gets done. One example of this is the FreeCiv Project [freeciv.org] which came up with a rather interesting GPL'd clone of Civilization II.
As for one person revolutionizing the gaming industry, that's not exactly something that happens every day, but still a possibility, but I think that it's more likely that it has to be a group effort.
-Valur
Re:That's why Linux is dead, too. (Score:1)
Esperandi
Everytime I upgrade my computer I think of getting Linux again and then i find out 90% of my peripherals won't work with it.
What's wrong with games today? :-) (Score:1)
This has got to be tongue-in-cheek flame bait. I can't believe anyone on /. would write this with a straight face. :-)
Ten years ago, home computers were relatively weak; business PCs were the 'big guns'. Over the last decade, that has reversed in a big way. (If it weren't for Y2K, there would still be plenty of major corporations using 486 systems.) Computer games have driven the constant churn for faster processors, more RAM, better 3D cards.
At the same time, competition in game design is driving bleeding-edge technology in graphics, simulation, world-modeling, and other nifty technologies. Budgets for commercial games have skyrocketed. One report I read claimed that the budget for Final Fantasy VII was $30M, and that the parent company considered Hollywood to be its competition.
The problem--speaking as a 'golden age' game designer (read: old fart who huffs and puffs a lot and remembers the 6502 page 0 map fondly)--is that the technical/artisitic barrier for new games is very, very high, so the market is captured by firms with loads of cash. It's hard to break through that.
I still get fan mail about my one published game (SunDog: Frozen Legacy, original Apple II version, released 1984), the gist of which is, "Most of the games today suck." That's unfair; I look at modern games in awe at the technology and sophistication behind them. But many of the ones I play do lack elegance or effectiveness in game design, attempting to cover their tracks with graphics, sound, and a zillion options.
I'm not sure what the solution is. Open source games sound interesting, but game design and development is far more intense, difficult, and uncertain than, say, writing a commercial word processor (speaking as someone who had done both). They both have to work--but the game has to be entertaining as well. ..bruce..
And Myst? (Score:1)
No Linux? No sale (Score:1)
date, which is an eternity in the game world. Along with looking
at others' code, you can also learn a lot about the latest
techniques from various web sites, starting with Gamasutra.
But all that aside, even if the book has some good information,
I just won't buy it if all the examples are for Windows. What
I'd like to see is a book on multiplatform game development,
using libraries like SDL and OpenGL.
Re:No Linux? No sale (Score:1)
architecture and design is choosing tools and libraries that
don't tie you into a single platform, since it may not be the only
place you want to be when your game is done 2-3 years
later.
Prices (Score:1)
Ouch $45 at thinkgeek. Methinks I'll buy it somewhere else. Here's a short price list. Fatbrain has it for $40, Amazon has it for $35, and bookpool.com has it for $31.
Re:Game design expert, engine idiot (Score:1)
Python? (Score:1)
--
Peace,
Lord Omlette
AOL IM: jeanlucpikachu
Re:The Futility of Game Development (Score:1)
Re:The Futility of Game Development (Score:1)
Re:Game programming/ design books... (Score:1)
Re:Game programming/ design books... (Score:1)
A point worth mentioning here is that Good Code Alone Does Not a Good Game Make.
As rude an awakening it may be to some die hard bit pushers, good games are derived from good stories, good art, good balances of tension and release, and good technology. Having a kick ass 3D renderer will make a good technology demo, but a lousy game. This holds true for movies as well. I'm sure we can all name a flick with good effects, but no plot, that left us feeling hollow.
Sadly, you can't just "code up" a good story yet. Perhaps when we can, all the software developers of the world will totally dominate the entertainment industry. Until then, I actually prefer the day to day diversity of talents and interests that I get to work with at my particular game development house.
-pjf
Re:Capitalizing on youth dreams? (Score:1)
There is a game somewhat like you describe. It's Escape Velocity [ambrosiasw.com] by Ambrosia Shareware. [ambrosiasw.com] It consists of an expandable map of planetary systems and several elaborate story lines that you can explore and visit as a trader. You can also pick up missions to fight pirates and become good, evil or neutral in different systems and to different alliances.
Systems and missions are simple to create and add on by fans and are available online at fan sites and an official repository.
Unfortunately it is only available for MacOS
A good story goes a long way (Score:1)
I must disagree. The obvious example is the game HALF-LIFE (which, if you enjoy fps games - you simply MUST try). This game uses the Quake II engine, but is a far better game - IMHO. The reason for this is a story line - which is executed brilliantly. They went so far as to hire a horror story author to write the story for them. The story is very good and since - through the game - you live it, you get an incredible sense of immersion.
They also did excellent work in having the gameplay balance be just right and consistent with the story. The resulting game is, again - incredible, and has justly won over 50 "best game of the year" awards. This is a lesson in game design, and yes - we want more games like this!
There is a lesson here: the Quake II engine was very good for its time and was capable of holding a (nearly) storyless game. This seemed very natural for a "story-less" genre like FPS. However, ONLY when a great story was put into the same engine did a truly great game come out.
Valve actually had an earlier design, which they threw away because it was too boring and regular. Only the second time they did it right. The entire story - which is very interesting, BTW - can be read at this link:
Valve's Cabal Process. [gamasutra.com]
I recommend this article for everyone with an interest in game design and even plain program design.
Re:Game design expert, engine idiot (Score:1)
http://crystal.linuxgames.com
have fun
Re:game dev: Not hard work - only fun (long) (Score:1)
I have the idea of an RPG flashing through my head since my school days (u could say i'm addicted to them
The Essence is, although u may be not able to finish ur project u can still get a lot of valuable experience and skill out of it which will allow u to advance in other areas as well. So keep coding and always remember the source is with u
the past and future of id and FPS (Score:1)
I was going to respond to spiralx's previous comment about gaming storyline, but I want to start a new thread. Here is a quote from his post.
If the game has enough "fun" value, a good storyline is not at all a necessity. Look at Quake. (As in Quake 1.) The "storyline" was really an afterthought. You all remember those little paragraphs between major level changes, right? I wouldn't be surprised if you didn't. I didn't, until I replayed it a few months ago. No offense to id or Carmack, because I love their games, but who wrote that crap? It sounded like the kind of thing some wannabe-goth 13 year old would write.
But look what happened: Quake is aruguably one of the most succesful games of all time.
Quake II greatly improved upon Quake by having an actual storyline, as well as having kick-ass action and an awesome graphics engine. But it pales in comparison to Half-Life in ambience and atmosphere, whose story was really cool, and it was blissfully woven in the gameplay itself. Half-Life has the shoot-em-up fun of Quake II and the storyline of a mediocre King book, which for me is the best I can get.
I think that Q3A will be id's last game of the series. They're no longer revolutionizing the industry. id invented deathmatch, and Q3A is the testament to its greatness, but there's no story in a deathmatch (well, they tried, but it's even less important than Quake's). And id is no longer has the monopoly on kick-ass deathmatch: UT is as fun as Q3A IMHO. Sure, I'd probably buy a Q3A add-on pack (like the QII mission packs) with more weapons and skins, but where do you go from there?
Personally I'd like to see Carmack try his hand at a Japanese-style RPG. Even though most of his work that we've seen so far has been based on action and not storyline (the heart of an RPG), and as much as I think he acts like an arrogant buttfucker, the man has some skillz. I'd like to see him put them to work in a different genre sometime in the future and see what happens.
But that's the future. For now, I'm happy with Q3A, UT, and Half-Life.
I am the Lord.
Game design expert, engine idiot (Score:1)
"Assume the worst about people, and you'll generally be correct"
Re:Management (Score:1)
His background is actually OS, but his book is written towards any sort of large computer project. I can't seem to find the book at the moment, but his back ground as I remember is 20 years with IBM and the like. Started out as a programer and moved on to manage software projects.
Cooperative alternative (Score:1)
So you and they can benefit by trying to hook up- You can get, uhh, well, less-than-expert programmers to show you their insights on source hackery, and they can get a better grasp of how to tackle the design aspect. And I'm not suggesting to completely remove yourself from the nutz&boltz, just to get the help you need, and in turn be helping someone out on what they feel could be their weakness.
I'll find out if my design spec is lacking once I see where my code is missing some functionality. :/
Re:Writing Games (Score:1)
Re:Making a game by yourself? (Score:1)
Re:Making a game by yourself? (Score:1)
Joe Public is not the Problem (Score:1)
Storyline vs. Gameplay (Score:1)
They talk about storylines and hooks for games in which they are relevant. They emphasise most that the game should be fun and rewarding to play.
However there are certain types of game where the storyline is very important - indeed discovering, influencing, experiencing it is the enjoyment of these games. These are thing like Adventures and story based RPGs.
The problem is the fact that game is a bit restrictive a term. In the book they make the case for the term (I think) Electronic Entertainment. Just calling it all games is a bit like lumping playing a sport in with reading a book, going to the opera, and hillwalking. They are all recreations but the essential elements that make them fun are very different.
I would argue that Doom and Quake (particularly multi-player) are like sports whereas RPGs and Adventures are more like an interactive book. Story is important only in some but gameplay is essential in all.
Re:Game programming/ design books... (Score:1)
The emphasis of the first section particularly is very much on gameplay, balance, and playability (the interface works with not against you).
The second section attempts to make an argument that at least some of the methods that are used in large projects would be useful in games development. They present a lot of these and I'll be the first to admit not being convinced by all of them. Some of them may be "crap" but a number of them are common sense and I am sure used in development houses like iD, Ensemble, and Black Isle.
They do emphasis that there will be problems trying to introduce these practices and recommend you cherry pick the ones that make sense to you. They emphasise that excessivly strict environments are just as bad (if not worse) than uncontrolled ones, and I don't remember them mentioning ISO9000 once.
I would recommend that anyone reading this book does not throw it down in disgust at the first suggestion that offends them but rather continue reading. There will be other ideas that are more palitable. Also I'm sure that any successful games house will recognise things they already do (and problems they have already had).
This book is littered with case studies and examples of both good and bad practices. In fact it can be amusing sometimes to play spot the game.
The techniques presented are meant to improve the chances of repeatably producing good games, and allow the shipping of stable playable programs. Can this really be something the computer games industry wants to avoid?
Re:Middleware, was Re:Game programming/ design... (Score:1)
If you didn't know how you were going to make a fun game then there has to be the question of why you built the technology in the first place. Everything has to come together and technology before design is putting the cart before the horse.
iD knew they were making a fully 3D version of Doom (with better multiplay etc.) before they created Quake and succeeded.
Half-Life creators Valve knew they were making a story driven FPS style game with good NPC AI when they licensed the Quake engine and succeeded.
On the other hand I'm not sure what Dreamworks Interactive thought they were making when working on Trespasser but what they released was a frustrating game (but a beautiful technology demonstration).
The book doesn't suggest simply assembling your game from other peoples code. It does suggest not reinventing the wheel but rather working on your new wizzy suspension or aerodynamics, and making sure that the final vehicle is fun to drive.
Multi-Platform Architecture (Score:1)
I think this is even the example they use to illustrate the Facade design pattern.
I suggest you read this book. I think you might be pleasantly suprised.
Re:Infinite games (Score:1)
A pity because it was the most interesting game they had on their lists, and now they've had the plug pulled themselves.
This book is an argument for proper methods (Score:1)
If you are writing something that is based on known techniques and you are simply writing your own enhanced version then that is not what they mean. Otherwise prove the technology before green lighting the entire project. They are not saying don't do it, just check the details first.
Yes this might have stopped some big games before they started but I suspect in cases like Quake that iD did prove the technology internally before creating the game (John Carmack seems to be very sensible like that).
The other question is how many companies have died trying to produce an impossible game when if they'd checked first they might have succeeded in creating a different great game?
If you read far enough through the book you will also discover that they are arguing that it will be more and more difficult for the smaller game companies to survive on their own. The research department issue is just one of their reasons for this. They relate it to the early days of the movie industry (pre Hollywood) and argue that the big studios are coming (sort of).
Bibliography Lite (Score:1)
It fails to mention "The Mythical Man Month" - Fredrick P. Brooks Jr (1975) at all despite references to mainframe project management, and the fact that it is the seminal project control book.
It bases an entire chapter on "Design Patterns" - Gamma et. al. (1995) but mentions it only at the start of the chapter and not in the bibliography at all.
Also they Credit "Code Complete" (1993) to Steve Maguire. They may have meant Steve McConnell or they may have meant Steve Maguire's book "Writing Solid Code" published the same year. Both should probably have been in the list.
These are just the items that I can think of without the book for reference.
Counterexample (Score:2)
There's a FPS with a similar engine to Doom, except that the story mattered, you needed to kill some things but not others, your allies would change based on the storyline, and rather than being bogged down in _your_ character development, you were a violent cipher acting first on behalf of a friendly AI ('Leela'), and then as Leela is destroyed, you end up acting on behalf of a mad AI whose motives are deeply questionable ('Durandal'). The literary quality is very high for a computer game, and the creativity is just off the scale. People have made elaborate web pages just _analyzing_ this game trilogy as if it was a literary work- yet reading the terminal texts straight through is not the way the work is meant to be experienced.
I'll concede that very few if any 16-year-old game hackers are capable of this sort of literary distinction. Of course, I'd be delighted to be proven wrong ;)
Re:Counterexample (Score:2)
The Marathon Story [bungie.org]
Re:Writing Games (Score:2)
Re:Game design (Score:2)
Nope, I couldn't disagree more. I wish games companies would concentrate less on storyline and character development, and more on gameplay. A game doesn't need a storyline to be playable. See Tetris for a prime example. Doom and Quake are more examples. Yes, they both have storylines, but they were tacked on to the game itself, and are basically just an excuse for saying "kill everything in sight", and weren't actually needed for the game at all. If a game is any good, it should be just as playable whether you know about the storyline or not.
Re:Liasing with the industry? (Slightly OT) (Score:2)
How I long for those days! Have you actually tried to buy a scolling shoot-em-up recently? No one sells them, because they're all trying to make the next Tomb Raider/Sports Sim/GT clone. Yawn! At least those making Quake clones have come up with something worthwhile (Unreal Tournament is excellent, as is Aliens vs Predator). Some days, though, I'd just like to be able to sit down and have a good old blast away in Battle Squadron, DataStorm or Uridium. Yes, you can play them on emulators, but it's not quite the same (unless someone can tell me how I can connect up my old Kempston Competition Pro to my PC...) Until then, I guess I'll have to settle for R-Types and Xevious on the PlayStation.
Finally (Score:2)
Game design in the past few years has gone heavily towards story lines reminiscent of soap operas. Take the final fanatasy series for instance. If you are die hard RPG player like myself you will notice that the whole flow of the game has moved away from series level building and monitary gain towards character developement and plot lines. I do miss spending hours on end building my levels and gold supplies so high that I can breeze through the game. it gives you a good sense of accomplishment. I would have to say though, that I like the big story lines in the games now. It draws you into the game. In FFVII you could actually feel sad when cloud killed his main love interest under an outside control.
I am really hoping that this book delves heavily into the building of the plots and storyline in newer games.
On the other end of the spectrum, we have our good friends over at ID cranking out the blood, guts and sheer graphical power. It's nice to play a good RPG, but I need to pick up a BFG and clear out a room full of people online every now and again. Gibs Gibs Gibs I love it all!!!
I'm thinking that I would look forward to a good tell all book from Carmack. Maybe someday my dream will become a reality. hahaha
Thanks for a *relevant* review! (Score:2)
...so I guess I'll have to pick this one up.
Well done, but that's not saying much (Score:2)
This is possibly the best book yet on the subject of game development, but it greatly saddens me. This isn't a book about the magic of game design and creation, it's a book about navigating the passageways of the game industry. Even that we have to call it an "industry" now is depressing. If you want to start a game company that yammers on about innovation and cutting edge technology, and then goes on to create Yet Another Realtime Strategy Game That Wishes It Were Starcraft and such, then go ahead. But otherwise this is on par with a book about getting into the consulting business. Bleah.
Re:No Linux? No sale (Score:2)
Isn't the whole point here that the book (which I admit that I have only just started reading) is to demonstrate Architecture and Design, not implementation? So it doesn't matter what platform the examples use, as long as they get their point across. Personally, I'd have preferred it if they had used OpenGL and Linux and
If you want an OpenGL development tutorial, buy an OpenGL book...
*****BUZZZTTTTT**** Wrong! (Score:2)
unproductive activities such as games. If software developers are smart, they'll switch over to business applications such as spreadsheets, word processors, billing and accounting software, etc. In fact, I would say that it's their patriotic
duty to do just that, so that their country will be able to better compete with the other countries. One could even make a case that games should be outlawed as a drain on the resources of society. Perhaps it's time to finally put selfish
individualism to rest.
I doubt you have realistically seen what happens to people when they don't have anything that they enjoy to do. Ever watch any sitcom? Notice something? Usually the person really hates their job and do let off steam they decide to do crazy random stuff.
I think that games will be played in some fashion even if it's just a handheld thing like a gameboy or maybe a good book or a crossword puzzle.
Since we haven't really seen much data to determine if the decade of 2000 will herald any such change we just have to look at what we have now.
Games sell more and more PCs every year. It's what basically keeps video card manufacturers in business. I mean come on do you really need that Voodoo 3 6000 do produce "scientific charts" or work related material. Well maybe but most of the hardware in this category is in the form of game desires from people who play games.
I think you are dead wrong on this one.
Re:Capitalizing on youth dreams? (Score:2)
then.
Yeah I have had experiences like that. Trying to get programs to compile that I thought surely that they would work, ideas that fizzled, concepts that if someone actually worked on them would make for a game better than the ones that we have now.
For example. Suppose you have a star trek like game. Well I thoght of creating say a universe and have individual planets that one could explore and look at and perhaps meet new and interesting life forms. Have this game be infinitely playable and expandable and use plenty of randomness. You could play for years and never win but have a hell of a lot of fun doing it.
I am wondering if perhaps there are any games like this or that have the concept of infinite play with a continuous running story that are open for expansion at will. Say perhaps a level or mission pack every 6 months.
Release a game like that and you will have people battering down the doors to get it.
Re:The Futility of Game Development (Score:2)
Esperandi
Re:Game programming/ design books... (Score:2)
Which is why people say the game companies lag behind others in following the lifecycle model and crap like that. FUN is not ISO9000 compliant. Managers hate that, but its why game companies will need to remain places where the coders can work whenever they want, sleep in their offices, all that stuff you hear about. The minute they start coming 9 to 5, having QA sessions every day at noon, and all that crap the people working on a word processor do, their game will die.
Esperandi
ISO9000 will eventually encircle the globe, standardize the production of every software project, then it will move into families and standardize familial activities.. from there, it will move on to the molecular level - surely physics isn't efficient, it doesn't document itself!
Re:Middleware, was Re:Game programming/ design... (Score:2)
Esperandi
Not an engineer unless you mean a software engineer
You apparently don't understand what the book is (Score:2)
Also, there are no open source projects that are done correctly. They're just people doing their thing, they do not follow the software lifecycle model that you will HAVE to follow in the gaming industry or you'll end up way behind on the times. Also, you have to consider that most of the goals of these things disappear when you're doing open source stuff. In this case, you want people to LOVE your game so they'll buy it and you can meet payroll and keep your programmers around for another couple months. In the open source environment you really don't give a rats ass if everyone in the world hates it because you won't make any money either way, you just want to do it because you find it fun personally...
Esperandi
If there are any open source projects out there that have SQA teams, have requirements, specification, design, and all those huge ultra-overly-detailed documents, feel free to tell me about them, but I don't believe they exist.
Re:Amen to that! (Score:2)
The future IS single-person or small teams, selling their products online. A cult following will be required in the beginning but eventually, if you want a game, you hop online and spend $10 and play a game all night or for months...
Go have a look at the roguelike community. They've got more fun, more replayability, and (for the most part) more game balance in their left testicle than in every other game company combined. If they'd wake up and sell their games online, they could make some money.
Esperandi
Re:Writing Games (Score:2)
Esperandi
Hell, run it on a BBC B emulator!
Re:Finally (Score:2)
Esperandi
I love Carmack and admire him deeply, but him and his employees need to learn that just because their game is good doesn't mean all games unlike it are bad.
Re:Liasing with the industry? (Slightly OT) (Score:2)
I think game designers need to start being paid more than programmers and need to have a lot more responsibility and such on their head. There should be majors in game design and such. Right now in most cases they're just some guy who says "I want a game where a hamster has to find his kidnapped sister. I want it to look like Quake 3, but you shoot forks and knives at vegetables instead of bullets at other people. Oh, and throw in some puzzles" and then halfway through the project they walk in and say "Scratch the hamster, bring back the bullets, we're searching for a sodomized stick of cellery in the basement of the Muppet's kitchen. Make them jumping puzzles, like the ones that pissed everybody off in Half Life.". We don't need that. We need someone who UNDERSTAND things like if you want to make a massively multiplayer online game you provide the ability for players to form a community around the game but in *NO* circumstances do you make it mandatory (like it is in Everquest which is why EQ is only a tenth of the game it could be).
Without these kinds of people, there won't be much innovation in the game industry. technological innovation is SO unimportant when compared to innovation in gameplay and such, so the designers ought to get the big bucks.
Esperandi
Re:Capitalizing on youth dreams? (Score:2)
Esperandi
Roguelikes are #1 for replayability without a doubt. Tetris doesn't even come close
Re: Then ask him (Score:2)
Esperandi
Re:This book is the root of all evil (Score:2)
You're writing a game, pushing all the pixels around manually, doing wonderful things with linear algebra and trigonometry, bending the laws of mathematics at your will.
The Voodoo card hits the market.
3D acceleration is the wave of the future.
Scratch what you've done.
Spend 3 months learning the Glide API.
Begin rewriting your engine.
The Voodoo2 is out with a better featureset!
Spend a month re-learning Glide.
Begin incorporating the cooler Glide features into your engine.
Uh-oh, a lot of people are talking about Nvidia and how DirectX and OpenGL are fighting for the lead in the market.
You keep working on your engine.. almost done...
Oops, looks like people were right, Nvidia is doing pretty good with that TNT!
You spend 8 months learning DirectX, DirectPlay, Direct3D Immediate Mode (cause you simply can't use Retained, its too slow!)
You begin rewriting your engine.
DX5 comes out.
Relearn.
DX6 comes out.
Relearn.
DX7 comes out.
Relearn.
You hear DX is going to soon be a thing of the past and everyone will be using something called Fahrenheit, so you decide to just sit around and wait, why even frigging bother with the engine?
I find it hard to believe you'd be able to make a payroll if that's how your company worked.
Esperandi
Re:The Futility of Game Development (Score:2)
Selfish individualism indeed.
Esperandi
I am the thing that we were born to hate.
Infinite games (Score:2)
For example. Suppose you have a star trek like game. Well I thoght of creating say a universe and have individual planets that one could explore and look at and perhaps meet new and interesting life forms. Have this game be infinitely playable and expandable and use plenty of randomness. You could play for years and never win but have a hell of a lot of fun doing it.
I like the idea of open-ended games such as you're suggesting here but I think that this sort of game would work best as a multi-player game - you can only explore the universe on your own for so long before the appeal fades. I suppose things like Ultima Online are the first steps in this process, but I'm sure the "online world" type of game will grow in popularity as more and more people join in.
But there are certainly some kinds of games which don't really work as a stand-alone product but are almost ideal for this kind of treatment. How about a game based in a fantasy city where intrigue is rife? Players can engage in all kinds of things within the city or intrigue with other players for positions of power. Over time characters will rise and fall in power and prestige. That's just the first idea that popped into my head, but I'm sure you can think of others.
Re:Game design (Score:2)
You may have noticed that I did say that this doesn't apply to all games. Of course games like Tetris wouldn't be improved one iota by some contrived plot - there are cases in which pure gameplay is the only important element.
And again, for games like Quake of course it is the gameplay that counts. This is what I was talking about in my last paragraph - that the game engine itself must be fully tested to be as playable as possible. Think of the many games that are like Quake, but not nearly as well-tuned and so just don't work.
Re:Infinite games (Score:2)
It seems that at the moment the only way to play in this kind of game is to join up with a play-by-(E)mail game. Of course you lose out on the immediacy of a real-time game, but you do gain a lot more role-playing opportunity, especially if it is moderated by a human rather than a computer.
It's a pity there's nothing like that because I'd definitely go for it. Still, this kind of open-ended online game is going to be more and more popular as the technology for it improves and hopefully we'll get to the point where there are enough games so that we could choose whatever we want.
Re:Making a game by yourself? (Score:2)
I remember trying to code something based on Civ after the original came out. After trying to work out an appropriate class structure I gave up in disgust because of the sheer amount of time and effort it would have taken :(
However I've also looked at the FreeCiv project and I'm very impressed. It looks like it'll be extremely good when it gets finished. OTOH I wish Microprose (?) would release the source code for Civ 1, now that would be a good download!
Not only fun - but a lot of hard work (Score:2)
Why games? Games are large and complicated systems. Games are also one of the best approximations that we have today of living systems - using such things as virtual reality environments, simulations and artificial intelligence (if there is such a thing).
In the earlier 90's it seemed that the game industry offered opportunities for starters. Now the game industry is a very much different environment, where large companies dominate the scene. In this sense, the dream of making off my own game seems very hard to attain. The cost to produce all the multimedia needed to make for an attractive game today is beyond most peoples pocket's. This is a shame, because a lot of people have very bright ideas, but have no way of realizing them.
Amen to that! (Score:2)
Braben/Bell/Crowther et al. had great ideas, and some phenomenal coding talent, but as much as I hate this, to the average punter who bought his PlayStation for evenings after/when he couldn't go to the pub, looking good, being bland and being advertised well is all that matters a lot of the time. If you showed Elite to a marketing department now (if it hadn't been written in the '80s), even with flashy graphics, it would be an uphill slog to get them to adopt it, simply because it doesn't cater to the demographic they are aiming at.
It seems to me that by finally pulling digital gaming into the mainstream, we may have done it the greatest disservice of all.
Liasing with the industry? (Slightly OT) (Score:2)
It worries me that there are fewer and fewer innovative games out there. Just as the market was saturated with scrolling shoot-em-ups 15 years ago, nowadays it seems that in order to convince the marketers, you need a Virtua Striker/Tomb Raider/Quake/Gran Turismo clone, or you can do a pinball game and aim for the 'quirky' dollar, in much the same way as the music industry is going formulaic with Britney/Backstreet/Puff Daddy-alikes. The customer is being told what to buy, rather than being asked.
Good programmers are being sucked up by companies that lack imagination, and the gamers that also program are generally not listened to at any level above their assigned project. Does anyone else get the feeling that those who play games should have at least some share of input?
Judging by the chapter titles, the book tells you how to build a software release team yourself. True, maverick software companies like id offer some solace, until they are fragmented by ego clashes (See also: ION Storm), and most large publishing companies just want to buck up revenue with variations on a theme (usually sports, in the UK at least). It just scares me that the truly innovative voices are being drowned out by the commerce, that within the games industry, the Industry is swamping the Games.
Re:Not only fun - but a lot of hard work (Score:2)
Going to the GDC Hardcore Physics Seminar last December impressed me with how smart the people doing game engines today are. They're not just pixel-pushers any more. Game development is drawing serious mathematicians. It's like visiting MIT. Good scientists are going into games, instead of NASA or Wall Street.
Game AI has probably passed academic AI in quality, too. More money, more bright young people, and a problem to solve.
Re:Management (Score:2)
BTW, what about the authors' résumé? If I were trying to learn about game software team management, I would try to get a book written by someone managing one of the big game companies: Id, Sierra, Accolade, Lucas, etc.
Supermen are superthinkers; anything else is a side issue.
Re:Not only fun - but a lot of hard work (Score:2)
First off, if you don't have a budget, you keep that in mind when you start your game. Skip the FMV and motion capture and design something you can write on a budget. Don't draw 500MB of textures, just make a few good ones and wring 'em for all they're worth. Above all, concentrate on gameplay, because in the end that's what'll keep people coming back to you.
And when your game is done, publish it yourself if you can't get publishers interested. The internet is perfect for that, there are plenty of places which will take care of selling it for you. For a price of course, but the margins are actually much higher online than in retail. Marketing the product online is up to you.
People in the industry frequently tell others looking to get into it that you have to 'pay your dues', and they're right. If you just want to get into the industry, you can get a job as a coder working on someone else's project and you've got a few titles under your belt you can get the green light to work on one of your own. If you've got a game that you've got to make yourself before anything else, then it's going to require a lot of time working for free in your basement. Which sacrifice you want to make is up to you.
JB
Re:Making a game by yourself? (Score:2)
Management (Score:2)
game dev: Not hard work - only fun (long) (Score:2)
Though the task of making a game could be classified as 'damn hard', if the task is all hard work, tedium, and discourages the hopeful developer from bringing their idea to fruition, then, well... They're not cut out for game development. (I havn't given up yet on my project[s], nor have I finished the first one I chose to tackle, so I don't know if I'm cut out or not.) And this makes no statement about those who havn't started just because they don't know where to start- just the ones who slammed the power button and gave up on the dream.
Let me refer to one of the other replies by _Gnubie_, whom has been at a 3D project since 96- (!!!) Now that's dedication! Of course, it might also be a good example of where a good design could have cut down on the coding time- without knowing any specifics, I can't say that anything _Gnubie_ is doing is wrong. But, having changed from Pascal to C/OpenGL is a good example of a change in the design, even at risk of throwing away a lot of the old code (but not the algorithms). And that's something else that will decide whether or not it's tedious work or fun game development- realizing that it's progress, because being attached to all that work you've done until then could be a Bad Thing(tm).
So now we picture ourselves as dauntless, aspiring game developers, finding joy even in wasting a few weekends writing volumes of code, and then writing them over again because we realize that last weekend's coding bout was pure crap (btdt). So, should we be discouraged because we can't compete with Big Industry? I say heck no! Well, unless your goal is to be a lone, independant game developer and do the sales and marketing yourself. Time to be dauntless and re-evaluate your business design. Personally, my completed project will serve as a nice portfolio/resume piece so I can get hired on by a company. If I'm able to make a quick buck off marketing it on the 'Net, that'll be a plus, but I'm not counting on that to cover the cost of my caffeine addiction. But even independantly produced bare-minimal games can be as fun (or better) than big-budget eye-candy packed titles put out by some big publisher- and THAT should be the encouragement for every aspiring developer to complete their project. Or at least keep their dream alive until they know where to start. :)
Re:Making a game by yourself? (Score:3)
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...
Re:Python? (Score:3)
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.
Re:Making a game by yourself? (Score:3)
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
Writing Games (Score:4)
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.
Game programming/ design books... (Score:5)
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 ?
Game design (Score:5)
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.