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.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • jgabios  On October 20, 2010 at 8:46 pm

    the collision layer is not necessary. you should make a data structure in memory with the objects placed on the map, and when you check for collisions you check against that data structure. [could be a double array [][] for example].
    [0][0]={‘type’: ‘tree’,’damage’: ’10’,’canpassthrough’: ‘false’}
    [0][1]={‘type’: ‘grass’,’damage’: ‘0’,’canpassthrough’: ‘true’} .
    so when your editor “paints” a tree in an area of the map, you fill the data structure with the corresponding object.

  • markw1970  On October 21, 2010 at 8:53 am

    Thanks for the response. I appreciate your thoughts.
    Looking at your approach I follow what you’re saying but am I not restricting myself in terms of what I can class as an obstruction ?
    For example I may want to have a secret wall that the player can pass through.

    Also, and perhaps more importantly, I may have a graphic of 32 x 32 but of which only 16 x 16 is an obstruction.
    e.g. a tree that casts a shadow diagonally from top left to bottom right. I wouldn’t want the player to collide with the shadow !

  • jgabios  On October 21, 2010 at 8:36 pm

    that is true.
    if i may continue the argument, not having a zone/area unit on the map will complicate the collission detection calculation a lot. 1 thing is to consider 32×32 the unit size of objects and totally other thing is to check also for 2 objects 16×16 inside a 32×32 area unit. and collission detection may be needed by more things besides characters movement, and i think here of a A* search algorithm, which can be quite a CPU eater.
    but anyway, in terms of game quality to the user your approach is better, offering a smoother experience in playing, though it is going to cost you.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: