Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Escape From HappyFaceLand

March 4th, 2009 by Multimedia Mike

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.

Escape From HappyFaceLand Map Editor -- command mode

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.

Escape From HappyFaceLand Map Editor -- map mode

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:

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

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.

Posted in Outlandish Brainstorms | 6 Comments »

6 Responses

  1. Tomer Gabel Says:

    Screwing with the VGA is an art-form, and a fun one at that. “Back in the day” (circa 1997, or perhaps earlier) my brother and I wrote a reader application for a monthly electronic newsletter (distributed via a local BBS) that ran in text mode but used every trick in the bock to look good:

    1. Arbitrarily smooth pixel-by-pixel vertical scrolling (you could accelerate/decelerate with the up/down keys)
    2. A true, controllable 16-color palette (you need to modify the meaning of the intensity bit via a hardware register, and I think you can do the same with the blink bit)
    3. True split-screen: the upper part showed the text and scrolled smoothly, the bottom part showed a static interface (current article, page number, a progress bar showing the location within the article etc.)
    4. Two fonts on the screen at the same time, one for the actual text (including ASCII art) and one for the interface. This required synchronizing with the video card’s horizontal refresh.
    5. True 640×400 resolution; VGA text mode is normally 720×400 with 9×16 character blocks, the 8th (right-most) column doubled for certain characters. This played havoc with the custom font we used for the progress bar, so we switched to 8×16 blocks.

    There were probably a few more, but I’ll be damned if I remember. Good thing I still have the source for this thing :-)

  2. Multimedia Mike Says:

    And I’ll be even more impressed if you can still compile/assemble/link the ancient source code specimen. :-)

    I might be taking another stab at getting this program working again. I found a page that describes all about VGA programming, including those scrolling features:

    I have a little more confidence that springs from having about 13 more years of practical programming experience since the first time I went at this. Maybe I can make a go of this.

  3. Reimar Says:

    Code you wrote ages ago always has a tendency of being quite scary, mysterious or wrong by your current standards.
    I recently went through some old programs and had to notice that during school I had time to work on that stuff almost daily, so there was no need for comments, you still remembered what the code does from last time you worked on it…
    Still, some programs still consider quite impressive, like game-character editors Diable, Hellfire, Diablo 2 or programs that manipulated the values of in-game variables on the heap (so you had to search all memory areas allocated by the game for them).
    Of course we all had no internet at home back then, otherwise we could have downloaded much better programs for all that instead of coding it ourself.
    Reminds me of a joke, where the guy from eastern Germany says: “we had nothing, we had to build everything ourselves”, whereto the one from western Germany responds: “we had no skills, we had to buy everything”.
    (Sounds nicer in German though “Wir hatten nichts, wir mussten alles selber bauen” – “Wir konnten nichts, wir mussten alles kaufen”)

  4. Reimar Says:

    For some reason my spelling/grammar is horrible today, sorry :-)

  5. Tomer Gabel Says:

    I could, actually – it only takes Watcom C++ 10.6 or 11.0 and Turbo Assembler. I set up a retro machine a few years back so I can play old games properly and run demoscene productions; it’s still set up with those tools. There just isn’t much of a point :-)

  6. Brief Reviews of Several Obscure DOS Games | Gaming Pathology Says:

    […] The game was made by 2 fairly young-looking programmers, neither of whom took credit for the sound. My notes indicate that the sound was rather lacking (and the sample from the game over screen was clearly taken from “Aliens”). Somehow, I feel I can’t be too hard on the game since I made a similar game around the same time. […]