In the time since the end of Ludum Dare 43, I've been working on upgrading and refining the code. The game still plays exactly the same (go check it out, if you haven't!) but coming back with a fresh mind and more time to think about coding style has been nice.

I had a basic prefab system in place already where you could write out the properties of a Sprite object as a simple object literal. This is still around and it still works, and for simple objects (for example, the coin or sword sprites in Golden Lord) it's a great way to do it because it minimizes the amount of boilerplate you have to write since there's no interactive property editor like you would have in an environment like Unity3D.

Simplified version of Golden Lord's "sword" object: return { animateHitboxes: false, hitboxes: [new Hitbox(-.25, 0, .25, -.5, 0x1)], animations: { down: new AnimationSequence([ new AnimationFrame(assets.images.sprites, 96, 96, 16, 16), new AnimationFrame(assets.images.sprites, 96, 112, 16, 16), ], 100.0), up: new AnimationSequence([ new AnimationFrame(assets.images.sprites, 112, 96, 16, 16), new AnimationFrame(assets.images.sprites, 112, 112, 16, 16), ], 100.0), left: new AnimationSequence([ new AnimationFrame(assets.images.sprites, 128, 96, 16, 16), new AnimationFrame(assets.images.sprites, 128, 112, 16, 16), ], 100.0), right: new AnimationSequence([ new AnimationFrame(assets.images.sprites, 144, 96, 16, 16), new AnimationFrame(assets.images.sprites, 144, 112, 16, 16), ], 100.0), }, };

You can also define code for lifecycle methods like start, update, render (if you need something custom beyond just sprite sequences), and collision events inside this block.

But any experienced developer knows that sometimes the simple way of doing things isn't good enough. Since these objects only allow you to define the properties available on the Sprite class itself, it doesn't provide a lot of room for more in-depth behaviors. It can be made to work, with some effort -- in Golden Lord, I copied additional properties and methods onto the object from within the start method -- but this is obviously neither intuitive nor clean.

The nature of coding for a game jam also resulted in some awkward organization. In the jam version of the code, the hero, the worshipers, and the monsters are all implemented with separate code, but they use common utility functions to share behaviors. This is, of course, how such a thing SHOULD be written, but the common functions then included conditionals that changed the behavior based on which type of character was calling the function.

I also had hard-coded a lot of things in the HTML page for expediency's sake, and while I did at least have the presence of mind to move all of the game initialization scripting into a .js file instead of embedding it directly into the page, it was still sort of a mess, with different parts of things being scattered all over the place and a huge reliance on global variables. Again, this is fine for a jam game, but it's an obvious point of improvement for post-jam cleanup.

So with these issues in mind, I set out to refactoring. In my next blog post, I'll describe the changes I made to the html52d engine to accommodate a nicer way of organizing the code.