The Technology Behind the Games

There is quite a bit of technology under the hood of Skotos games, despite their text interface. Game players can play the games either through an HTML-based client or through an Active-X client. The HTML client is accessed through web pages, while the Active-X client is a downloadable one intended for more lengthy game play.

What about on the server side of things? At the base level, Skotos games use a modified version of DGD, Dworkin's Generic Driver. DGD was written by Felix "Dworkin" Croes as a replacement for Lars Pensjö's original LPC driver, the code which let LPMuds work. DGD implements LPC, a variant of the C programming language designed for LPMuds. The operating system which Skotos games used is called SkotOS, and runs in DGD.

DGD can be used for a wide variety of programs, not just LPMuds. Several years ago ichat (which became Acuity Corporation before being bought by Quintus Corporation, in case you wish to navigate the maze of twisty corporate acquisitions, all alike) got the commercial license rights to DGD and used DGD to create a series of chat applications. Skotos in turn licensed those commercial rights to DGD from ichat/Acuity/Quintus.

While DGD and SkotOS form the back-end of the Skotos server, its front-end is a modified version of XML, the eXtensible Markup Language. Everything in a Skotos game, be it a player, an object, a verb, or a help file, is created using XML.

Why XML? One reason was to make creation of the Skotos game development environment, which is web-based, easier. XML can be readily parsed into forms and then displayed in web pages. Another was to make game programming easier for the novice programmer. While game designers can edit the raw XML code, they can use the web forms as well, making the code more readable to non-programmers.

Physical objects in the game world are all instances of the same class of programming object. The runtime engine views all physical objects the same way in terms of internal code. The only differences between, say, a stone altar and a rapier are those that are specified within the data of the objects themselves. The rapier might have a flag which indicates that it is a weapon, while the stone alter might have one which indicates that it cannot be picked up.

According to Par Winzell, Skotos's lead engineer, this was one of the best decisions they made in designing SkotOS: This all-data approach lends consistency to Skotos worlds. To see why, consider how object behavior is handled in Diku MUDs, which are statically-compiled and have all game logic defined by a central engine, and in LPMuds, which allow pieces of a game world to be changed while the game is running and do not use a central engine.

In an LPMud, if you wish to create a sword which can cut a rope, you code a "cut" verb in a scripting language, a specific sword, and a specific rope. The "cut" verb is programmed to see if the player is using that specific sword on that specific rope. But what happens if a player picks up that sword, goes to another part of the game, and tries to cut a loaf of bread with it? If whoever coded that loaf of bread didn't take into account your "cut" verb -- and how could they, unless you told each and every programmer? -- then the player can't cut the bread with the sword. The result is a collection of objects which don't work consistently together and which don't have a consistent user interface.

In a Diku MUD, you would have to add a "cut" verb to the central simulation engine, which would define how that verb by default works with various objects. Then any object that flagged itself as "able to be cut" could be cut properly. (This is also how traditional text adventures are programmed.) In effect the central engine is acting as a clearinghouse for game logic, making sure that consistency is maintained across all items. "cut rope with stone altar" might not make any sense, but the game should acknowledge your attempt, if only with a sarcastic message.

Does that mean that game designers can only allow actions which are already programmed into SkotOS? No. As Par said to me, "We wanted the centralized consistency enforcement of defining an object entirely in data. That said, we have actually implemented two separate scripting languages, and are now engaged in the tricky task of recommending their proper use without the integrity of our virtual reality crumbling under our feet."