Tea Leaves

Bargain Bin

by peterb

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)

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)

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)

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?

Gamers' Bill of Rights

by peterb

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.

Pittsburgh Apple Store Photos

by peterb
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.

Pittsburgh Apple Store Update

by peterb

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.

Pharaoh Speaks

by peterb
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.

Reviews of Games You've Already Played

by psu

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.

A Tale in the Desert

by peterb

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.

Foreshadowing

by peterb

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.

OfflineRT Woes

by peterb

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?

Favorite Words

by peterb

• 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."

Olympics Without NBC

by peterb
If you're in the USA, and want to see how Olympics coverage should be done, consider grabbing this video of the BBC's coverage of the opening ceremonies in three parts. You'll need a Bittorrent client like Azureus to download these, and probably also the DivX video codec. The movie files are quite large -- about 700 Mb per part -- but worth it.

Typically, I hate spectacles like this -- they're usually full of noise and bombast, but signify nothing other than spending. This presentation grabbed me, though -- I found it, if not understated, at least stately. The fact that I'm a mythology geek might have something to do with that. It's the same video feed that NBC used, yet without Katie Couric's incessant babbling you can actually follow the narrative. (I almost choked when one of the NBC commentators attributed "know thyself," the dictum of the Oracle, to Socrates.)

I remember in 1980, NBC test broadcast a football game without any announcers. It was the Miami Dolphins vs. the New York Jets. No voiceovers. No play by play. Just the game, and the occasional graphics telling you stats and game positions. It was one of the best games I ever watched. They never did it again. They probably never will.

So it's a serious question I have for NBC: why is your coverage so awful? Why are you so afraid of airtime that isn't filled by the chiaccharare-batcheat-chitchat of your chirpy and uninformed magpies? Who is responsible for this? Does your market research show that people would rather listen to your talking heads babble about what we're watching rather than actually listen to the show they tuned in to watch? Do you really think you're going to be able to compete in the global marketplace in 2008, when instead of having to wait all of 24 hours to see the BBC feed, I'll be able to watch it live as it happens? Because if you do, it's time for me to short-sell General Electric.

Additional Resources

• A website with lots of images of Greek art from the Minoan period of the sort you will see in the Opening Ceremonies. Thanks to Stewart Clamen.

Blueberry Pie

by psu

Where I grew up in Amherst, MA, there is a farm market called Atkins Fruit Bowl that has been around forever. They started out as just an apple orchard, but quickly grew into almost a whole supermarket. In particular, at some point they started baking pies and donuts and other things in the store. And oh, what pies they are. They have a perfect crust, which is incredible in a semi-mass produced product. They come with a variety of different fillings, but the pumpkin, apple, and blueberry pies are the best.

Whenever we visit home, we take two or three pies back with us. Whenever my parents visit, they bring two or three pies with them. I know people visit to buy a dozen pies and freeze them when they get back home.

A particular pleasure is blueberry pie from Atkins in the summer. This is because they are close enough to Maine to make the pie with wild blueberries. This is a blueberry pie like no other. Nothing even comes close. The wild blueberries make the pie sweet without making it sugary and gloppy. It's a natural fruity sweetness. Also, the fact that the wild blueberries are teeny weeny gives the pie a different texture than the big golf ball blueberries. It's just incredible. I will go eat the whole pie now.

Olympics Rant

by peterb

AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH! Björk is singing, but I can't hear the song if you are talking during it, you idiots. Shut up, shut up, shut up, shut up, shut up. I hate you.

Is there anyone, anywhere, who has thought that NBC's Olympics coverage for the past 20 years has been anything less than uniformly terrible? Who are these people? Why haven't they been fired yet? What can I do to hasten the process?

These aren't rhetorical questions. Have you ever met anyone who said "Wow! What a great job NBC did covering the Olympics, ignoring most of the non-American athletes and not covering most of the events!"

I didn't think so. Me neither.

Also, NBC decided to only show the Kouroi from the waist up, leading this poster on an internet forum to comment:

Whereas they only see dirty, filthy penises and breasts, most of the rest of the world, including myself, saw culture, history, art, architecture, sculpture and the human form. Not a single shot of the naked statues below the waist, and I had no idea there was a naked snake lady... Well, the FCC can rest happy. They won't have to arrest or fine anyone. Ratings are safe. Advertisment dollars will be spent.

Right on.

Bonaguil 0.2

by peterb
Bonaguil 0.2 is out, with support for pluggable AI modules. Give it a try.

The UI still sucks, because, well -- I'm not very good at user interfaces. "Know thyself," said the Oracle, and I know that I've never been one of the graphics people. Fortunately, in addition to making the AI easily customizable, I tried to keep all the GUI callouts separated in their own little ghetto. So hopefully someday when Bonaguil Mania is sweeping the world, someone more talented at graphic design and usability than I am will rewrite the GUI.

There are currently only two robots, both intended simply as demos. The Jester makes completely random moves, and is intended to showcase the bare minimum interface you need to implement to make things work. The Knave looks at the board and does a 1-ply calculation to find the move that will give him the best score. He doesn't think about degrading the enemy's position, and in the event of a tie he just goes with the first thing he found, which is stupid. The point of the Knave from a tutorial standpoint is to show how to use the Board class's copy constructor to make a virtual representation of the board that isn't connected to the display that can then be used for analysis.

I'm not ready to release the source generally yet, because there's still at least one bug (each) in the AI and UI interfaces which will require a change to the API. If you're a glutton for punishment and promise not to complain when I cruelly change the method signatures on you, and are interested in trying your hand at supplying an AI early, drop me a line at developer -at- tleaves.com and I'll arrange a source drop. (Oh, Eclipse, how I adore your "refactoring" menu, you adorable little mynx).

The next release is going to concentrate on freezing the UI and AI interfaces and on improving the display slightly. In particular, it has to add some simple animation, which I am dreading, because it calls on me to draw more little pictures, and I hate that. There's a corner case where you can drop a castle in a suicidal spot for tactical purposes, and currently the display updates everything pretty much instantly, so the user can't tell what actually happened. Some blinky animation would make that a lot more apparent.

There's one aspect of Fortress that I probably can't simulate in an applet, and that's machine learning. Fortress claimed that the AIs got smarter as they played more games. Basically, after each game, the game would ask you if you wanted the computer players to update their strategy tables. If you said yes, they (allegedly) got smarter. Once I add move logging, it might be feasible to have the results reported to a central server, and update them there. But I haven't yet decided if that's actally worth the effort.

Simple Pleasures (summer)

by peterb
Nevat, a Spanish goats' milk cheese that has the body of a brie but the lightness of a chevre. Cabrales, the best blue cheese in the world after true Roquefort. No bread, no crackers. Just a fork.

A glass of white port.

And, last but not least, two ripe, fresh green figs.

Sometimes, life is good.

Eclipse

by peterb

Last night I downloaded the Eclipse Java IDE to try to make a little progress on Bonaguil.

Wow.

Suffice it to say that I was bitter that I had to go in to work today and work in an environment without it. It is the best IDE I've ever used, and I've tried quite a few. It's like music, love, and cookies all rolled up into one convenient package and available for free download. And I haven't even tried the CVS integration yet.

Things I like about Eclipse, in no particular order:

• It's fast. Really fast. Faster than I expected a full IDE written in Java to be.
• The editor is pretty good; syntax highlighting, brace matching, etc, all work without any special effort.
• No need to explicitly build to discover syntactic problems. Just save your file; within a couple of seconds you'll get a list of all errors and warnings for that file in a window in the bottom of the screen, which is easily ignored if you don't want to deal with them right then and there; problems are also syntax highlighted in the editor (think of how some email clients flag misspelled words -- it's the same idea). This is a hugely great thing. I got a lot more work done last night because I didn't have to go through full explicit build cycles to find the stupid typos.
• At least on Windows -- I haven't tried it on OS X yet -- the integration with the system is perfectly smooth. Dialogue boxes and the like all look and feel native.

And, tonight, for the first time, I played with the refactoring support.

Oh my god.

Let me say that again: Oh. My. God. It's like Ada Lovelace came in to rewrite your code for you. While making chocolate cake. And playing Bach on the harmonium. Naked. I haven't been this enthusiastic about a development environment since discovering CALL -151.

Bonaguil is a pretty tiny project at this point, so I can't say that the experience will continue to be fabulous with a sufficiently large project. But it feels right, and that makes me very optimistic. If you're a developer, and haven't tried Eclipse, you should. You can download it from the Eclipse project web site.

Madness and the Minotaur

by peterb
Slot machines, so the theory goes, are addictive precisely because of the randomness of the payoff. It's not simply the possibility of winning that draws players, but the hypnotic, chaotic patternlessness of winning and losing that sucks them in.

Videogames work this way too, sometimes. D.B. Weiss's otherwise undistinguished book Lucky Wander Boy does have the germ of an idea in exploring the (fictional), eponymous arcade game, which was both exceedingly difficult and surrealist.

My own personal Lucky Wander Boy is a text adventure for the TRS-80 Color Computer called Madness and the Minotaur. To the best of my knowledge, no one has ever beaten the game. It's not clear to me that it is actually possible. I've held on to a TRS-80 Color Computer solely to play this game. For years I've dragged a cassette around with a backup of the game on it, on the b-side of a tape which held Frank Zappa's Joe's Garage album. I could sing you the scratchy John Zorn song the accumulated bits make from the tape as they load, slowly, into memory.

I didn't have a Color Computer in 1980, but my best friend, Billy, did. If Ultima and the Apple 2 make me think of Albert and Paul and eighth grade, the Color Computer makes me think of Billy and his Irish Setter, Sputnik, and the fireworks his parents let us set off -- a firecracker, a moment's distraction, looking back and time slows and expands as I see the red glowworm of lit fuse crawl into the paper, my face just a foot away, the report knocking me back in slow motion, high pitched ringing in my ears and the sky ash-gray over a green green lawn. Like a long-forgotten odor, memories of each of these little computers, these little bits of consumer electronics, activate different aspects of my nostalgia. Each time the perfume of nostalgia wells up, it clouds my vision, and I have to wrestle with a part of my emotional past and understand it before I can see these products for what they were, rather than getting lost in what they represent to me. Perhaps what they represent is more important than what they actually were. But, nonetheless, let's talk about the game that, to me, epitomizes the Color Computer.

Madness and the Minotaur is a text adventure game. It is a brutal, unfair, senseless labyrinth which is amateurishly written and probabaly unwinnable. The parser is primitive and arbitrary. Object placement is semi-random (some objects are guaranteed to be on certain floors of the labyrinth). Some objects are protected by key-rules: for example, you can't pick up the shield unless you're holding some other object. In one game, that might be the dagger, in another, the sword. There's never any explanation for these rules; they simply are. If you are holding the dagger, you can reach the shield. If you're not, the shield is out of your reach. There's a wandering Oracle whom you'll meet occasionally, who will tell you the arbitrary rules. But sometimes he lies.

Part of the labyrinth -- the first part -- is the same from game to game, so the player is comforted by the sense of familiarity. Things go rapidly downhill from there. There are one-way doors, and secret doors. The obstacles in the game I hate the most, perhaps, are the pits that must be jumped even though you have no reason to suspect they're there. With a different syntax each time -- maybe here you'll need to JUMP PIT, or here you might have to JUMP UP. Or JUMP POOL. or just JUMP. If you pick the wrong adjective the game will ask you JUMP WHAT?, as if the randomness of its syntax is your fault.

There are monsters, but most games don't end with players getting killed by them. Usually, players will either lose the lamp (due to a random event) and die by falling into a pit. Or there will be a rock slide, trapping them in a room until they die of boredom (there are magic spells to blow away the rock slides, but they're very hard to get, and usually the rock slides happen early in the game, long before you've gotten the spells.) Or players will wander in to the maze part of the map and then give up.

I'd never met anyone who had successfully mapped the maze. Every few years, I'd fire up the Color Computer (or, in more recent years, an emulator), play the game a bit, and then search the internet to see if anyone else knew anything about it. For the first few years of the early 90s, it seemed that no one had even heard of the game. Then, in 1995, I found a fan page that basically said "This game is really hard. Here are some hints, but I've never even come close to finishing it." Another page cropped up the next year.

This year, I found a page by someone who has gotten further than anyone else I know. Through seemingly obsessive effort, he has cracked the puzzle of the maze, although he still hasn't won the game. I never would have been able to figure out how this maze worked in a million years. Here's how it is laid out (skip to the end of this article and download the game itself if you want to avoid spoilers):

The game itself takes place in 4 floors; you start on the top level. Each floor is an 8x8 grid. The bottom three rows of each floor are part of "the big maze". In the big maze, every room has basically the same description ("You are in a maze of...") and is connected to every other room above and below it (if you go down from the fourth floor, you'll end up in the same cell on the first floor). The rooms also wrap east-west, but discontiguously: if you're in the easternmost room of row 7, and you go east, you'll end up in the westernmost room of row 8. Of course, just to make it even harder, there's no indication to tell you you've "wrapped" to the next row. There's no north-south wrapping. The southeasternmost room of each floor generally has no eastern exit.

There's one and only one way to exit the big maze. You have to find the southeasternmost room on the "bottommost" floor. That room has an eastern exit, which if you take it leads to another, smaller maze (which can't be distinguished by description, only by mapping it). Somewhere in that maze is a pit. If you jump the pit, you get outside.

"Cruel" doesn't even begin to describe this game.

The guy who figured out the maze has done better than anyone else I know -- he's gotten 220 points out of a possible 240 (for comparison, the most I ever got was, perhaps, 30, which is about all you can hope for without figuring out the maze). He has no idea where the other 20 points could possibly come from.

The game was written by "Spectral Associates," a company that usually put author credits on their games, but didn't on this one. Who actually wrote it? What was he thinking? Did he ever play his own game through to the end? I will probably never find out. But I will always wonder. Madness and the Minotaur was not my first computer game obsession, nor my last, nor even my strongest, but it occupies a strange and special place in my soul. A little portion of my brain is twisted in a labyrinth of black on green uppercase letters, searching for systematic meaning and order where there is only an undertested game, and...a maze.

Additional Resources

• The most comprehensive spoiler/hint page on the net for Madness and the Mintoaur is maintained by btritico. I may not like his page design, but he understands more about the game than I do.
• Another fan page -- the first one that I found, in 1995, is at figmentfly
• You can download an image of the cassette, suitable for use in an emulator, here. On the Mac, you probably want (or need) the MESS or AdvanceMess emulators. Those should work on PC as well, although I believe there are also standalone CoCo emulators for Windows that might be less overhead. Feel free to contact me if you're having difficulty getting an emulator up and running, and I'll do what I can to help.
• There's actually a Java-based CoCo emulator which will let you load cassette files -- this is probably your best bet to play the game on any platform.
• I thought that Lucky Wander Boy suffered from a lot of problems, not the least of which was that it devolved into psychotic melodrama in an attempt to give its topic more gravitas than it needed. But I'd be lying if I said I didn't feel a shock of recognition a few times when reading it.

Persepolis

by peterb

According to amazon.com, the English version of the second part of Marjane Satrapi's Persepolis comes out at the end of this month.

I may not be able to wait.

Additional Resources

• The preorder page at Amazon is making me salivate.
• If you haven't read the first part of Persepolis, just stop what you're doing right now and go buy it. Really. It's that good.

Software Development Considered Harmful

by peterb

Those of us who develop software are familiar with all sorts of bonehead mistakes. I use "bonehead" in this context as a term of endearment -- we all do stupid things like forget to initialize some value or forget to close a brace now and then. And there are plenty of discussions, in books and elsewhere, about the sorts of mistakes that new programmers make.

That's not what I'm going to talk about today.

What I want to talk about today are the most common mistakes I see experienced software developers make on a somewhat regular basis. Not every developer makes all these mistakes, of course, but if you work for a big enough company you'll see all of these at different times. They bug me. I've committed some of the sins in here myself, and I bug myself when I realize that. Note that I'm deliberately keeping this list fairly low level, and not addressing larger questions of design. The overall problems I'm aiming for are the sorts of things when you're reading someone else's code (or your own) and have that "What? Didn't you go to school and have 10 years of experience that should have told you not to do something lame like this?" moment.

I've heard things like this referred to as "antipatterns," but I think that's an unnecessarily highfalutin' name for what can more accurately and concisely be described as: screwups. So here we go.

1. Improperly maintained namespace.

Software projects tend to grow over time, like the blob. Assumptions about your environment that you made early on in the project don't always turn out to be true. Do yourself a favor; pick a prefix for every global variable and every extern or public function or class, and use it. Maintain a naming scheme so that if your project has many files -- and it always does -- I can tell just from looking at an identifier where to find it.

2. Misuse of asserts.

I see this all the time, and it drives me up a wall:

Assertions aren't there for you to claim that errors are impossible; asserts are about finding impossible conditions -- programming errors. "Out of disk space" is not a programming error: asserting on it is never right (although, depending on the nature of what you're doing, panicking might be correct). Contrariwise, something like decrementing the refcount on some resource and finding that it is less than 0 is a programming error, and is a good candidate for an assert.

