There is something very satisfying for me about programming. I’m specifically referring to coding here; it’s part problem-solving, part art. The problem to solve can be small (make this mess of text into a nice table), or big (make a game). The art part is the design of the code “building blocks” that will work together to make a computer program. The term used among programmers is “elegant code,” and I think it is an apt word. If you can create some code that can be reused for many things, both now and in the future, you just saved a lot of time. You never have to touch it again, because you know it works. I love that.
Take this example from my own game code, which I find to be very elegant, (if I do say so myself). A tile-based game is a grid where objects can move in any direction to a tile next to it. Sometimes an object can’t move for various reasons, maybe it’s blocked by a wall. In any case, a game needs to be able to handle an object moving from one tile to another.
When I first made my Heroquest game, the code handled moving objects very specific to the game. I would never be able to use the code again, because it was very closely tied to only that game. Later, I discovered I could refactor that code and make it reusable. In order to do that, I had to completely generalize what was happening when an object moved from one tile to another. It doesn’t matter if the game is Heroquest or Monopoly or Sorry!
This is what I came up with:
When a pawn wants to move in a certain direction, follow these steps
- Does the pawn meet the prerequisites to be able to move in the first place? If no, do something else because they are not met. Otherwise, continue
- Are Diagonal moves allowed? If no, does the pawn want to move diagonally? If yes, do something else because diagonal moves are not allowed. Otherwise, continue
- Does the tile the pawn wants to move to exist? If no, do something else because the tile can not be found. Otherwise, continue
- Is the tile the pawn wants to move to accessible based on where the pawn is now? If no, do something else because the move is blocked. Otherwise, continue
- If you got this far, the move will now happen:
- Process/do the physical move itself
- Evaluate the ramifications of the move to the pawn, the surrounding area, and/or the whole game itself
- Do any post-move processing (clean up, things that always happen at the end of a move, etc)
Now I had a skeleton framework to make some reusable code, and I could use it any game I wanted. Here is the actual code:
public void move(TileOccupier pawn, Compass dir) {
if (movePrerequisitesMet(pawn))
{
if (!(!diagonalMovesAllowed() && dir.ordinal() > 3))
{
AbstractTile targetTile =
tileMap.getAdjacentTile(pawn.getLocation(), dir);
if (targetTile != null)
{
movePreProcessing(pawn, pawn.getLocation(), targetTile, dir);
if (tileMap.isEnterableFromOppositeDirection(targetTile, dir) ||
ignoreTileBoundaries(pawn, dir))
{
processMove(pawn, pawn.getLocation(), targetTile, dir);
evaluateMove(pawn, pawn.getLocation(), targetTile, dir);
movePostProcessing(pawn, pawn.getLocation(), targetTile, dir);
}
else { processMoveBlocked(); }
}
else { processTargetTileNotFound(); }
}
else { processNotAllowedDiagonalDirection(); }
}
else { processMovePrerequisitesNotMet(); }
}
Not that long at all. And the way it works is that any game I make in the future will be able to use it because it is abstract. I simply have to make some concrete decisions about what happens in the particular game at the various stages of the move. (For example, one game may yell at you when try to move diagonally; another game may do nothing at all.)
For the non-programmer types reading this blog, this post may have been boring. But whenever I look at that code above – something I made all on my own – I think, “wow, that was a really elegant design.”
And then it makes me want to go code something!
So that’s another thing I’d rather be doing now, programming.
Rob Vitaro 
