Category Archives: Game development tools

Building a visual style

I’m very happy with the mechanics of the game just now. Although I still need to set aside some design time in terms of adding a few puzzle elements I’m happy that the game is behaving itself enough for me to go off and start drawing sprites and tiles. Art afterall is what I’m actually good at.

I have a very clear idea as to the look that I’m after. In short I want colour and contrast.
It’s important for me that the floor tiles are somewhat saturated in appearance whilst the walls stand out a bit more. The actual characters in the game will stand out quite a lot since I’ll draw them with more vibrant colours. Same goes for the effects – wizard’s magic, sparks, explosions etc.

There is a feature to my game editor that I hadn’t used thus far that I wanted to use now – the canpass flag.

Each tile has several flags that I set in the editor. One of them is the canpass flag which when set to 1 effectively renders the tile transparent in terms of collision detection. I’m using this flag to present shadow tiles.


Level designer
Level designer

Just now I have a limitation in the editor that prevents a sprite and a tile occupying the same space. Rather stupidly this doesn’t extend to the game where sprites can pass over tiles with ease.

So now that I have a mini objective (collect the strange brown artifacts) and a few challenges (find the key – open the door, dodge / defeat the bad guys) and a nice little twist (defeated monsters come hunting for you once they’re ressurected) I’m going to set about cementing the game’s visual style.

The latest version is available here:

Something that I’m preoccupied with is the idea of creating a light mask around the glowable objects. I’d love it if the wizard could hurl a magic ball down a corridor and it glows such that it lights up the floor and walls around it. I’m sure there’s a way with canvas.

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.


JavaScript level editor – first attempt

I invested a little time knocking up a (very crude) level editor. I wasn’t going to share it since it is so crude. But I’m a sucker for criticism ;)

You can find it here:

With this code I’ve ditched the idea of having a separate collision mask. For now.
Using my own example of a 16×16 tree casting a shadow across a 32×32 tile graphic and the player sprite therefore potentially colliding with the shadow when the tree is the only physical obstruction – I have opted to either draw the graphics as 4 separate tiles or simply ditch the support for such an elaborate feature.

If you highlight one of my simple tiles and click “set as floor” you can quickly get a feel for how you level will look.
Then click to select a tile to paint with, ensure that the mode is set as Brush and click away. I don’t currently support dragging the mouse around the level with the button down.

For each tile you can set two parameters just now. CanPass and Damage.

Finally when you’ve finished click the “generate level data” button to output the JSON structure to the textarea bottom right.

There are no game entities just now just obstructions. That comes next.

Interested in feedback and suggestions.

JavaScript game designer’s level editor – simple collision theory

Something that I have been giving some thought to lately is a detailed level editor. In the past I have deliberately crafted games that offer the same structure but with only slight variances.

In Invaders from Mars the aliens offered slightly different patterns, for example. In Hoth Strike the number of rebel soldiers increased. Essentially the core game mechanics remained the same. That is, the puzzles didn’t vary in style or complexity.

But I want to move beyond that. I want to offer games that have been designed with a more immersive level of play. The only way to achieve this is to create a tool that allows me to position obstacles, challenges, rewards, monsters and power-ups. Furthermore I want to be able to literally paint the screen with decorations (platforms, walls, tiles) independently of the game’s consideration for what should and shouldn’t be a collision.

So I’ve been putting together some ideas based on applying layers to my games.
Here’s how it works.


Level designer - layers

Level designer - layers


Since I am working on a Gauntlet style top-down game just now I figured it best to illustrate my thoughts with that style in mind. As you can see in the illustration above the level starts out with a simple floor covering. This is a general carpet effect most probably achieved using the CSS backgroundImage style set to repeat; In my editor I select the floor tile to paint the scene with.

Then I move up a layer to the decoration. I intend to work with a minimum of 16 x 16 scaled tiles here.
The larger wall blocks are actually 32 x 32 and form the perimeter of my level. Then for added decoration I paint some black .png tiles to form shadows as if cast by the walls. These .png files are set to 10% alpga in Photoshop before I export them. I could alternatively control them with CSS or even using JavaScript. But I prefer to have this work done with the art package. If necessary I’ll create several tiles to affect different shadow levels.

When the two layers are combined you can see that I get a satisfactory amount of detail. The game code will handle any scrolling through the viewing window where the level is larger than the canvas dimensions and literally stitch the two levels together.

The final part of the puzzle is the collision layer. Here I need to instruct the game code where in the level cannot be crossed. Walls, doors, tables etc all need to be “painted” with the collision mask.
Something like this


Level editor - collision mask

Level editor - collision mask


The red area forms the collision area.
Additional attributes in the level editor will inform the game code just how to handle collision with the region.

For example I may wish to make a wall electric or red hot. I can assign a pain value to the wall.
In the game I will be returned something like this

col.damage = 10;

Either way I have some information to work with in the game code.

Future developments may see additional detail such as ambient sound effects or spawn effects.

Of course I need to consider such things as output format such that the level data can actually be used. I’m pretty sure that JSON formatted text files are the way to do it.

All just thoughts at the moment. As a rule I enjoy writing web based tools more than most projects so I’m going to enjoy this. Half the battle is knowing when to stop ! :-)

Interested in feedback from anyone with similar experience.