If a function really, honestly, cannot ever return any value other than SUCCESS, then it should return void.

There's a school of thought that says that asserts should never be used, particularly in any code that is going to an end-user. I don't know what sort of crack these people are smoki I'm not going to get involved in that particular argument, but if you do use asserts, you should use them correctly.

3. Ignoring return codes.

This is even more annoying than the last one. If it's valid for you to ignore a return code from a call -- any call -- then at a bare minimum I want a detailed comment explaining why it's OK.

4. Making everything extern/public.

If a function or method is intended to only be used internally, don't rely on me, the user of your function, to be polite and not use it. Experience has shown that users -- including me -- are stupid, and if we can use something we're not supposed to, we will. You can smack big banners on your functions that say "Don't use this, you dope", and we will still use them. Think of this as self-defense. If you make a function or method static or private, then we can't use it without checking in a change to your code, and then when it bites us, you can point to our dumb checkin where we changed your nice, safe code, and it will be our fault, not yours. Don't make internal functions extern. Keep them secret. Keep them safe.

If you write the API for a given part of your code first, then it's really easy: the API calls are extern. Everything else is static. You'd be surprised how many people who should know better just make everything extern by default.

5. Not thinking about versioning until "later".

The voice of experience: if you don't figure out how to version interfaces right from the get go, it will be a nightmarish whirling calliope of hatred, pain, and misery later on.

6. Making a change to a changelist after running the regression tests.

Look. I understand. I've been there. I know all you did was update a comment. I know you just made some change that couldn't possibly, in a million years, cause anything to fail. I know the regression test suite takes a long time to run. That change you made was totally trivial, and couldn't possibly break anything. I feel your pain. But the fact is, those are inevitably the checkins that break the build. No one knows why. It just works that way. So run the tests again before pulling that trigger.

7. Sending a human to do a robot's job.

Any piece of software that is more than trivial is too big for a human to debug properly without help. I'll tell you my dirty little secret: I hate code reviews. Yes, they're valuable in their own special way, and yes, I've caught bugs in other people's code in a review (and others have caught bugs in my code), but in terms of pure effort/reward ratio, I have gotten more out of letting the robots debug my code than out of the hours I've spent in code reviews. Use Purify to find memory leaks. Use Coverity to find other types of programmatic mistakes. Run gcov to find out what parts of your code your tests aren't exercising. If speed is a problem, profile your code to find out where it's slow, rather than looking at the code and guessing.

8. Not obeying the robots

Really, a special case of the last item. Turn on all of your compiler's warnings. Fix your code so it doesn't trip any of them. If the language you're using has a lint program, run it. Listen to what it says. Fix your code so lint is happy. To quote Peter van der Linden, from his excellent book Expert C Programming:

