Monday, August 21, 2006

Parallel Universes and Design Patterns

I just finished reading the article The Theory of Parallel Game Universes: A Paradigm Shift in Multiplayer Gaming and Game Accessibility, over at Gamasutra. It talks about presenting a game to different players in different ways; that is, providing a mapping of the game experience to those that might have limitations in the way they can interact with the game, be it a physical disability, a skill gap, or a hardware limitation.

The article talked about the idea of a transition function that would take the viewpoint of one player and convert it to that of another, and vice versa. While I'm not specifically looking to design a system (and in this case, it's a client-side problem and not server-side anyway) to work around a player's disabilities, whether reduced motor functions, poor vision or deafness, I believe I have mentioned my intent to implement various levels of client before.

On the grand scale of things, a MMO is a large-scale simulation, running innumerable things at any given time, into which players have an interface, a viewport, through which they can watch and, we hope, interact with the simulation.

On the top end of the scale, we'd expect a lavish 3D environment, with lighting and shading and textures, something taxing the latest-and-greatest video cards. You can look all around you, interact with the world using the mouse as an extension of your arm, and generally feel fully immersed in your surroundings.

For less powerful machines, we might provide a simpler, 2D interface, perhaps with a top-down or isometric point-of-view, in which we can still see all of the scenery, residents and objects of our world, albeit in lesser detail, fewer colors, a from the "front" only. We have this version because the graphics are bitmaps, not rendered meshes, and so aging hardware can still display it with a sense of immediacy, or perhaps because players just prefer this view-from-above (perhaps to avoid motion sickness when playing in a first-person 3D view).

For specialized devices, such as PocketPCs or cellphones, with very limited resolution, and reduced memory, CPU and GPU availability, we can perhaps provide a very low-res 2D- or 3D-view, flipping menus and text information overtop of our graphics to get non-visual information about our world. Without a mouse, we might have a stylus (for our PocketPC) or a simple control button on our cellphone, each with which we must be able to interact with the world as well as well as with the mouse.

And then we have the lowest level of interface, a text-only interface. Whether this is used because of a lack of video card, because of physical disabilities, or because of a preference for the simple, the ability for the world to be described in text, and interacted with from a keyboard can and should exist. In the case of such an interface on a portable device, a menu-driven or shortcut-driven interface might be used, to obviate the need for a keyboard.

I feel that any virtual world should be represented to the client in such a way that any of the above interfaces can be supported. For testing purposes, the text-only interface is by far the easiest to whip up, to interact with, and even to automate. Proof of concept for a world might be implemented in simple, 2D tiled graphics, where the game's content can still be seen in full, if not in full graphical glory. And time permitting, the 3D eye-candy version can eventually be written to make the game what it was truly meant to be for the player.

But how is this done? By separating out the system into parts conducive to this manner of design. In the world of design patterns, this is the Model/View/Controller pattern. The idea is that you separate the software (in this case, our MMO) into these three different "ideas", and keep them separate, providing an interface between the three. The Model is the simulation itself; the world running the physics, holding the database, and communicating with the other two about what's going on. The View is our world's representation on the client, whether a 2D or 3D graphical display or or a bunch of lines of text. The Controller, in this case tied very closely to the View (because they're both in the client), is our source of input from the user to the simulation, through mouse, keyboard, stylus or joystick.

The work for the designer and programmer is to decide what the communication between Model/View and Model/Controller is going to look like -- to design a proper transition function, as talked about in the article. If something moves in the world, we need to tell the View that this has happened, possibly with the path taken, the speed done, the direction the object faced, etc. In the 3D world, the mesh will be animated smoothly on the client; in the 2D world, it may hop from "tile" to "tile", or may "slide" from one to another; and in the text world, a sentential description of the move would be provided.

Likewise, if the player wants to move herself forward a few steps, her Controller might have her hold down the up-arrow key on the keyboard for a second or two, or might use left- or right-click on the terrain in front of them on the screen, or perhaps typing walk forward 3, all of which are translated into a "walk forward" or "walk forward 3 steps" or "walk to here" message to the Model.

The "trick", in the case of the View, is finding out all of the information that needs to be sent from the Model, and then figuring out how to represent it in all View implementations. Likewise, every type of Controller needs to be able to communicate the players' needs, completely, all boiled down to the common "language" that Controllers use to make requests in the Model.

In theory, people should have no advantage or disadvantage given any implementation of View or Controller. That is, no View information should be extra to some or lost to others, and actions in the simulation should not be possible in some Controllers and not others. While it's a given that for speed-dependent simulations, certain interfaces will have an advantage, it should only be based on time and not lack of information or ability. The time it takes to read the description of the monster is certainly longer than visually seeing some 3D monstrosity eating your head, and typing "shoot bug-eyed creature" over and over is going to take longer than right-clicking on the screen a bunch of times... but these are all limitations of the player, not the interface.

Since I've never read Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, I don't know for sure whether my description of Model/View/Controller is the same as they present; what I've talked about above is something I came up with independently. I have obviously heard of design patterns, though, and the book I talked about before, Massively Multiplayer Game Development, makes mention of them, so I've started reading Design Patterns to finally see what the fuss is about. I'm sure that there will be other patterns in there that are intuitively obvious (to me, anyway) like the MVC pattern, but perhaps I'll learn some other useful nuggets that might be applicable to the MMORF project.

No comments: