Tea Leaves

One of the advantages to owning a nearly-obsolete PC is that you know off the bat that the latest and greatest games won’t run on it. So rather than spend $49.99 on the latest releases, which, let’s be frank, are usually not that good, you can hit the bargain shelf and find games for $10 or less. You’ve heard me talk about this before, as the “kielbasa sandwich in Chiodo’s” effect: it may not be a great sandwich, but it was only $2, so who cares?

My favorite bargain rack, currently, is the one at Electronics Boutique. EB is already predisposed to dump their PC game stock — the real money is in consoles, after all — so you can find some great deals on preowned PC games there. This weekend I picked up four titles, three of which I’ve been actually able to play.

Myst III: Exile ($4.99)

Myst 3: Exile

I’m enjoying this. It’s been a while — years — since I’ve played any of the Myst games. Some of the mystery of the larger game is dissipated off the bat by the presentation of the plot on a silver platter, but perhaps that is to be expected of a sequel. Once you’re past the cheesy dialogue, though, the game has the right feel.

Puzzle difficulty (I’m only a quarter of the way in, so it may improve later on) feels a little low compared to the first Myst, and certainly easier than in Riven. This is compounded by the comparatively linear nature of the early puzzles. One of the beguiling things about Myst, to me, was the idea that there were various puzzles that were exposed almost from the very beginning. I found that in that game, I wanted to go around and explore all of them and taste them before picking one to spend time on and solve. The first quarter of Exile, contrariwise, has been “solve the very next puzzle in order to even open up the possibility of solving others.” That’s a disappointment.

As expected, the game is visually breathtaking. The pallette is rich and varied, and the visual style within each world consistent. It is mostly presented in the same sort of slide-show manner as the original Myst (and indeed, their earlier work The Manhole). One notable difference is that you can look around freely in environments when not moving. There’s a bit of a fisheye effect, as if you’re in the middle of a sphere upon which has been plastered an image (which, in fact, you probably are), but my eyes adjusted to that very quickly, and I don’t even notice it anymore unless I’m specifically looking for it. Good use of audio is made and is essential to solving some puzzles (”subtitles” can be turned on for purely aural clues, so this is a game even the hearing impaired can enjoy).

I haven’t finished the game yet, so I can’t give a truly full review; but I’ve definitely already gotten 5 bucks worth of enjoyment out of it. If you see it on the bargain rack, grab it.

Etherlords II ($3.99)

Give me a break.

I spent 4 bucks on the first Etherlords, and didn’t like it. Now I’ve spent 4 bucks on the second Etherlords, and I don’t like it either.

It’s frustrating, because this is a game that should be good. I want it to be good. It’s not good. Basically, Etherlords is an attempt to implement a game similar in nature to Magic: The Gathering without tying itself quite so closely to the idea that you are playing actual “cards.” Etherlords II has a number of improvements over the previous version. These include: it crashes more. It doesn’t support Alt-Tab, thus violating Article 3 of The Gamers’ Bill of Rights. It has higher hardware requirements for no detectable benefit.

There’s also the mostly-naked-except-for-armor-chick issue. When the first image you see when installing a game is of a chick wearing bright orange leather “armor” that exposes her boobs, holding on to the leash of a reptilian monster with a huge penis projecting from its forehead, it’s hard to have any reaction other than “uh oh.” In this particular case, the first reaction is the correct one: the game really is that bad.

Supposedly, Etherlords II brings new features to the online arena. I won’t be checking these out. I don’t know about the rest of you, but I find that before I am ready or willing to spend time playing a game online with strangers, I want to play it offline to see if it’s any fun. If the offline experience is subpar, then the online experience will be as well. Are there exceptions to this? Maybe. But that’s still my rule of thumb.

Myth: The Total Codex ($2.99)

Myth: The Fallen Lords

Bungie’s Myth games still engender a cult following to this day. I actually owned this years ago and managed to misplace the disks (this was before I developed the habit of making the very first thing I do with a new game be ripping each CD to an image I keep on the hard drive.) The Total Codex consists of Myth: The Fallen Lords and Myth II: Soulblighter in one package.

