The Stack

Moving on, then. I’m already a week behind schedule, and I want to make some time to finish up the last few games, so lets go for something short. Adventure games usually qualify. It’s hard to pad things out when every interaction is a special case.

Unfortunately, we seem to have entered the danger zone, where the games are too old to run without problems on a modern system, but not old enough that I can easily get around the problem with a robust and stable emulator. The first game that I pulled out of the Stack for this week, an ill-regarded exercise in wackiness titled Armed & Delirious, consistently crashed to the desktop during the intro cutscene, with a popup reading “Unexpected Error”. No tweaking of the compatibility settings helped. Online searches turned up no patches and no record of anyone else ever having solved this problem, and precious few mentions of anyone even encountering it. Such is the doom of ill-regarded games.

After giving that up, I switched to plan B: Blade Runner, a point-and-click adventure loosely based on the movie of the same name. Blade Runner: The Game doesn’t tell the same story as the movie — or, for that matter, as the novel it was based on (again loosely) — but instead puts you in the shoes of a different cop/murderer hunting for a different set of synthetic humans. It’s more or less a sci-fi police procedural, and I’ll probably be comparing it to my recent experiences with Police Quest if I keep on playing. I have to say, it’s a pretty slick package, if low-fi and over-antialiased by today’s standards. I’m particularly impressed by how smoothly the FMV scene transitions are integrated into the action (something probably helped by the fact that I copied all four CDs to my hard drive).

Operation of the game seemed trouble-free at first, but then I hit a wall, ran out of ways to progress. The last thing I did to advance the story was chase a suspect through an abandoned building. The chase ended at a locked door in a room with no other hotspots. Lacking anything better to do, I left, then tried out the shooting gallery back at HQ, only to find that there was nothing to shoot — no targets ever appeared. Growing suspicious, I hit up the net for information. Walkthroughs confirmed that the chase scene was supposed to end with a triggered event: when I reached the locked door, the guy I was chasing was supposed to jump me from behind. I’m hoping that this is the same sort of trigger that was supposed to make the targets in the shooting gallery appear, because I’ve solved that part. An old FAQ suggested that it had problems on fast systems, and that I should use a slow-down program like Turbo to cut the system speed down to somewhere between 30% and 50%. I had to set it to 1% to get the shooting gallery working — and until that happened, I wasn’t even sure that Turbo was having any effect at all.

But I still haven’t completed the chase successfully. Going back to the locked door after having left it once has no effect. I’m probably going to have to do the chase over again — and since my only save is after that point, that means starting over from scratch. If it doesn’t work, I suppose it’s time for plan C. (Or rather, plan D. I don’t have any unfinished adventure games from 1997 beginning with C.)

1995 was an epochal year for the PC: with the release of Windows 95, we suddenly had 32-bit addressing, true preemptive multitasking, and, most importantly for gaming, genuine hope for hardware-independent code in an increasingly unwieldy world of semi-compatibility. The installers for DOS games of the time presented to the user long lists of all the graphics, sound, and input devices they supported, and asked the user to select IRQ settings and other such arcana. 3D graphics accelerators were still a speck on the horizon, but the age of the CD-ROM multimedia extravaganza was here, and with it, long-since-forgotten extravagances like MPEG decoder cards. The new Windows Games SDK promised to simplify things by putting a layer of indirection between the software and the hardware — an indirection layer that, in a tremendous feat of denial and marketing spin, was dubbed “DirectX”. But none of this happened immediately, and PC game developers continued to primarily target DOS for a while. After all, not everyone had Windows 95 yet, and why limit your potential audience? Besides, Windows was reputedly inferior as a gaming platform — Windows 3.1 functioned as an abstraction layer too, but tended towards lowest common functionality.

So why, in 1995 of all times, would anyone release games for Windows 3.1? It seems like the worst of both worlds: limited adoption and lagging behind the cutting edge. But apparently it was a convenient platform to port things to — Myst, for example, never saw a DOS port, presumably because Windows 3.1 was a better fit to the original Macintosh code. Today’s selection, Icebreaker, was originally written for the 3DO, and, if I understand correctly, ported to both Windows and Mac simultaneously by a third party.

