Simple Prototypes; Complex Virtual Worlds (Part II)

In Part I, Dr. Ricardo Rademacher, CEO of Futur-E-Scape, begins his journey of creating a virtual world prototype by reviewing the existing literature on prototyping. In Part II, he gives his thoughts on how simplicity pertains to a virtual world prototype.

For my own contribution to the subject, I will write down my thoughts into three areas: design, art, and technical. Each of these areas will be seen during the prototype phase but will receive on equal consideration.

Design Simplicity

A prototype should be designed to focus on a single gameplay element. For example you may wish to prototype a close combat module and a ranged combat module for your RPG. The prototype should test one or the other but not both. Because of this, it can be easy to align a prototype to a use case scenario. If written at the proper level, each use case will address a certain gameplay module within the total design. Since each use case narrative should completely track how that gameplay could be instantiated, there could be a one-to-one relationship between prototypes and use cases. As well, a prototype design document can be as little as one page for a developed use case narrative or a few pages at most for an extended high concept treatment. Because in a virtual world these systems will be interrelated and coupled to various others, it is important to understand them on a small modular level before you integrate. In our example, since most combat is usually presented also in a chat window, a stable prototype of a chat module will ensure that when you go into production, each element is well understood before mashing together.

Artistic Simplicity

One of the major difference is given between a prototype in a demo is in the art assets. While a demo should look as good as a finished product code, the prototype is not bound by such constraints. In effect, this means that the production and integration of art assets should not be a priority during the prototype phase. The art pipeline should be part of any game engine analysis done prior to choosing that particular engine. And since art assets do not contribute significantly to gameplay or other systems, making a prototype looked pretty merely wastes time that could be used testing deeper systems. This is particularly relevant when it comes to the creation of virtual worlds. Since a virtual world has so many art assets, often in redundant roles, focusing on art early on in game production will unnecessarily sap resources that could be better put it to design work.

Technical Simplicity

I found that the biggest challenge of prototyping a virtual world to comes from the technical side. Given the online nature of virtual worlds, there is a host of technical issues that you do not encounter in single player games. However, when it comes to prototyping, these are NOT the issues you want to focus on. For example, these elements should not be part of your prototype and our best relegated to a technical review phase of your production or a separate technical team:

Networking: while networking is arguably the most important system of a virtual world, its lifeblood if you will, there is no need to test it during prototype. We know the Internet works and reassuring yourself of this while you are trying to create a game will again divert unnecessary focus away from the design. As a matter of fact, it is during the prototyping phase that information about the networked data elements will come to light such as how much and what type.


Database: just like networking, the database is a central part of your game and yet one that you should not prototype. While there are many networking engines available for free or commercially, you can more or less exclusively use the mySQL engine for database. Thus just like networking, this is an aspect that is well understood and thus should not be prototype. There is a strong temptation to make use of a database early in prototyping, such as by putting in extensive player information or combat tables. I would advise that during the prototype you merely use a flat file system, if the amount of information necessary for a prototype is so large that it requires a database, then you are likely attempting to prototype too much or too large.

Security: while bad security will bring your game down, there is absolutely no reason to be concerned about this during the prototype phase. A prototype by my definition should not be made public. It should be a purely in-house application for testing purposes. Hence there is no reason to include any kind of security model. Furthermore, security will often have the effect of merely adding some latency to your virtual world. The extra milliseconds needed to encode and decode a network packet should not significantly alter your games performance.

Dr. Ricardo Rademacher is a native Chilean who obtained his Physics PhD in 2002 and is the founder and CEO of Futur-E-Scape, LLC. Created in 2004, this company is dedicated to the creation and research of educational virtual worlds. He also speaks at various educational and entertainment conferences and has written several publications on these subjects.