Myth is a real-time tactical combat game. I’d call it a “real time strategy” game, but it is missing some aspects that we normally associate with RTS games. It is a stronger game for not having these elements. Rather than building structures and creating new troops, each battle in Myth is a set piece battle: both the number, type, and starting locations of all troops, both yours and the enemy’s, are predefined. This leads to the rock-paper-scissors aspect of combined arms warfare that we’ve seen in strategic-level games such as Panzer General: archers defeat infantry at distance, but infantry cuts archers to pieces in melee, for example.

I’ve had a lot of fun playing and replaying battles, trying out different tactics, seeing what works and what doesn’t. And, since it’s Bungie, the plot is fairly enjoyable as well. Style points are granted for discs that work on both Windows and MacOS (download OS X versions of the installers here, or, for Myth II, here). Out of the four bargains I picked up this round, Myth wins hands down.

Finding the OS X install binaries for Myth wasn’t trivial — I remembered that they used to be at mythdev.com, but visiting that site just brings up an annoying and useless pig that talks about Myth III, which is nice, but not what I wanted. The Internet Archive indicates that there was some sort of trouble that lead to one of the Mythdev developers getting all Fatal Attraction on a rival developer’s connectivity. If anyone knows more about this and wants to gossip about it, please drop me a line. It feels like there’s a story here, somewhere.

Silent Hill 3 ($8.99)

I splurged on this one, mostly because the PS2 version is still around $20. Unfortunately, it won’t run on my system, because it requires a slightly better video card than I actually have. More unfortunately, it let me go through the entire 5-disc install and actually try to run it before informing me of this, thus violating Article 4 of the Gamer’s Bill of Rights. On the upside, it came with a soundtrack album. So I paid $9 for a fairly enjoyable music CD. So now I need to find someone to lend me the PS2 version of the game so I can actually play it.

So, that’s what I’ve been lifting from the bargain racks, not counting Flight Simulator 2004 which, with the $20 coupon floating around the net, can be had for just $7. But that deserves its own article, which is forthcoming.

What good deals have you found lately?

Every so often, I forget that many PC games are bug-riddled sacks of garbage. When this happens, I go out and buy a couple, until I remember why I was driven to transfer most of my gaming to dedicated consoles. This is sad, since PC games do have a rich and storied history, and address a market that is not adequately served by consoles (that market being “people willing to spend way too much money on games.”)

Many of you style yourselves “game developers” and write computer programs that you call “games.” From this point forward, all games that you develop must conform to the following requirements. Those who produce games that do not meet these criteria will be punished.

1. Every modern operating system is capable of running more than one program at a time. Every modern windowing system provides a command key sequence to switch which program is in the foreground (e.g. Alt-Tab in Windows). Every game should honour that key sequence and be well-behaved in its presence. Violation of this rule shall result in this key sequence being permanently disabled on the developer’s personal machine.

2. If your game changes the resolution of my monitor when I start the game, it should restore the original resolution when I exit the game, or when I alt-tab to another application while playing.

3. The use of scantily clad women in advertising, splash screens, or actual games, while unfortunate and somewhat immature, is still permitted. The use of women wearing “armor” that leaves them nearly naked, however, is now forbidden. Developers and artists must choose between lingerie and plate mail. You may not have both. Developers incapable of understanding the difference between armor and lingerie will have a steel plate welded to their groin.

4. If your game enforces minimum hardware requirements, those requirements should be enforced at the very beginning of the installation phase (at which time the installation should give the user the opportunity to abort the install), not at runtime. Violation of this clause shall result in lashing; one lash for every 100 megabytes of data your game installs.

5. All cut scenes and movies should be interruptible with the “esc” key. No exceptions. Ever. Peter Molyneux (Black and White), this means you. Violation of this clause shall result in the developer being tied to a chair and forced to watch the movie “Bad Lieutenant” from start to finish.

6. All games should provide some facility to pause the game at any point. Multiplayer games are exempted from this rule. Violation of this clause shall result in the confiscation of the developer’s Tivo.

7. Wherever possible, games should accommodate the colorblind and the hearing impaired. Where not possible, note this on the box, in the installation notes, or on your web site. Open question: what other common disabilities can be reasonably accommodated by most games? (For example, clearly text adventures can be designed to work well with reading software for the visually impaired). Violation of this clause shall require the developer to feel ashamed of him or herself.

8. No game should require the game disk to be in the drive in order to play, unless the user chooses to not do a full install. No other exceptions. Violation of this clause shall require the developer who wrote the CD-checking code to personally field every telephone support call from purchasers of their game who have lost or damaged their game disk, in perpetuity. “My publisher made me do it” is not an adequate excuse for violating this clause.

9. If the platform you are using supports a standard method of uninstalling programs, your game should use that method. Violation of this clause shall result in RealPlayer being installed on the developer’s machine.

10. Your game should synchronize to real time or a target frame rate, not number of CPU ticks. I know it sounds unbelievable, but this still happens. CPU speed, unlike the intelligence of game developers, doubles approximately every 18 months. If five years from now I try to run a game on my 250 GHz six-CPU gaming monstrosity and it is unplayable because the enemies are running around at 25 times their intended speed, the developer shall be placed in the stockade in the village square and forced to wear a dunce cap, while the Chipmunks Christmas song plays in the background, slowed down to normal speed.

By following these simple guidelines and respecting the PC Gamer’s Bill of Rights, you can help make the word a better place.

Thank you all in advance for your cooperation. If you feel I’ve left any rights out, please feel free to contribute them in the comments section, below.

Additional Notes

• The Chipmunk’s Christmas Song, slowed down, which I originally heard from the said the gramaphone website.
• Thanks to John Prevost, Benoit Hudson, and Robert O’Callahan for helpful suggestions and edits.

Signs

As promised, here are some photos of the soon-to-open Pittsburgh (Shadyside) Apple Store. I concur with the opinion that it doesn’t look anywhere near close to done, but then my experience in constructing anything other than computer programs is severely limited. Perhaps Steve will visit. We could have coffee at the relaxing and sociable café, Jitterz, across the street, and down one block.

Here’s the exterior (click to enlarge) which still has quite a ways to go:

Exterior

The interior looks mostly finished, though. One of the construction workers mentioned that they’re hiring:

Interior

The target date is allegedly September 4th. I’ll be out of town that weekend. My wallet thanks me.

Note to Mac fan and news sites: please feel free to link to this article. As a courtesy, I ask that you do not link directly to the photos. Thanks.

According to Apple’s web site the Pittsburgh (Shadyside) store should go live the weekend of September 4th.

Quoth people who have walked by and looked in the window: “Hmm. the store didn’t look like it was 2 weeks away from completion when I went by yesterday. Must look more carefully.”

I’ll try to post some photos tomorrow evening; check this space then.

Update: The photos are here.

Andrew Tepper

Continuing our focus on A Tale in the Desert, here is an interview with the Pharaoh of this particular Egypt, Andrew (”Teppy”) Tepper, the game’s designer and President of eGenesis, its publisher.

Typically, interviews like this focus on the gameplay design or community development. I’m less interested in that (in part because I think you can often explore those aspects by simply playing the game). Instead, my aim for this interview was to focus specifically on the actual technical development challenges in creating a complex online game with a small team, something that few of us have done. If you’re want details about the game itself, you might want to look at my recent review. I reached Andrew at home, just after he had finished up work for the evening.

peterb: A Tale in the Desert has been released on multiple platforms (Windows and Linux) with more on the way. How early did you decide to go multi-platform? Did it impact development?

Andrew Tepper: We did it immediately, so right from the start we did things like separating the rendering code so that in theory there was one file that needed to be changed to go to a different platform, or to a different graphics API (openGL to DirectX, for example) and then a single #ifdef to change to a system that was different byte order. In practice, it worked pretty well. There were a few bugs, but it’s been pretty easy. For the most part there were just a half dozen or so bugs where we made assumptions about byte order…the whole idea was that stuff that hooks in to the operating system is isolated. It was pretty clean. The Linux port took about 3 weeks. And the Mac port has been underway for about 5 weeks.

How big is the team, and what development environment are you using?

We have 2 full time coders, and 3 full time graphics artists. We use Visual C (a slightly older version) on the Windows side and just gcc in Linux and, I don’t even know what we use in Mac. gcc, I think?

