31 Things, Day 15: Programming

31 things I'd rather be doing right now

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

  1. 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
  2. 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
  3. Does the tile the pawn wants to move to exist? If no, do something else because the tile can not be found. Otherwise, continue
  4. 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
  5. If you got this far, the move will now happen:
  6. Process/do the physical move itself
  7. Evaluate the ramifications of the move to the pawn, the surrounding area, and/or the whole game itself
  8. 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.

How I Wrote a Novel, Part Three

(continued from part one and part two)

So I had just finished writing half a novel in a month (50,000 words!), and after an honest critique I had to face an uncomfortable truth: it wasn’t really a novel.  I had a choice to make.  I could either wallow in self-pity, go back to making it a video game, or start educating myself on just what a novel really is.

After some wallowing, I decided I didn’t want this story to be a game.  I wanted it to be a book.  So the education began.

I’m a fairly adept writer.  I don’t say that to sound arrogant, I know I’m far from a great writer, but I also know that this is a talent I have had for a long time.  If you peruse my site, you’ll see I’ve been writing for over ten years.  Never published, mind you, but that’s only because I’ve never tried yet.  I’m man enough to admit when I don’t know something, though, and I was faced with something I did not know: what makes a novel good enough that people will buy it?

I’ll be creating a list of resources soon so that people can see all the things I’ve read up on over the last year.  For now, I’ll list just three things that had a major impact on shapping my novel’s story.

First, I had to boil the whole thing down to a protagonist who wants something, and give the story a theme.  My first attempt had a protagonist, sure, but he was just thrown into the middle of saving the world because I, the writer, made it happen that way.  Fine for a video game, not really believable for a novel.  So I searched my heart, decided on the “big picture” story I wanted to tell, and I found my theme.  From there, I used that theme to drive the motivations of my main character so that he had a reason for doing the things he did.  Every obstacle in his way equaled a scene of action, and those scenes together formed a plot.

Second, I had to structure that plot.  For this, I found the Ten Scene Tool from The Writer’s Little Helper to be an excellent resource.  The general idea of this tool is to create rising and falling tension, a point of no return, a climax and a resolution, and break them down into ten key scenes.  The novel only has ten scenes?  Of course not, but it has ten really important ones, and they form the skeleton of the story.  Everything else built around them, filled in the gaps so to speak.

Third, I needed some guidance from a master.  To that end, I read Stephen King’s On Writing.  I recommend this book to anyone who wants to write.  Not only is it an encouraging read, he is refreshingly honest about what it takes to write in a way that people like to read today.

As I said, there were a lot of things I looked at, but these three were essential.  Another final piece I found everywhere I searched was, “Finish it.”  I had to resist going back to the first half and begin editing.  I made myself write another 60,000 words before ever looking at the first 50,000 again.  It took me 8 months, but I’m glad I did that way.  Now I could look at my huge document and say, “alright, draft one is done.  I did it.  I really wrote a novel.”  It was a great accomplishment, and those of you who have done it know the feeling.

NOW, I had to piece together two halves of a book and make sure they told a coherent story.  Oh what fun.

…Continued in part four

How I Wrote a Novel, Part One

My novel wasn’t a novel at first.  It began as a video game.


Since the mid 90’s I have always wanted to make my own Role Playing Game (RPG) in the style of my old-school SNES favorite Final Fantasy II (IV if we’re being true to Japanese numbering).   I still do.  Making games takes time, though.  I worked on learning programming over the course of many years, and only gave a little bit of thought to the story line.

A few years ago I discovered RPG Maker XP, and then the easier-to-use RPG Maker VX.  Wonderful tools, just a little too expensive and too short of a trial period.  But I started making something I really liked without the hassle of coding.  It was fun.  And lo and behold, a story emerged.

The demo ran out of time, but I kept writing the outline for the story.  That was fun too.

Then life happened. Depression happened.  Life ambitions fizzled, and with it my life’s focus.  A dark page.

I can’t remember why I started thinking about the old game, but it was around the summer of 2010.  I guess I just wanted to be creative again.  I looked over my notes.  It was pretty good.  Complex story.  A bit cliche, but standard fare for the RPG genre.  I remember thinking about the first task the game required: go to the temple cellar and kill all the rats (a deliberate cliche).  I remember picturing the lead character, Adain, swatting away rats with a pole, the weakest weapon in the game.  In my mind it looked like a movie.  Wait, what if I wrote it down like a story?  I hadn’t written fiction in 10 years or so.  But sure, why not?  I wrote a paragraph.  Wow, pretty good again.   Not bad for a depressed guy. But it sat for a while.

And then in October of 2010 I saw something that would change my life:  National Novel Writing Month.

…Continued in part two

HeroQuest demo now available!

After over a year of on-and-off programming, I now have a demo of my computer game HeroQuest available for people to test.

Head over to my HeroQuest page for the download link and some screenshots.

Hopefully, the full version will be available in a couple of months.

I would love to hear comments from people who try it out!