Lint is your software conscience. It tells you when you are doing bad things. Always use lint. Listen to your conscience.

Separating lint out from the compiler as an independent program was a big mistake that people are only now coming to terms with. It's true that it made the compiler smaller and more focused, but it was at the grievous cost of allowing bugs and dubious code idioms to lurk unnoticed. Many, perhaps most, programmers do not use lint by default after each and every compilation. It's a poor trade-off to have buggy code compiled fast.

Words to live by.

That's my list. These are things that I see people mess up with some regularity. What would you add to this list?

Additional Resources

• If you're a C programmer, you need a copy of Expert C Programming: Deep C Secrets.
• Here's a nice primer on what asserts are, and how to properly use them. Sun's guide to asserts in Java is pretty good, too.

Château-Fort de Bonaguil

by peterb
In the latter years of the 15th century, after losing a lawsuit brought against him by his vassals, the Baron Berenger de Roqueteuil is reported to have said:

By Lord Jesus and all the saints of his glorious Paradise, I will raise a manor house that neither my unpleasant subjects will be able to take, nor English if they have the audacity to return there, nor even the powerful soldiers of King of France.

And that is just what he did, creating the awe-inspiring Château-Fort de Bonaguil over the course of 40 years.

Bonaguil is located between Perigord and Quercy, and is open to the public. If you're brave enough, you can climb its decaying ramparts and contemplate the surrounding woods.

T.E. Lawrence said of Bonaguil "It is so perfect that it is almost ridiculous to call it a ruin."

What I've Played.

by psu

It's been about a year since I bought that xbox. Here's what I've learned.

This started out as a simple list of pithy generalizations. But, after looking around and noticing that many of my points had been made by others, I decided to focus on a few issues in the context of specific games that I have played.

Wage slave games

Project Gotham Racing 2 and Madden Football are nearly perfect games for the wage slave, with Gotham having the slight advantage. Aside from having excellent gameplay mechanics and creating a wonderful sense of place, the best thing about Gotham is that you can fire it up, get into a race and get out in less than ten minutes. But, if you like, you can also sit here and race for hours. Here are some things that Gotham does not require you to tolerate:

• Load screens that take minutes
• Navigating through dozens of levels of stupid menus just to save (in fact, there is no save at all, it's all automatic).
• Useless cut scenes, splash screens, and other nonsense that you can't skip.

Along these lines, Madden Football almost reaches the same level, but its annoying menu screens put it just one notch below. Still, it's easy to pick up Madden and play one week of the season and the put it away and go to bed. In terms of game play, Madden is at least as good if not better than Gotham. There is an almost perfect mix of arcade-like fun and just enough simulated reality to really make you feel, once in a while, like you've just read that defense perfectly or called just the right play to stuff the offense at the goal line. Competing football games are arguably prettier, but I don't think any of them play as well as Madden, although it's hard to put my finger on the specific issues that define playability.

Sneaky games

When i first got the xbox, a friend of mine gave me the first Splinter Cell. But I didn't play it. There was something about the mechanics and the settings that I didn't like. After xbox-live took over my life, I picked up Pandora Tomorrow for the multiplay, but actually spent more time with the single player. It's one of the few single player games I've "beaten" (the other one being Halo).

Stealth games appeal because the pace is a bit slower and rewards a bit of strategy. Pandora Tomorrow in particular appealed because of the settings : the jungle was cool, Jerusalem was pretty, and the TGV train was just awesone. The game gets a raspberry for using cursed savepoints, but I survived.

Interest in stealth games leads one naturally to Thief and Metal Gear Solid. The new Thief game is basically Splinter Cell set in the past. I find it enjoyable, except for the ludicrously long load times. The lack of a stupid savepoint system almost makes up for it.

Metal Gear Solid 2 presents the player with several challenges that have nothing to do with the game:

• Cut scenes that last longer than the level you just played.
• The single worst third person/first person camera system I have ever used. In first person, you can see but you can't move. In third person, you can move around, but the camera almost always parks itself somewhere that makes what you need to see invisible. In particular, the favored perspective is an angle that is from nearly overhead, which is completely useless. The camera seems specifically designed to make the game hard to play. Also, the combinaton of the stupid camera system and complicated game controls make using your weapon nearly impossible, which makes for a lot of dying in the boss fights.
• Savepoints, with a twist. You can save anytime you like, but the game only saves you as of the last savepoint. This is even more retarded than usual.
• The most annoying game over screen in the world.

On the up side, there are basically no load screens, the game is fast to start, and the game and story are mildly interesting. I played through the first part of the game. I'll have to decide if I can put up with the camera and the lack of a decent save system.

The camera in this game brings up the obvious question, which is: why would any rational being deliberately design the camera so badly? Contrast this with Splinter Cell and Thief (and also the non sneaky games KOTOR and Beyond Good and Evil) which for the most part allow the user to park the camera anywhere he wants. All third person games should work this way. Like save points, fixed, non-controllable third person cameras are a relic that deserves to die.

Shooty Games

Counterstrike is the best multiplayer shooter in the world. It's just perfect. Games are fast, the gameplay is simple and tight, the guns are cool, and playing with bots makes the team aspect more fun. I can play the same maps with the same bots and my same set of friends forever.

Halo is a nice FPS which suffers a bit for not really getting going until half the game is already done. But, the game redeems itself after it gives you the shotgun. An FPS is just not an FPS until you have the shotgun.

Nintendo

Here was an unexpected twist. I had never owned any Nintendo gaming hardware. But, a craving for a nice turn based strategy name led me to Advance Wars for the Gameboy Advance. An unfortunate incident with an emulator led me to the Mario and Luigi RPG (an offshoot of the Super Mario RPG for the SNES). These games are fabulous. They play fast, you can save and restart easily, the gameplay is simple but deep, and the games are full of great animation, sound effects and other flourishes. These are the perfect "wage slave" games, and they are insanely long. There are more levels in each game than I think I would ever finish in a year. How they get this much game into those tiny little cartridges is beyond my understanding.

Special Thanks

Here are some special people who helped.

• peterb, for dealing me crack at every possible opportunity, and for making me write this piece differently.
• Stuart Walpole for the Games for the Wage Slave article.
• tilt for secondary crack dealing.
• The whole Counterstrike crew.
• Karen, for putting up with this stuff without killing me, and for letting me know that ESPN NFL2K sucks.

Bonaguil 0.1

by peterb

Because I'm kinda thickheaded, I spent my weekend vacation programming a game. That's my idea of relaxation. I'm funny that way.

This is a bare-bones reimplementation of the SSI-published Apple ][ strategy game Fortress, ("A game of strategic development and fortification") which combines elements of Go and Chess, although it is much less sophisticated than either of those games. I don't know if this was based on some actual board game; I suspect not, since the scoring is irritating enough that I can't imagine doing it without a machine's help. It's a fun game, though, and I got tired of firing up the emulator in order to play it. Thus, this version, which I call Bonaguil (I was considering calling it "Harlech," since the original Fortress used the ancient tune "Men of Harlech" as its theme song, but if you've ever actually seen Château-Fort de Bonaguil up close and personal, you'll agree it's a good choice).

Bonaguil is a game of taking territory. Each player takes a turn; on a player's turn they can either place a new castle on an unoccupied square, or fortify one of their existing castle. Castles can be fortified twice, so a castle has a strength of 1, 2, or 3. Castles exert their strength level on the square they are on and on the squares in all 4 cardinal directions (or fewer, if they're on an edge.) Influence strength of like castles are additive, influences of opposite-coloured castles that intersect are subtractive (so two strength 1 castles of opposite colours with one empty space between them result in that empty space being uncontrolled.)

If a castle is on a space with no positive influence, it is "in check" (for example, two opposite coloured castles right next to each other will control the spaces away from each other, but will put each other "in check", in the absence of any other factors). The game represents being "in check" by the drawbridge coming up and the windows turning red. A castle on a space the enemy controls is destroyed. Newly placed castles get to exert influence before they are destroyed, so it is legitimate to drop a castle in a suicidal spot if doing so might kill an enemy castle

The present version is extremely primitive, but all of the game logic is encapsulated in its own class, so it will be easy to extend, which I'll be doing over the next few weeks. I even went ahead and drew some cheesy icons and used those instead of text display, even though I'm about as comfortable with drawing as W.C. Fields was with playing with children. My initial cut was a bit more colorful -- I used red and blue, instead of black and white -- but I toned it down to try to stay true to the feel of the original.

Features I plan on adding, if I can find the time, include:

• Some basic AI so you can play without a partner (this was claim to fame of the original Fortress: it had different AIs with different play styles, and they adapted and learned as you played them) At least in the short term, I'll probably focus my effort on making the AI module pluggable so I can sucker other people into doing the hard work allow the gaming community unfettered access to express their creativity.


• Some in-game help and instructions so that people other than those who played the original Apple ][ game know what the heck is going on.


• Some animations / better user feedback. There's one tricky corner case where it is a legitimate game strategy to drop a castle in a suicidal position because you're trying to take out an enemy castle that is already in check. As it is now, both the enemy castle and your castle disappear pretty much simultaneously. This is "correct," but a small delay and some 'death animation' for a castle might make it more clear to the player what just happened.


• Apropos of that, I'd like to support multiple icon sets, so that people aren't stuck with my horrible little pictures.


• Allow the user to set some of the game's parameters. The big one here is game length (it's currently hardwired to 21 turns), but there's no reason we couldn't let people choose arbitrary board sizes (internally, the game can handle any size square board; I did the initial testing with a 3x3 board).


