Writing "Smart" Code

One of the most challenging parts of the Amoeba project so far is making sure I'm writing "smart code". By this I mean minimizing duplicate code, making the most of object hierarchy, and generalizing objects as much as possible.

One example of this idea is the way I started thinking about how the door mechanic would work in Amoeba. I imagined our protagonist blob of goo being able to ooze through vent grates in the background to get to secret or out-of-the-way locations. Step one was to create a vent object and start describing its behavior. I realized that I could just make the vent act like a teleporter, changing the player's x and y coordinates to the target of the "vent". With a little animation work, I could now have my blob ooze through a vent into some ducts (i.e. teleported t a new area of the level), crawl to another vent, then ooze through back into the main environment (again teleport to the appropriate level location).

This worked great, and I was happy with it, until I started working on sliding doors. Now I had two types of "doors" and started to write checks in the code to decide which type of door I was working with. Then I started working on elevators and was having conflicts with my object hierarchy; doors and elevators are pretty similar.

As I stepped back for awhile I realized that I had been treating elevators and doors are two separate things when really they're both just collidable platforms that may or may not move. They're the same thing and can be treated as such with a few parameters to decide whether they act like a door or an elevator. I also realized that my vents weren't really doors at all but teleporters. This observation allowed me to clean up my code and simplify my hierarchy.

All of this probably sounds pretty obvious to anybody who's job is software development. Although I have some experience in the field, it's not my area of expertise, and so I have a lot to learn - especially how to think.

I think it's interesting to note that the process I described above is not just a programming exercise. The way I imagine and talk about game mechanics and gameplay directly affects how I go about executing those ideas in the code. It's important for me to start to think about the implications of the code earlier in the process. Thankfully my engineering background makes me intimately familiar with the process of design iteration, so I never get too far along before I realize I'm doing things the hard way.

Today was spent on navigating all these issues vis-a-vis doors, vents, elevators, and switches. Although I'm not done yet, I can already tell I've made a huge improvement to Amoeba that will save me a lot of time and frustration in the future.