A completely different Myst fan game

I have talked a lot about the prospect of Uru players creating worlds after Cyan shuts the game down. But I haven't said much about the fan Myst projects that exist today.

Quite a number have been started over the years; Cyan is generally willing to give permission if you ask nicely. Some exist as small web-based adventures, such as the now-vanished D'ni Legacy. Some are planned as full-scale downloadable games, such as The Ages of Ilathid -- ambitious, but making slow and uncertain progress.

A year ago, in April of 2007, I ran a small game directly on the Uru web forums. Plum Lake was pure text -- because that's what I'm good at, that's why. (Okay, I included one illustration.) I took the standard text-adventure model and ran it interactively. I would post to the forum, describing where I was and what I saw. Then I'd open the floor to suggestions on what I should do next.

My game ran for about two weeks, and concluded satisfactorily. The players reached the end of what I'd designed, and I decided it was an experiment well run.

A few months later, a player called Norfren began running something that comprehensively and conclusively blew my game's pants off.

He began by posting several images notionally captured in the Age of Minkata. Cyan had opened Minkata in May; it was an expansive but barren world, hemmed in by blinding dust-storms. Norfren's images were not actually from Uru, but people were willing to accept them as an extension because they were imaginative and nicely rendered. (Using POVRay, a free ray-tracing package. Some of the images have Uru avatars edited in.)

Over the next couple of weeks, Norfren began describing his journey across Minkata in a first-person, narrative style... and in plural: "we are here, we are doing these things." And the readers played along, describing what they were doing as members of the exploratory party.

By the end of October, the scenario included puzzles and linking books, and the readers were fully engaged -- solving the puzzles and allowing the narrative to advance. They found their way underground, explored a series of aqueducts and tunnels, found a link to an undiscovered section of the D'ni city, and so on.

(Warning: Posts in the forum thread consistently use Javascript spoiler tags to hide both large images and puzzle solutions. However, due to a recent server change, the spoiler tags are currently nonfunctional -- everything is visible up front.)

Throughout this process, the bottleneck remained Norfren's ability to render new art. He could respond to ad-hoc ideas to some extent, but had to provide fairly clear hints about what to do, and occasionally nudge players back into the areas that he was preparing. The players were quite willing to go along with this.

In late December, Norfren posted images on his own web site, in order to accomodate some animated details. In late January he included a 360-degree view, and then a puzzle that responded interactively. And in early February, as we were digesting the news of Uru's cancellation, a complete (if tiny) Age to look around. (Contributed by vikike176, in collaboration with Norfren.)

By the way, I'm focussing on the designer's work here, but don't get the idea that the thread is all his. Most of the text is the player group, poking around, making suggestions, goofing off, adding their own wrinkles to the narrative. Everyone is clearly deferring to Norfren as the "game master" -- nobody is posting their own images of unexplored areas, for example. But the tone of the thread is the players telling their story, not Norfren telling a story to them.

Finally, in March, a puzzle unlocked a fully explorable Age, complete with clues, puzzles, links to other Ages, a maze, and finally a link home to Relto, which resolved the story. I don't know if the author intends to continue, but it's enough of a stopping point for me to blog about it: six months and over 900 posts, including dozens of images.

So what does this tell us?

"Surprise in Minkata" (I have no other title for it) constitutes the biggest chunk of exploration in the Myst universe since Cyan ended its Age releases. The visual quality is not on the level of a modern commercial adventure game; but it's easily comparable with the original Myst, or with other one-man adventure creations like Rhem. I could quibble with the placement of navigation hotspots in the final Age. But, overall, it's effectively a player-contributed Uru episode.

I think that if the game had continued, we would have seen more like this. And with no Uru in operation? The audience is clearly waning, but the most dedicated players remain. We will see what the coming year yields.

Design Sketch for an MMO Adventure Game

Uru Live is scheduled to be shut down in a bit over two weeks, as I write this. Cyan has not made any public pronouncement about what they will do next. They haven't said if the online version of Uru will remain available in any form.

