Think this page sucks? Check out my new Portfolio, which is better organized.

Notable Projects
The following is a complete list of every notable project I've ever worked on, beginning with the most recent and extending back to the very start.

December 2003-Present: Integrated Bug-Tracking, Product Requirements, And Project Management
After having tried everything from shared drives, email, Excel spreadsheets, and even writing QwikiWiki, I finally decided that the easiest way to do project management was through the bug tracker. We use a product called TeamTrack, which is just your standard Web-based bug-tracking system. However, it offers a lot of flexiblity in terms of what data types and reports it allows, and thus I've been using it to track product requirements, engineering estimates, implementation tasks, enhancement requests, and bug reports, all in a unified reporting structure. It's still too early to see if it works out, but so far the results have been very promising. TeamTrack on WWW.

After running into a freelance circuit-board designer (I didn't realize they existed either), I learned of the opportunity to create a graphical terminal for configuring and communicating with embedded controllers. Basically had started it with a different programmer, and the whole thing fell apart. I picked it up, rewrote it from scratch, and now it's a fully functional commercial product. It's essentially like X Windows, but uses native Win32 components, communicates over a simple COM serial port, and is optimized for extremely small footprint embedded devices. C++ on Win32.

As it stands, the "first 90%" is done, and it's awaiting testing (my partner has disappeared as of late, and I'm thinking of just bypassing him and going right to the masses). It was a pretty tough project I set a very high bar for quality (basically a "design by contract" approach with very stringent and pervasive state assertions throughout, validate every argument, verify every return value), with minimal compromises for the Win32 API.

Now, I'm actually a fan of Win32. I don't think I'd design it this way with the benefit of hindsight, but I'm amazed by how well it has stood the test of time. Regardless, time has taken its toll, and there are lots of things that are just really bizarre. One of which is the order of window destruction. Because I created an OO ecapsulation layer over window management, and I was very picky about cleaning up memory usage and verifying proper destruction, this was a real challenge to get working. But now I can confidently run the application and as it creates and destroys parent and child windows, and it just cleans up after itself nicely. Combine that with a multi-threaded architecture and all sorts of things could go wrong, but don't.

Anyway, now I'm starting the "last 90%", and let's hope I can learn from the QwikiWiki experience.

Employed once again at NextPage, we found that we needed some way to organize some of our internal data and a wiki seemed like a natural solution. I looked around a few implementations but everything seemed so messy and feature-creeped that I just decided to make my own (that, and I secretly harbored the ambition all along). Since then it's been downloaded over a thousand users, and is verging on its fourth release. It's an open-source project on Sourceforge.net, and more information is available at QwikiWiki.com. PHP on Apache.

QwikiWiki was a great project for me in two ways: First, it was a fun technical challenge. It really helped solidify my understanding of PHP and web architecture, and each release was substantially more robust and well-designed than its previous. Now I'm starting to create some good PHP habits, and I feel increasingly confident with the language.

But more importantly, QwikiWiki was a great exercise in "finishing what's started". Basically, it was pretty easy to get the "first 90%" done, where all the features basically work for me and for my needs. But getting the "last 90%" was a real challenge. Organizing beta testers, managing bug reports, creating the website, embedded context-sensitive help, managing the mailing list, managing a download site with version management, READMEs... it all adds up to a lot of crap that just needs to get done. But I'm really glad to have done it, and I'm very satisfied with the professional and customer-focused result. Every day I get registration emails from new users, and the overwhelming comment is "this is so much easier than any other wiki I've tried". It's a great feeling.

April 2003: Qwiki
At the GDC I for the first time learned of the Wiki collaborative-Web paradigm. Fascinated by its similarity to automated documentation (ala JavaDoc or Doxygen) I came up with the idea of creating a collaborative API documentation system based on the Wiki techniques. From there the idea has grown into a general collaborative space for software development designed to serve as the living repository for all project-related documentation. At this very moment I'm still defining its inner workings, but it's an interesting project that I hope will help my in my future work.

Though perhaps the worst cell phone on the market today, the T-Mobile Hiptop (aka Sidekick) is the world's best portable email, AIM, and web-browsing device. But for all its glory, it is lacking two standard cellphone applications: a calculator and alarm clock. Seeking to at least partially rectify this, I downloaded the SDK and created my own infix calculator, released under the BSD license and available for download on its project on sourceforge.net.

