Search Results for: mmos

DayZ and new experiments in interplayer violence

When the excellent internet-culture podcast TLDR tweeted a couple weeks ago that its new episode featured an interview with someone who witnessed her persona within a certain video game get sexually assaulted by other human players, I had an immediate guess which game they’d name. I was right: the incident occurred in DayZ, a popular MMO with a nominal post-apocalyptic survival theme.

My knowledge of DayZ is quite limited. I’ve never played it. I have had one friend, a inveterate fan of actual role-playing in online RPGs, regale me at length about all the time she’d spent there with an online improv group, experiencing varying success at playing out story-games in its setting. When the game got a wider release on Steam last year, I read a long comment-thread on imgur about all the goofy ways new players had died, with a strange focus on other players force-feeding them rotten fruit or drain cleaner.

And then, earlier this year, I discovered this video, following a link describing it as something amazing that happened in the game. With my lack of knowledge about typical interactions in DayZ, and otherwise not knowing what to expect (outside of the video’s title), I found the first 40 seconds — which isn’t supposed to be the amazing part — very stressful to watch.

Those 40 seconds contain one of the most violent exchanges I have ever seen in a video game, even though (modulo some casual language) the incident, if dramatized on film, wouldn’t rate more than a PG in the US. In one sense, it’s just two men talking; neither so much as lays a finger on the either.

The third man who shows up at the 40-second mark is the star of the video, and immediately changes the tone in an unexpected and genuinely impressive direction. But from context, I take it that one player brandishing a gun and verbally instructing an unarmed player to kneel, humiliated, is such a typical interaction in the game that it doesn’t even bear comment. This video uses it as mere stage-setting; one gets the impression that if the third character hadn’t appeared, this player wouldn’t have bothered posting this video.

I have killed, and been killed by, others in online multiplayer videogames like Team Fortress 2 many times, and have never considered that activity gross or personal violence. These games are silly cartoons, and I can take them only as seriously as their verb-sets allow. Pretty much all you can do in TF2 is run around shooting and stabbing people, and all characters are equally powerful. When my character — who is not, by any stretch, “me” — is blown to bloody bits by an enemy rocket, there’s really no route for me to take it as a personal affront. I laugh, and wait for my respawn, where I’ll jump back in just as heavily-armed as I was before.

DayZ shifts this. Most obviously, like other MMOs, it presents players with a vast open world full of countless strangers, most of whom you’ll never see, rather than a fixed arena containing a only a handful of other players. More subtly, it starts all freshly spawned characters as completely weak, unarmed and powerless to do anything except run. Those with enough luck — or cunning — will scrape together enough weapons and other resources to become objectively more powerful than other players. Then it becomes in their interest to maintain this position however they can, because if their character dies, they lose all that stuff and have to start over from the bottom.

An obvious solution to this, then, becomes to prey on weaker characters as you come across them. This is how every typical RPG works, after all, yes? Slay another hundred orcs, take their stuff, go up another level. And other online RPGs have long let you attack and loot other players’ characters. But DayZ, through its design, seems to make this action far more intense and personal than the heavily abstracted violence found in the “PvP” mechanics of fantasy MMOs, let alone that of offline games where one player knows all the other players.

If this were a board game or even a LARP I can imagine any number of in-game mechanic that would allow this to play out. You’d say “OK, my attack is 5 and your defense is 2. That means I rob you!” And I’d say “Argh! OK,” and then let you pick a card from my hand while returning my pawn to home base or whatever. But in DayZ you would say “You: freeze. Good. Now kneel. Don’t try anything stupid.” And I’d kneel, and I’d stay there kneeling while you went through my stuff, and I’d hope you didn’t feel like shooting me anyway.

I’d likely have never heard your voice before, and I’d perhaps never hear from you again, either. This might be our only interaction during our entire lives together on this earth: your putting a gun to my head for a minute in a videogame while you nullify my last few hours’ work within it, all while we can hear each other breathing into our microphones. And then, one way or another, we part company.

