Abstract: Online PC game company wanted to extend their game world to the web. Via prototypes, data models, and involvement of stakeholders, we exposed and remedied early design issues before they became costly integration failures.
Efficient development is critically important in the massively multiplayer online game industry — where an innovation can go from cutting-edge to old hat before it's even released.
Trion World Networks had conceived a modular, distributed, server-based MMO game system. The game would be played with PC software that acted as a client to the game servers, but an important part of their "persistent gaming" system was that parts of the game could be viewed and played from a web browser.
When Trion brought us in, development of game software (PC client and game servers) was already well underway, but the web software was just a set of high-level business requirements. Any web software that took part in the game world would have to interface with game components that were already underway and had been designed before the web components had been conceived. Web communication with game data services had to be near-real-time, synchronous, stateless, and available to third-party developers.
We held discussions with the game server architects, web product manager, and project stakeholders to identify the toughest requirements and the riskiest untested assumptions. Those were the issues to focus on — we wanted to ensure that the company could produce web software that integrated well with all the other components, could be developed on its own, and still meet performance requirements.
We did this by authoring prototype software and other documents that probed these key issues, including:
We built these prototypes quickly, with simple technology (PHP, for example), usually gluing together third-party software whenever available (Google Maps). These components weren't themselves necessarily feasible for production use — perhaps they wouldn't scale well or remain maintainable, or perhaps they'd have been expensive to use publicly. That was okay. The goal was to explore key architectural decisions upon which major spending decisions were going to be predicated.
Altogether, our prototypes and paper models quickly:
Both of these results used early yellow flags to help Trion and Simple Dynamics design better services before the more expensive red flags went up. The Trion web team was able to redesign a few key APIs, keep the board of directors informed, and eliminate some of the noncritical features from the schedule in order to meet their launch date.
Video game client-server communication usually needs to be complex, since there's so much data and CPU operation involved. Both client and server need to remember the entire conversation; either side can make a request to which the other side must respond; a dedicated connection is kept open for the entire game session. In short, this communication style violates most of the REST principles that the web is built on.
So it was clear that Trion would need to build a software layer that marshalled HTTP communication into the protocol required by the game servers, and that the game servers would have to tolerate that load.
We acted quickly to test whether, in fact, the game servers could tolerate that load. Parts of the game server interface suggested that they couldn't. For example: compared to PC game clients, a web client has a long session with small throughput — yet each web user still took up a dedicated server connection. (Usually, this isn't a problem because a lot of web users share a single server connection by waiting in line for some number of milliseconds.)
We also realized that a stateful agent would have to be placed between the web clients and the game servers, to handle all the data persistence on which a PC client can rely and a RESTful web client cannot rely. This part was also worthy of a test.
Our quick prototype demonstrated that the ongoing development costs of such a design, as well as its runtime performance costs, were significant. Either the game server communication needed to be redesigned, or immersive web-based gameplay would have to wait until a later release date.
This information was instrumental in realistically re-scoping the project. We then focused our energy on more realizable efforts.