• A log of game moves so games can be replayed (and debugged, for that matter)


• Long-shot goal: network play, and player history/ratings.

I'll release the source code under some fairly permissive non-Gnu license once I'm comfortable that it's not completely embarrassing -- it's been several years since I've done anything in Java, so this is still too rough to show the source code to anyone yet.

Which brings me to a brief digression: God, I love Java. I know this is probably simply the-grass-is-greener syndrome. I work writing systems-level code for a high-performance distributed filesystem in C. I have to ask myself questions like "What happens when we get a request to do a few thousand of these operations at once?" or "What happens if this update needs to go out to several thousand clients?" Programming a little game like this in Java is like being an alcoholic on-the-wagon children's clown at a party with an open bar. "Yeah! Let's do this the slow way because it doesn't matter! Hey, I need some scratch space. Let's just allocate a bunch of objects even if I might not use them! Hmmm, gonna be doing some arithmetic. I'll just precache a matrix table of every integer addition with addends below 1000 just because I can! WAHOOOOOOOOOOO IT'S PARTY TIME!"

(Of course, after I do those things, I make sure to complain to everyone I know that Java is slow. Just kidding!)

I had a basic, text-only version of the game up and running in about 60 minutes; it took just another two hours or so to get the graphical version working, and most of that was spent drawing the icons. It's not very pretty, of course, and it doesn't do much of anything yet. But just the mere thought of how much more painful this would have been to implement in pure C on pretty much any platform you care to name -- well, it makes me love Java all over again.

If you see something that looks like a bug, please drop me a line and try to describe what you saw.

Hopefully the authors of the original game (Jim Templeton and Patty Dembrook -- I've tried to locate them, without success) won't sue me.

To play Bonaguil, if you have a Java-enabled browser, just click here. I've noticed some "issues" getting it to work if you're behind a firewall, so if any Java gurus want to educate me on how to deploy an applet that doesn't break in a firewalled environment, I'm all ears.