Installing Icebreaker on a modern system is a bit of an adventure. I’ve run it on a win32 system before, and I know from experience that it has overzealous copy protection that demands that you insert the CD even when you already did. The game’s author, Andrew Looney, has gone on record encouraging the use of a no-CD crack. Possibly related to this, I have never managed to get the game to play its intro, outro, or between-levels movies. But that’s not such a big deal: they’re not an essential part of the experience, and besides, they’re all stored as ordinary AVI files, watchable from the desktop.

A more serious obstacle is the palette requirement. Icebreaker will only run if Windows is set to 256 colors, neither more nor less. Windows apps in those days didn’t know how to change the color depth on their own — this is one of the many reasons why DOS was considered a superior gaming platform. The problem is, my current system doesn’t do 256 colors. 32-bit color it can handle without problems, but 8-bit, once the mainstay of VGA, isn’t even an option. It’s true that I’ve run other 256-color games lately, and even 16-color games, but only through an additional indirection layer — specifically, DOSBox. DOSBox is certainly capable of emulating 256-color mode on a more capable display, but unfortunately, it only runs DOS apps, not Windows 3.1 apps.

I was about ready to give up and pick a different game, when I realized that Windows 3.1 itself is a DOS app, and can be run inside DOSBox.

Thus began the second round of installation fun: locating Windows 3.1 device drivers that behave correctly under DOSBox. None of the built-in graphics drivers supported 640x480x256, but I managed to find something that worked just as well, given a little help from Vogons. It took me a few tries to find a Soundblaster driver that actually produced sound. But now, I have a convoluted-but-functional Windows 3.1 gaming system that, as an added bonus, works on my Macbook, which I really wasn’t expecting when I got started.

Tomorrow, I suppose I’ll try to describe the actual game.

[ADDENDUM] Looks like I could have just installed it under XP and checked the “Run in 256 colors” setting in the “Compatibility” tab in the shortcut properties. But that wouldn’t have helped me play it on the Macbook.

And finally, we get to something that isn’t a RPG: The Humans, a 1992 cavemen-and-dinosaurs-themed puzzle-platformer. Although it isn’t the oldest game on the Stack, it’s probably the game that’s been on the Stack the longest — which came as a surprise to me when I compiled the list; for years, I thought that honor went to Bloodnet (a 1994 cyberpunk/vampire adventure game with some RPG elements). I suppose Bloodnet weighed more heavily on my sense of backlog guilt, because I abandoned it so near the beginning: for a time, when the Stack was much smaller, it was the one game that I felt like I hadn’t even given a serious try. (Today, I have over a hundred marked as not even tried at all.) Whereas I was fairly advanced in The Humans when I shelved it, putting it into extended I’ll-get-back-to-this-soon limbo.

I abandoned the game the first time around due to frustration over its pixel-precise demands. And yes, the game does make the gaps I have to jump uncomfortably wide sometimes, so that my first attempt falls short, and my second attempt falls down before jumping as a result of trying not to fall short. But in truth, it wasn’t just the game’s demands that caused my frustration, but my own demands on top of them. In those days, I was not just a completist, but a perfectionist. The game provides you with a limited number of lives — okay, it’s not quite that simple. The game puts multiple cavemen on each level, and lets you switch control between them Lost Vikings-style. If one of them dies, he ¹I use the masculine pronoun because there don’t seem to be any females, which makes me fear for the future of the tribe. is immediately replaced by a spare, but you can run out of spares. The number of cavemen you have available persists from level to level, and only increases if you rescue a captive on the occasional level where that’s an option. So, to my younger self, part of the challenge here was to make my tribe as large as possible — that is, to do all the rescues and never let anyone die unless a puzzle demands it. (Sometimes the only way to sneak one caveman past a hungry dinosaur is to take advantage of the delay while it eats another caveman. This is not a very good-hearted game.) Note that this doesn’t really affect your ability to finish the game: you can jump in with a full set of lives at the beginning of any level. There’s a scoring system that would be affected by this, but I didn’t care about that even in my perfectionist days. No, hoarding all those lives was just a self-imposed challenge that I’m willing to forgo today.