I find this equal parts horrifying and fascinating. Obviously, during the exchange in the video, the player controlling the man with the gun cannot literally shoot the other player, sitting in front of his PC. Obviously, the men who cornered the woman as described in the TLDR interview could not, at that moment, physically assault her in reality. And yet, the violence portrayed in these cases does not feel like complete pantomime to me. It feels, on some level, real: one person forcing another to consciously act against their will, under threat of worse harm.

Sure, “it’s all a game”, but the abstractions and safeties one expects in games seem absent. Even if we step out a level, we see a situation where the player of the gunman, sitting at his computer, did in fact force, though threat-laden speech — real speech, delivered in plain English — the player of the shovel-wielder to input the sequence of keypresses and mouseclicks to make his character stop and kneel for inspection, lest he lose that shovel and everything else he’d managed to collect. There were no rules saying he had to do that, as one would find in other games; it was a compelled action, made under duress. I can’t read it any other way.

DayZ does seem to be exploring new territory for what games can do. Objectively, I find that valuable. Because I haven’t played it myself yet, I don’t feel I can pass much judgment on it beyond that. But I can’t hide that I find these stories very interesting, very important, and deeply troubling.

Posted in Essays, Jmac on Games | Tagged , , , | 6 Comments

"And then those limits pushed back."

We learn that the browser-based MMO Glitch is shutting down next month. The team at Tiny Speck breaks the news in a frank statement that eloquently and powerfully expresses the heartbreak they feel coming to this decision; I take the expression as genuine, and not without my own source of sympathy.

I accepted a friend’s invitation to mess around with the game a bit only a few weeks ago, and two things struck me immediately. First, the writing was very good, especially in terms of in-game text and dialogue. I’d also been nosing around with Guild Wars 2 at the same time, and found the contrast between Glitch’s intelligently whimsical banter and Guild Wars’ generic-fantasy blah-blah quite striking.

But I could not shake the feeling that this game really wanted to live on a tablet. The colorful, 2D world with its goofy, melon-headed player-characters seemed very out of place running on a PC. This is a game that invited play as a pleasant attention drain while relaxing in a comfy chair, perhaps with the TV on, or chatting with others in the room — not sitting at one’s desk, with mouse and keyboard at hand. And indeed, Tiny Speck points to the inexorable trend towards mobile — and, by definition, away from their chosen platform of Flash — in their shutdown announcement.

I can’t help but think of another game that’s captured our attention lately that also very much seems out of place running anywhere but on a tablet, yet here it is running in a little window on our PCs. I know nothing about Glitch’s development history, but based on its scope I’m willing to guess it shares something that I know to be true of The Fool and His Money: that the game took long enough to plan that, when making initial targeting decisions, Flash seemed ubiquitous and invincible, and mobile nothing more than an interesting future possibility.

I cannot fault anyone who made decisions five years ago that didn’t account for mobile becoming a new primary platform so quickly; the iPhone existed, but the sense of inevitability didn’t really take hold until the (Flash-free) iPad became a mega-hit, three years later. When Adobe announced their abandonment of Flash-on-mobile not long after, I saw technology pundits nod with satisfaction, but I can’t imagine that Tiny Speck met that news with a great sense of assurance.

So, to a certain extent, I blame rotten luck for Glitch’s misfortune. It had the bad timing to choose a platform that dropped from obvious to obsolete due to a truly amazing and very rapid shift in the direction of personal computing. But — and I realize I say this as a newly minted iPad game developer, who is therefore beholden to the King — it also serves an an object lesson in the risks you take when you bind your fortunes too tightly to a single, proprietary platform.

Stay flexible.

Posted in Jmac on Games | Tagged , , | 5 Comments

Santiaga for Senate

I happened to be visiting Portland on the weekend that the official website of the Maine Republican Party put a lot of energy into mocking Colleen Lachowicz, a state senate candidate, for playing World of Warcraft. The story became literal front-page news of the October 5 Portland Press Herald, so that the toothy green face of “Santiaga”, Lachowicz’s orcish in-game persona, grinned from within every nearby newspaper kiosk.