How do you track bugs?

We just started using bugzilla for script code kinda bugs. With two programmers, tracking bugs isn’t a big deal — if there’s a bug, you just scribble down a note and then fix the bug.

How about version control?

We use cvs. That’s been helpful. Sometimes, i’ll go off on a project kind of experimentally, or my partner will, and 20% of the time it won’t work and we’ll just throw it all away.

What’s the single hardest bug you’ve encountered in developing A Tale in the Desert? How did you fix it?

The hardest bug was probably — well, I have to explain this. Our execution model is that the client has synchronous and an asynchronous, or we sometimes say a predictive, model of the game world. The server has a master world model, distributed over many physical CPUs, and a predictive world model for each client. The synchronous model is the subset of the master model that a particular client sees. The invariant is that the server model for a given client, and the synchronous model on a client, always stay in lockstep. So for a given time, the synchronous models must match exactly. So we had one or probably a few bugs where for some reason the synchronous model on the client got out of sync with the model on the server. So that required changing the memory manager and rewriting a whole bunch of subsystems in the server so that we were able to log every byte going in to one of the cpus and every byte coming out. So we wrote a replay facility which we still use which simulates the bytes going in to a server. The solution to finding the bug was replaying on both the client and server kind of at the same time and figuring out where the two synchronous models diverged. It turned out to be something like uninitialized memory. It was not a very glorious bug. But because our execution model is pretty unique, it took some custom tools.

The replay tool is so handy that now when we get a server crash, 90-plus percent of the time, the solution is you take the replay log, rerun it in a debugger, the server crashes in the same place, and then you say “aha!” For something as complicated as a massively parallel system as this — boy, I can’t imagine a better way to do it. The server itself, by the way, is a single-threaded application. the server is designed to handle a million pseudo-threads at once — every building in the game gets its own pseudo-thread. On the client we use three threads.

A pseudo-thread isn’t actually sharing memory with other threads, so there aren’t any tricky concurrency issues?

Yeah, it’s not an OS-level construct. It’s just an internal thing. That’s just what we call it.

Is there any feature you implemented that you wish, from a timeline standpoint, that you wouldn’t have implemented? Something that you look back on and say “Wow, that really blew the schedule for not a lot of benefit?”

Josh [Yelon] would have different answers than me. For instance, I bet Josh would say bump mapping was more effort than it was worth, but I would say just the opposite. For me, there were a bunch of kind of specialized things we added, not big architectural things that were a pain in the ass.

Are any of those still in the codebase?

That still remain in the code? No, because usually when something like that happens we rip it out. For instance we had a conversation system built in, so if you had NPCs in the game you could talk to them. We didn’t actually start out to write A Tale in the Desert. We were writing a system for creating massively multiplayer RPGs, so you had a character in the middle of the screen, and there are other characters running around, and objects to interact with. We knew we were a small company, so we spent a long time writing sophisticated tools to let us quickly develop content, because we knew we’d never be able to dump millions of dollars into developing the content. We spent 2 and 1/2 years not writing a game, just developing a toolset. If you ask me what part of the toolset is the biggest thing, it’s being able to change the code on the fly without kicking people off. That’s as big a change to developing as going from punch cards to interactive editing. Instead of the big testing cycle, you can put your code out as soon as its done, and the really bleeding edge players will run into bugs, and you can fix them in minutes. It’s a giant leap forward.

A lot of the players in A Tale in the Desert seem fairly sophisticated, and they’re very vocal. So it’s clear that a lot of the content has been developed with these more sophisticated players in mind. Certainly, most of them have played other MMORPGs before. So how do you gauge how the game is received by Joe Average who has never played an online game before? Do you capture those guys, or do they wander away confused?

It’s very hard, because they’re kinda shy. They don’t talk as much as the MMO veterans. I’ve done things like kinda gone incognito and played the start of the game, to try to find out. But you don’t know if someone’s dropping out because their connection went down, or they don’t like it and they’re embarassed to say it, or they feel stupid. I don’t know. It’s very hard.