Inspired by the Nokia NGage development kit that was handed out at the Game Developer's Conference early that month, I came up with the idea of making a modern update of the classic Atari Combat game. One neat feature of the NGage is its Bluetooth capability, which creates interesting possibilities for high- speed multiplayer gaming. In this project I started off playing with the Symbian SDK, but found it incredibly obtuse and unpleasant. Instead I decided to just prepare a simple abstracted mobile environment of my own and program to that, with the idea of using this to easily port to a variety of real mobile environments (GBA, NGage, Hiptop, etc). Once done, I prepared the beginnings of the game, including a FSM for the menu environment and a basic script engine.

As it stands I can control a box as it runs around and shoots other boxes that chase it. Needless to say, it has a ways to go. But in the process I've learned that realtime AI is incredibly hard, and lacking an easy way to actually test the multiplayer component (which would be the only fun part of the game), I sorta lost interest in the project. Regardless, I'm hoping to apply some of the same technology to a Penny Arcade game that is being built by some fans, but we'll see where that goes. Combatallion is written in C++ using Win32. A quick design doc for the simple game can be downloaded here.

January 2003 - March 2003: QSite Platform
One day I came up with the idea of creating a platform for fast website development and deployment, the ultimate goal of which was to allow individual users purchase, customize, redeploy, and maintain websites (such as personal blogs or corporate portals) without technical expertise. Doing this would require a standard way to package Web applications, an end-to-end installation and customization system, and a truly platform-independent API for website development (ie, beyond what is offered by PHP). To explore this idea I prepared several documents for review, each of which can be found here. In the end, however, I couldn't get anybody else excited about the idea and thus, though I think it's a good one, I don't have any practical way to pursue the idea in a way that would prove successful. Alas.

Feeling somewhat nostalgic for the "good old days" BBSing with my enviable 1200 baud modem, I've decided to build a BBS-style website. Though I considered making the entire thing truly teletype, I eventually figured that'd be much more of a pain (to me and you) than the coolness warrants. Instead, I'll just make due with the gaudy colors and pseudo-menus.

November 2002 - Present: Sigtonoi.com
My favorite hobby is debating and discussing topics of many natures, though most frequently world politics, with just about anyone that will tolerate it. In practice, my preferred medium is face-to-face as its the most exciting way to do it. But, this medium suffers from "emotional pollution", where people get more concerned with "appearing right" than "being right". For this reason, in theory I think the best medium would be in an online, written form. To this end, I've exchanged hundreds of debate-emails with dozens of people, and have found that commons problems repeatedly occur: people lose track of what was said, drift all over the topic, change viewpoints without notification, and generally, the whole thing gets increasingly frustrating and confusing until everyone gets sick of it. All this has fed into my decision to create Sigtonoi.com -- a specialized forum optimized for managing long-running debates between many people. It's questionable whether it'll ever take off, but the process of creating it has helped refine my understanding of the debate practice itself, as well as taught me a lot more about PHP and MySQL. Furthermore, Sigtonoi has given me another chance to play around with hierarchical writing styles, a personal pastime.

June 2002 - March 2003: CozEngine
Easily the largest and most challenging project I've ever undertaken alone, CozEngine is a standalone platform for developing 3d graphical applications. Weighing in at around 18,000 lines (every one of which was written by me), it boasts its own 3d scene graph, 2d GUI manager, custom scripting engine (with nested expression evaluation and functions), file-mapped data access, OBB collision-detection, ROAM-like continuous level of detail heightmap rendering, RTTI infrastructure, and lots, lots more. Of course, all that's been done for months and is just a platform for doing research into the real cool stuff. To be clear, the "cool stuff" isn't trying to make the best ROAM terrain system ever -- that's surely been done already. What I'm working on is how to go beyond traditional continuous-LOD terrain engines using new techniques, which I'll leave a mystery for now. Regardless, it's all written on my laptop in C++ using Visual Studio 6.0, and the only 3rd- party tech it uses is Win32 and OpenGL. In the end I tested what I wanted to test and proved what I wanted to prove, and thus the engine has been mothballed for the time being. Feel free to download the demo (CozEngine Demo.zip), or read more about it (CozEngine Demo.doc).

May 2002: The Precision-English Dictionary
A core problem I encounter in discussions on any topic is the use of extremely imprecise and ambiguous language. This is obviously a fault of the language itself where a lot of context is required to distinguish between, for example, the various forms of "right". Lacking the time to establish this context it's often impossible to have a conversation of precision whatsoever. To rectify this problem I put together a quick PHP/mySQL application to build a dictionary of precisely-defined terms in (that's right) a hierarchical form. Plus, given a block of text written in Precision English it would automatically detect words in the dictionary and craft the appropriate hyperlink. The end goal is to create both a large dictionary of internally-consistent definitions, as well as a tool that could easily map from Precision English to standard English through useful hyperlinks. I got the thing working in a basic form, but sorta lost interest and never developed the dictionary size to be useful in the real world. As it stands I hope to drop integrate this functionality into Sigtonoi in some form, but haven't figured out the best way to go about it.

