Advanced level editor and some good Gauntlet progress

Well I’m calling it Gauntlet anyway ;)

The best thing about a week away from the internet is the amount of quality time one can spend working out the mundane stuff. This last week I got the chance to spend a week next to the coast with the family. In rare moments of downtime I sat with a coffee and a laptop ironing out a number of bugs and issues with my level editor. Issues largely surrounding the storage of data and integration with the main game engine.

Initially I had worked with the idea of the level editor spitting out JSON formatted code which the game then read in to populate the levels with walls, tiles, sprites and other features. It was working fine but I felt rather uncomfortable storing data in text format. So, being a database guy at heart I switched and dumped all level data in to a MySQL database. The results are very pleasing. The level editor still spits out the JSON formatted text for use in game. I was keen not to have any DB involvement with the game. Not yet anyway. (I’m keen on researching the new features of HTML5 with regard to storing data)

Level editor

Level editor

So as you can see with the screen above I got around to implementing a few new features. Namely backgrounds, entities and a number of flags and modes. I’m fairly sure the screen shot explains all but I thought it worth elaborating on something that has caused me much grief.

Something from my Acclaim days that always haunts me is the notion of scale. When you’re working with a small screen (GBA) scale is a big deal. We always knew that we had little room to move with characters. Indeed memory limitations demanded a small scale with plenty of repeatable tiles. But that’s not such an issue with my game. The issue is with squeezing enough in to the playing arena and not reducing everything to pea size to accomodate. I like large and colourful characters in my games. Chunky sprites makes for happy gamers in my book :-)

So I tried a number of variations. Initially I drew all sprites to 32 x 32 on a base 16 grid. Nothing is drawn less than 16 x 16px. But I had to try all options. 24 x 24, 16 x 16. They just seemed to dwarf the characters such that it seemed like I was controlling a dot in a large playing area.

I’m using Atari’s wonderful Gauntlet game as a guide for style and play but of course that game contained a larger playing area than was viewable. Everything scrolled through the playing window hence their use of larger sprite characters. I’m not using scrolling this time.
I just couldn’t get comfortable with the scale of the sprites in my game so I took the decision to increase the playing area and present it more landscape than portrait (the original orientation).

I quickly put together a test whereby I could provide some adversaries and collectable items.

Currently the Wizard character can fire magic using Z or CTRL. I’m not sure if I want to keep this as a free feature. It’s just too easy. What I liked about my original Castle Adventure game was the emphasis on avoiding the Ghouls. Each level had collectable magic balls that could be picked up and hurled at the ghouls to wipe them out. I often think that the perfect maze game would involve a good balance of player missiles / monsters / puzzles  and exploration.


Anyway this is a somewhat hasty attempt to catch up on some blogging before the game and related tech moves on too far.

I’ve not uploaded the level editor because of its hooks in to the offline database but you can see the latest version of the game here.


Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: