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
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 ;)
Ian Bell has posted the source code for the original on his website, if you want to try porting BBC-B specific 65C02 assembly to something Linux can chew on. :)
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)
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I'm glad to see someone finally press a book that deals with what most likely takes up the largest portion of my life. GAMES
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
Technology's a battle between companies producing more idiot-proof systems and nature producing bigger and better idiots
Well, to me anyway. There are those who say I could use a book that intelligently covers game design and architecture. ;)
...so I guess I'll have to pick this one up.
Geeky modern art T-shirts
Note: I work in the game industry.
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.
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...
Games were important back in the 80's and 90's, but that era is coming to a close. The future is here, and the future is business. As our society advances, people will spend more and more time at work, and less time with
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.
Slashdot social engineering at it's finest
Does anyone else have a similar experience? I was about 13, and 100% self-confident when it came to computers. I bought a similar book in hope of writing the next Doom, and it has successfully gathered dust on my shelves since
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.
Slashdot social engineering at it's finest
But if you waste your time playing games, you're not submitting to the will of the collective! Yu're not sacrificing your life to giving the community more applications as Open Source dictates that you do. The Reverend is simply taking the ideas of the majority of Slashdotters and thinking them through to completion.
Esperandi
The least important thing in a game is its coding methods. Sure, it needs to run fast enough to not be aggravating but there are certain concepts which are eternal in games and are far more important that any code. Gameplay. Balance. Etcetera. For instance, Everquest is a game that is coded quite well, and yet there is a very great deal lacking from their gameplay because they chose to shove inter-player interaction down everyones throat instead of letting it happen on its own. These are the kinds of things that people need to learn, not code. Someone who codes an accounting package can't just jump over into games. They won't have any concept of how to make the game FUN.
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!
Yeah, you can use a middleware product designed 2 months ago in your new projects... if you don't mind being laughed at by everyone who passed on your project and is using the new guys product who went and made his own in a new and innovative way... game programming involves constant innovation. Unless you build a brand name and depend on your fans simply wanting more of the same, you have to be out there to do even mediocre. Then once you've got the technology that knocks their socks off you've gotta figure out how to make the game fun enough, how to build in replayability, how to make it balanced so its not too easy or too hard, etc, etc, which are the things that really build a game.
Esperandi
Not an engineer unless you mean a software engineer
The code is completely irrelevant in the book just like its irrelevant when you're making the game. The book is about the design of the game and the process. The things like "Okay, the most powerful sword in the game will be on level 1 and you'll be able to kill every creature in the game with one hit except the end guy who is next to impossible". That's really bad game balance. That is much more important than whether you use OpenGL or anything like that.
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.
Emerging trends are not apparent trends. If you look HARD, you will see a trend. Fatbrain.com eMatter... Adware... Amazon zShops...
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
Don't bother, it'd be much less work to port it to 6502 asm for the NES, assembling it and mixing it together into a NES image file and running it through a NES emulator.
Esperandi
Hell, run it on a BBC B emulator!
Well, a lot of game players I've talked to say 'I don't know why its fun, it just is". They can usually give you a rundown of what they hate, but you ask what they like and they either draw a blank or spit out a bunch of completely useless crap. "Well, I liked it because it wasn't too easy and it wasn't too hard" is NOT helpful. They're telling you its a good game and that's not what you need to create your own good game.
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
Well, there are roguelikes. You can beat them in theory, though I've been playing them for 10 years and never have. They're some of the msot fun I've ever had in games, most notably Angband. The variants of Angband are good too (only play Zangband if you don't mind it getting harder every damn weak... the mantra of the development team is "the game is too easy" when only a handful of people can beat it). Recently in rec.games.roguelike.development someone has been talking about a new roguelike he's making that sounds similar your yours, random planets with random creatures on it and such stuff...
;)
Esperandi
Roguelikes are #1 for replayability without a doubt. Tetris doesn't even come close
I find it odd that you call yourself a software developer and yet you think code is relevant in games. Of course its not. Gameplay, balance, presenting a comprehensive requirements document to the client, being able to whip up a rapid prototype in VB or something similar, having an all-encompassing design document, THESE and many similar things are the important stuff, not the engine below. If you've got gameplay, you can beat the guy next door who took 6 months to get his game to run in a higher resolution at the same speed as yours...
Esperandi
I haven't read the book but I believe you misunderstood (which doesn't say much for the book) what they were talking about. In every thing I've ever read about game design, one of the principle things is not to look at up-and-coming technology. The simple reason is because you'll never STOP looking at uo-and-coming technology. Imagine this scenario:
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
Bwahaha, if the reader of /. only knew that you're following their viewpoints to a logical conclusion with this "sacrifice for the will of the many, progammers need not be paid" shit.
Selfish individualism indeed.
Esperandi
I am the thing that we were born to hate.
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.
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.
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!
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.
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.
- "How do we do it? Volume!" - The Bursar of Unseen University.
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.
- "How do we do it? Volume!" - The Bursar of Unseen University.
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.
Maybe it is not the quality of game content that has declined, but rather you have become spoiled by the quantity of good gaming software. Look at the younger game playing generation... they become totally immersed when playing StarCraft, Quake III, etc. With these 'new' classics, you use both your brain and reflexes.
The bit about Team Building and Management seems especially interesting. Based on what I've seen, about half the games out there come out with significant delays, release dates keep getting pushed back (also note that acording to some(vaugely remembered) statistics from Ed Yordan (ug) more than 80% of all software projects are in some way late.) This seems a rather valuable part of the book. Also, all programers should be required to read "The Mythical Man Month" (Frederick P. Brooks Jr, 1995), a great book about how not to be late.
--Chris
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. :)
Yes, we understand these tags always apply: fud, dupe, typo, slashdotted, topic name
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.