Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Disney Online's Toontown
View All     RSS
May 27, 2017
arrowPress Releases
May 27, 2017
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Postmortem: Disney Online's Toontown

January 28, 2004 Article Start Previous Page 2 of 2

What Went Wrong

1. Making an MMORPG is hard! Anyone who has worked on one of these will tell you this. We had to develop several core competencies from scratch, rewrite our development software, work for years, and are even still revising our operations plan on a regular basis. The number of skill sets necessary to produce and run an MMORPG surpasses anything we had experienced before.

A good illustration of the difficulty in programming a massively multiplayer game is the Toontown battle system. We designed a turn-based combat system where players could choose their actions and then a round of the battle would play out as a short scripted sequence where the Toons do their attacks and the Cogs retaliate. These battles take place on the streets of Toontown, which are a public place. It was important for us to allow passersby to be able to observe battles and even discuss what was happening in them as a way for new players to learn how to play this part of the game. This required us to design the battle system so that players coming around a corner and observing a battle for the first time would see essentially the same thing that players in the battle were seeing at roughly the same time. In other words, the sequences generated for each round of the battle had to be distributed to everyone in sight of the battle and synchronized. In addition, these sequences needed to support arbitrary starting points in case someone arrived late. Our solution was to represent every animation, sound, transformation, and effect for a given sequence as a hierarchical set of "tracks" that had defined state throughout the duration of the movie. We could then distribute this set of tracks and every player in view of the battle could synchronize by setting the network time value. As a result, a player that rounds a corner and sees a battle for the first time can actually see a pie in mid-throw.

2. We had to change scripting languages. Changing scripting languages is the last thing you want to contemplate more than six months into a project like this, but by that point we had begun to realize our scripting language was not going to get the job done. The language we originally chose was terrific for rapid prototyping and we were able to make a lot of progress. As the code base grew, however, we began to experience both performance problems and code management problems. We finally made the painful, but necessary, decision to switch, and ported the game to Python. Things have been great ever since.


This was the starting point for the feel of Toontown--the houses were modeled after the feel of this concept art.


It is worth mentioning that our development environment consists of C++ libraries that are loaded by an interpreted scripting language. This allows us to have the performance of compiled code where it matters, but also gives us the flexibility to make changes to the game without having to recompile. We like being able to iterate quickly and even occasionally rewrite methods while the game is running.

Python is working out for us because it is relatively efficient, lightweight, and scales well. It has a syntax that is easy to learn and debug, and the documentation is excellent.

3. Be careful when you let players create their own names. We assumed correctly that we would have to filter name choices to eliminate offensive words or phrases. We underestimated the ingenuity with which some players would approach the challenge of trying to defeat our filters, however. After refining our filter and accumulating an impressively long list of bad words, euphemisms, and other exotic uses of language, we finally resigned ourselves to the fact that we would either need to revoke the privilege of naming characters, or require a human reader to check every submission. Currently when you create your own name in Toontown, you must wait for approval from the "Toon Council" before you can use it.

Having a human look at every name submission can be fairly expensive, however, so we developed a system intended to make name-picking fun. Our name generator can produce a wide range of Toon themed names such as "Professor Skimpy Googlemuddle" or "Dippy Funnycorn". The name choices available to new players make it easier to begin role-playing as a Toon because they convey the humor and sensibilities of the Toon world. Also, for new players, and especially younger players, it is often a relief to not have to come up with an appropriate name from scratch.

4. The Internet can be a challenging platform. The Internet is very good at delivering web content. Web browsers are very forgiving when packets fail to arrive quickly (or at all). Unfortunately, an MMORPG requires a persistent, relatively low-latency connection that is reliable and sustainable for up to hours at a time. This is extremely difficult to deliver using today's Internet. We have suffered from a variety of packet loss or corruption problems that happen between our servers and client applications. These types of problems are extremely difficult to reproduce and isolate. Even when you manage to identify them, they are often impossible to fix because they don't happen in your code. For example, we eventually decided to use SSL to send game data back and forth from the clients, not only for the obvious security benefits but to prevent occasional misinterpretation of our data by various pieces of networking hardware between our servers and our players on the Internet.


The levels in ToonTown resemble a Hollywood backlot set--only the necessary details of the streets and buildings are modeled.

Latency is another major obstacle that we had to contend with when we designed Toontown. Since latency is extremely variable by geographical distance, Internet service provider, and congestion at any point in time, it is difficult to take anything for granted. We chose turn-based combat rather than real-time combat in order to minimize the effect of latency, for example, and generally designed all of our game systems to work smoothly with up to two seconds of lag. As part of our testing process, we exercised most game systems under simulated latencies of up to twelve seconds to make sure things would not degenerate completely.

5. Online distribution. Online distribution turns out to be both a blessing and a curse. As mentioned in the "What Went Right" section, online distribution helped us to market Toontown virally. Unfortunately, it is difficult to market an online-only game using means other than viral ones. As it turns out, many people today are still generally uncomfortable with the idea of buying a game that doesn't come in a box that they can hold. They also worry about what happens to their purchase if their hard-drive crashes, for example. Other people are unwilling to use their credit cards online at all. Finally, it is awkward to give an online-only subscription as a gift.

As a result, we chose to distribute a CD for Toontown that can be purchased at retail. This gives us a more traditional game product around which to rally our marketing campaign, and provides a faster way for narrowband users to load the game on their computer.


It is difficult to build and operate an MMORPG, and probably even harder to do this for a broad audience. You are confronted with the increase in design complexity to handle massively multiplayer but at the same time must keep things simple to learn for the mass audience. You need to keep things safe without smothering your community and taking away fun and freedom. You need to find new ways to reach players and get them to experience and understand this genre of game, on a delivery platform that can be tricky and unreliable.

Despite the numerous and often painful lessons we had to learn about building and operating an MMORPG, Disney's Toontown Online was finally launched online in June of 2003. In case you are wondering if we have been deterred by our experience, you should know that we have recently begun development on another MMORPG.



Publisher: Disney Online
Developer: VR Studio
Number of full-time developers: n/a
Number of part-time developers: n/a
Contractors: Level editor, artists.
Length of development: 2 1/2 years
Release Date: Online launch June 2003, retail launch September 2003
Target Platform: Windows PC.
Development Hardware: Typical development platform was a high-end Windows or Linux PC with 1.5GHz CPU, 500MB RAM, and 32MB graphics card.
Development Software: Microsoft Visual C++ v.6-7, Python, Panda3D (internal rendering engine), DIRECT (internal level design and interface tool), Softimage, Maya, Multigen, Photoshop, DeepPaint, Miles, CVS.
Notable Technologies: Staged online distribution system, safe but effective communication (SpeedChat and Secret Friends), scalable servers.
Key Staff:
Mike Goslin, Director
Daniel Aasheim, Production
Felipe Lara-Garcia, Art
Mike Goslin, Director
Roger Hughston, Servers
Mark Mine, R&D
Joe Shochet, Game Design
Bruce Woodside, Animation



Article Start Previous Page 2 of 2

Related Jobs

Mindshow, Inc.
Mindshow, Inc. — Los Angeles, California, United States

Unity Engineer / VR Inverse Kinematics
Mindshow, Inc.
Mindshow, Inc. — Los Angeles, California, United States

Unity Engineer / VR Platform
WRKSHP — San Francisco, California, United States

Senior Game Artist
WRKSHP — San Francisco, California, United States

UI/UX Designer

Loading Comments

loader image