I recall attempting the game again some years later and finding that it disagreed with my newer sound hardware. The sounds here aren’t anything special, really — just a bunch of looped tunes that play in the background — but I deemed it to be an essential part of the experience anyway (for reasons I may elaborate in my next post), and reshelved it again. DOSBox takes care of that, of course. But for some reason, DOSBox crashes the installer. I seriously thought for a while that I wasn’t going to be able to play this game: it refuses to run until it has a config file telling it about your sound and video hardware, and the only way to generate that is with the installer, which brought down DOSBox in impressive manner, with ill-formatted double-wide text and a completely unresponsive prompt. Fortunately, I was able to run the installer natively, even though the game itself balks at this treatment.

The earliest games on the Stack, the ones from the 1980s and early 90s, are all RPGs. You might think this means that I’m a big RPG fan, but only if you forget the reason that these games are still on the Stack after all these years: they’re the ones that I haven’t played yet. They’re also not games that I purchased when they were new. Everything I’ve played so far in this chronological run-through has been from various anthology packages, all released around 1998. I’d say Heimdall doesn’t quite qualify as part of this trend, but it’s a judgment call: I bought it, on impulse, as part of a 1995 bargain-bin two-pack re-release that included its sequel, Heimdall II.

I understand Heimdall to be a fairly short game, but I was unable to complete it back when I bought it because the graphical effects accompanying spellcasting caused my system to crash. We’ll see if DOSBox does any better. I have reason to be worried already, though: even before I get into the game proper, I’m getting graphical glitches. If I play in fullscreen mode, sometimes it gets into this state where graphics simply don’t show up until the part of the screen they’re on changes. Animation shows, and the non-animated bits of the screen can be revealed by scrubbing over them with the cursor, which could make an interesting game element if it were deliberate, but it’s not. At any rate, it doesn’t seem to happen when run the game in a window, so that’s how I’m going forward. We’ll see if this prevents the game-crashing later on.

I suppose I’ve been fortunate to have had so little trouble with other games this year. I remember the DOS days as being full of game-specific tweaking — editing the config.sys file to free up more EMS memory, fiddling with IRQs, etc. DOSBox takes care of a lot of that automatically, of course, but also, I think we’re just hitting the point in the history of PC games where compatibility problems started hitting hard, thanks to the slow adoption of VGA, the variety of new sound cards, and the increasing demands on memory of both the games and the hardware drivers. Windows 95 and DirectX would simplify things a lot, but that’s still a few years off at this point. (And also, the era of DOS games didn’t exactly end immediately.)

So, about the game. This is basically an action-puzzle-RPG about vikings. Cartoonish ones. Not nearly as cartoonish as the ones in The Lost Vikings, but definitely moreso than those in Rune. But unlike most games about vikings, it puts a certain amount of emphasis on the fact that vikings are sailors. The main navigation mode is all about sailing from island to island, and your party can contain characters of classes like “shipwright” and “navigator”. Functionally, however, they all seem to just occupy various spots on the scale from warrior to wizard. I’m just getting started here, so it’s possible that the nominal professions will become important later, but there’s no indication of it in the docs. (Also, the fact that all characters, regardless of profession, are represented in the landing party by either a warrior figure or a wizard figure is a little suspicious.)