Among the many surprising upsets and turnarounds that happened through state and local ballots in the shadow of Tuesday’s presidential election, nestled among sudden groundbreaking advances for women and gay rights, came the conclusion of this story: the mockery seems to have backfired, and Lachowicz won the election, unseating incumbent state senator Tom Martin. (Her support came largely from Waterville, my own fond home for several years post-college.)

I’ve seen some on Twitter stating proudly that Lachowicz represents a first for gamers or WoW-players in state politics, which I would be willing to wager isn’t really true, among American representatives in general or Maine’s senate in particular. More true is that this is the first time I recall seeing gameplay among (potential) American office-holders becoming so overtly politicized, and therefore becoming part of the conversation, even if only over the relatively small stage of a Maine state senate seat.

I find myself at least as interested, though, in how this story has given the lie to the bogeyman, which we like to rattle occasionally before our Facebook-addled youth, that a life lived online can only come back to haunt you later. Here we had a troublemaking entity literally mailing out colorful fliers pull-quoting Lachowicz posting gleefully on message boards about poisons and stabbing (Santiaga is an 85th-level rogue, you know), attempting paint her as a silly fool or perhaps a dangerous maniac. Not only did that not hurt her, but it might very well have helped her win.

Generation-X member Lachowicz is on the leading edge of younger citizens, digitally apt and fully enmeshed in online cultures — including games — who begin to hear the call to run for public office. There will follow countless more after her, in this country and others. To the swelling ranks of postmillenials now becoming politically active, I say this: may xkcd 137 forever serve as a shining beacon. Have courage, say what you mean, and make the change you want to see. And don’t stop playing.

Posted in Jmac on Games | Tagged , , | 1 Comment

Legends of Zork going squish

We learn today that the casual-MMO Legends of Zork is shutting down, two years after launch:

It is with a heavy heart we announce that Legends of Zork will be closing its doors to adventurers from noon BST (GMT +1) Tuesday 31st May 2011.

We all know that development work has been scarce of late: We have tried to find leeway within a work intensive schedule to devote some time to fixing the issues in the game; We have tried to find time to create new content for the community; But on the whole we have been unable to undertake any major work on the game.

(-- from a post on the Jolt Online forums, May 24th 2011)

(Thanks jizaboz and brasslantern for the tipoff.)

I don't particularly want to be smug about this. The resurrection of the Zork license was neither a cause for excitement nor despair. I pretty much said "Let's see if it's a decent Kingdom of Loathing clone." Then when it shipped, I played for a couple of days and decided: no, it's a dull and lifeless Kingdom of Loathing clone. My IF-playing friends all agreed. If Jolt ever upgraded LoZ with more interesting game mechanics, it was too late for me.

Nor was this snobbery of original-Zork fans. Game reviews from 2009, at a quick scan, ran from "This is not the Zork you’re looking for" to "deserves a solid 'B'". It doesn't seem that players ever got excited about the game -- and, reading the above quote, it doesn't seem that the developers stayed interested either. (Jolt is off to some new thing, "Utopia Kingdoms," on Facebook.)

So the only lessons to be drawn are the obvious ones: flash all the intellectual property you like, but you stand or fall on your game mechanics. IF has stayed in the gaming news; this iteration of Zork has not.

I got one nice piece of speculative game design out of the subject, and I'm not ashamed to requote it here:

What if we built our hypothetical Zork game (let me stress that I'm not talking about Legends of Zork here, I'm making stuff up) on a "monetary" basis of unique treasures? We could randomly generate their names and descriptions -- that's not hard. Succeed in a quest, find an antique Dwarvish black opal. Do it again, discover a handful of silver-inlaid knucklebones. Or a rare blue faience brooch. These don't auto-convert into gold; they retain their identity. [...]

The fundamental act of Zork is exploration. What if the basic quest of our Zork CRPG was exploring a dungeon? (Or forest copse, or temple...) An "attack" would be the entire act of entering a room and facing its challenge -- by stealth, or trickery, or courage, or willpower. You'd still find monsters in the dungeon -- but the rhythm of the game would not be fighting blow-by-blow-by-blow, but rather exploring trap-by-monster-by-maze.

(-- me, early 2009)

(There was also a bunch of stuff about algorithmic content generation. I developed those ideas more fully in my Secrets Game prototype, a few months ago.)

I still think that "the casual space" (a phrase that leaches calcium from my fingers as I type it, but what else am I going to say?) remains wide-open for old-style adventuring ideas. True, the mechanics of the CRPG-oid genre have a strong tendency to bog down and turn into cliche. (Because the learning curve is so high that skilled players always dominate the market?) But innovations do pop up regularly and rearrange the landscape. Diablo upset the applecart once upon a time, and then the online heavyweight MMOs did it again.

Nowadays half the casual-adventure efforts that I see hearken back to Nethack, but the other half are genuinely trying to build something new off the basic equation of "effort = reward". (Do I need to link to Echo Bazaar again? I need to play Echo Bazaar at some point, is what I need to do.) I bet there are still many unexplored approaches to, well, the theme of exploration.

Tagged , , , , | Leave a comment

I have not played Echo Bazaar

I have not played Echo Bazaar. But whoo-ee, a whole lot of my friends sure are playing it.

The reasons I'm not playing are as banal as I can possibly make them. I don't want to use my Twitter account that way! I want to play once a night, not once every 70 minutes! I like whining on the Internet!

...I'm busy writing stuff, and I have no time to get hooked on new games. Except for these iPad hidden-object time-wasters! And the new Prince of Persia retread is coming out soon!

...No, look. The truth is that I love this kind of game -- I was an early Kingdom of Loathing fan. Worse, for years I've wanted to write this kind of game. But I only have scraps of filthy sketchwork and insoluble economics diagrams, and those Echo Bazaar people have actually gone ahead and done the thing. And I hear it's awfully cool.

What's even cooler is when a horde of highly literate gamers, designers and interactivity freaks get hold of something like this and start whaling on it in four-part harmony. And suggesting new design ideas. And then the game creators notice and start commenting back.

So, without ullage:

I do not have time, I do not have time...

Tagged , , , , | 3 Comments

Paintings from Azeroth

Rob Noyes discovered that WoW screenshots take on a new light if run through various Painter filters. Thus, he presents a gallery of original fine-art works by his Troll dude, including some in-character commentary.

wowpaint-haystacks.jpg

Haystacks in Westfall, Eastern Kingdoms. Oil on whatever the heck that thing was.

Tagged , , , | Leave a comment

Designing a casual MMO based on Zork

This week's topic of "hey, look at that" among IF fans is Legends of Zork -- a browser-based "casual MMO" being developed by Jolt. (Licensed from Activision, of course. For those of you who missed the 90s, Activision owns all the old Infocom titles; it was Activision who published the three Zork graphical adventures after Infocom dissolved.)

The Great Underground Empire has recently fallen and the land is in disarray. The Royal Treasury has been sacked. The stock market has collapsed, leading even mighty FrobozzCo International to fire employees from throughout its subsidiaries. A craze of treasure-hunting has swept through the remnants of the Great Underground Empire. The New Zork Times reports that trolls, kobolds and other dangerous creatures are venturing far from their lairs. Adventurers and monsters are increasingly coming into conflict over areas rich with loot. It's a dangerous time to be a newly-unemployed traveling salesman, but it's also a great time to try a bit of adventuring.

