I delved deep into my personal programming archives and was reminded of the brief stint I served at my dream job as a video game developer. The game I worked on was entitled Escape From HappyFaceLand. The stories you have no doubt heard about the game industry are true– Ridiculous hours, breakneck development cycles, struggles with arcane gaming technology, haphazard coding just to get something that barely works in time to meet an artificial deadline, only to be promptly forgotten about, even though the game is an unqualified success at release time.

Okay, so a little clarification and confession — I have never worked as a professional game developer. However, I did once program a complete game back in 1995. It was for an electrical/computer engineering lab assignment. And it was written almost entirely in 16-bit x86 assembly language. In less than a week. For an assignment that was only worth 10 points (negligible in the grand scheme of the course). And I wrote a level editor to go with it. And you need to understand that no one has ever really had cause to label me an “overachiever”.

Perhaps I should explain the goal of the assignment, just one in a series of weekly assignments– The task for each group (I worked in a group of 4 students) was to program a game. The game could be absolutely anything we could conceive of; the only requirement pertained to the input mechanism– the optical shaft. This was simply a knob that was hooked up to a piece of hardware called the ML16P interface card. The game had to allow for movement in 2 dimensions using this shaft which really only operated on a unidimensional paradigm.

(Another absolutely fascinating lab assignment was to use the same ML16P interface card to hammer out properly timed bits in order to communicate in real time via basic serial protocol — e.g., 1 start bit, 7 data bits, 1 parity bit, 1 stop bit — to an attached dumb terminal. Incidentally, it appears that my old university was using the same hardware as late as 2003 if this old exam is any indication.)

I seem to recall that a number of teams opted to adapt the Nibbles concept for their assignments. The idea that I quickly brainstormed — and that my team promptly allowed me to run with — was a top-down adventure game that scrolled in a style clearly influenced by The Legend Of Zelda. The game was constructed using DOS code page 437 graphics arranged on an 80×25 text screen. A game map consisted of 8 screens in a 4×2 arrangement. The goal was to navigate the perils of the maze to collect as much treasure as possible (denoted by various currency symbols including USD, GBP, and YEN) while trying to reach the exit before the timer expires. My method for solving the multidimensional problem was for the player to tap the space bar on the keyboard in order to alter the axis on which the shaft moved the player.

The map editor was a piece of work. It sported a rather odd usability paradigm that I now recognize would be analogous to vi’s worldview applied to game map editors. The editor basically featured a command mode (above) and an editing mode (below). It was written in Turbo Pascal when I was at the very top of my Pascal game. Not saying much, but still.

Browsing through the map editor Pascal source, I was shocked to see my brazen disregard for endian-safety as demonstrated by this map file I/O code:

[delphi]
TimeLimit:Word; {Up to 65,535 seconds to solve the maze!}
{…}
BlockRead (DataFile,TimeLimit,2);
{…}
BlockWrite (DataFile,TimeLimit,2);
[/delphi]

Though I think that, at the time, machines that weren’t little endian were only legends.

Thankfully, I still have a compiled executable of the map editor alongside the source code, an executable which, predictably, runs marvelously in DosBox. I don’t know why I didn’t keep a copy of the final game executable. However, it’s not like it would have been of much use without the ML16P and optical shaft.

I still have Turbo Assembler and should be able to assemble the ASM files which comprise the bulk of the game. I am pretty sure we had Turbo C on the computers for doing C work; either that or Borland C++. I don’t have either program handy but I wager I know people who could hook me up if need be. However, the amount of C code in this project is so minor that I wonder why I bothered with the C portion at all. It could be because the assignment required at least a little of each — C and x86 ASM — for a passing grade. It would probably be easiest to just rewrite the small C file in ASM, which pretty much just manages all of the functions written in pure ASM anyway. I mean, if I cared about getting this program running again.

While I remember having an amazing amount of fun developing this game in the span of a week (actually, we may have been graciously allowed 2 weeks for this one), I now recognize that the manner in which I haphazardly slapped together this game in such short time and on such a tight schedule is pretty much the same as game development in the real world. And once the game was “shipped” (the teaching assistant played and graded it), I never got around to touching it again, even though I wanted to. 2 things I wanted to improve: 1) Naturally, I wanted to free the game from the incredibly niche shaft control mechanism and allow the player to navigate happy face character using the keyboard arrow keys or a joystick/gamepad. 2) Right around the time I was finishing this assignment, I came to understand how the PC VGA line incidence register hardware operated. This would have allowed for much smoother scrolling with a proper split-screen scrolling effect. As it was, the scrolling effect was hackish at best and not truly split-screen.

You might be interested to know that my team ended up receiving the full 10/10 points for the lab assignment.