The initial character creation stage — which only creates the stats for the main hero, not for the rest of the crew (at least not directly) — is particularly notable. In it, you prove your worth for the coming adventure by means of three minigames: throwing axes, fighting on a boat, and catching a greased pig. The notable thing about it is how much programming time must have gone into such a minor part of the game: each of the minigames uses its own mechanics and user interface, takes about a minute to finish, and, as far as I can tell, is used nowhere else in the game. You see it only once unless you start over — which I suppose most players will do, because you’re bound to be disappointed in your first try. But to make the whole thing even more marginal, it’s skippable. You can go directly into the main game with less-than-ideal stats if you want to. For a while, I thought I was going to have to do this, because I thought that the game had frozen up at the start of the greased pig sequence, but when I consulted the manual, it turned out that I had to press the space bar to make it start. (I think I tried every other plausible keystroke.) I’m glad I didn’t have to skip it after all, because in addition to your stats, the minigames also govern who you can put on your crew: there’s a choice of 30 characters, but the more powerful ones turn up their noses at sailing under viking who can’t even catch a pig.

Next time I’ll try to describe the main part of the game a little. I’m still getting used to how it all works.

Onward to 1988, when SSI acquired the Dungeons & Dragons license and started churning out what would be called the “Gold Box” games. I know a lot of people have fond memories of these, but my first impression here is of a game that really doesn’t want me to play it.

First, it throws up a deliberate obstacle to running the game at all: key-word copy protection. Every time you start up the game, it needs a word from the code wheel included with the docs; I’ve already made a sheet with equivalent information so I don’t have to go fiddling with the wheel. Then come the perverse UI design decisions. In the PC version, the keys that cycle through vertically-arranged menu options are not the up/down keys, but “home” and “end”. I suppose I see where they were coming from here: you have to be able to select characters while in navigation mode, and up/down already has a meaning there. But, well, other games managed to come up with better solutions. And by “better”, I mean ones that didn’t make me read the manual.

Then there was the matter of file access. At first, the game was incapable of reading or writing saves, and would just get stuck asking me repeatedly to “insert disk for drive D:”. I can’t fully blame the game for this, though: it was because I had run the installer directly from Windows at first, but run the game itself from DOSBox (after finding that it had the same video problems as the other games I’ve played lately — I should probably just assume that anything that runs in EGA mode will be affected.) It turns out that the installer had set up some configuration files with absolute paths in them, which became wrong when I used DOSBox’s virtual drives. This was easily corrected by editing the configuration files, but it took me a while to figure out. Anyway, it’s a problem that the previous games this year didn’t share. They just assumed that whatever directory they were run from was the one they should be using.

Anyway, after a lengthy character creation process (lengthy mostly because of the optional icon customization, which I may describe in more detail later), I got into the game, and went to the part of town labeled “Taverns and Shops” on the map in the manual, hoping to buy some basic equipment — just armor and weapons for each character. But there’s no obvious way to tell whether a given door leads to a shop or to a tavern, so I wound up blundering into the latter before the former. I tried to make a quick exit, but the game wouldn’t let me; I got caught in a tavern brawl that wound up killing my entire party. But even with everyone dead, the brawl continued for a long time, preventing me from doing anything else in the game. I’ve heard stories about terrible dungeon masters who play out battles that don’t involve the players at all, essentially treating the players as a passive audience. If that’s part of the D&D experience, SSI captured it well.

One thing about playing old games: they often don’t work well with hardware that runs thousands of times faster than what they were written for. I mentioned how there were occasional text messages in Wizardry that didn’t wait for the player to dismiss them and went by too fast to read. The same thing happens in Might and Magic, but far more frequently. Most status update notifications flit by without a prompt, including the hit/miss messages in combat. Combat messages are a special case, because the game lets you change their speed, and even considers it important enough that this is one of the core elements of the combat menu (presumably to let you temporarily speed things up when you’re fighting a dozen weak monsters who all have to take a a turn at missing you). But even there, the delay is relative to the CPU speed, and unreadable at even the maximum delay if I run the game at full speed.

Fortunately, I don’t have to run the game at full speed. As with Wizardry, I’m running it under DOSBox. I can’t say enough good things about DOSBox; it’s easily the best emulator I’ve ever used, and the whole project represented by this blog would probably be impossible without it, or at least very inconvenient.

