Results tagged “myst” from The Gameshelf

I haven't posted one of these since the Gameshelf got its stylish new (that is, Greek antiquarian) logo. But the fanboy I remain, so here's what Cyan has been whispering:

The Manhole for iPhone/iPad/etc is out. (App Store link) It's a whimsical children's story-or-environment -- worth exploring if you only know the Myst series.

Riven for iPhone/iPad/etc is marked as "coming soon". Riven is my favorite of the series, but I haven't played it since its original release -- it's notably hard to get running on modern machines. (Even harder than Myst, which has been updated and re-implemented all over the place.) I am seriously looking forward to this one.

Cyan also pushed a stack of games up on Steam. But if you use Steam, you probably saw that.

And finally, this teaser page was linked from Cyan's home page today (although I don't see it there now). The banner tag was "Never Let Your Timbers Be Shivered." What is it? Looks like some kind of resource-based explore-and-fight. With pirates. That's all we know -- except that a Cyan folk also dropped into a forum thread and linked to this MP3 file.

I know, I'm supposed to be all on top of Myst news. But I've slacked on this post, which is the post where I tell you that Myst Online is back online, totally free (but Cyan is accepting Paypal donations).

Everything takes longer than expected these days. Cyan Worlds' plans are to move MO:UL to open source, and we finally have some good news. We've taken a first step and started a MO:UL server, so the Ages of Uru are available again. We've opened all the Ages, and added most of the goodies in MO:UL. We're referring to it as MO:ULagain - feel free to explore and enjoy.

-- from Cyan's Play Myst Online page

I haven't posted much about the Myst movie project since I first blogged about it. Patrick McIntire and Adrian Vanderbosch have been posting occasionally on their blog, but while they've been colorful about the life of indie filmmakers, they haven't had much in the way of solid news.

They still don't have solid news. But they do have encouraging news:

Our trip to LA was to meet with potential producing partners.  What this means is that we were looking for producers to join forces with to further develop the script and project in preparation for pitching to the studios. [...]

We have joined forces with two production companies.  Announcement of those names will come at a later date after some business elements have been taken care of.  For now I will tell you this: One of our partners has a first-look deal at Warner Brothers.  [...]  Don't assume this is a guarantee of WB being the studio.  I will also tell you that the other producer we partnered with is an Oscar winner and has extensive experience with world-creation and bringing epic films like ours to the theaters.  We are very excited about our partners and we're enjoying the collaboration.

-- Adrian Vanderbosch, posting on Christmas