While checking my email in a cybercafe in Tulum, Mexico, the owner of a group of Cabanas down there remarked that he needed a website done, and wondered if I could do it for him. Of course the only answer to such a question is "Yes", so I pulled out the digital camera and laptop and got to work. The whole thing didn't take too terribly long and wasn't that hard, just a static PHP webpage (I used PHP in order to simplify its multilingual aspect, which never materialized).

February 2002 - Present: 360ToGo.com
Seeing as how I have a digital camera and laptop on my trip, I figured I should make a website to document my travels. Building it was my first foray into dynamic website programming, and it introduced me to PHP and MySQL. Also, 360ToGo.com has been an experiment in hierarchical writing, where I attempt to circumvent the need for leafing through pages and pages of a big list by using a hierarchical organization scheme. I've learned that it's hard to maintain the hierarchy while actively writing it, but I think it'll come out strong in the end once I've had a chance to reorganize it all into a giant photo album of the trip.

November 2001 - December 2001: NetBack
Something that's always in the back of my mind is that I never back up nearly as much as I should. I realized one day that I'm probably not the first person to have that thought, and so I started thinking more about exactly why I don't use any of the existing backup solutions out there, and what kind of solution I would use. In the end I realized that the biggest reason I don't back up with regularity is that I didn't have any sort of permanent server on which to keep my backups, nor any convenient way to get it there from my laptop (I discount out of hand any non-Internet solution as just too tedious and manual). With this in mind, I conceived NetBack: a backup program for the masses. In essence, the idea is to configure NetBack to monitor the tiny, critical subset of a computer's data (for me, my code and documents), compute daily deltas, compress the heck out of them, and then -- get this -- email them to myself and use my email server as an archive. The theory is that between my email and my local computer, the chances of both suddenly disappearing is rather remote. Furthermore, I figure that everyone that can access the Internet must have an email account, so this would be a way for anyone to backup their files in an automated, online fashion, without relying upon service subscriptions or setting up their own permanent server. Anyway, I whipped up a functional prototype: SMTP, POP3, Base96 encoding (no it's not a typo, those extra bits matter!), XML- SAX configuration file, as well as byte- level delta computation and a nifty Win32 GUI to manage it all (I started with MFC but realized it was more a pain than a joy for this application). My idea was to create a pretty simple shareware utility that could grow into a larger service and, like all good startup ideas, eventually take over the world. But of course, like all good startup ideas, it overlooked some major issues (such as AOL not offering POP3 access, and Hotmail/Yahoo recanting from free POP3 access and reducing storage space), and was more of a pain to use than I originally conceived (did you know that changing a single letter in a Microsoft Word document can create hundreds of major changes throughout the entire file?). That, combined with some exceptionally good (albeit painful) feedback on business plans I circulated amongst friends and colleagues, convinced me to just drop the whole thing. After all, if I can't take over the world with it, why bother?

My time with NextPage wasn't marked by any independent projects, per se, but rather me being on call to fly out at a moment's notice to do emergency documentation. Be it helping gather requirements, document/invent a software development process, prepare marketing materials or whatever, I got to taste a wide variety of documents in an equal diversity of projects.

Though it probably doesn't matter, technically I'm not supposed to talk about it due to nondisclosure agreement. So, I won't go into specifics, but they're really pretty boring and irrelevant anyway. That said, at this point I was pretty excited about learning how to write well in a technical sense, and was short on cash, so I decided to get a contract job technical writing (the real dotcom bust hadn't sunk in yet, so I got a couple offers despite having no experience in this area to speak of). The contract I picked was with a company called netLens which, in theory, was developing some super-cool and super-secret distributed computing technology. Having just sat around for months thinking about the Ubiquity Project, this appealed to me tremendously (that, and their offer for full-time, permanent employment didn't sound too bad either).

Basically, they were a month away from shipping their major product, and they had no documentation to speak of as they couldn't find anyone with the engineering background necessary to write it in a way they liked. So, I show up and after making my introductions, I request a complete copy of the API (in the form of sparse Javadocs) and everything written by the previous technical writer (who wasn't shaping up as they liked, leading to them hiring me). With the red folder in hand, I walk across the parking lot to the nearby Starbucks, get my Zen tea and a comfortable seat, and pour over the documents.