Anyway, any decent emulator provides some way to adjust the emulated CPU speed, so making all those messages readable is not a problem. But it introduces a new problem: playing at the game’s original speed is a great deal less pleasant. The game takes noticeable time between keypresses to figure things out and then render them. I’m talking about fractions of seconds here (unless you’re moving between map sectors, which is slower), but it’s enough to make the interaction seem muddy and unresponsive, as opposed to the crisp immediacy of reaction before I slowed it down. I suppose I’m spoiled, but this is one aspect of the original experience I can do without.

DOSBox provides a couple of hotkeys for turning the speed up and down, and I’ve spent some time fiddling with it to find a good compromise. Setting it somewhere around 160 KHz seems to work pretty well. Messages flash by pretty quickly, but not too quickly to read, for the most part. Some of the messages from triggering traps are longish, but as long as I understand that I triggered a trap, I can see the effects by looking at the party status screen.

The traps. That’s another thing M&M does differently from Wizardry. They’re less deadly, but more numerous and harder to avoid: in addition to traps on treasure chests, there are traps on doors, which means sometimes you need to get through one to move forward. I’ll probably have more to say about that later.

Looks like I’m not finishing Story Mode today after all. The game crashed in the middle of a recent session, and has since then has refused to start up. Sometimes I just get a splash screen and nothing else, sometimes it gives me an “illegal operation” error, once and only once did it start up successfully. I don’t know why this suddenly started happening after a period of trouble-free operation. Or, well, not quite trouble-free: I had problems at the very beginning with environmental sounds — traffic noises and the like — being entirely too loud and drowning out the voices. Apparently the game was trying to do things with point sound sources that my hardware didn’t support, and the solution was to turn off hardware sound acceleration.

Anyway, I said I’d post about the interface, and I can still do that. Platforming in first person presents some difficulty, especially when the game tries to create a sense of immediacy by shaking the camera, as happens whenever you break down a door in ME. Also, one of the moves you can do to avoid damage and maintain momentum is a tuck-and-roll at the end of a fall, which is rather disorienting, because the camera actually does a quick 360-degree pitch.

The thing I most anticipated having problems with was judging exactly when to jump when running toward the edge of a roof. In part, the game solves this by doing something rare for a first-person game: if you look downward, you can actually see yourself. Most first-person games — which are mostly shooters — display, at most, an arm holding a gun. I can think of only two other first-person games I’ve played that gave the player a visible body: Trespasser (the Jurassic Park game) and Montezuma’s Return (a 3D sequel to the classic 2D platformer Montezuma’s Revenge). Montezuma’s Return did it because, like Mirror’s Edge, it’s a first-person platformer; Trespasser did it out of a misguided sense of realism, which pretty much describes every design decision in Trespasser. At any rate, if you’re really worried about jumping at the right moment in ME, you can watch your feet while you run. But honestly, I haven’t found this necessary. If I find myself missing a ledge by inches, I find it’s more productive to just get a better run-up. Running in this game means accelerating, and a few extra feet of acceleration can mean a lot.

To me, the bigger way that the first-person view affects things is when you’re climbing ladders and pipes and the like. For a game with such gorgeous scenery, you spend a lot of time facing into walls. When you reach the end of a climb, you often need to twist the view around to locate the next pipe you need to jump to, and then your vantage can make it difficult to judge if it’s close enough and whether or not you’re actually pointed in exactly the right direction to grab it. The game has a clever way around this: when something can be grabbed, the player character will reach towards it with a visible hand. It took me a while to figure this out. It’s invaluable feedback once you recognize it, but I think it’s telling that tricks like this were necessary.

It’s been pointed out before that a more traditional over-the-shoulder view allows the sight of the player character’s body to substitute for a sense that’s otherwise lost in games: proprioception, the sense of one’s own body’s position. ME gives you occasional body glimpses, but proprioception isn’t constant. The people who say that ME is immersive partly because of its first-person view really have it backward: if it’s immersive, it’s in spite of the first-person perspective, because it’s found ways to overcome the limitations of its viewpoint and its lack of normal sensory information. And sometimes it fails at that. That roll move is disorienting in part because it temporarily takes away the intuitive sense of which way is up, something provided by by the way the camera movement normally works in the game, and by the sense of balance in real life.