So, no deal yet. But they have friends in high places, or rather in glitzy places, who will be working with them to help make a deal possible. (Adrian estimates that they're "two and half or three years" away from having a finished film, and that's if they don't bog down anywhere.)

I find this awesome, and I look forward to more.

---

In other news, Chogon (Mark DeForest, CTO of Cyan) posted this on the Myst forums a few days ago:

I am working on Riven for the iPhone/iTouch (along with RAWA and Rand) as I type. And yes. There are some challenges still ahead that I am confident we can solve. And we are determine to make this the best Riven evvvv-er.

(That's with Richard Watson and Rand Miller, two of the other Cyan honchos.)

Myst has been ported to quite a few platforms (DS, iPhone, Saturn, Jaguar... seriously, I didn't even know about most of these). Riven, due to its size -- five CD-ROMs originally -- has been much less widely ported. And in fact, while I've replayed versions of Myst several times over the years, I've never gone back to Riven. My old Mac version certainly won't run on OSX, and I've never gone through the contortions needed to set up a Windows version.

So I'm super-excited about an iPhone Riven. There are challenges, as Chogon says; see his full post for his comments about making the video-playing toolkit do what they need it to do. But it's in progress.

(Yes, someone asked about Droid/Android. Unfortunately the current Android devices still have limited space for app storage, so no luck there for the moment.)

I posted last year about a couple of indie filmmakers who are tackling the idea of a Myst movie. Sadly, Patrick McIntire and Adrian Vanderbosch still haven't made a film -- last we heard, they had a script of roughly three zillion pages and were trying to slash it down to feature-length.

I still think that's pretty awesome, but even more awesome -- at a slightly different angle -- is this: their project has inspired a different couple of guys to become amateur filmmakers, from a standing start. Isaac Testerman and Nate Salciccioli have produced what they call an "Audition Project", offering to help out with the Mysteriacs film.

Watch the Audition Project on their web site, or on the Mysteriacs blog.

Regardless of where it goes, it is great: a ten-minute clip, covering several scenes of the basic Book of Ti'ana story. Shot on the classic shoestring budget, on locations (seriously: real caves), and it looks terrific. Plus director commentary at the end! The story stands on its own; my only note is that the character Aitrus you're watching is the grandfather of the Atrus in the Myst games.

iPhone Myst was released this weekend. Six dollars. Search "myst" in the App Store to buy.

It's kind of enormous -- over 700 megabytes. (The install process needs another 700 megs of temporary space, so if your phone is super-full, you'll need to clear out 1.5 gig of free space.) Downloading it from Apple took about half an hour on my cable-modem net connection; transferring it to the phone took another fifteen minutes. (That was with the dock connector. I didn't have the nerve to try installing it over wifi.)

I've only played with it briefly. The port seems solid; tap to touch or move, edge-tap or swipe to turn. The only problem I've seen is that background music and repeating animations sometimes fail to continue through taps or scene changes.

I'm not sure that all the puzzles will play exactly the same. The original Myst introduced several subtle variations of the "click to do it" interface, as you played through the game. The cruder touch-screen system may not lead players to think outside the box in that way. Indeed, the info screen says outright:

Some objects (certain large valves or levers or switches) only respond to dragging - moving the object with your finger. Try touching an object first - if it doesn't seem to respond, maybe you can pull it or rotate it by dragging.

I am still waiting for an adventure game which is truly native to the iPhone interface... somebody surprise me?

So what next for Cyan? They haven't mentioned any product being in active development except for this one. My butt-estimate is that the iPhone app will pull in enough money to justify itself, but not enough to let Cyan expand beyond its current (very small) staff level. Even the best iPhone app success stories have been on the level of "Yay I am a successful indie developer", not "Yay now I can hire ten people and start a development studio."

The last word on open-sourcing Uru was mid-April:

The plans for opening the sources for UruLive is still intact. Unfortunately the schedule for it has been effected. Besides myself being busy with Myst, the ex-Cyan programmers that were going to help also had greater demands from their 'real' jobs.

So, I am trying to get the initial team together again and find out what has yet to be done and how much time and effort it will take to achieve that. I'll let you know as soon as I do. -- Mark DeForest, April 16

So, once again, who knows.

Cyan said a few days ago that they had a big change in the works. I wasn't expecting this:

So, Cyan has decided to give make MystOnline available to the fans by releasing the source code for the servers, client and tools for MystOnline as an open source project. We will also host a data server with the data for MystOnline. MORE is still possible but only with the help from fans.

This is a bit scary for Cyan because this is an area that we have never gone before, to let a product freely roam in the wild. But we've poured so much into UruLive, and it has touched so many, that we could not just let it whither and die. We still have hopes that someday we will be able to provide new content for UruLive and/or work on the next UruLive.

(posted Dec 12 on mystonline.com; reprint on Spokesman Review blog.)

Damn. Mondo cool. I wish I had the free energy to pitch into this full-time.

Recalling Cyan's status in late summer: their game development division was down to a skeleton crew, whose only funded project was iPhone Myst. They were working getting Uru back up as a low-budget, low-profile sandbox for fans to play in. Most of the company's revenue came from CyanTest, their game-testing service.

Unfortunately, in October, Cyan announced that "a major revenue stream to Cyan was disrupted". We now have a little more information: CyanTest's biggest customer was Gamecock Media -- which was recently bought out by SouthPeak Interactive. Cyan's testing deal with Gamecock apparently didn't survive the acquisition.

As a result, we now hear that fifty employees of CyanTest were laid off today. (News article from the Spokesman-Review.)

Presumably Cyan has spent the past month looking for new customers, and failing. The layoffs leave seven people in CyanTest. So, a skeleton crew on both sides. They have a few small game-testing customers, and iPhone Myst is on track, but Cyan is now nearly nonexistent.

Cyan has pitched the idea of a new video game to several publishers but hasn’t been given any funding yet. If the new project is funded, the game development side of the company will ramp up, [CEO] Fryman said. (ibid.)

As long as I've got this thing lit up, have some comments from Rand Miller on Myst Online, given at a panel discussion at the Austin GDC in September.

Elaborating on why the game couldn't manage to initially keep itself alive, Miller said, "I'm always going to fall back on 'we were ahead of our time,' because it's easy."

"The biggest thing we did was an all or nothing proposal from an entertainment point of view," he continued. "It's not like you can start up a new TV network and give one show a month and expect it to be successful... We couldn't quite pull that off with the money we had." (from the writeup on gamesindustry.biz)

---

EDIT-ADD: The layoffs may have been as early as October 7th, the day Cyan posted about revenue trouble. The news article only says "recently" (and not "today", as I originally misread). Rumors about layoffs popped up that day (see this forum thread), although I had no confirmation until now. Some time between then and now, anyhow.

I promised, didn't I?

On the Myst Forums, from Chogon (Mark DeForest, CTO of Cyan):

This is a small project that probably a very few of you know about. We are porting Myst to the iPhone. Ok, before some of you start groaning, this is an outside funded project that is keeping a few developers employed... but it is really more than that. It is an interesting and fun project. This is also a very small team with three of us (which includes Derek, Rand (not Randy) [Miller] and myself).

The groaning, I assume, is because of the Nintendo DS port of Myst, which debuted a few months ago to an avalanche of held noses. (Someone was passing it around at the Myst fan convention I mentioned a couple of weeks ago. I didn't get a close look, but the disgust oozing from that side of the room was tangible.)

So hopefully iMyst will be smoother.

Other bits from that post:

MORE - UruLive: The current focus is to get the servers back online and subscribers back in the game (in other words, launched!) before the end of the year. [...]

Other projects: We do have a number of other projects that are suspended waiting for publisher approval or other outside funding. These range from a large epic multi-console game to smaller single console games with a number inbetween. All of the games are unique, artistic and have different aspects of exploration... and I can't tell you anything about them until they become active.

People talk about a movie based on the Myst games. People have been talking about it since Myst first appeared. Cyan even starting working with the Sci-Fi Channel around 2002, but that effort was quietly canned after a few months. (For creative differences, i.e., Cyan didn't like what the SFC was planning. As the SFC's adaptations have ranged from the miserable (Earthsea, Riverworld) all the way up to adequate (Children of Dune), nobody was too stricken about this.)

It is less well known that a couple of indie filmmakers have been struggling with a Myst film for several years now. They only opened their web site this past February, but there has been a great deal of quiet work before that.

Patrick McIntire and Adrian Vanderbosch do not yet have a movie. They do not yet have funding, or actors, or indeed a complete script. They do, however, have a concept trailer. This is an animatic, a series of storyboard images linked with music and voiceover dialogue. They produced it in 2004, in support of their proposal to Cyan to make a movie. Cyan liked the looks of it, and said "Go for it."

Yesterday they put this animatic on-line. So take a look.

It may help to know that the movie is based on Myst: The Book of Ti'ana. It is set many years before the Myst games, the era of Atrus's grandparents, at the height (and end) of the D'ni civilization.

Quick pointer to an audio interview with Rand Miller, conducted by Julian Murdoch of Gamers With Jobs, the day after Uru Live shut down.

Here's a text transcript by Uru players Generator, CrisGer, and Mara.

Not a lot of new specifics, but it's the best braindump we've gotten recently from behind Cyan's magic curtain.

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.

At a local gathering of friends the other day, the classic puzzle book Maze, by Christopher Manson, came up in conversation. Many, myself included, recalled encountering it not too long after its original 1985 publication date. At the time, we all found it a fascinating artifact, though a completely inscrutable puzzle.

The book is still for sale, as it turns out, and there's also an online, hypertext version of the book you can wander through freely. (I note that the website appears to reside among the archives of an early electronic-publishing venture, and has remained unmodified since the mid-1990s. Sadly, the scanned illustrations are formatted to fit the relatively dinky computer displays of that era, resulting in much of the fine detail getting lost. I suppose I should encourage you to go buy the book, if you find them sufficiently intriguing.)

I should correct myself and call the book semi-scrutable, at least. It represents a labyrinth of connected chambers, you see, where each page features a haunting and evocative illustration of one room, trimmed with a short bit of text where the book's mysterious narrator leads a group of squabbling explorers through. The first part of the book's puzzle, then, is simply to find a path that takes you from the entrance to the maze's center and back in 16 steps. The harder part involves teasing the text of a riddle out of all the depicted stuff that lay along this route. And this is where most mortals get stopped, finding themselves with a pile of stuff and no clues.

After I returned home that evening, it occurred to me that I probably hadn't thought much about Maze since the ascent of Wikipedia, and surely it spelled out the solution. Why, yes. And what a solution! It's amusing I can look at this more than 20 years after the book's original publication and tell you why this would get razzed by any of the hardcore puzzle people I know today.

Granted, it was supposed to be very hard, because there was a cash-money prize for the first correct response. But the Wikipedia article implies that they overdid it, since the publishers extended the deadline at least once, and it's unclear if any claim was ever made. And no wonder, really; the solution demands you selectively perform wordplay on picture and text elements along the path, but gives you no clues as to which elements are important, and what should be done with them.

For example (and I'm about to get a little spoilery here) on this page, it happens that you're supposed to get a word by taking two picture elements and anagramming them together. But for all you know, maybe you combine the A with BELL and perform a sound-alike wordplay to get ABLE. Or perhaps the word is simply BELL, after all. Or a dozen other things suggested by the image. They all seem equally right - which is to say, none especially so.

Carry this feeling over the path's 16 pages, and I assert you've got an utterly unsolvable combinatorial explosion. I would be quite interested to learn of integral clues I'm overlooking, though, or to hear about someone who solved the book without any hints! Until then, I must conclude that for all the book's beauty - and it is quite a lovely thing to flip through - as a puzzle, it would get booed off the stage at the MIT mystery hunt.

More important than its puzzle, however, is the book's legacy. Without a doubt, the book left a lasting inspiration to many, stoking a hunger to try solving more baroque and beautiful puzzles, even if that means having to create them first. You can see echoes of Maze in art-heavy digital adventures such as Myst. In fact, the stimulus for this group recollection among friends was a new puzzle designed with Maze in mind, by Gameshelf pal Andrew Plotkin. I have it on good authority that it was cracked by dedicated solvers within a day.

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.

Speaking as Uru's premier blogger...

(...he said, lying blatantly...)

The truth is, I've been writing notes about Uru Live for more than four years. So I have a notion I oughtta say something about its end. But it's a silly notion.

I haven't even been here for the whole run. I only logged into Untìl Uru a few times. The community was playing UU; history piled up; things happened. But new worlds were what I was interested in, so I didn't hang out.

You want to hear something funny? Untìl Uru -- the fan-run, fan-hacked servers -- lasted longer than any other phase of Uru. Nearly two years. Some players had more attachment to UU than to the "real" run of the game. It was buggy, inconsistent, devoid of plot, prone to half-assed extensions and updates... it wasn't a game, by any definition. But players felt they had a stake in UU, in a way that never gelled for Uru Live.

And I say this without having been there. I'm reading the tone of the community. In the days since the cancellation post, people have been all over the idea of bringing back UU. It's Cyan's decision, mind you, and Cyan hasn't said anything about it. (They haven't said anything at all about their plans, except that they will continue making games.) But people remember what it was like to be the ones who kept the City open.

People liked that. I will return to this point.

You know what, I'm not even going to talk about the final cancellation of Uru Live. I'll give the thirty-second summary: Gametap funded Cyan for a couple of years. Whatever deal they made, it didn't work out. Cyan spent some time updating their 2003 code, some time fixing bugs, some time updating old material from Path of the Shell, and some time creating new material. None of these really happened fast enough to build a stable, enticing game experience. Maybe if Gametap had pumped the money faster, or for another year, or if Cyan had built something else, or run their game differently, it would have worked. It didn't, so it's done.

(I must address one point specifically: I am not blaming the POTS material for killing Uru Live. It was old hat to a lot of old players, including me. But Uru failed because the growth rate was insufficient. Growth is defined as new players, meaning people who (mostly) haven't played the 2004 expansion packs. 2007 was all new to them. And it still didn't bring them in fast enough. So now you know.)

The real question is: Do I see Uru coming back?

Not in its original form. The plan for Uru was a commercial, online, massively-multiplayer adventure game, with new adventure material constantly being produced by Cyan and consumed by players.

This plan now has several fatal holes. Cyan is smaller than it was in 2003. It has not managed to produce a stream of great adventure material in the online mode. The Uru codebase has scaling issues on multiple axes. (I'm not just talking about frame rate. The player-to-player message system is nearly useless for a large community; the world state model has synch problems in crowded Ages; the physics system is a millstone in several ways; the avatar and clothing system can't make a crowd of people look distinct.)

None of those are unbreakable obstacles -- but breaking any of them would take a pile of time and money. Another pile, I should say. Cyan spent all of 2006 working on these problems, using Gametap's money. The 2007 Uru was vastly better than the 2003 model, but not enough better.

Which brings up the real fatal hole in Uru's plan, which is that it's failed twice now. Only a crazy person would fund it again. By "crazy person", I mean someone who would be willing to throw tens of millions of dollars into a hole and never see it again. And even if you found such a person, would Cyan want to exhume the project? I cannot remotely imagine the burnout, the pain that those coders and admins and artists must associate with Uru right now.

So that's a dumb question: Uru is not coming back as a commercial Cyan enterprise, not anytime soon. The real question is, will Uru return as a player-supported project?

It could, as I've said. If Cyan opens up exactly the same server system that they did in 2004-2006, people will run servers and hang out. It would not be a blip in the gaming universe, mind you. It would be some people sharing a virtual space. Maybe several hundred, maybe as few as fifty, on a regular basis.

Or maybe more than that. If new areas begin opening up, it's more than a chat room. And players have been working on new Uru areas, using homegrown tools, for years. Those efforts went into high gear in mid-2007, when Cyan announced that Uru's social model would grow to include Guilds, modelled after the Guilds of D'ni history -- including the Guild of Writers, the creators of Ages. (In December, Cyan slipped a hint that their intended arc for 2008 was "Rise of the Guilds".)

The player-organized Guild of Writers is using the Uru software of the 2004-6 era. Several showcase Ages are already shaping up. So there's an obvious route: fan-run servers, connected through Cyan but not under Cyan's direct management, with fan-created content posted as it appears. Anarchic and vital, as I've been pushing for all along.

I am glossing over an entire sub-argument: how much oversight Cyan should have over player Ages and storylines. Do they review designs before implementation? Do they accept some as "official" after release? Will there be such a thing as an official constellation of Ages, an official storyline?

I've discussed all these arguments before, in the pre-cancellation era. There wasn't any community concensus then either, but of course all the goalposts are shifted now. (And will continue to shift, since Cyan's plans are still unannounced.) The past week has seen dozens of posts about the "obvious" plan of bringing back Untìl Uru with fan-created Ages. Each of them has an "obvious" notion of Cyan's role in this plan. No two such notions quite agree.

If you dig even a few inches down, I suspect, you'll uncover the real relic of contention: was Cyan's plan for Uru a work of genius, murdered by insufficient funding? Or was it clueless blundering devoid of story, immersion, and interest? (Both sides add a twist of the shallowness of our corrupt society, chill and serve with bitter aperitif.)

I am condensing these points of view, not exaggerating them. Forum threads are going on right now on both themes, and both have been stated in about so many words. (And, I admit, many more judicious and less extreme.) The valuable question is not which is right. (Both are self-evidently true, to an extent. You already knew that.)

The real question is, can you criticize Cyan's handling of story, interactivity, and game design -- all of which I've done, intelligently, I hope -- without also criticizing Cyan's role as the ultimate arbiter of Uru fan work? That is: who says they're so smart? Look at all the mistakes they've made.

Cue wild disagreement on just what mistakes those are. Which is precisely my point.

One might argue someone has to be in charge, if the universe is to have any consistency, and it might as well be Cyan. To which I say: Cyan hasn't been that big on consistency either. Look at any discussion of linking-book logic, or Age instances. Or, don't. Every such discussion descends into pages of detailed minutiae, precisely because Cyan has fudged their rules again and again in their quest for better gameplay. I don't hold this against them -- gameplay should come first.

Since Uru invites us to design gameplay on an Age-by-Age basis, the argument for a Grand Master of Consistency vanishes. This is massively-collaborative art, not a single game. We've had the era of rigid central control. Look how well it worked. Next!

The whole debate assumes that Cyan wants to be overseer of Uru; it assumes they'll have that power. In the UU era, Cyan ran a central authentication server. So they had no real power except the power to shut all the servers down (which they did, when Uru Live launched). But nothing says Cyan even has to go that far. If they release server binaries without that authentication hook, Uru moves entirely into the hands of the players.

Or, for all I know, we could do that hack ourselves.

To some degree, the Uru code -- venerable and scary as it must be -- is not the heart of Uru. I mentioned scaling issues. Who says Uru should continue on Cyan's client and server architecture? Certainly, if I had fifty million dollars to refloat the project, the first thing I'd want is rewrite a whole lot of code.

Yes, we have reasons to lean towards continuity. Dozens of Age models using the current codebase. The Guild of Writers tools are geared for... well, a three-year-old version of that codebase. If Cyan restarts UU, just as it was three years ago, everyone will go there by default.

But virtual world platforms are becoming a commodity. From a quick web search:

• Second Life. Okay, everyone knows it. And I can't mention it without using the phrase "rain of genitalia". But it's big, well-tested, and you can fence off areas for your own community. Or, heck, run your own Second Life server -- the code is open-source, and I hear it's not expensive to run if you turn off all the server-side physics.

• Metaplace. Not open yet; don't know much about it. It doesn't seem to be open-source, but the goal seems to be to let people create and script 3D environments.

• Project Darkstar. Sun offers MMO-specialized server hosting. Open-source, but you have to like Java.

• Croquet. Open-source software system. Looks low-level, but therefore powerful.

• Multiverse. Software system for MMO creation. Not open-source, but free for non-commercial use.

This is not intended to be a complete list. (See this post for a much better one.) I'm pointing out that a lot of people are working on this. Multiplayer world hosting is going to be an off-the-shelf solution soon, if it isn't already. Uru is not a perfect system today; it's tempting to ditch its bugs, and equally tempting to ditch the effort of writing our own Age creation tool.

So the real question is: what do we want? And what's stopping us?