To my dismay, not an hour into my new job, I'm entertaining thoughts of quitting. I mean, their big project is just terrible. I'm guessing I could have put together a prototype of what they were doing in about a weekend, though they had already spent well over a year and millions of dollars to get where they were. But worse than that, I would never bother to put together a prototype because the whole thing is just pointless anyway.

Regardless, I needed the money, and I really, really liked the people with whom I was working (excepting the heads of the engineering department -- some academically-smart but practically-inept people in whom everyone misplaced a whole lot of trust). That, and they were really screwed as it was, and me quitting would be a real downer. So, I worked night and day over the next month to put together an API and programming guide (tutorial) for the supertech. This was passed to a real pro technical writer for layout and editing, and we finished everything just in the nick of time.

Of course, a funny conclusion is that exactly one day before we were to ship our product, the very day that we received a big boxful of CDs... the whole product was canceled and remarked for internal use as we were bought by NextPage, a really cool company out of Utah. Furthermore, about a year later, the whole thing was canceled as, apparently, everyone came to my same conclusion.

February 2000 - November 2000: UbiquityProject
In one sense, UbiqiutyProject.com is a website I built to showcase some crazy technology ideas I was tossing around at the time. The website is entirely static, but generated using a command-line Java program from XML source files. It was my first real attempt to make a modern website, and my first serious use of the XML DOM interface. This was also my first real attempt to use a hierarchical style of writing where each parent node completely summarizes its children and thus encourages "drilling down" rather than "paging through".

In another sense, however, the Ubiquity Project was basically my attempt of rethinking how the Internet and computers at large should work, from scratch. I attempted to categorize the major problems that computers attempt to solve, the various technologies that do and may soon exist, the problems that we face and the solutions they require, and so on. Then, given all this, I tried to present in a self-consistent fashion an alternate reality in which all the major dreams touted by today's visionaries could actually come to be. However, its major failing (if it can be called that) is that it requires rather radical changes from how today "works", as well as presumes that alternate paths were taken. I do feel somewhat vindicated that a few of my predictions are now coming true, but I likewise am a little bummed that I couldn't figure out a way to capitalize any of those ideas.

My foray into the whole "dot com" mess lasted a full six weeks, but covered a lot of ground. It was being started by some people I knew and liked, but I was clear from the beginning that I didn't understand what we were trying to do and was only giving it a shot because Steve Jobs, Larry Ellison, and Michael Milken were on the board of directors (or so I naively thought). When I found out that my boss just blatantly lied to me about this, and then had the gall to just brush off my confusion by saying "It happens," well, I didn't stay on too much longer (even though he graciously told me "I just might be able to pretend that you didn't resign, but I can't promise anything."). They did pay for me to move to California however, as well as gave me a huge bonus check the day before quitting (due to this crazy incentive program that I was strenuously against but hesitantly accepted -- after all, Steve, Larry, and Michael on the board doesn't come along too often, eh?).

News Flash: Recent discussions have informed me that he didn't lie to me intentionally, he was misinformed himself. I'm terribly sorry for the wrongful accusation.

As I understood it, we were some kind of children's website, though nobody seemed to have any idea what that actually meant. Of particular importance, there were few ideas as to how we actually made money. My role was to create a sweet set of client-side tools, such as a music player, instant messenger, file sharing, and so on. I was all into this, and as such I worked up (on paper) a strong architecture and fantastic skinning system that'd allow for extreme flexibility, as well as all sorts of future cool directions to go with Marimba- style autoupdating, integration of point systems for prize/product redemption (one of the few money-related ideas we were seriously considering), and so on. But despite how fun it would have been to make these tools, I never figured what they had to do with this whole website thing and thus couldn't get into it knowing that the rest of the company was on the verge of implosion.

Anyway, I think my boss at Kewlminds was the first person I truly upset by leaving (see ReKewlminds). The strange thing was that rather than attempting to explain how my staying was in my best interests, he instead took the angle that I was betraying his personal loyalty and that I, to quote "didn't have what it takes to hang with the big boys". Um.. ok. That's about as absurd as when I quit Motorsims the president responding to my friendly "Well, maybe something will work out in the future..." with a harsh "In this industry there are no second chances" despite must of the company having been staffed with second-chancers. (For the record my incredibly-cool boss at Motorsims supported my leaving, and left himself perhaps a year later.)

Though I never participated in the creation of what is now Moto1.net, I was actively involved in the initial concepts. For background, Moto1.net was intended to be a leading motorsports news and gaming website, combining the best elements of real-world and virtual racing into a single portal. Having just completed the disastrous release of AMA Superbike, many in the company were interested in plotting an ambitious course where we could rise out of the ashes of despair to become a real name in the motorsports gaming world.

The big idea I and others were pushing was to build a persistent online racing world, allowing players to use the same character/avatar in multiple arenas (car, superbike, motocross, drag, boat) in a sort of major Gran Turismo style game. Money you won in one area could be spent on any other (so if I were a crappy on a superbike but killer in a hydrofoil I could take my boat winnings and buy a nice bike). After all, we had (or was on the verge of getting) exclusive gaming licenses to major bodies in all these areas (AMA, SCCA, NHRA, etc.), so we thought it'd make sense to leverage them all together.

Furthermore, given our exceptional access to these racing communities, we were thinking of augmenting a regular racing website (of which there were many established players) with high-profile reporting on our own virtual racers. Thus, when reporting on the results of some major AMA tournament, we could have photos (screenshots) of a simultaneous virtual AMA tournament and interviews with the riders (players). After all, we actually had the AMA rules re-written to make virtual racing an official mode of racing, so we wanted to solidify the realism by including real-world sponsorships, reporting, and treatment of the virtual racing community.

Granted, it was all very ambitious, and it's understandable that we wouldn't commit ourself to such a risky venture 100%. But, we couldn't get any traction on the idea whatsoever, and thus the company has since dedicated itself to carving out a niche at the lowest price-point in the market. Soon after this I left the company. Again, if you're not at least committed in theory to trying to take over the world (or at least your market), why bother? If I wanted to hate my job I'd go flip burgers.

Fresh out of college I entered the exciting world of game development with Motorsims, a small startup in Dallas, Texas (I was employee sixteen, though we never did grow much beyond thirty). Though hired primarily for the graphics engine, I became the de facto architect as the original man to do it got tied up in other things (such as dealing with the crazy politics and insane management of the company). Thus, while I didn't actively take part in all of the areas, I was pretty much responsible for gluing all of the individual parts together. In retrospect, I definitely wasn't the right person for the job -- it was fun and exciting and educational to be in that role, but at the time I was just too inexperienced to reliably make good decisions. For example, I'd often make major changes without considering the ramifications on others, particularly the artists. But in the end, to my knowledge there were no fatal bugs attributed code for which I was responsible (though I never had the chance to implement some major graphics optimizations, so framerate wasn't where we wanted it to be).

