Developing Online Games

peterwayner writes "If you're a bit tired of programming books, API descriptions, tables of keywords, and arguments about which data structure is buzzword compliant, super-mega-efficient and intuitively easy to grasp, turn to Developing Online Games , a book that seems to have very little interest in many of the traditional challenges for programmers. The authors spend four lines discussing the best computer language for the job (C/C++), conclude that objects give "far more flexibility in design" and then move on to fun questions like how to make a online game compelling for achievers, socializers, killers and explorers. This book is a wonderful psychoanalysis of the gamer's mind and it should be the first and last book read by game developers about to start a quest to capture the hearts, minds and subscription fees of people on the Internet." Read on for the rest of Peter's review. 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.

Comments

slightly OT : Networking question

[linuxlover]

I am developing an online card game, and I am stuck with Networking. Both client and server has to call each other. (callbacks in other words)

- First, I used Java RMI, and it couldn't work behind firewall-firewall situations. So much for network transparency promise!

- I am evaluating various Networking mechanisms. Apache SOAP, XML RPC...etc. They all work on the principal of request-response.

* I want a protocol that would work with the existing client Socket. Let me explain, client behind fire wall makes the connection to a server (behind firewall, but one port open). Now both have to use this existing socket to communicate.

* when the server wants to call-back client, it uses the existing socket. not opening a new connection, as that won't work when a client is behind a firewall. Both XML RPC and SOAP can not handle this.. or am I missing something?

* I want a package that will handle marshaling/unmarshaling data structs and also can handle exceptions.

* right now, I am left with plain socket programming. There must be a better way..right?

thanks in advance.. ./LinuxLover