(-- from Jolt's press release.)

A lot of people -- both active IF fans and long-ago IF fans who remember Zork fondly -- immediately started talking about this LoZ thing as "multiplayer IF", as a game that would be "like Zork" in some sense.

Yeah, no. Let's look at the first post on the official LoZ blog:

Gain experience and wealth as you battle creatures, dodge traps and solve puzzles. The game is designed to be played at your own pace, so you can log in and do some exploring whenever you feel like it. Achieve fame by challenging other players in the arena or form a group to take on some of the more difficult quests.

The card game Double Fanucci also makes an appearance, in the form of a full deck of 174 Fanucci cards that you can collect and use to improve your skills. [...]

(-- from the Legends of Zork blog.)

Experience points, money, combat, skills, buffs. This is an online CRPG. That's what they're announcing, that's what it is. I immediately said "Oh, Kingdom of Loathing with Zork monsters," and I wasn't the first one to say it, either.

So that's fine; I played a lot of KoL for a year or two. The question which I wish to tromp on today is, what kind of CRPG should a Zork CRPG be?


I am, of course, being arrogant and probably irrelevant here. LoZ is in beta-testing now; Jolt has done their design work. It's too late for me to be making suggestions, even if they had a mind to pay attention to suggestions from random IF amateurs out on the Web.

But it's such a cool question.

The default CRPG used to be rat-clubbing for gold pieces; you could be a fighter, a cleric, a mage, or a thief. That's what "CRPG" meant. D&D did it, so Ultima did it and Wizardry did it. Then there were variations (you need bards for the Bard's Tale) but that was the setup.

(Kids these days will tell you that the classes are tank, damage-dealer, buffer, healer, and controller... or something like that... I'm not a kid these days, so I'll leave it to them to explain.)

It's hard to argue that the Zork tradition is unrelated to the fighter-cleric-mage-thief quadrangle. I wrote a whole post about Gary Gygax and his fundamental interconnectedness to all things, including Colossal Cave and Zork.

But D&D style combat has never meshed well with IF. Zork 1 starts off with a swordfight, straight-up dice rolling and hit points -- and then that mechanic essentially vanishes from the Infocom tradition for seven years. The other combat in Zork 1 is so heavily plot-biased that it's essentially a deterministic puzzle: nearly impossible if you plunge straight into it, but easily winnable at the right place and time.

And that's how Infocom set up their subsequent games -- up until Beyond Zork, which had several interludes of typical RPG combat. I, like nearly everybody, "solved" those scenes by saving and restoring the game. It wasn't fun, it wasn't immersive, and it didn't fit in with the rest of the game. I don't think I'm far off the concensus if I say that those elements of BZ were a failed experiment.

So am I saying that a Zork CRPG should eschew combat entirely? Heck no. There are plenty of battles in Infocom games. You defeat enemies. But they're not D&D, CRPG, wear-down-stat-X-using-stat-Y battles. (I have another whole design screed about a combatless RPG, but I feel like I should implement it rather than blogging about it... maybe next year.)

But yet, we're talking about a CRPG here! I'd love to go off and say "Jolt should have implemented true multiplayer narrative IF," but they didn't -- as far as they've announced.

Let's stipulate that the design problem is "a CRPG with the flavor of Zork". We will have stats, treasure, and skills. The game will be about burning time on repetitive actions that crank up some numbers until you can succeed at tougher actions.

But -- it doesn't have to be arranged the same way as Ultima 1 and Wizardry. I want to see how far I can break down the traditional concepts.

Treasure. When you win fights, you get treasure. Treasure buys stuff. Okay, that's good. But what is treasure? Nearly all games have currency -- a simple scalar of how rich you are. D&D had gold pieces (and a table of other coins, roundly ignored). CRPGs followed suit, although some call them "credits" or "meat".

Zork doesn't have money. Treasure, yes. Coins, sure. Barter, sometimes. Money, no. You collect and use items, distinct and distinctive. (Even the stack of zorkmid bills is a unique item -- you never cash it in for face value.)

What if we built our hypothetical Zork game (let me stress that I'm not talking about Legends of Zork here, I'm making stuff up) on a "monetary" basis of unique treasures? We could randomly generate their names and descriptions -- that's not hard. Succeed in a quest, find an antique Dwarvish black opal. Do it again, discover a handful of silver-inlaid knucklebones. Or a rare blue faience brooch. These don't auto-convert into gold; they retain their identity.