Not that it mattered, as the entire project was a disaster, and I was one of many that pushed heavily for the whole thing to be canceled at least six months before shipping. It was abundantly clear that we just didn't have our act together, and good changes made at the end were too little too late. Plus, my insatiable curiosity got the best of me and I started rummaging through our business plan, budget, and marketing data, and realized that we had no chance in hell of making our projections, and thus were heading towards a brick wall. I shared this with some trusted others and we pushed, unsuccessfully, to have our company acknowledge reality before wasting more money and embarrassing ourselves further. In the end, we shipped something like three thousand copies (ie, virtually nothing), and we estimate that over half of our customers never actually got the game to work. Of course, it could be worse: we did manage to catch the bug in our first gold-master that required reformatting every computer it touched.

Given the 32-bit vector floating-point capabilities of the PIII processor (then given the internal code named "Katmai"), they realized they had enough precision to do "fun" physics and graphics, but not enough to do serious simulation or visualization. Thus, they decided that the major thrust of their marketing would be towards the gaming customer base, and wanted to have some good statistics to back up their claims. However, seeing as how no shipping video games yet used this new processor or its (presumably) great features, they had to create their statistics from scratch. To this end they brought in me to create a stand-alone demo incorporating basic game physics and graphics for purposes of performance analysis and producing neat marketing stats. Given only a few weeks over my Christmas break to do it, we knew the project had to be pretty constrained in ambition. Lots of other people had been working on optimizing the graphics pipeline, so it was agreed that I'd extend upon my summer's work with collision detection. In the vein of the old SGI GL demos, I made up a box that could hold a collection of rigid shapes bouncing and spinning off each other. The shapes we chose were concentric rings and cubic boxes forced in close proximity, though seeing as how OBB is really a pretty efficient algorithm, our scene was rather contrived to stress the collision system.

For some reason somebody at the University of Michigan College of Engineering wanted 3d models of various buildings around the North Campus. Somehow I managed to lad that gig, and thus spent a couple months fooling around in AutoCAD reconstructing 3d models of the Campus Commons and Media Union from stacks of 3d blueprints. Halfway through the process we discovered that a small department of the University exists for exactly this purpose, and then the project was handed to their much more skilled hands.

