#31: Engineering MCRPGs: An Introductionby Shannon Appelcline
November 12, 2001
Back in Thinking Virtually #10, DEaD Again: A Statement of Purpose I described the three aspect of MCRPG creation--of any game creation, really. Design, development, and engineering.
Design was what I discussed in the first twenty installments of this column. It's the art of figuring out what your game is going to be about in all of the broad aspects. It can be a very large amount of work, but it's just the tip of the tip of the iceberg. What will take months or years of your life is what comes next--the development and the engineering.
Really, development and engineering go hand in hand. They're both about expanding your basic game designs until you have something complete and finished. Development, however, is really about the storytelling aspects of your game--things like plot, which I spent the last ten installments on.
Engineering, on the other hand is about expanding the mechanical aspects of your game, the actual systems which I tried to get you thinking about in articles like The Game Is what the Game Is. And that's what I want to return to today.
This article is the first of an extended series on engineering. For the next 19 columns I'll be talking about some of the biggest problems in MCRPG engineering, and how some people have started to solve. But, before I go there, I want to offer a wide broad overview of engineering--of what I really mean by the topic.
Defining the Medium
In the MCRPG medium there are two main categories of engineering tasks. The first is the development of the mechanics of the systems that the players interact with inside a game--combat, experience, that type of thing. It's very familiar to RPG gamemasters, and so I'm going to only briefly touch upon it in a later part of this article.
The second category of tasks, however, is a little more alien to RPG gamemasters. MCRPG engineers have to figure out how players interface with the systems, with each other, and with gamemasters through a very specific medium--the medium of the MCRPG.
0Before I go on, I should probably define what a medium is. According to definition 5a of my OED, a medium is: "An intermediate agency, means, instrument or channel. Also, intermediation, instrumentality: in phrase by or through the medium of. spec. of newspapers, radio, television, etc., as vehicles of mass communication." I've actually been talking about mediums a lot during the last three months: movies, television, comic books, RPGs, and ... MCRPGs.
So that begs the question: what is the medium of MCRPGs exactly? I've already defined the term, Multiplayer Computer Roleplaying Games, and that actually gets us much of the way to a definition. I'd say the MCRPG medium:
I'm also going to show my bias by offering one other definition of the MCRPG medium. It:
This definition fits in really well with MUDs, MUSHes, and the games that my own company, Skotos, creates. But, it would seem to neglect many current games like Ultima Online and EverQuest which meet the definition of MCRPG at least as well as the AberMUDs that I was playing back in 1989. Why? Three reasons.
First, I somewhat believe in the maxim of writing what you know. And, I know text-based MCRPGs. I played their "Adventure" game predecessors in High School and enjoyed MUDs in college. I've now spent almost three years working at a company where I concentrate on text-dominant MCRPG games.
Second, I honestly believe that text games are better suited for the MCRPG genre. They can do a better job of creating stories with impact, just as books can often outdo movies. Their text basis allows for the type of rapid, easy development that an online gamemaster will desire; most gamemasters just don't have the time or knowledge to spend long days rendering three-dimensional models. And, they build upon the fact that tabletop RPing is primarily a verbal medium, not a visual one.
Third, even graphical games like Ultima Online do use text. It's how you communicate with other players verbally. How well or poorly they do so may ultimately be a factor in their success.
So, in defining the medium I've laid out three main points: connection of multiple players; computer arbitration; and textual interface. But I'm going to go a little light on the last element on the definition, to acknowledge the fact that other types of interface do exist.
Interfacing with the Medium
Back to my point: MCRPG engineers have to do something that tabletop RPG engineers don't ever have to think about. They have to figure out how players are going to interface with each other, with gamemasters, and with the game itself. It's traditional computer I/O: input/output.
Graphical computer games like EverQuest have what I consider to be a fairly simple and uninteresting I/O.
The input is based upon graphics on screen. You click on a sword, then click on a scabbard to put the sword in the scabbard. You click on a person to see basic information about them. You click on a monster to attack it. You click on a spell book to see a listing of spells, then a flame to see fire spells, then a fireball to attack. When the graphical input fails because you're trying to do something complex, you fall back to keyboard commands like "/autosplit" or "/wave" or "/cheer". If you're trying to do something really complex, and the game actually lets you, you might as well be using a full text parser: "/pet follow me".
The output is likewise almost entirely graphical. You see whatever pictures graphic artists turned out of their 3-D raytracers, all put together into a fairly beautiful whole. But you tend to get lots of repetition--lots of stuff that looks exactly alike--because turning out new graphics is expensive. Likewise you don't always have a lot of detail, and some of the intricate tricks you can do in a textual parser--like grouping together like objects--totally fails in graphical output.
So that's the world of graphical I/O. It's definitely something that requires huge amounts of engineering. It has intricacies and challenges all its own, without doubt, but they're ones that I'm less familiar with. (If someone is interested in exploring the topic in ways that I can't, feel free to drop me a line, and I'd be happy to guest you into a future Thinking Virtually.)
Likewise, I/O in text games has a lot of intricacies--and these are topics that I'm likely to explore more in the future.
Input is done through something called a "parser". This is a portion of the computer game which tries to understand the commands that you're typing in. Most textual MCRPGs require that you type imperatives--which is to say commands. This can actually allow a lot of different possibilities. The Skotos parser, for example, supports adjectives, nouns, verbs, adverbs, pronouns, and prepositions. Things like:
> skillfully massage the beautiful girl's back > point excitedly at the full moon
However, the Skotos parser still has limitations that we're working on. It doesn't currently support a sentence with both a direct and indirect object in it, nor do conjunctions work in most parts of the parser. The following two imperatives are both things I'd love to see accepted by our parser, but currently aren't:
> wave my fist angrily at the haughty noble > sharpen my sword and sheathe it and invade France
(As I write this, one of the Skotos engineers says that the former command is actually possible in some experimental code that hasn't been committed to our main development tree yet; however, there's not yet any ability to invade France conjunctively.)
Engineering textual input isn't as easy as just writing a parser that understands each part of speech. You have to solve questions like:
Output in a textual MCRPG can also be a tricky thing. You have to figure out how to describe locales to players, and allow them to view those locales with variable levels of description. (Are they just glancing or really searching an area?) You have to figure out how to rationally group together a mass of potentially unrelated objects in a room. You have to determine how to allow players to cut out the chaff in a very loud and busy location, only seeing or hearing those things that are important to them.
Graphical games just punt on a lot of these issues, because the graphical medium doesn't allow for this level of individual differentiation .... but they also can on occasion take advantage of the fact that their graphics are interpreted by a second very powerful computer: the human brain. If a graphical player sees a mass of stuff on a screen he's going to do some of this grouping on his own ( 1 ).
There are advantages and disadvantages to every medium.
And I think that's sufficient summary on the issues involved with engineering MCRPG interface systems. They won't be a very prominent topic in the months to come, but they are a useful foundation.
Expanding the Systems
And that brings me to the second type of MCRPG engineering--the one that will weave in and out of my narrative for the next nineteen weeks: engineering MCRPG game systems.
As an RPG gamemaster or player you're well familiar with game systems. They are the system that arbitrate how you fight critters; and the system that determine how you get better at what you do; and maybe even the system that figure out what happens when you're suffocating or on fire or piloting a starship or grappling an opponent.
Game designers have to spend a long time engineering those systems. They have to figure out how to make the systems intuitive and balanced. They have to figure out what type of game play they encourage. (Why was AD&D 1st ed a hack-and-slash game while RuneQuest 1st ed was a game of skill use and Hero Wars is a game of storytelling? The game system.)
The important thing to remember when engaging in engineering is that you're not just mechanically engineering components of your game, but you're also socially engineering players. What you do has effects, and that's a topic I'm sure I'll be returning to in the future.
We'll see bits and pieces of a whole bunch of game systems as I move into my next topic ...
Solving the World's Problems
And that's an overview of what I mean when I'm talking about engineering. I'm talking about figuring out how your interface should work; and designing your game systems; and figuring out how those systems encourage certain types of game play. I'm talking about the programming that goes into an MCRPG, but also the careful thought that goes into that programming. Engineering can be just about anything in MCRPG design ... except for the storytelling aspects that I've already neatly filed away under "development".
So, expect plenty of variety as we move forward.
In developing systems, MCRPG engineers have traditionally run into a number of problems that are somewhat hard to solve. Some are people issues, some are administration issues, and some are mere mechanical issues. They run the gamut and include questions like:
For the next nineteen weeks I plan to discuss some of these issues and many others in "The Top Ten Problems for MCRPGs". I'll be finalizing the topic list next week in an overview and will be spending between one and three weeks on each topic. I hope it'll be an excellent introduction to many of the general issues facing MCRPG designers.
I'll see you for the start of that in 7!