Demo!

First, a demo is now available for Hackers of 2073! It's really "Hackers of 2073 Lite". The game is scaled back about 50%, but the game has unlimited play. There's no nagging, just a link to our site in the "Start Menu" and help files.

Personally, I dislike the "standard" demo play that a lot of portals are doing. Most sites just allow an hour of play, at which point you must buy or quit. It forces me to whip through the game to see as many features as I can, but I never have any time to appreciate the game. That's why I created this unlimited version.

Postmortem

I really love this part of our splash screen. The gear brings in "Machine Code Games" and, at the same time, is part of our logo. N.R. is a genius!

N.R. and I worked on this game for just under 4 months. What follows is our take on what made this project work and what things could have gone better.

What Went Right.

1. Game-In-A-Day Prototype. N.R. and I wanted a small project to work on. I had an idea, but I felt that it was easier to show than to describe. I worked for about 24 hours straight and created a prototype. That, combined with a page of sentence fragments, was all I needed to describe the game. It also because a "prop" that allowed N.R. and I to describe features in terms of what already existed. We never had a design document during the game (which both of us would rather have), but we managed to work out the entire game anyway. I'm giving that success to the prototype.

2. Partnership Agreement. It was very simple (2 pages), but made it clear what the expectations were during development, post development, and even further (such as a buy-out of one partner to the other). It made it clear what was expected and made the worries of any problems disappear.

3. Off-Site Subversion. It allowed for easy transfer of changes between us. In addition, we each had computer problems during the development. This was no big deal, as we could still access the code and the game with little delay.

4. Long-Lost-Twin Effect. I'm starting to believe that N.R. and I were long-lost twins. We had only email contact, and had 1 or 2 difficulties understanding each other. One of us could describe something, and the other could implement it with no difficulties. Occasionally, one of us would implement something the other was about to ask for. We're an awesome team, if I do say so myself.

Still Sight. A technomage program that allows you to visualize a large area, as long as you don't move.

5. Alpha Testing. I had 5 computers running the game and 6 people who never played it come over to my house. I watched them play for hours, getting direct and indirect feedback that shaped the game heavily in the last months.

6. Everything Is Worth Trying. I consider myself a talented coder and N.R. is a talented artist. When one of us made a suggestion for change, the other had the skill to implement it. This allowed us to try various combinations of code and art until we found just what we liked.

7. 2D Rocks! In 3D, you always run into glitches or problems that take hours to troubleshoot. No so much with 2D content. The graphics went so easily into TGB that we may make a few more 2D games before we head back into the 3D realm.

8. Audacity and Free Sound Project. N.R. did virtually all of the sound effects and music. If you want to get sounds into your game quickly, these products will be a massive help.

What Went Wrong.

Thirteen Squared. This effect was created manually, but looks cool as it is animating.

To quote N.R., "I honestly can't think of anything that went so wrong that I remember it. ...[S]witching
to 2D has been like cresting [a] hill and finding a Super-Fun-Happy-Slide on the other side."

I've thought of a few things.

1. Game-In-A-Day Prototype. This became the game. It should have been re-written from near scratch after the prototype expanded. There came a point where code changes were harder than they should have been.

2. File Transfers. Initially we worked by transferring ZIP and individual files. At one point, we worked for a day to refine the puzzle-opening effect, but we spent a lot of time just getting our changes to each other. It was 2 weeks before I put the game into Subversion. (What was I thinking?!)

3. No Built-In Animation System. All of the gates were animated manually, which worked well, but it was a lot more effort than a key-frame animation system.

IC Sense. This shows the 4 closest IC to your current location.

4. Load/Save. Part of Bullet (1), but all of the state was scattered and was hard to get together for loading and saving.

5. Beta Testing. This was done at each tester's home. Each tester was slow to respond. Our subversion site allows for bug entry, which is something I should have opened up to these users.

Well... I hope somebody finds this informative. It has definitely shaped our work for the next project!