The summer between my Junior and Senior years of college were spent in Folsom, California working on the secret Katmai project, which eventually produced the first PIII processor. At the time, the big excitement over the Katmai was the MMX 2 instructions (later renamed KNI for Katmai New Instructions because they lost the trademark for MMX, and then renamed SSIMD for Streaming Single Instruction Multiple Data, I think), which in my opinion were anything but exciting. Granted, the idea of being able to work natively with four-component floating-point vectors sounds like a great idea. But seeing as how they inconceivable didn't include any dot-product function -- despite the dot product being at the heart of the most important graphics operations -- they were just really difficult with which to work. Instead, you had to do all this crazy rotation crap that ate up tons of cycles and introduced severe algorithmic headaches.

Anyway, I was hired to evaluate how the KNI could accelerate collision detection. After researching the various options, I decided that Oriented Bounding Boxes (OBB) stood the best chance of gaining future widespread acceptance, as well as for gaining the most improvement from KNI. Thus it was decided that I'd create an optimized version of the VCOLLIDE OBB library in x86 ASM, with and without KNI, and run it through an internal program that simulated cycle-by-cycle how it'd perform on the nonexistent Katmai processor. In the end I was able to eek out substantial improvements using the KNI capabilities, though the lion's share of the gain actually came from what I though was a clever use of the KNI (non-vector) memory prefetching functions: Basically, every time I'd walk down the tree I'd tag each node with the result of the collision test from last frame. Thus, before computing the test I'd just prefetch the data that would be required if the test came up the same as last time (which it usually did due to frame coherence). Then, by the time the test was done computing, the memory for the most-likely next step was ready to go, neatly side-stepping the erratic memory access patterns of traversing a binary tree. As for the vector functions, there were some benefits to using them, though it was just so nasty to get working that I don't think I'd ever really bother with them in production code.

March 1997: Non-MMX Vector Functions
One day I got this really cool idea: I could jam a complete 24-bit RGB color vector into a single 32-bit integer and operate on all three components at once by using the remaining bits to pad the data. Given my recent work on trying to make a fast dithered/shaded bitmap blitter, this was going to help me a ton. I worked pretty seriously on the idea for a few days, until I learned that the new integer MMX functions effectively did what I was trying to do, except much better.

On a whim I headed down to the Urbana/Champagne university for an AI competition where, in essence, four teams control a pac-man like avatar in a single world of ghosts and pellets. Whoever gets the most points wins the round in a big ladder. We started early in the morning, and the competition was held that night. Team sizes varied, but I was flying solo. I decided to use a kind of A* technique where I'd sum the shortest distance to every pellet on the board for each potential direction, always moving toward whatever direction would take me towards most pellets. This worked extremely well, but I had trouble finding a good penalty factor to negatively weight in the sum of distances to ghosts. Short on time, I threw in a quick hack at the very end that contributed to disaster: by arbitrarily halving the value of whatever square I had just come from (in the hopes of preventing backtracking) I inadvertently halved the perceived danger of walking backwards, such as towards a ghost. Doh! When it came to the competition, each team had so many seconds to pick a move. Most of the other teams took more random paths, or just followed walls and just ignored the ghosts, and thus their decisions were made almost instantly. But whenever my avatar got up, I'd use almost the entire allotted time to think out my move. All was going very well and I was chomping pellets at a brisk pace, but eventually I was running away from a ghost and my avatar's bug caused it to alternate between two squares in a paralyzed fear as the cruel ghost charged upon its prey. Alas.

In 1997: Tile-Based RPG Engine
Having just finished off a couple simple tile-based engines for various school projects, I decided to see what I could do "for real". In the end I came up with a tile engine that had animated tile graphics, transparent (but not translucent) objects, classic Ultima IV-like visibility shading, and flickering realtime point light sources (no bilinear filtering) that used the same shadowing technique as for visibility. My true pride, however, was my x86 ASM bitmap blitting function: I divided the 256-color palette into sixteen color gradients of sixteen shades each, which would be used to render a source bitmap and transparency mask with shading and dithering. Ahh... it was so pretty.