You’re extremely accessible to your users; players and GMs have your cell phone number, and often lobby for features vocally (even outside of the in-game ‘election’ protocol). Is there a downside to giving such easy access to your users? Has pressure for a particular feature ever blown the schedule?

In 18 months I’ve only had 10 inappropriate calls. As for the questions on the schedule, players will always ask for features, but ultimately I’m in control.

I’ve tried to stick to questions about development, but do you have any comments on the game design in terms of the choice to go with economic model vs. monster killing?

I consider this an adventure game. I think Tale is kinda the MMO side of adventure games, where the puzzles are all social puzzles… Think about the Test of the Covered Cartouche, for example. [Ed: In this test, participate in successive rounds of creating a building in secret, all throughout Egypt. At the end of each round, the player whose building is the smallest is eliminated. Since creating larger buildings is quite expensive (which can spoil your chances for future rounds), the challenge is to spend as little as possible on your building while not spending the least.] The puzzles in A Tale in the Desert are all like the old-style adventure games, but with the smartest NPCs you ever came across. If you think about the game, about unlocking technologies, it’s an adventure game. We add some stats so it’s RPG-like, but I think Tale is much more an adventure game then everquest.

To me the boring stuff is where there’s just a single plodding path — find a sheep, grow onions, feed the sheep — but, y’know, the whole game can’t be a chess match. There has to be some mindless stuff, then some thinking stuff. But the coolest thing to me is where I make up a challenge where I don’t know what the best solution is. A few times, I’ve screwed up and the players haven’t stumbled on a solution. For example, the Test of the Seven Phoenix in Tale 1 [Ed: The Test of the Seven Phoenix involves building expensive statues of a specific type in named locations within a one hour period. "Waypoint" travel during the test is forbidden. Which statues need to be built in which locations is a secret before the test begins.] Either I just made it too hard, or there is no good solution, but it hasn’t been a great success.

If you could work on any game next, and it couldn’t be an MMO, what would it be?

If it couldn’t be an MMO, I like physics games. But what those have in common with Tale is that they’re both sorts of sandboxes where the designer ahead of time doesn’t know what the best way to solve it is.

Thanks for your time. I hope Tale 2 is a great success.

Thank you. Nice talking to you.

I don’t buy too many games the day they come out, so by the time I’m done with one it’s been around a while. Here are some thoughts on a couple of games that have been around for a while.

DEUS EX: Invisible War

This game has been derided for being a shallow, cheap, and generally lame followup to DEUS EX. Having not played the first game, I can only give impressions of the second on its own terms.

On the up side, the game has excellent production values. It’s pretty, with nicely rendered and detailed environments. The writing is interesting and the game makes you want to see what’s going to happen next, which is always good. I didn’t even mind the NPC dialog much, and that usually drives me bats. The game generally offers many paths through each particular phase, and it’s sometimes interesting enough to play different stages multiple times with different strategies. You can save any time you like. Hoorah.

On the down side, the game’s levels are small, and to make up for it they take a ludicrous amount of time to load. The game world is a bit contrived. Vents are conveniently placed to allow you to bypass locked doors. And, the world is full of a myriad of items all of which might be useful, but you never know. This would be OK, except that the game has a stupid inventory system where you are allowed to carry a ludicrous amount of stuff, but for some reason you can’t carry as much as you want. This means you leave half the stuff you find lying around, and you risk needing to backtrack for some crucial item that you didn’t have room for.

My other main beef with the game is that the combat blows. Except for the sniper rifle, all the weapons are severely underpowered and chew ammo at a high rate without killing anything. The shotgun is particularly anemic. The game tries to support multiple styles of combat, but I can’t really see how you’d do this game with the melee weapons.

Once you get the sniper rifle, the game is a bit too easy. Sneak around, possibly completely invisible, and snipe everything in sight at will. This is particularly true on the last level of the game, where if you set yourself up with the right abilities your enemies will fall like flies.

Finally, the game is a bit short. I don’t usually complain about short games. But, I got through this in a little over a week, and that includes replaying multiple areas. I could imagine someone who was good at games could finish this in a couple of nights.

Overall though, this game was good and interesting enough for me to finish, which in and of itself is a recommendation.

Mario and Luigi: Superstar Saga

