Posts tagged ‘programming’

One more Ultima Underworld story

Thursday, March 17th, 2011

I can’t believe I forgot this one.

One of the levels (5, I think?) was largely populated by ghouls, with standard flesh-eating names like Eyesnack and Kneenibble. Naturally you could talk to them instead of just fighting them. Jon Maiara (the same guy responsible for the Pac-Man homage) was writing the conversations for them, and included all sorts of things like the opportunity for you to make fun of Eyesnack’s name, to which he would respond by making fun of your name in return. You see the edge case, of course, right?

That’s right, part of our precious 640K was devoted to checking for whether the player’s name is also Eyesnack, in which case, in response to your mockery, the ghoul proclaims indignantly, “But your name same as mine!”

Maybe that will make you feel better about Judy falling into the lava.

Ultima Underworld bugs

Monday, February 21st, 2011

While I’m reminiscing about the old days…

As we (Blue Sky Productions, later Looking Glass Technologies / Studios) were developing Ultima Underworld in 1991-1992, largely in a basement room in an office building in Somerville’s Davis Square, we received bug reports both from our own people and the QA team at Origin Systems, who published the game. “Our own people” largely meant MIT friends of the core programming team (me, Doug Church, and Jon Maiara) who we roped into helping out.

Our lead tester was Tim Stellmach (now at Vicarious Visions), a math major. You could tell he was a math major because his bug reports would start with “Consider a door.”

Our producer from Origin was Warren Spector, already a pretty important guy in the industry but someone who has since received yet more accolades for working on, well, Ultima Underworld, not to mention other games such as System Shock (with us), Deus Ex, and Epic Mickey. He is a super down-to-earth guy and we wasted no time in making fun of him, which he took with impressive grace. I guess it was a tradition at Origin to insert characters based on Warren into their games, so we figured we had to as well. Luckily we already had a “spectre” type of monster so it took no work to name one of them Warren. We made sure that Warren was in town the day that Tim was reading through the daily bug report list and said “Bug: There is no reference in the game to Warren Spector”, to which the rest of us immediately piped up, “Fixed!” without further explanation, much to Warren’s chagrin.

We were working with a lot of pretty raw graphics technology, as you can imagine, and it created some unintended graphical results fairly often. The upside was that whenever we ran into some heinous graphics bug that resulted in crazy psychedelic effects, once we figured out what was causing it, after fixing it we kept the code that would make it happen and enabled it when you ate too many mushrooms.

Speaking of graphics… well, probably most of you are far too young to remember the Apple ][, but it had a seriously weird graphics mode, which had not only a crazy palette (black, white, green, blue, orange, and purple) but also placed additional restrictions on how you could use the colors near each other (see here if you really need to know the gory details). Paul Neurath, our CEO, never tired of telling stories of what a pain it was to work with that system when he had written his earlier game Space Rogue. So naturally we added code that would specifically look for a certain file we had planted on Paul’s computer, and if it found it, would switch to a green-blue-orange-purple palette for one frame every half hour or so. Unfortunately I honestly can’t remember whether Paul ever actually noticed it.

One part of one of the levels, designed by Jon, was a Pac-Man homage. You had to run around a maze, which I believe faithfully duplicated the first level of Pac-Man picking up “ore” while avoiding ghosts. How Origin let this through I’ll never know, but they did have one complaint: Jon had named the ore “unobtanium” (yes, the same joke that Avatar used 20 years later), and they insisted that that name was too silly. So we changed it to “zanium” in protest… and apparently they were perfectly fine with that.

The worst bug that made it into the shipping game was probably mine. One of the quests involved talking to a woman named Judy, who could be found hanging out next to a river of lava. It turned out that, given our emergent-gameplay physics-driven simulation philosophy, we never actually prohibited characters from walking into the lava (although of course their AI tried to avoid it). So it was possible (although thankfully rare) for Judy to wander into the lava and die, making your game unwinnable. If you have been enraged at me for the last 20 years, I apologize.

But the best bug report I remember came from Origin. We rendered the world in true 3D but most of the objects (monsters, objects you could pick up) were 2D sprites. There were a few actual 3D polygonal objects, though, such as boulders. When we added the 3D object capability, we needed something to test it out, and we hadn’t created any ourselves yet, so we used a red sports car from some friends who were developing a game with the Car & Driver license, which we plopped down in the middle of a cavern. Sure enough, you could walk all around it and it looked just like a red sports car.

Then the bug report came in, of course. “On the fifth level, at this particular location, there is a red sports car sitting on the floor.” OK, I guess we could have expected that. What we did not expect was the next sentence: “I should be able to enter it and drive around.”

The dangers of self-modifying code

Sunday, February 20th, 2011

One of my coding stories recently showed up on reddit and spawned a giant thread. Having it brought up again reminded me of another fun bug from the early days, in this case 1991.

I had just graduated from college and joined Blue Sky Productions, soon to be renamed Looking Glass Technologies, where we were working on the PC game Ultima Underworld, a first-person 3D dungeon crawl. I needed a machine so I was given an 33 MHz 80486 PC. Everybody else was jealous because not only was it immediately the fastest PC in the office, it was also the only one with a floating point unit. The downside was that everybody wanted to run their tools requiring floating point on my machine.

Anyway, of course the first thing to do as soon as the machine showed up was to run the in-progress version of Underworld on it to see how zippy it would be—perhaps it could get all the way up to 15 frames a second! Unfortunately, the game completely failed on my machine. I can’t remember whether it just crashed, or everything on screen was just black, or what, but it just did not work at all.

After much hair-tearing, we figured out the problem. The texture mapper (in software, not hardware, of course), which had been written by an outside guy (Chris Green—I see he’s now at Valve) and handed to us, was using self-modifying code in an attempt to squeeze as much performance as possible out of the system. Where a normal program might have a loop that accesses a variable each time through the loop, our texture mapper’s loop would just refer to a constant value. Before entering the loop, it would do the variable lookup once, poke that value into its own code, replacing the constant, and then run the loop a bunch of times without having to waste time looking up the value again. Brilliant! Impossible to debug, but brilliant.

Unfortunately, the 486 had its own optimization—an instruction cache. So we were dutifully poking new values into program memory that had already been read and was never reread, which meant that all of the updates were completely ignored. Oops.

I see that the Wikipedia article on self-modifying code has a section on exactly this problem.