In 1997: Dyson
Ahh, a true victim of the "second system" syndrome, I overextended myself on this one, big time. My good friend John Wolthuis and I were collaborating to create an RTS game for a video game class we were taking. The goal was to tweak with timelines a bit and record all troop movements in a keyframed form, such that you could reconstruct the state of the game at any previous point, as well as project how the game would look in the future. The point (I think, it's kinda murky) was to allow each player to define his moves in a turn-based fashion, and then execute the moves in parallel, while allowing for complex maneuvers using the extrapolated planning system. Anyway, some kind of memory leak appeared there that just collapsed the whole system and eventually, I'm not sure if we could even make it run when we tried to demo it. Of course I say "we", when the true blame is that "I" couldn't get it to run. John's graphics (we split the work) looked and worked great (though I recall the last rendering of our opening movie was so close to the deadline that we said "I hope this one works, because we simply do not have time to render it again."). Anyway, the graphics engine was pretty cool and worked fine: we went for an isometric view where our transparent tiles would overlap in a way that looked really good. That, and the editing toolset (for assembling tiles from multiple bitmaps, assigning properties to tiles, and building maps) was a thing of beauty.

In 1997: Macrocosm
Though I really didn't care about grades throughout college, I was seriously upset that our group only received an A- on this project, given the exceptional ground we covered. Granted, it wasn't a fully-functional, standalone game, and it wasn't in Java (which the teacher just loved to death), but it was still impressive. Basically, like all ambitious students, we figured a nice constrained project would be... a complete MMORPG. I took the client, and my two partners took sound and networking (including the server), respectively. The client -- indeed, the entire thing (including our custom orchestral MIDI score) shaped up beautifully. What was really missing was, well, the whole game part. You could walk around, pick up and drop items, chat, and even fight, while exploring a huge map (we had no NPCs, however). But it wasn't really engaging enough to be called more than simply a technology demo. Anyway, it was stable and functional and when our teacher deigned to spend all of one and a half minutes evaluating our semester-long project, other students exploring the game mercilessly PK'd his avatar until he just got bored and went to look at some fancy Java gizmo. Oh, the humanity!!

As a Junior I managed to convince the super-cool professor of the school's only real computer graphics course to let me be the TA for a semester. I enjoyed it tremendously, and I got to teach a couple classes as well. Most of my time was spent helping students with their projects in the computer labs, as well as defending them from the other TA. (At one point he explained to a student "To normalize a vector you just divide its components by the dot product of the vector and itself." When I explained to him that actually you'd have to take the square root of that first (unless it was already unit length, but then why are you normalizing it to begin with?), he actually told me "Well... I'm the senior TA, so let's just go with what I say." Err.. whatever dude.) One of the highlights of the class was meeting Bressenham, a friend of the professor, and the inventor of the line.

The University of Michigan is laden with this bloated organization called the Michigan Student Assembly (MSA) -- a group that fashions itself as being some kind of student government, but in reality just consumes money as a value-free middleman between the university funds and student groups. Some friends and I decided that we'd start a political party based on the platform of eliminating the MSA and creating a more streamlined group that exclusively distributed funds to student groups (I think, among other things). Given this, the name Nihilist Party just really kinda fit, especially with our stark white-on-black themed posters and buttons.