The point is to trade these in for useful tools and items -- I'm not throwing that idea away. So there will still be an underlying monetary value. Maybe it'll say "...rank-3 treasure" on the back of the brooch. But you would still have the experience of finding something, something new and interesting. (Even if it's really generated from a template algorithm.) The game designers could throw new adjectives and templates into the database occasionally. Find a treasure that takes your fancy? Don't sell it -- put it in your trophy case to display!

And you can open a market for players to swap for treasures they want.

There are design consequences, of course. You can't pile up treasures as a reward, the way you can with gold pieces. Eighty treasures are not eighty times as cool as one; they blur together and spoil the point. So rewards become much more granular -- you might get one or two per hour. That affects the rhythm of buying (or bartering) tools for further play. That affects the way you design those tools, and the challenges that the tools resolve.

Doesn't this start to sound more interesting than yet another Wizardry knockoff?

Algorithmically generating instances of things is a good trick. Let's run with it. How about locations? Kingdom of Loathing has lots of locations, but you visit each one over and over again, and the descriptions never change. (Well, rarely.) Let's set up our game so that you enter the forest, and find a unique, freshly-generated forest clearing.

(Again, the template and random-table work for this is pretty easy. You aren't trying to fool the player into thinking that there's a human being writing this stuff. It just has to read well. As long as the game doesn't lead you past a hundred of them in quick succession, players will buy into the descriptions. My own experiments with this tool are in Hunter in Darkness, and the cave section of my web site.)

If you explore out from the clearing, you find more forest locations. New room names, new descriptions. These are just "instances", in the usual MMO sense -- but you're going to visit them frequently, first to "solve" a location, and then passing through to more distant ones. You'll remember the descriptions; they'll feel like a real environment. And if you can invite other players into your instances, they'll find your part of the forest to be different from theirs.

(Maybe draw all this out on the traditional IF box-and-line grid... Oh, I'm not against graphics here. But if you have a generic forest illustration that appears above varying textual descriptions, I guarantee that the players will read and be interested in the text.) (If you can procedurally generate interesting forest illustrations too, you're really in clover...)

I did promise to get back around to combat. The burning-stats-against-enemy-stats model is a rich and well-explored mechanic, and I'm not going to try to discard it. (Today...) But who says that a "combat" must be a blow-by-blow struggle against a monster?

The fundamental act of Zork is exploration. What if the basic quest of our Zork CRPG was exploring a dungeon? (Or forest copse, or temple...) An "attack" would be the entire act of entering a room and facing its challenge -- by stealth, or trickery, or courage, or willpower. You'd still find monsters in the dungeon -- but the rhythm of the game would not be fighting blow-by-blow-by-blow, but rather exploring trap-by-monster-by-maze.

Of course you'd have to have a rich set of "combat" (exploration) mechanics. You'd have options on each move; you'd have tools and resources to use up. Ink and map parchment? Bread crumbs? Arrows? (I smell a Wumpus...) Maybe willpower and courage and steath and cunning are your solvent stats, expended against the dungeon -- just as the traditional CRPG hero expends his hit points frugally, trying to reach the orc's last hit point before the orc reaches his. Reach the end of the dungeon, and you find a treasure.

Ooh, treasures! They come in lots of varieties, right? (Since we're randomly generating them.) So they can have properties. There's the depth we want for the exploration "combat". Treasures can bribe monsters, treasures can jam traps, treasures can be left behind to mark your path through a maze. (Very Zork, that idea.) I know, I said treasures would be rare -- but you're bartering some of them for tools, and tools can be randomly generated too. Ropes, spikes, torches. Oil and batteries, food and water, all usable as "hit points" against the dungeon.

Clues! Use up clues to solve puzzles. I'm not talking about actual IF-style puzzles. Tell the player "There is a mysterious altar here, covered with Gnomic runes." To pass, he has to expend some of the Gnomic lore or rune lore in his inventory. Instead of healing potions, you find more lore. Instead of strength potions, you find a book of Gnomish history, which enables you to understand all Gnomish puzzles better...

You see where I'm going? Starting to go? Sketching a path in the direction of going? It isn't Zork-the-text-adventure -- as stipulated. But it tells the same kind of story.


EDIT-ADD:

I see I completely forgot to talk about character classes, you know, the fighter and the mage...

Well, I don't know if I want them, in the traditional sense. The adventure-game experience rather assumes that you, the adventurer, go everywhere and do everything. You cast the spells and defeat the monsters and solve the puzzles. Then you go back and find all the alternate solutions too.

But there are different approaches, and maybe specialization is okay. (Sneaking, courage, etc, etc.) Or maybe those specialties should be per adventure? That might be fun. Gear up as a thief and go after that dungeon -- but if you're defeated by a surfeit of mazes, you'd try again from the riddle-master's point of view. Or the warrior hero, for monsters. "Healer" is not a concept that makes sense, given the model, but there just might be room for the dungeon master to make a few key changes for his own benefit...

Posted in Zarf on Games | Tagged , , , , | 4 Comments

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.

Posted in Zarf on Games | Tagged , , , , | 4 Comments

Legos, Cliques, and the Invisible Hand

Legos are not a game, but you can play games with Legos. Two teachers at a child-care center in Seattle talk about Why We Banned Legos, and how they brought them back in. (Link via coffeeandink.)

A group of about eight children conceived and launched Legotown. Other children were eager to join the project, but as the city grew -- and space and raw materials became more precious -- the builders began excluding other children.

Occasionally, Legotown leaders explicitly rebuffed children, telling them that they couldn't play. Typically the exclusion was more subtle, growing from a climate in which Legotown was seen as the turf of particular kids. [...] As they closed doors to other children, the Legotown builders turned their attention to complex negotiations among themselves about what sorts of structures to build, whether these ought to be primarily privately owned or collectively used, and how "cool pieces" would be distributed and protected.

(from Why We Banned Legos, Ann Pelo and Kendra Pelojoaquin)

This is a microcosm of the player-created content economy, to which so many modern MMO games and social web sites aspire. The MMO games rely directly on "cool pieces" -- resources of limited availability. Content-sharing sites like Youtube don't have explicit limitations, but the experience crystallizes out around scarcity anyway; eyeballs, attention, popularity. Social capital, in short.

I am a devotee of the gift economy. I have been ever since I got to college and fell into the decadent stews of free software and free (Usenet) conversation. (Before that, there was pirated software. Which was shared by us junior-high-school reprobates in the same way, once we'd pried it loose from the DRM-encrusted, clearly-unworthy hands of the software industry. I'm not making excuses, I'm just explaining my roots.)

I use the gift economy as a model wherever I can. It's built into Volity, our nascent board-game site; it's my plan for Boodler, my half-finished sound-effects project; it underlay my suggestions for player-created Ages in the now-cancelled Myst Online. But equal opportunity does not mean "fairness". Do we have an explicit notion of how to offer equal fun, in the face of social power laws? (That is, the inevitability that a few people will wind up famous/important/influential.)

Legotown was not, please note, the result of simplistic selfishness. These kids had strong attachments to fair play, concensus decision-making, and generosity:

Carl: "We didn't 'give' the pieces, we found and shared them."

Lukas: "It's like giving to charity."

Carl: "I don't agree with using words like 'gave.' Because when someone wants to move in, we find them a platform and bricks and we build them a house and find them windows and a door."

These children seemed to squirm at the implications of privilege, wealth, and power that "giving" holds. The children denied their power, framing it as benign and neutral, not something actively sought out and maintained.

(names of children have been changed by the authors)

The kids negotiated rules; they planned to spread the fun around. Their response to resource shortages was to propose community standards, such as building-plot size limits. Nonetheless, they wound up in a situation where a few children -- including Carl and Lukas above -- effectively excluded the rest.

Being eight and nine years old, they didn't have a clear grasp of the differences between intent, self-image, and outcome:

During the boom days of Legotown, we'd suggested to the key Lego players that there was an unequal distribution of power giving rise to conflict and tension. Our suggestions were met with deep resistance. Children denied any explicit or unfair power, making comments like "Somebody's got to be in charge or there would be chaos," and "The little kids ask me because I'm good at Legos." They viewed their power as passive leadership, benignly granted, arising from mastery and long experience with Legos, as well as from their social status in the group.

Oh ye with social capital on the Internet, raise your hand if that's never been you. Mm-hmm. It sure sounds like me, in many contexts.

The Legotown story continues through discussions between the teachers and the children; a demonstrative trading game as a microcosm of the microcosm (yay!); a supervised Lego building project; discussion of the kids' principles (shared power, collectivity, creative expression); and finally the rebuilding of Legotown, under a new set of rules -- developed by the children -- which dealt directly with access rights, community standards, and resource management.

And I'm using polysyllabic words, but all of these things are right in the forefront of kids' minds. All of them are linchpins of every Internet community and game world, from the first design document to launch day to popular peak. Go finish the article, and you will recognize them on sight.


So what do we do with this perspective? I have no answer beyond "Remember it, and be mindful of what you do." So I will tack.

I have a theory -- not tested at all -- that whenever you build a social structure, you should plan for schism. What happens when this falls apart? What happens when you have a screaming argument with your partner and he walks out? What happens when someone starts a competing group? What happens when someone wants to join, but he doesn't like you so he never bothers? (That's the hidden "schism", more damaging than the overt screaming argument, because you never see it -- that person's potential contribution just evaporates.)

In a command model, the answers are simple and merciless: somebody wins, somebody is cut out. You try to make sure you stay on top.

The gift economy wants to avoid this struggle. It doesn't always succeed. I propose that one major cause of failure is the fear of schism. A group (or person) gets the notion that they are necessary. That means that any rival, whether from within the group or outside, is an enemy -- they're not bad people, of course, but they'll bring down the whole community with their challenge. And then begin the rules, the definitions of who's a member, and all the other cruft of command.

More subtly: the group's goals change from "empower people" to "empower our people". I mean, it's not subtle when I say it like that. But when the Uru Guild of Writers was setting itself up, there was tension between two notions: "Our goal is to help people create Ages" vs "Our goal is to create Ages". And it's not a semantic triviality. In the former case, if a rival Guild arises, that's great -- they're helping more players create more Ages. Our goal is being accomplished. In the latter case, a rival Guild is creating Ages... hey, that's our job! We're failing at our goal! What gives?

Even if there's no notion of controlling Age creation -- and that notion certainly arose in the Uru community -- the Guild still has to worry about being made obsolete. New creators might create Ages for them, thus leaving our Guild to wither and stagnate. Which is a legitimate fear, but it drives people to defend their turf.

I'm sorry; I burble on about the nonexistent future of Uru. The generalization: love your schisms. Cheer your rivals. Define your membership as everyone who hangs out with you, not as everyone you accept. Make sure your social structure is not threatened by outsiders; provide paths by which they can organize without you; choose aims which are strengthened by their work "against" you.

That way, when something goes nasty in the state of Denmark -- or Legotown -- you won't have any motivation to either block or co-opt them. Which will do wonders for keeping the drama-gnomes away.


One more quote, which is somewhat about power, but entirely about why we're here. In the toy game I mentioned, the winners in the first round got to change the rules for the second round.

Kyla added this rule to the game: "If you have more than one green [high-value piece], you have to trade one of them." [...]

Kyla: "I wasn't trying to make other people feel bad. I felt bad when people felt bad, so I tried to make a rule that would make them feel better. It was fun to make up the rule -- like a treat, to be one of only three people out of the whole group."

Yeah, kid, that's it -- not the "only three" -- but the "make up a rule". Work with that.

Posted in Zarf on Games | Tagged , , , | 4 Comments

Myst Online: Beyond the Cancellation

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?

Tagged , , , | 1 Comment