I mentioned this game briefly in my recent bout with self confession. This Gameboy RPG is modeled after the Super Mario RPG and Paper Mario games for the SNES and Nintendo 64 machines. Briefly, you control the two brothers as they run around, fight stuff, collect coins, mushrooms and other magic vegetables, and try to rescue something valuable.

The game design is remarkable. You never feel like you have to optimize your path through the world for fear of running out of some critical resource at a bad time. You never search endlessly for the next step in the path through the game, or just the right sequence of button pushes for some stupid puzzle. Things are generally transparent but interesting.

The navigation and combat system is really fun. You move around in the world much like you would in a platformer, although perfect timing isn’t always necessary. The combat system is similar. It’s a great combination of turn based play and timing based attacks. Each turn, you decide what attack you want to use. Each attack can do a certain amount of damage, but if you hit the right button at the right time, you can do extra damage. Again, the game design shines here. While Mario doesn’t have 3-d rendering, pixel shaders, normal maps and physics, what it does have is nearly perfect game-play mechanics. A game like DEUS EX just wishes it could have something as good as Mario jumping, but it doesn’t come close.

The most gratifying aspect of the gameplay is how the brothers gradually gain cooperative moves and attacks. For example, each brother can jump a certain height and distance. But, a bit into the game, you learn how the two can combine to be able to jump both higher and further than each can alone, so you can get through more challenging terrain. The moves available for combat evolve in a similar way. You start with simple jumping attacks, but soon the brothers can combine multiple jumps to do extra damage. Not only is the system easy to understand, but the interface is described to you in tutorials integrated into the gameplay. If only all interfaces were this well designed and explained.

The main nit I have about the game is the use of savepoints. But, this is mostly mitigated by the fact that you can hit a hot key and sleep the GBA any time you want. Hit the hot key again and the game comes back exactly where you left it. So you can just carry the game with you and play in arbitrarily small slices of time. Perfect!

If you are thinking about getting a GBA, you must buy this game. In fact, this game highlights one of the pleasures of the portable platform, which is that it has a really strong collection of turn based strategy and RPG games which have mostly died out on PCs and consoles. This is a great thing.

The gamer’s complaint of “we want innovative games!” is one that the industry has learned, through experience, to ignore. Some gamers want innovative games. Most gamers say they want innovative games, but really the marketplace proves that — as a group — they want derivative games that carry the illusion of being innovative. This is doubly true in the tired and pretty much creatively dead genre of multiplayer online role-playing games, which combine the kludgy game mechanics of any mediocre game that is five years out of date with the social culture of IRC and the lousy user interface of a MUD. (As I speak, some commissar in the politburo of pretentiousness is marking me down for the next purge for referring to this technology as “multiplayer online game” rather than “virtual world.” History, however, will be on my side).

When innovative games do come along, it often takes us a long time to recognize them. I’ve been playing the A Tale in the Desert II beta lately — I played the original game last year, but never wrote about it — and I think it’s innovative enough that anyone who is interested in online games should at least try it. Whether or not one wants to actually pay to keep playing it is, of course, a matter of taste.

There are a few things I find intriguing about A Tale in the Desert. I like the mise-en-scène. I like that there’s no combat at all — not against other players, not against bad guys or monsters. I like the sheer size of the land (which, while not actually as large as the real Egypt, manages to feel like it is). I like the tech tree that punishes antisocial people (like me!) who try to build everything by themselves. I like that technologies are locked until enough people in an area cooperate to open them up.

The theme of A Tale in the Desert is: you’re in Egypt, and there is stuff around you — grass, mud, sand, rock. You can pick stuff up and do things with it and build structures and devices. You can learn new skills from schools and universities (in some cases paying a tuition via barter) or from other players. You can teach skills in turn to other players. That’s basically it.

In the introductory part of the game, for example, you’ll learn and apply some basic skills. You’ll find a body of water and pick up some pieces of slate from the shore. If you bring some slate to the local school of architecture, they’ll take it in barter and in return teach you how to smack two pieces of slate together to make a stone blade. You can then make a stone blade, and use that and some more slate to build a wood plane. Gather some wood from trees, cut it into boards, and then you can make brick racks. You’ll pick up some grass and dry it into straw in the sun; then you mix straw, some mud, and some sand and dry them on your brick rack. Now you have bricks.