I think I’ve fixed my recent hardware problems. As you may recall, my system was occasionally turning itself off, suddenly and without warning. Graphically-intensive games seemed to be the cause: I first noticed the problem in Team Fortress 2, but later observed it in other games, including ones that I had played without problems before. This is weird behavior for a PC: the sort of problem that can be triggered by running a game generally manifests more mildly, with the game dumping you back to the desktop with an “illegal operation” dialog. At most, you expect a system lock-up, not a system shut-down.

Well, when I was blowing the dust out of the case the other day, I noticed that some internal cables were out of place. This box keeps its wiring tidied up with plastic clips stuck to the metal of the case walls with adhesive pads, and one of those pads had come unstuck. The cables didn’t seem damaged, but they were hanging vary close to where the video card sits, and some of the dust was actually blackened. My theory is that the cables were actually touching the video card’s heat sink. Once the card started really working, the metal of the wires would carry that heat straight into the heart of the PSU, which has to take things like sudden heat spikes seriously and really has only one way of dealing with them.

With the wires re-secured, I was able to get through all of the TF2 Developer Commentary tracks without incident. So I’m ready to give the high-graphics games another try. Now that I know what was going on, I’m pleased that the system handled the situation as gracefully as it did, and apparently avoided permanent damage.

Games on Steam that I’ve tried and failed to play in the last 24 hours:

Majesty 2: Sequel to a game that I quite liked. Steam had it on sale for $10, so I picked it up. Before I was done with the tutorial, it triggered the spontaneous-shut-off problem that I first observed in Team Fortress 2. This has happened in a few other graphically-intensive games lately.

Audiosurf: Included in that Steam indie sale pack that I’ve played most of by now. (Mr. Robot was in the same pack.) Launching it with Steam already running brings up a featureless white window that either goes away after a fraction of a second or freezes up and has to be killed through the task manager. Launching it without Steam already running somehow lets it get far enough to put a bunch of text in that window, then crash with the error “Questviewer.exe has encountered an error and must close”.

Gish: Part of the same sale package as Audiosurf, although I already had a registered copy from pre-Steam days. After twice temporarily feezing up with a dusting of random pixels and then coming back with a video driver error saying that the hardware had to be reset, it finally turned off the machine like Majesty 2. This from a 2D game.

I’m really going to have to get a new video card. I’m willing to put it off for a while, though. There are still plenty of games that don’t need it.

Playing TF2 at home continues to pose problems. I mentioned before how playing the Developer Commentary caused my machine to shut off. Sometimes it does this during a real game as well. Other times it doesn’t. There is one new development: sometimes, instead of shutting the machine off, it just gets stuck for a while, looping a second or so of sound and puting some garbage pixels on the screen before popping up a system dialog stating that the graphics hardware stopped responding and it’s had to reset them. After this, I can resume the game as if nothing happened except the loss of some valuable time during which I naturally got killed.

What’s more, I’ve now seen this happen outside of TF2. It also happened in Darwinia — a game I finished some years ago, but I gave it another look simply because it was in that Steam Indie Pack. Anyway, it’s a pretty clear confirmation that the problem isn’t just in TF2. It really seems like a malfunction of the graphics card, and I turned all my graphics settings down to the minimum during today’s session to see if that would help. It seemed to, and I had a nice crashless session (during which I managed to get one more Achievement as a Heavy), but I still got a crash when I tried Developer Commentary mode.

Well, the one real difference in Developer Commenty is the voiceovers. And in fact I had voice chat turned off in my online session — it seems to get turned back on automatically sometimes, and I specifically turned it off while I had the Options menu open to change the graphics settings. So my working hypothesis at this point is that the real cause has to do with sound, and that the reported graphics problems are just a symptom. We’ll see how that works out.