In essence, our argument was that nobody even knew what the MSA was, and thus they really couldn't claim to be a leader of anybody (other than the status- seeking political-science wannabes). To back this up, I decided to poll some students via email. Like... all of them. See, the /etc/password files had a bit set that indicated whether the account was for a student, professor, or whatever. Thus, I figured I'd just loop over this file and mass mail everyone with the correct bit set. (The debate on spam wasn't yet in full swing, though it was still a controversial move.)

Death threats aside, the poll was a success and we got lots of great data to back up our claims. And to be clear, we limited our poll to one in four students, numbering roughly ten-thousand. So it could have been worse. And, it gave me the perfect opportunity to learn Perl.

Of course, the next day I was called into the office of "Grue", the head of network security. Seeing as how I was an employee of the university network, I figured I had a problem on my hands. However, the UoM is extremely liberal, and didn't (yet) have any rules against what I did, so he instead just offered suggestions on how to more accurately determine which accounts are valid and actually go to students (apparently the bit I trusted was pretty inaccurate).

Sadly, we still lost the race. Later, some of the same people decided to run a spent carbon rod, of the kind you'd to cool the core of a nuclear reactor, for a seat in the MSA. Though it didn't win, it did surprisingly well.

In 1996: Regatta
Perhaps the only truly fun, standalone game I ever made by myself, Regatta was a two-player sailing game reminiscent of Mario Kart. It used a split-screen, top- down, smooth-scrolling tile-based engine with animated tiles and wonderful programmer art, supplied by me. The boats were rendered in 3d Studio R4 (I was really hip with R4, but Max is just way over my head. If anyone has a copy of R4 laying around, I beg of you, please contact me) and consisted of I think thirty-two different angles of a large sea-bearing vessel (not really racing quality, but oh well). The wind would blow from a particular angle, randomly and slightly changing in direction and magnitude, while you had to race in a circle for several laps around a big island. It even had a fancy stopwatch (using my own Bressenham line function) and intense scrolling numbers and the works. Really, I was very proud of the polish I was able to get out of it (primarily due to how constrained I kept its scope). Though I had hoped to get some fancy Mario-Kart deathmatch going, that never materialized. Anyway, I got an A on this one. Cha-ching!

In 1996: BSharp
Perhaps the hardest class I ever took (that had information of value, that is) was Compiler Construction. Wow, tough stuff. But one of the projects consisted of creating a functional Unix compiler for a C-like language called BSharp using LEX and YACC.

When looking through a list of departments in the university I noticed we our very own virtual reality lab. I immediately headed over and started begging for a job, and they eventually relented to offer me some work modeling the interior of a racing yacht in AutoCAD. Later it was hooked up with the hull (done by another student using decimation techniques) to create a single model.

In 1994: Interactive Computer Graphics
My first year at the University of Michigan I noticed there was a class for computer graphics. However, it listed prerequisites up the wazoo, not the least of which was graduate student standing. However, I spoke with the professor and, against his recommendation, I took the class anyway. It was great fun, and served as my first introduction to OpenGL, beginning a long love affair.

In 1994: Gecko
Though clipping was still giving me nightmares, I wrote my first animated 3d engine in C -- a black and white wireframe thing that showed an animated gecko walking (very primitive), and had fancy special effects like motion blur. My filled triangle blitter was just killing me, especially the textured one.

In 1993: "Make It Colorful And Exciting!"
While in high school I went to a local community college to take my first C programming course. It was really a pretty simple course, and in it I learned for the first time that "people don't care if you skip college classes". (After that I never went and just delivered assignments to the teacher directly.) One of the assignments was some sort of accounting application or something, but the teacher instructed the class to "use lots of colors and make it look nice!". I took this seriously and whipped up a pseudo-GUI interface, complete with (what looked like, but weren't) drop down menus, dialog boxes -- the works. So I came to class with my floppy, as we were going to show them off as a group, when I started to see what the other students were turning in. For example, "for my application, I decided to make the text blue." Just, plain TTY text, but blue. Feeling uncomfortable, I decided instead to just hand in my project in private.

Suffering from extreme clipping problems and limited to black-and-white wireframe, my first 3d engine was in Pascal using standard library line functions. I think the only scene I had looked like Monopoly building.

In 1992: Yet Another Tile-Based Engine
Though it finally succumbed to pointer bugs that I just didn't know how to shake at the time (it was my first real experience with pointers, such as directly modifying the frame buffer), I had a really cool tile-based engine running in Pascal. Ultima-IV visibility shading, animated monsters that would chase you until they hit a wall (no path finding), custom bitmap editor, animated tile graphics, etc.

My first real tile-based engine was using colored ASCII characters, reminiscent to some of the fancier door games on BBSes. I seem to recall only having a tiny world of a single castle, but I think I had mouse support and a decent editor going.

In 1988: Hamburger Maker
I think the point of this program was to choose what kind of toppings you wanted on a burger, and it'd draw a picture of said burger, kinda like the game "Burger Time". I never really got that working well, but the real innovation was with the sound: This was the first program I ever made that incorporated sound, in the form of a single, defiant "Boop!" at the start of the program. Basic on C64.

In 1987: Kim's Astronomy Helper
The daughter of my parent's friends, Kim needed help learning some astrology, particularly identifying constellations. So, I put together a big program that'd display a picture of the constellation (rendered using C64 characters) and give a multiple choice for the name, and it'd then display a score at the end. The most impressive aspect of this application was its length: I could do no less than three laps of our house while the program was listing.

In 1986: Cheating In Lemonade Stand
The earliest thing I can remember programming was actually a hack: our math class had a Commodore 64 in the corner, and one of our assignments was to play Lemonade Stand -- you know, where there's a picture of the lemonade stand and it shows you how hot it is outside, how much money you have, how much it costs for lemons and sugar, and asks you how much to sell lemonade for, and you've got to try to make the biggest profit over the summer? Well, I wanted to win, so I just upped the temperature a bit. Like, by a million degrees. So, I could sell my lemonade for a record markup, as darn those guys were thirsty.

Of course, my memory isn't the best in the world, and when I told my parents about my attempt to remember my first programming experience, they assured me I had been at it well before 1986. And lo and behold, now that they mention it, I do remember a certain flying-bat program I'd whip up on any BASIC-enabled computer I could find whenever taken to Radio Shack: basically (ha!) a two- state ASCII bat (wings up: "\o/", wings down: "/o\") would bounce about the screen in an endless frenzy. Truly, the essence of digital fun.

May 6th, 1976: David Barrett, 1.0
But how can I forget the ultimate act of genetic engineering, coincidentally released to the world on my birthday: me. Granted, I think my parents had more to do with this than me, but I take no small amount of credit for the event.