Small projects can easily be made by one person (creating a flax comb, for example, or a distaff for spinning fiber into thread), but the scale of projects rapidly mounts to the point where solo progress is impracticable: when a project requires 1000 boards, 10 people have a huge advantage over the solo player. And in the game’s tech tree, a 1000 board project is probably considered comparatively small. That being said, there’s no strict requirement for cooperation in most parts of the game. Just like in a real economy, if you’re happy living by the shore and growing flax, well, you can do that.

The game is glacially paced. This is not for everyone. I find myself simultaneously fascinated and repelled by it. On the one hand, I love the idea that for me to run — literally run — down the Nile delta to the nearest bridge and a few miles away will take me many minutes of real time. And there’s pretty scenery to look at while you do it. But when I say I love the idea, you can also guess that secretly I hate the actual doing. I have these moments that hit me like a lightning bolt: “What the heck am I doing? I’m in the middle of a desert running seventy miles to find a mountaintop to dry some papyrus! Am I insane?” The game is full of places where — if you are playing by yourself or in a sufficiently small group — you have no alternative but to spend 10 minutes or more just running from place to place. That by itself is what drove me away from the first telling of the Tale, and it may yet drive me away from the second one.

Transportation is somewhat better than in Tale 1 in that a hub and spoke “chariot” system has been introduced, so you can run to the nearby chariot stop and hop a bus to another region many miles away, instantly. That helps alleviate some of the pain, but it really isn’t enough. Players can “earn” the ability to set waypoints that they can warp to immediately (by spending “accumulated offline time,” which fortunately isn’t in short supply), but it takes long enough to unlock those when playing “from scratch” that the impatient will have a rough time of the first week or so, if they want to explore.

The other interesting aspect of the chariot system is that it changes the way in which the economy is developing. More populated regions will tend to develop more quickly as they can unlock technologies at the local Universities faster. In Tale 1, the Nile Delta advanced the quickest, and there was a lag time before technologies reached the other regions (say, Lower Nubia). Intrepid explorers could, of course, run up to the Delta and learn the technologies there. But fundamentally the different regions had different qualities and different population densities. With the chariot system in place, there’s no essential reason to prefer one region over another, and what we see happening in the beta is that population density accrues and thickens around the bus stops, rather than simply around the resources. So the key question in terms of local economies and competitions will likely be not “how close are you to the Delta?” but “how far are you from your local bus stop?”

The other major improvements from Tale 1 include a revamped mining system (the idea of “veins” and the aggressive resource competition they brought have gone away, replaced with the idea that every mine can produce any sort of ore, but correctly smelting it is up to the player’s judgment) and a few additions and tweaks to the technology tree.

Pretty much all online games that have tried to design an economy have messed it up. The main reason for this, I think, is that the scarce resource in most games is rewarded in the form of treasure. In A Tale in the Desert the economy is complex enough that the scarce resource — as Andrew Plotkin pointed out to me the other day — isn’t any particular treasure, per se, but labor. So much labor is required to build, say, a Lesser Sphinx, that it doesn’t particularly matter how much richer one individual is than another. The richest individual in Egypt doesn’t have 140,000 straw, 33,000 clay, 31,000 silt, or the thousands of gallons of paint required. But the richest corporation might.

This has interesting implications. In the same way that City of Heroes solved the Gordian knots of economics and inventory management by just mostly getting rid of them, A Tale in the Desert solves the economic problem by making labor basically interchangeable. Sure, there are some subtleties — a more experienced player might have more endurance or be able to run a little faster, but these are differences of degree, not of fundamentals. To accomplish a goal in the game, you generally don’t need to own a smelting pot (or whatever the hard-to-build building of the day is). You just need the right to use one.

Tale also has a clever self-modifying nature. Any citizen can propose a rule change; rule changes are voted on, and any rule change that passes by a 2/3’s vote and is not vetoed for technical reasons by the developer can be implemented. This can dramatically reshape the land, or property rights, within the game world. While the prospect of a veto always remains, it’s still a bold move to put so much of your game’s future (and, to be frank, your development schedule) in the hands of your users.

