Developing Online Games 240
| Developing Online Games | |
| author | Jessica Mulligan and Bridgette Patrovsky |
| pages | 495 |
| publisher | New Riders |
| rating | 8 |
| reviewer | Peter Wayner |
| ISBN | 1592730000 |
| summary | The Sociology of building online games. |
The book's strength lies in the deep experience of the authors and the efficient, occasionally gimlet-eyed voice they use to analyze their collective addiction. Jessica Mulligan's bio lists work on more than 50 online games like Ultima Online, while Bridgette Patrovsky's includes time building games for Electronic Arts, Sony and Interplay Online Services. If you believe that Online games are the latest thing, Mulligan would like you to know that you're wrong. She wrote a column celebrating the 30th birthday of the Online game in 1999. Rick Blomme wrote Spacewar back in 1969 and Dave Arneson started an RPG named Blackmoor in 1970 or 1971. It was so long ago, he can't be quite sure.
All of this experience weighs a bit heavily on the authors. The book is more of a core dump than a logical progression and that means we hear bitter echoes of the past. One section is entitled "Yes, it really will take 2-3 years to complete" and another is called "No, More Programmers Won't Make it Go Faster." These sections don't add much to the usual literature about herding cats, but they do offer a strong reminder that this isn't a task for slackers who never could get around to forming that garage band.
The better parts are aimed at the design of the games themselves. While game players are slaying monsters or saving Princesses, game designers are questing after a full Player Satisfaction Matrix. Good games sate the player's need for socialization, accomplishment, discovery and conflict as they journey from the state of confusion (0-1 month), on to excitement (2-4 months), glide through the state of involvement (5-48+ months) before landing in boredom (until VH1 starts making "Behind the Game" documentaries). The trick to good design is making sure that there's plenty to feed the player's involvement.
For instance, you may be driven to create a new persistent world that emphasizes socialization because you're tired of all that death. The authors gamed that scenario and decided that "killers do have a positive role to play from the point of view of the socializers." Good can't exist without evil acting as a contrast and besides, players can usually find some other passive/aggressive technique for stabbing each other in the back even if knife objects aren't instantiated.
The authors tend to view the online realms as ecosystems. If you want to "increase the number of achievers," then the authors advise that you "reduce the number of killers, but not too much" while maybe "increas[ing] the number of explorers." I suspect that these recommendations are to be taken with a grain of salt, but they do reflect the observations of people who've spent a long time managing these games. I'm even tempted to develop my own Sim Sim that lets you simulate the process of crafting a simulation.
Ultimately it's hard for the authors to offer much more than these recipes and matrices. The details about the management, the strategies for stopping cheaters, and the intricacies of player relations are essential parts of the journey, but those are only half of the battle. Making the characters sing and the world come to life is a job for the artist.
This book is like many of the simple guides for writing a screenplay. They talk about arcs, hinge points and beats, but end up counseling that the screenwriter should aim to make each of these "good," This book can't tell you how to make your characters "good," but it can give you much insight into how others have done it before.
You can purchase Developing Online Games from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Great place to learn game programming (Score:5, Informative)
I know, I know you can't learn everything from there and you should pick up a book after a while, but nonetheless a great place to start.
Not quite (Score:5, Informative)
Also, there may be more flux among likes. TV tended to homogenize interests -- you watch one show that's in line with your interests, and it becomes very easy to also try another show that isn't quite as much as it, and eventually, you watch a pretty broad range.
If someone tries a MMORPG, it may be easier for them to play similar games.
Richard Bartle, Players Who Suit MUDs (Score:4, Informative)
http://www.mud.co.uk/richard/hcds.htm [mud.co.uk]
This is the source of "reduce killers to increase achievers" and such. I haven't had the chance to see this book yet to verify if they give him the proper credit for his research, however.
Dave Arneson (Score:5, Informative)
Talk about an understatement. This guy is one of the founding fathers of the RPG, who co-created D&D with Gary Gygax. Here's a good article [cgonline.com] detailing a little more about exactly what his role was in the development of the RPG.
Re:The Slashdot Game (Score:2, Informative)
Many people redefine "killers" to be any person who engages in grief play. In MUDs and other MUD-like games, these are usually people who indulge in player-killing for the sheer sport of being annoying. Other ways to grief play include destroying or hording items needed to complete quests, spamming communication channels with gibberish or swearing, etc. It's pretty clear that the /. trolls you mention are grief players who can mostly be lumped into the killer category.
For the individual who truly wants to see Natalie Portman petrified and covered with hot grits, they're a "dark socializer" as they want to talk about their obsession and no one around them wants to hear it.
The four player types (Score:4, Informative)
This is NOT a programming book. (Score:1, Informative)
When a game is small, sure, the same person might be wearing different hats - only then should a programmer be worrying intensely about game design. With larger teams programmers tend to concentrate on the technical details, working with the designers to accomodate the visions of the project. Meanwhile the designers concentrate on the design and layout of the game, while working with the programmers to make sure that it's technically possible and is implemented smoothly. It's only with this division of tasks that anyone can really focus and hone their skills.
Re:Yes, it's just you. (Score:3, Informative)
The context in which "C/C++" appears most often is a job ad, where it is in fact crucial whether you find yourself a C expert, a C++ expert, or an expert in both. In fact, even an experienced embedded systems C++ programmer may be unfamiliar with exceptions and templates, which are generally only usable on higher powered machines.
A person who doesn't make a distinction in this case is not likely to hire the best person for the job.
C++ compilers understand C code.
No, they don't. C doesn't require an explicit cast to convert any pointer to a void *, and vice versa. C++ does. What you have is a compiler with two modes, only one of which can be active for one source file. Try this if you don't believe me:
You will get a compile error on one line or the other.Some versions of C++ preprocess the code into C
Irrelevant. Many languages are "pre-processed" into assembly before it turns into object code.
The modules link together without any changes.
Even less relevant on two separate fronts. One, ever heard of name mangling? C++ needs to be specially written (as opposed to linking with just other C++ code) to link with C, and instance methods are not even callable from C. Two, many other languages are designed to link with C. So what?