StackHack – A game prototyping project: part 4 – moving to production code

In the previous parts of this series I showed how to develop a concept with a paper prototype, how to transition to the first digital prototype and how to further develop and enhance that prototype. In this part I’ll discuss making the transition to production code.

If you’ve taken your prototyping to the point that you’re happy that you have a project you want to progress with, then it’s time to make the leap from your prototyping code to your production code.

A decision you have to make now is whether there is any part of your prototype that could be repurposed for your production version. There are a number of factors that are going to affect this decision. Clearly if you’ve chosen to build your prototype on a different platform, or using a different technology from the one you intend to use for your target system then you have no choice but to start from scratch.

If, as is the case with StackHack, your target platform and technology is the same as your prototyping platform and technology then you might be able to salvage something. There are three important considerations here:

  1. Don’t be concerned about throwing your prototype code away – that was always going to be a possibility
  2. You should never code your prototype with reusability in mind – quick and dirty are the watchwords here
  3. Only repurpose prototype code if it’s going to be quicker and more productive to do that than to start from scratch

Having said all that, there is no point in throwing the baby out with the bathwater, so if there is stuff that is robust enough to reuse and which will save you some production effort and time then go ahead and use it.

That was certainly the case with StackHack, I was able to create my production code by refactoring a lot of the prototype code, which was a quicker process than starting from scratch.

You can play the version with production code. In case you have not read any of the earlier posts, please note you will need an up-to-date browser on a device with a keyboard. The controls are:

  • Move left: left arrow
  • Move right: right arrow
  • Jump: up arrow
  • Pick up/drop a present: space

Screen Shot 2015-01-07 at 15.17.33

Ostensibly, this version looks very similar to the second prototype, but of course a lot of the work (refactoring and re-creating code) has gone on behind the scenes.

The other thing you are going to want to do at this stage, is add the aspects of the game that are not fundamental parts of the gameplay, but add polish. One of the first elements I added was an animation system for the main character.  Rather than have a static character, the player character now shows the relevant frame from an extended sprite sheet, as shown below.

character

 

Note that I am still using what are often euphemistically described as “programmer graphics”. The point it which it is worthwhile starting work on production-quality art, whether it’s to be created by you or somebody else, is once all your animation code is in place and is working well.

The other thing you should note about this sprite sheet is that the character is only ever facing in one direction. Flipping a character sprite about its vertical access is something that can so easily be done in code, it’s rarely worth the effort of adding these additional frames to your sprite sheet.

The other thing you’ll notice about this version is that the cannon is now animating smoothly between its firing positions.

With all the main game mechanics completed, the next stage is to start work on art, audio and level development, and I’ll discuss that in the next part.

This entry was posted in Games, HTML5, Prototyping and tagged , , , . Bookmark the permalink.

Leave a reply