(We know that Gametap will return Uru: Ages Beyond Myst to their rental service. That's the original single-player Uru game -- without even the expansion packs -- and you can't hack Gametap downloads to add new content. The news is therefore irrelevant to me. I'm interested in Uru as a shared, extendable universe.)

My last post worked around to the idea of a fan-created Uru game. Not an extension of the existing Uru, not managed by Cyan; a completely new system, open-source and run by the players. This post contains my sketch of how to do it.

In other words, this post will be too technical for the game nerds, and too handywavy for the programmers. I have no code to back it up. I have experience running a multiplayer gaming service... which has never had more than a dozen people online at a time. So -- dismiss away, if you want.

On the up side, the technical issues here are not specific to Uru or to the Myst universe. Want to run a graphical MMO adventure? Here's a plan. Go to town with it.

So...

---

How would I design a fan-run Uru-inspired game?

This post is speculative -- in fact, completely hypothetical. If:

• Cyan shuts down the Uru servers on April 10th, and
• they do not offer any future plans for Uru, and
• a group of Uru players want to begin operating a new multiplayer adventure environment for the Uru community, and
• I were making all the decisions,

...then what would I build?

This post does not rise to the level of a proposal. It's a sketch; it's my answers to a bunch of hypothetical questions. I'll argue the merits of each point separately; you don't have to accept my ideas on one point just because you buy another.

This is a conservative proposal; it's a system I think I could build. However, I am not volunteering to build it. Planning is the fun part. I have too many unfinished projects already to pick up a new one. But I can gab about ideas all day. Lucky you, eh?

---

Assumptions

I want a multiplayer, graphical, 3D environment that approximates what people did in Uru Live.

I will rely entirely on open-source software. Cyan's Plasma engine will not be used.

I do not want to infringe on Cyan's ownership of the Myst series, or their ability to bring back Uru Live someday. (It will always be true that Cyan might bring back Uru Live.)

The plan will be implemented by a small group of part-time programmers. (Not crazy genius programmers; just programmers.) (Maybe I am a crazy genius programmer, but I'm not volunteering to build this, right?)

The result does not have to be as impressive as Uru Live. (See previous point!) We can tolerate shakier graphics, less scalability, and so on, because we have no budget and nobody's doing this full-time.

The game world consists of a set of small areas -- Ages, in Myst parlance. Each Age is replicated in many instances. Any player or group can get an instance of their own; instances are cheap to create on the fly.

The goal is for players to hang out in the environments and chat.

The goal (also!) is for players to contribute new Ages, and explore each others' Ages.

Socializing happens in medium-sized groups -- perhaps twenty or thirty. That's the size of a conversation. Getting a hundred people together in one place would be neat, but it's not a design goal.

Exploring is done alone, or in small groups. Interactive environments stop being fun when a bunch of strangers are jumping in front of you and messing with your stuff. Adventure-style game logic -- with specific, discrete actions and unique results -- tends to have a small number of actor roles. When you have a hundred people cooperating on a task, that's CRPG design, not adventure design.

In other words: while I want a game world that encompasses hundreds or thousands of people, I'm not worried about rendering them on the a single screen or managing their simultaneous access to a single real-time puzzle.

---

Overall Architecture

The plan in short:

• many independent shards
• • but probably one shard is the "main" or common shard
• • each shard can contain many Ages, at the shard owner's discretion
• • anyone can run a shard, if you have a server with Python and MySQL
• Jabber is the communication layer
• • an Age instance is a Jabber MUC (chat room)
• Ogre3D is the client 3D engine
• • scripting is in Python (both client-side and server-side)
• limited character animation
• no physics
• storyline is not my problem

The Shards

A "shard" is a stand-alone, fully functional server running the game system. (It might actually be several machines, but imagine it as one host.) Uru Live has a single public shard -- when you log into Uru, you're in the Uru world, and you can (potentially) meet anyone else logged in at the same time. Other MMO games run many shards, but they're all managed by the same company. (Actually, in the 2004 Uru Prologue, Cyan put up two or three shards for load-balancing reasons.)

I envision my game system being much more heterogenous. I don't like the idea of enforcing one server for everybody, or one player database. I don't even want a single group of people operating the game. This should be an open system. That means anybody can run a shard. Download the software and set it up; you're on.

Shards should be completely independent. We don't want one badly-maintained shard to corrupt others. We also don't want the whole system to die because one person went on vacation. By keeping shards separate, we can keep problems contained. We can also address scaling issues -- crudely but effectively -- by setting up more shards.

Anyhow, there won't be any notion of global avatar progress, because there is no global set of goals or achievements imposed. So there's no real reason to share avatar information between shards.

Naturally, I expect one shard to be the common place where people hang out. There could also be a development shard for the Writers, a testing shard for the Maintainers (or maybe several), and private shards for small groups or for the hell of it.

When you decide to run a shard, you decide what Ages it will contain. This will be a plugin system; you download an Age plugin (Python code) from whoever wrote it, stick it into your server directory, and presto. Some Ages may be used in all shards, others might be featured by a single shard.

There can be a published list of public shards -- I'll accept that much centralization. (It could be as simple as a wiki page.)

Scenario

(This section is, of course, specific to the Uru mythology.)

The Called, exiled from the Cavern, gather on the surface to discuss their future. Their Relto books no longer work; Yeesha has apparently abandoned them. But the Guild of Writers announces a breakthrough: intensive computer analysis has found some of the underlying structure of the D'ni linking symbols. Surface dwellers are beginning to create effective Linking Books.

While the Guild cannot replicate all of Yeesha's techniques, they have discovered some useful tricks. Instancing is one. More important is the ability to replicate linking pages -- literally print them out on an inkjet printer. (This only applies to modern-made Books, not to Relto or D'ni Ages.)

This means you can carry around a sheaf of link-home pages on your belt. When you use one, it remains behind (and disintegrates -- biodegradable!) but you still have the rest of the sheaf. Similarly, if you come across a Book that you want permanent access to, you can lift out a linking page and take it home to your library. As long as the Book's creator included a whole sheaf of pages, the Book won't be damaged, and there will be plenty for future explorers.

Your "home" in this scenario is not a beautiful island Age. It's just a small room in your house or apartment -- a closet that you've converted to an office for your Uru work. Very plain. (You might get to customize the color of the walls.) You have a desk, a bookshelf and a stack of linking sheets. This is your entry point to the shard, but its game function is more like the Nexus than like Relto.

You have a book for a community Age (Ahra Pahts or something like it). You have, or will gather, more books and pages as the shard provides them.

Since all these Ages are written by surface dwellers, we have no access to any D'ni Age we are familiar with. Nor will you find any links to the Cavern, or any other place on Earth besides your home. There may, however, be traces of the D'ni out there in the Ages we explore -- perhaps even other civilizations with linking technology. The Tree has many leaves, and no one knows what the next one might hold.

(This scenario takes a deliberately conservative approach to Cyan's intellectual property. I assume that the people running this game would want Cyan's permission, but would not want Cyan to take an interest in controlling the game world. To get that, I take a long, ostentatious, good-faith step away from their financial interests. Cyan has always hinted that their outlook on player-created Uru content would be "No D'ni history, no D'ni Ages." I can live with that.)

(Of course, if Cyan is cool with us using their toys, that's great. I'd want to at least use the familiar Linking sound effect!)

Storyline: Not Mine

Uru Live wanted to be very story-oriented; much more so than most MMO-RPGs. And Cyan wanted to have firm control over Uru's story. They did not, most people agree, get the balance right. Control versus flexibility versus coherency versus player involvement is a long argument, which I will not reiterate here.

In a fan-run game, I don't think one group should be in control of all the story. That model doesn't even start to work without a lot of community trust of the game-masters -- a different kind of trust than mere technical adequacy. Cyan held that trust tentatively, and (for a lot of players) squandered it. I do not propose to re-vest that trust in another cabal.

Rather, I'll let everyone do their thing. (The Myst logic of many separate Ages encourages this.) If something good emerges, it'll have to emerge on its own. So this section of the plan is up to everybody. Yes, including you.

---

Architecture Details

Language: Python

Obvious choice. I like Python. Uru's client scripting is Python, so anyone who's played with Age creation so far has at least seen it.

(Security is a weak spot. I will address this later.)

Communication: Jabber

Jabber is a widely-used IM and chat system. Google Talk and Livejournal's chat system are both Jabber.

Using Jabber as the transport layer for a game is a compromise. I'm using it because I'm used to it. I've implemented a board-game system (Volity) using Jabber, and I am writing this plan to work very much the same way.

Basically, the shard server is a Jabber bot. Each Age instance is a Jabber chat room, managed by an instance server, which is also a Jabber bot. Your client is a Jabber client with a fancy graphical display; when you enter an instance, you join that chat room.

Pros:

• Open source. Jabber libraries exist for lots of languages, including Python.
• Supports Unicode from the ground up.
• The Jabber server handles authentication and encryption for us.
• Jabber is firewall-friendly; it only needs an outgoing network connection (to the Jabber server).
• It's a chat system, so game chat is covered. (And it interoperates with every other Jabber chat server. Someone running iChat on a Mac, or Google Talk, could send you a message in-game, same as they talk to anyone else.)
• Jabber is extendable. Sending movement or emote messages through Jabber isn't a gross hack; the format is designed to let people design new message types.

Cons:

• Not as fast as a raw TCP connection. (All messages go through the Jabber server; all messages are XML snippets. Message encoding, transport, and decoding take time.)
• We'd probably want to run our own Jabber server, which is a bit harder to set up than (say) a wiki or an IRC server. (The architecture I'm planning doesn't require customizing a Jabber server; but things are faster if the game servers and the Jabber server are on the same machine.)

A Jabber-based system would not be as speedy as Uru Live. My experience from Volity says that game actions would take a small fraction of a second -- say, 1/4 to 1/2 second. That's fine for board games; it's fine for chat and emotes. But it's a bit slow for a 3D game. (Imagine that fractional delay every time you push a puzzle button.)

More importantly, Jabber is not optimized for many tiny messages. When you walk around in Uru Live, you are sending a constant stream of avatar position updates. My Jabber-based system can't do that. (The XML snippets aren't huge but they're bulkier than a typical MMO walk packet.) So it would send those updates much less frequently. Maybe once every ten seconds, or less often than that. In a crowded instance, the server might have to filter that down even further. Chat, emotes, and action messages would have priority.

Basically, movement of other avatars would look like occasional jumps. You wouldn't get the walking-around that you're used to. You might fail to see someone who just arrived, or see somebody present who really walked away thirty seconds ago. A static conversation -- several people standing in one place talking -- would be fine, though.

As I said, it's a compromise. I think of chat and puzzle-solving as being more important to Uru than smooth animation.

(By the way, when I say movement is jumpy, I'm talking not talking about your movement. Your viewpoint will move smoothly, like in any 3D game.)

(An alternative: you could treat movement updates as a very special case. Don't send them via Jabber; have a separate stream, binary-encoded and UDP. You'd need to treat the UDP data as unreliable, superseded by any Jabber data about that avatar. But I was planning to do something like that anyway. See the "Synchronization" section, below.)

Display: Ogre3D

I typed "open source 3d engine" into Google and Ogre was at the top of the list. It's portable and it supports Python scripting, and that's all I was looking for. If some other package turns out to be better, that's fine too.

Other possibilities: Irrlicht; NeoEngine; Crystal Space.

Note that I have listed 3D graphics engines. I am not considering game engines, MMO engines, or online virtual world systems. I don't want a software package that comes with communication or server code; I'd just have to rip it out.

It may sound stupid to plan to write MMO communications code "from scratch". But it's not really from scratch. Jabber is a complete, working, scalable message system. And the game server code needed for adventure gaming is really not complicated. Jabber bots that talk to a database, and write a limited amount of instance state, should be easier to maintain than a third-party virtual-world system.

(Of course it's perfectly reasonable to plan an Uru game using an existing MMO client-server solution. It's just not this plan. For the sake of completeness, here are some open-source virtual-world projects: Uni-Verse; Croquet; Project Darkstar.)

Age Distribution

An Age consists of two parts: a server module (Python), and an Age package (ZIP file containing textures, 3D models, and Python).

By the way, the Age is identified by a URI (a string), rather than by a sequence number. (URIs are great. Anybody can invent a URI without worrying about collision -- just pick one based on your home domain or email address.)

The server module is downloaded once by the shard admin and installed into his shard config. The module contains the URL of its Age package. (Or the shard admin can specify a mirror URL, I guess, if he doesn't want to rely on the original author's web server.) The URL can be any web address.

There's also a general UI package associated with the shard. This contains clothing, menu images and scripts -- the stuff that the player can see in any Age and instance of the shard. (But note that different shards can offer different UIs. So you might have a standard Uru KI interface on one shard, and an enhanced KI on another.)

When a client logs into a shard, it downloads the UI package; when it links to an Age, it downloads the Age package. These are simple HTTP downloads, using the URLs that the server provides. We use an HTTP HEAD request (or If-Modified-Since) to skip the download if the client already has the package cached.

(Since downloads will be slow, we might offer the player a "download in background" button on the download screen. That effectively cancels the link, and lets him wander around the original Age or go somewhere else while his client finishes the download. We don't really want a "download all Ages" option, because there's no upper limit to the number of Ages on a shard.)

The client caches packages. So it will have to offer a way to clear the cache. Probably just a list, showing the last time each one was loaded, and a button to delete the older ones.

Note that this system is very modular: an Age package must contain every resource used in that Age. This is simple, but not efficient. (If a texture appears in three Ages, you'll download it three times.) I think simplicity is more important to begin with. If resource sharing becomes important, I'd do it by wrapping the shared resources up as a separate package; then the server module requests a list of packages (instead of just one).

Age Upgrades

Ages will change over time. But it's likely that different shards will update them at different times. This means we need a system for tracking different versions.

There are several upgrade scenarios:

• A server module is updated, but it doesn't require any changes to the Age package. (Bug fixes, for example.)
• An Age package is upgraded, but it doesn't require any changes to the server module. (Models or textures are improved with no change to the scripting.)
• A major update requires both the server module and the Age package to change.

The first two cases are pretty simple.

• Distribute a new server module. Shard admins will install it (or not bother) at their leisure. (For simplicity's sake, you have to take down your shard to install new Age modules. Cyan did it, you can do it.)
• Post a new Age package at your distribution URL. The next time a player links in, his client will download it. A player who is currently in your Age won't see the new models right away, but that's okay.

The third case is the tricky one.

• The rule is, if your Age update requires a new Age package, you must change the package URL. And you must leave the original package available -- because some shards might still be running the old version. You should only take down an Age package when you're sure that no shards out there are running the code that requires it.

(The server module and Age packages will each contain embedded version numbers which ensure that this matching is correct. I have a standard scheme for doing this, which I won't get into here. See version matching on the Volity wiki if you really care.)

Logging In and Out

The shard has a shard server, which handles new arrivals, and also shard-wide services such as personal messaging. The shard server, as I said earlier, is a Jabber bot (written in Python). It is always logged into Jabber, and can talk to a MySQL database (the vault).

When you start your client and select an avatar, the client contacts the shard server. The server notes that your avatar has no active game session, so it tells you to link to your "home" instance.

(By the way, Jabber lets you log in with multiple clients at the same time. My game architecture is fine with that. You can drive two avatars around on different shards, or even on the same shard, as long as they're different avatar records.)

When you enter a new instance, the shard server starts up an instance server, which is also a Jabber bot. The instance server creates a Jabber chat room and sends the address back to your client. The client joins the chat room, the instance server sends you the local state (including other avatars), and then you are officially in the instance.

When your client disconnects, your instance server is notified (Jabber handles this automatically). It can then notify other players (in that instance) that you've vanished. (The shard server doesn't have to care that you've logged out.)

Chat and Friends

We rely on the basic Jabber facilities for chat and friends-list. When you speak in an instance, the message goes out to the chat room, and everyone else's client sees it. The instance server isn't involved at all. Similarly, when you send private chat, it's a regular Jabber chat message.

(Emotes are regular Jabber chat messages with a special tag naming the emote. Jabber lets you add special tags to any message. Other clients, like iChat or Google Talk, will just ignore the tags.)

Jabber gives you a friends-list. Whenever you log on, Jabber automatically notifies your friends; again, the instance server (and the shard server) don't have to be involved. Your client will add special tags to your presence notification to indicate which Age you're in.

(This won't work identically to Uru Live. For example, when you friend someone, they have to accept it -- that's a Jabber policy. And we can have a "recent" list, but it won't include the player's Age location, because you only get presence notifications from friends and people in your chat room.)

No Physics

The Uru physics engine is a big old pain in the butt. Way too much of Age development is "find the collision holes; find the improperly climbable walls." Coordinating a rolling object between many players is a significant load on both CPU and network. The heck with all that. No physics. You won't be able to implement Jalak or Eder Gira, exactly. Big deal.

Certain polygons will be marked in the Age file as "floor". Your avatar can move around a floor polygon (strictly two-dimensional movement, no jumping). When you reach the edge of a floor polygon, if there's an adjacent floor polygon in the mesh, you can continue on to it. If not, you stop.

Ladders are "floor" polygons with a vertical orientation. The client doesn't have to treat them specially, except to change your movement animation. Same goes for water. You can't fall through the world because there's no falling. You can't get flung through the ceiling by a misaligned ladder. Everybody is relieved.

(Yes, that ladder flinging thing really does happen with Uru's Plasma engine. Take a look at the Guild of Writers' instructions for ladder placement. Not pleasant.)

Some "floor" polygons trigger scripts. We will get more into this later, but this is how you do a falling or jumping action if you want one in your Age. You mark a specific polygon with a script saying "When the player walks here, move him down to that floor polygon there." (Or panic-link him with a falling animation.)

Limited Avatar Animation

I'm leery of animation because it's unexplored territory. The current Writers group has people working on textures, models, sounds, and scripts, but nobody has touched character animation (as far as I know). So this plan includes only minimal animation work. Stiff walking/running, stiff ladder-climbing, maybe a stiff panic-link move.

I'm assuming that simple animations -- a door opening, a globe rotating, an avatar falling straight down -- will be easy. However, Uru Live currently has a huge palette of fluid avatar animations, for emotes and story actions. I don't think we're going to replicate those, not right off the bat. We're certainly not going to have the perfect finger-on-button, hand-on-rung precision that Uru Live offers.

But I've already conceded that avatar position updates will be slow and jumpy. So weak animations don't really make things worse. You're just going to have to get used to avatars standing around and being stiff.

If someone then comes along and offers better animations, that's great.

Synchronization

This is the hard part of the MMO problem. (It's certainly the part that Uru Live had the most trouble with.) Keeping everybody's world-state in sync is easy, if you don't mind lag; avoiding lag is easy, if you don't mind client inconsistencies. Then your database bogs down, and you have the lag and the inconsistencies.

This scheme is optimized for Myst-style adventure gaming. That means small Ages, with a relatively small amount of persistent data. (Kadish Tolesa has maybe fifty stored values for all its puzzles.) And not too many people interacting with one instance's puzzles at a time.

(If you want gigantic Ages with lots of players interacting with lots of objects, I can't help you. That's a hard problem. Go talk to the people who run Second Life or OpenCroquet.)

The general rule is: the outcome of game actions will be decided by the server. (This is in contrast to Uru Live, which left a lot of decisions to client scripting.) Jabber messages are reliable and in-order, so as long as the server processes commands sequentially, consistency is assured.

This costs. Reliable, in-order messages can be slow; they can bottleneck. So we have to be careful to make server-side decisions quickly.

Therefore, our other general rule is: the instance server keeps all the instance state in memory. It shouldn't hit the vault database every time a door opens or closes. For transient events (like the Delin/Tsogal door opening), it won't hit the database at all. Permanent state changes (like the Bevin book room door opening) will have to be written to the vault, but that can happen as a periodic checkpoint. As much as possible, we want to avoid a player action blocking on server database work.

Nonetheless, when you push a button, there will be a brief pause before you see a result. If the server is stressed, this may be a long brief pause. In general, you will be "stuck" to the button until that server reply comes back. (Although in some cases this won't be necessary.)

This brings up the flip side of game actions: moving around. I've said that this system is pretty sloppy about player location. The client knows where you are, but the server (and other players) aren't updated that often.

"Great," you say, "leave location up to the client." But in many cases, game actions are triggered by location. (For example, the Cleft bridge that breaks when you step on it. Or the Gahreesen auto-doors. Or the Teledahn prison.)

It's easy to mark some "floor" polygons as having (client) scripts, so that stepping on them has an effect. But I just said that game actions suffer a brief pause, while the server replies with the result. Should you be beset by these pauses while you walk around an Age? I think not. Free movement is a big part of the immersive experience, and it's worth making an exception to keep it smooth.

The problem is, if you don't freeze when you enter a script region, you run the risk of "outrunning the script". (You start to run across the Cleft bridge. The server is running slow, and by the time it reacts, you've already reached the other side. Whoops! Now you're somewhere impossible. Not a big deal in the Cleft, but it could be a plot bug in another Age.)

To prevent this, we give these regions a "sticky" attribute. When you enter or leave a sticky region, the client sends a location update to the server. (The client does this regularly, of course, but it is careful to send one when it crosses a sticky boundary.)

Until the server acknowledges this update, you are logically stuck to the region. As far as the client is concerned, you're frozen. You can still move your avatar around, but you can't push buttons or trigger any other scripts.

Hopefully, this hidden freeze will be brief (a quarter second, just like being stuck on a button). Then the server reply comes back, and everything continues on; you never ever notice it's happened.

But say the server replies "Hey! The bridge just broke!" As far as the server is concerned, you were on the bridge when it broke. Game logic decrees that you must fall. So the client runs the "break and fall" event -- regardless of where you were. You teleport back to where you're "supposed" to be (the break-point of the bridge).

Again, in the normal case, it's only been a quarter second since you hit the bridge. Falling makes sense. But if the server is slow? Well, you might be teleported back several steps. Maybe even from the far side of the bridge. Too bad. Adventure game design needs reliable plot logic.

(Mind you, not every script region requires this kind of rigid control. If a room's lights brighten as you enter, that's just cosmetic; it's no big deal if it's out of sync with your "real" entering time. So that region wouldn't be marked sticky.)

There are more details to this plan. (What if you enter another sticky region while logically frozen? What if you fall off a cliff? What if you log out?) I won't go into them, because this section is already way too long.

---

Potential Problems

Scaling Issues

I've said that I'm willing to accept less scalability than Uru Live had. That doesn't mean I want to ignore the issue entirely. There are several walls that Uru Live ran into, and we should at least think about them.

• 
  Really large Ages: We'd like to support areas which are very large, but are divided into sections. The client doesn't render distant sections, thus saving polygons. (UL does this in Aegura. If you haven't noticed, it's because it does it well.) The 3D engine should support this out of the box; it's an old trick. Hopefully, it'll be easier than the Plasma engine's "multiple page" trick -- I understand that's kind of a hack.
  
• 
  Too many avatars: Even in a simple Age, if enough avatars show up, the 3D engine will eventually choke. The crude solution is avatar pop-in: the client only renders the fifty closest avatars to you. (Once again, we shovel all the graphical problems onto avatars.) A less crude solution (which UL employed) is levels-of-detail on the avatar models.
  
• 
  Client threading: Uru Live had a lot of problems where the client's Python scripting would hold up the Plasma rendering. (That is, some network traffic would arrive and cause a frame-rate glitch.) I haven't looked at the Python-Ogre interface, but I really hope we can avoid that. It will require careful implementation of the interface. I expect this to be the hardest part of the whole system, really.
  
• 
  Instance server overload: The biggest traffic load on the instance server is avatar movement updates. (Recall that chat, emotes, and Age-location are handled by Jabber directly.) In a crowded Age, the server will have to start ignoring movement updates. (Not the important scripted ones, but the normal step-by-step updates.) Jumpiness will get worse. We might even need a signal to tell the client to send fewer movement updates.
  
• 
  Vault database overload: All persistent updates in a shard are going to a single SQL database. (I am not smart enough to design a distributed database cluster. I can install MySQL.) My only plan is: don't create Ages which require lots of data written frequently. Keep everything in memory. Checkpoint occasionally; if possible, checkpoint only the state which has changed. (But you have to be careful to keep the in-DB state of an instance consistent.) If problem remains, bring up another shard somewhere.
  

Not Being MMO Enough

When I posted the first draft of this essay, the most common response was: "Jabber? Slow? XML? You can't run an online game like that! You have to compress movement updates into individual bits!"

Well, small UDP packets, anyway.

As I've said, this is a compromise strategy. Jabber buys you a lot: good authentication and encryption is not easy! And it costs a lot. But I'm not just making a quid-pro-quo argument. I'm trying to pick out what's actually vital to an MMO adventure game, and what people are simply used to.

Free-ranging, real-time movement is a recent addition to the adventure world. Myst 1 through 4 used discrete movement -- click on a location to jump there. Most adventures still work that way, although a handful (including Myst 5) have followed the Uru model.

Adventure interactions require you to be in particular locations at particular times -- the times when you interact. (With puzzles or with other players, it's the same constraint. Although other players are more flexible, since you can generally interact with them anywhere.) In between interactions is essentially gravy. Important, immersive gravy; it's when you absorb the game world. But in terms of what you do, the game doesn't care whether you're looking around at fixed angles, or turning in place, or moving freely. (Not until you enter one of those scripted regions!)

Uru players are used to the MMO model, where every avatar in view seems to move freely. (With occasional glitches; but then, Uru has much better movement animation than most MMOs.) But I'll note that not all adventure gamers are convinced. One of my friends tried Uru and then told me that he wanted a "click to jump" interface. The 3D movement repelled him; he hated maneuvering towards the button or lever or whatever he had his eye on. He just wanted to decide to be there.

That's not how I feel; I like free navigation, and so I've written this proposal to have it. But we should remember that there is no unassailable requirement for this stuff. You could take my plan and drop the free movement entirely; build the game engine to render a series of still views, with other avatars clustered in nice natural-looking groups around their respective location points. It would still be an MMO adventure game. (And you'd be able to drop the section about the sticky regions. I mean, eww. And I wrote it.)

Security Issues

Python is great in many ways, but one thing it's bad at is secure operation of downloaded scripts. That is, when you're getting arbitrary Python code off the Net -- like in an Age package -- you're trusting it completely. There's no way to run that code in a secure sandbox. A malicious Age script can very easily erase your hard drive, or install a virus.

(Old versions of Python contained a "rexec" module which was supposed to offer sandboxing. This is now deprecated, because it doesn't work -- Python actually got too powerful for it. There is also a secure-Python project I've seen, but I don't know if it's been verified or tested at all. I'm keeping an eye on it for possible future use.)

We can't ignore this issue. Anyone who downloads a free game and runs it is trusting the programmer; but this system is an extendable game, and it's intentionally as open as possible. We want a flood of new Ages -- we can't ask the user to trust everybody who contributes to that flood.

We're going to have to start by manually inspecting Age scripts as they are contributed. Ideally, we'd have one "safe" shard -- the common one, to which new players are directed first -- whose admin guarantees:

• that the Age packages that it links to have been inspected for booby-traps;
• that these Age packages are stored on the shard's own web server. (If the Age package is stored on the original author's server, a malicious author could "upgrade" the file at that URL at any time, adding a booby-trap.)

(The admin will also want to inspect the Python server module, but that's for his own protection, not for the players.)

This is additional headache and bureaucracy, which sucks. Development shards, testing shards, and private shards will certainly take a more freewheeling approach, which means we'll have to educate users about the dangers. That sucks too.

The up side is that inspecting Age packages should not be slow or difficult. Normal Age script code will be simple; it will call almost nothing except standard game APIs. If a script calls open(), socket(), or most general Python library APIs, something is wrong. If a script is obfuscated, something is wrong.

---

Conclusion

It's possible.

More quick links

A couple more quick links from the Internet, where "the Internet" in this case means "Chad Orzel's blog". (No particular reason; it just happens to be the place where I saw both of these.)

---

Susan Beckhardt gives a nice introduction to game theory. If you have no idea what I mean by game theory, or how you can think about games mathematically, read these. If the idea is old hat to you, go play a game or something. It's a quick link!

Let's Play a Game!

• The basic idea of game theory, using everyone's favorite example, Nim. (Or actually not -- it's a simpler subtraction game which she calls "G(6,3)". But you think about it the same way.)

Game Trees and Totally Finite Games

• How to analyze a simple game. (This is what people mean when they say things like Checkers is Solved.) Now, what is Supergame?

Third part to arrive after her thesis is turned in. Hopefully she'll give a description of the Supergame paradox, which I remember fondly from old Martin Gardner logic books.

---

And, in the "old standards" category: Relativistic Asteroids. (Java applet.)

Try the classic version, hit "S" to start the game, and then "F" to put the display in the ship's reference frame. (That's with the ship always in the center of the screen.) Accelerate around and watch Lorenz-Fitzgerald contraction in... action.

I apologize. Couldn't find any other way to end that sentence. I'll go get into the crate now.

Genre studies in scariness

A few months ago I played Penumbra: Overture, and wrote:

A survival horror game. I'm not sure why it's marketed as adventure. Perhaps because the technology isn't up to commercial survival horror games; the graphics are crude, the controls are clumsy, and there are only a couple types of creepy-crawlies.

The gimmick is a physics engine, on which some of the puzzles are based. Sadly, this is bad for the puzzles -- I spent a lot of time trying ideas which should have worked, but which I couldn't force the physics to comply with. And it's not great for the horror either. Rule of thumb: simulation engines lead to solutions which are emergent, surprising, and dull. You can kill nearly everything in the game by kneeling on a crate and flailing with your biggest weapon.

(from my web site.)

This week I played the sequel (and conclusion), Penumbra: Black Plague, and wrote:

This chapter fixes everything I complained about in the first game. The physics engine is now harnessed to serve the puzzles and plot, instead of the other way around. You still do lots of stuff, but your actions are now clear and definite when they need to be, analogue and simulation-y only when that's interesting. The combat is entirely gone; monsters may chase you, and you might even be trapped in a room with one, but you aren't flailing with a crowbar. You have to either run, or figure out how to use the environment to save your butt. More immersive, scarier, and far less dull.

Is this not interesting? ("You mean the way you reflog stuff from your website onto the Gameshelf?" Thanks, Steve, back in the crate please. We're doing Analysis, here.)

The interesting point, at least to me, is that the designers turned a mediocre action game into a good adventure game by taking things out. They took out the periodic attacks by zombie dogs. They took out the succession of weapons (broom, crowbar, hatchet). And they took the physics modelling out of many (but not all) of the story actions you undertake.

When we ask "what kind of game is this, really?" we expect the answer to be: whatever you spend most of your time doing. Overture had plenty of adventure-style puzzles and unique story actions. But they were paced out with zombie dogs. Furthermore, when you were wandering around exploring, you were watching for zombie dogs. (Which answers a slightly deeper question: what do you spend most of your attention on, in this game?) So Overture felt like an action game punctuated by adventure puzzles. Particularly since the action parts were flawed, and thus memorable. (Sorry! That's usually the way it works in reviewerland.)

("Survival horror" has a bit of cognitive advantage in this comparison. It's a subgenre of "action game"; but "action" these days implies some adventure-style elements -- if there's any storyline at all -- which there usually is. Action games will have some puzzles, some environment interactions, that sort of thing. Certainly all the well-known horror lines -- Fatal Frame, Silent Hill, etc -- have these adventure elements. Whereas adventure games are quite allergic to action-style intrusions. When minigames show up, as in Next Life, or even jumping sequences as in Uru, many adventure gamers mutter darkly and wave incense.)

Now, I'm not saying that the improvements in Black Plague, the sequel, stemmed only from negative changes. I fully acknowledge that the designers put in good stuff. They were able to do this -- and, moreover, make that good stuff dominate the game -- by dropping the elements that hadn't worked before.

Here's my second example: the physics puzzles. In Overture, at one point, you're being chased by a zombie dog. You run through a door and slam it. The door, being a weight on a hinge, bounces halfway back open again. Great. Some crates are nearby, and the narration hints that you should block the door. You drag the crates in front of the door. The zombie dog leaps against the door; since it's a massive object, and the crates have finite friction, the dog is able to push the crates aside. Great. I reload (the dog has killed me several times by now) and try piling the crates on top of each other in front of the door. The dog now pushes through them more slowly, and kills me.

At this point I've died about five times, and the best solution I've come up with is to slam the door, run back into a dark corridor, and hope the dog doesn't see me when it makes it inside. Which works, but then why was I fooling around with all these movable objects? Why did the game present them?

I never once managed to kill a zombie dog by dropping a crate on it, or anything clever like that.

In contrast, in Black Plague when you're being chased, you run. Generally if you make it through a solid door, the chase is over -- and you're into the next phase of the plot, because the designers have planned it out that way. In one case the zombie starts pounding on the door, and the narration hints that you should block it; but when you drag something in the way, it works. Because the game is scripted for it to work. If you fail to drag something in the way, the zombie bursts in and kills you -- try again.

This is where the fans of simulationism start howling about linear plotting. But the simulation puzzle didn't work, and the scripted puzzle did. Why? At least in this instance, it's because simulation means multiple fuzzy outcomes -- and all of those outcomes have to be fun, engaging, and advance the plot. That's hard to do! You fail to block the door, you slightly block the door, you block the door for quite a while, you block the door completely. Are all of those satisfactory? If one of them is only mostly satisfactory, is the player going to try to think of something better, or is he going to go on with a weakened game position?

(Which he may not even know is weakened. Remember, multiple plot paths add no value for a player who is only aware of one of them.)

Similarly, in Overture you have to maneuver some things into careful stacks, or particular positions. In Black Plague, generally, you just have to shove something into the right region; the game fits it into place automatically. Which means you're engaged with your intent, not with mouse mechanics. If the challenge is physical manipulation, then the manipulation has to be challenging; if the challenge is thinking of the right idea, then the manipulation only has to be satisfying. In other words: in an adventure, you're not supposed to fail for trivial reasons.

(There are satisfying interactions with the physics in Black Plague. You drag crates around in order to reach the "right region." This is fun, for the same reason that walking an avatar around is more fun than "click to go there." But it's not overused -- for the same reason that walking an avatar around shouldn't be slow or awkward.)

This is where the fans of simulationism start saying... "Will Wright! He rules the universe!"

And, yeah, he does. I am well aware that The Sims has better sales figures than the entire adventure genre piled up. Different game goal, different player goals -- in fact, the player's goal revolves around the fact that there is no game goal. This is the opposite of the story game.

Can they be combined? Well, maybe. I've spent this post arguing that Penumbra doesn't combine them effectively. That doesn't mean it's impossible.

Wright sure hopes it's possible; it's Spore. Thus far we have no idea whether its simulation elements and its goal-oriented elements will fit together. I hesitantly advance some skepticis -- hey! Ow! ...Okay, okay, I'm sorry! I'm just a cranky refugee from the early 90s -- from SimEarth and SimAnt, neither of which were, you know, any fun.

I don't think simulation-based adventure games are impossible. What I think is that they're really hard, and require months -- years -- of rebalancing and player feedback. This is what all the MMO-RPGs are doing, right? In a sense. They aren't simulating physics, but they have these immensely detailed combat engines, with thousands of dials to tweak and (hopefully) dozens of valid player strategies. And they always get it wrong a few times first.

Hopefully Spore has spent its months and years of buildup time on that balancing work. We'll see.

E. Gary Gygax and computer gaming

We have all just heard that E. Gary Gygax, the man who launched a thousand basement RPG sessions, has died.

Others will speak of his impact on the tabletop gaming world. But Johan Larson asked an interesting question:

I wonder how computer games would be different if GG hadn't created D&D. Conanesque fantasy [e.g., "kill him and take his stuff"] would surely be a smaller niche, but would there be any larger effects?

My immediate response is "Heck, yes."

(Note: the following is quite off-the-cuff. I haven't studied the history of computer gaming, outside of text adventures. I lived through that era, but I didn't see everything that went on. Nonetheless, this is my theory.)

Computer gaming would have been wildly different if D&D had never existed. As Johan implies, the earliest CRPGs (Ultima, Wizardry, Hack/Rogue) were explicitly inspired by the idea of getting D&D onto a computer. The earliest adventure wasn't derived from D&D, but D&D was a huge part of its evolution from Crowther's toy to the Colossal Cave that swept the computer world:

Kraley joined Crowther in a months-long Dungeons and Dragons campaign (led by Eric Roberts and including future Infocom co-founder Dave Lebling among the core of about eight participants). "[O]ne day, a few of us wandered into [Crowther's] office so he could show off his program. It was very crude in many respects -- Will was always parsimonious of memory -- but surprisingly sophisticated. We all had a blast playing it, offering suggestions, finding bugs, and so forth."

(from Somewhere Nearby is Colossal Cave, Dennis Jerz)

It's not a matter of a smaller niche. Withouth D&D, there would have been no such niche, not in those earliest years.

So what other influences were there? The arcade shooters (etc) were all there, independent of D&D. Maybe sim-type games would have taken off earlier, led by Hammurabi and Oregon Trail. There were Star-Trek-themed space-exploration games... Hunt the Wumpus? Maybe, maybe not, and Gregory Yob isn't around to ask. But Pong, Pac-Man, all those, they wouldn't be affected.

So there would have been games. But I can imagine years going by in which computer games did not have the notion of you on the screen acting. The player would control a starship, or an empire, or a yellow chompy dot, but not an avatar of himself.

It would have come along eventually, I suppose. And, okay, this is an extreme extrapolation.

Nonethless... I'd bet quite a lot that the computer game industry as we know it would have launched later and slower. Up until the mid-90s, it was adventures and RPGs that were big games; they drove the game industry in the direction of big budgets and big development groups. The arcade games weren't doing that. So, if RPGs had been delayed, the whole industry would have been delayed.

(Once Doom hit, it became the game-industry driver -- in the US, anyway. I suppose Japan remained firmly entrenched with CRPGs, the Final Fantasy crowd.)

And it goes without saying that a bunch of MIT wackos would never have formed a wacko startup called Infocom. So, there's my life unrecognizable. But I wouldn't be the only one.

It was thirteen years ago today

(...give or take a few months...)

So I heard this weekend that a design company called MOO is running an Internet Easter egg hunt, as a promotion for their company. Which is cool. Obviously, it's not a new idea; Easter egg hunts have been floating around the Web for as long as there's been a Web.

(I know, I'm blithely equating the Web with the Internet, even though I was an old Net hand during the Web's birth. But I'm not aware of any egg hunts that ran over Usenet or Gopher or anything like that. Anyhow, "Internet" means the Web to most people -- when it doesn't mean spam -- and "Internet Easter Egg Hunt" turns up more hits than "Web Easter Egg Hunt". Sociology in action!)

Since I am an egotist, I'm going to talk about the Easter Egg Hunt that I worked on. Which has the distinction of being, as far as I know, the first one: it ran in Fall of 1994. Think back...

(...twingly harp music...)

You're a student. (Of our 50 eggs, only five were on .COM sites!) You've heard of Web search engines -- Webcrawler and Lycos are just starting -- but they're not up to the task of finding Easter Egg links scattered everywhere. But you are; you can hunt through the most popular web pages and read them all. For the purposes of a silly contest.

Probably you found most of them by looking at Netscape's catalog of links to the entire Web.

(Yeah, take a look at those URLs. Bianca's Smut Shack! Phil Greenspun! Doctor Fun! People with top-level home directories on their university's servers! Really, the reason I'm blogging this is to bring up all that old stuff.)

If you want to see an actual preserved Easter Egg, look here. Not its original location, mind you. Notice that the author of that page invents the wiki, down in a footnote... I wonder if he ever realized it.

But this is a gaming blog, and the ghosts of Jmacs past, present, and hypothetical are yelling at me to relate all of this to gaming.

Well, it is gaming. It prefigures the Alternate Reality Game, doesn't it? Clues are scattered in real life, or whatever part of the Internet you can imagine is real life. If we'd attached a story fragment to each of our Easter Eggs, we would have beaten out the bee folks by several years.

Although, not exactly. Modern puzzles-for-the-community have been transformed by two things: the hive mind, and the search engine. Which is to say: everybody is pounding on your puzzle together, and they're using Google to pound with. Neither was true in 1994.

We worried about the search engines, mind you. Our contest rules asked people to please not write scripts to web-crawl for Easter Eggs. For the sake of the web servers! Imagine the traffic load! Which brought in the most wonderful bit of email:

That's ridiculous for you to tell people not to write "robot searchers" for the easter egg contest or it might bring the Web to its knees. Your warning is going to serve as a challenge. Obviously technodweebs are going to do just that. You should never have held this ill-timed easter egg hunt, or at least have anticipated how people would look for eggs. If Internet dies, we'll know who to blame.

Well, the Internet didn't die, and nobody wrote such a script as far as we know. But apparently we were the smartest people on the Internet, and the idea of search engines would never have occurred to anybody if we hadn't mentioned it. Good to know!

But enough about the past.

If Google is your hammer, does everything look like a nail? Perhaps not. If you don't know what words you're looking for, Google is helpless. Come up with a set of items which are recognizable only by their phrasing. Paraphrases or misspellings of famous quotes? Bits of poetry in a common meter? Or images, of course; it'll be a few years before Google cracks content out of those. A bunch of photographs of related subjects, or image-rendered text.

(The image search seems to be how MOO's hunt is structured. Although, remember that common link URLs or Javascript snippets are also vulnerable. Avoid them, or anonymize them.)

Or you turn the idea inside out: the eggs are easy to find, but it's hard to figure out how the relate. There's the ARG model. And in fact modern puzzles often treat web-searching as a pacing mechanism. You know the players are going to find your eggs (trivia, whatever) but it'll take them a while to work it out. So you have puzzles on your site, and each one has a solution that points at some phrase, and then the players all Google off to find it. That's fun, and it's egg-hunt-shaped, even if it's not the original model.

What else can folks come up with?