I plan on signing up for A Tale in the Desert 2 once it gets out of beta. I can’t be sure that I will actually play it much or for a long time — look, between you and me, there’s only so much flax growing a man can bear — but it’s such a creative take on the multiplayer game idea, so completely devoted to crafting, exploration, and such a rebuke of the “kill monsters, level up” ideal enshrined in every other online RPG that I feel, at some level, “I want these guys to have some of my money, because I want to see what they do next.” Sure, it’s still a treadmill — but at least it’s a different treadmill.

Additional Resources

• If you want to wander in ancient Egypt for a bit, visit the A Tale in the Desert web site and download the free client; players get 24 hours of “play time” for free before being asked to pay. There are currently clients for both Windows and Linux, but a Mac OS X port is in the works.
• If you want to get a sense of the scope of the project, you can poke around the wiki (warning: may contain some spoilers.)
• If you’re interested in some of the development challenges faced by eGenesis in creating the game, you’ll want to read my interview with Tale’s creator, Andrew Tepper.

I have cancelled my City of Heroes account. It was fun while it lasted, but eventually I realized that my main motivation was to see cool super powers and beat up computer controlled bad guys. City of Heroes did that very effectively, but so does Diablo II, and that doesn’t charge me $15 a month for the privilege.

However, I have once again gotten entangled in the intriguing game A Tale in the Desert, this time as part of the beta test for the next version. Watch this space for an overall discussion of the game in game terms, and then, later, an interview with the developers, focusing specifically on the challenges of software development.

Now, if you’ll excuse me, I have to go comb some flax.

I have a problem that I can replicate reliably. If I capture in OfflineRT mode in Final Cut Pro I can generally only capture about 30 seconds of video before I drop a frame.

This has led to me spending hours debugging my camera, film, and every element in my chain other than my computer before reaching the sad conclusion: there’s nothing wrong with my equipment per se. The 867 Mhz Powerbook G4 with 640 Mb of memory is just too slow to capture more than about 30 seconds of OfflineRT video (30 seconds, incidentally, sounding suspiciously like “the amount of time it takes some internal buffer to fill up before it has to page to disk.”) My working theory is it’s not a problem during the ‘true’ capture — after all, I’m able to capture full rate DV just fine — but the extra CPU time spent compressing the frames into photo JPEG is just a tiny bit slower than needed, resulting in hosage.

So, not particularly wanting to buy a new laptop, I arrived at a workaround: turn off “abort capture on dropped frame”. I leave the warnings on, just on principle. I turn the abort back on when I capture at full res.

I know, I know, I’m playing with fire. But what else can I do? I’m addicted to OfflineRT editing. It’s a sickness.

I’ve found precious little information on the net about OfflineRT, and of course nothing useful from Apple about system requirements. So let me turn the question around: is anyone else out there using OfflineRT on a laptop? What model laptop are you using? Do you experience dropped frames?

• Tooku (far away, Japanese)
• Chiacchiarare (to chit-chat, to gossip, Italian)
• Batcheat (chit-chat, Hindi)
• Decimate (kill every tenth soldier, Latin)
• Hamartia (sin, human frailty, Greek)
• Quay (wharf, Canadian)
• Zdorovie (health, Russian)

Decimation, in Latin, does not actually refer to senseless violence, but to a very specific — and rare — military punishment that could be imposed on a legion (or a subunit thereof, such as a cohort) for extreme cowardice. The soldiers were divided into groups of 10. Each group drew lots. One soldier in the group drew the losing tessera. The other 9 were given clubs, and forced to beat the losing soldier to death. A devious and harrowing punishment, decimation was arguably as hard on the soldiers who “won,” who had to murder the comrade they had marched, ate, slept, and fought with, as it was on the soldier who was killed. Probably the most well-known decimation was that handed down by Crassus on those of his legions who were routed by Spartacus. Fifty squads of ten men each were decimated.

As Plutarch observes, “Those who are punished in this way not only lose their lives but are also disgraced, since the whole army are there as spectators, and the actual circumstances of the execution are very savage and repulsive.”