PDA

View Full Version : My own map engine



ShadowMaster
16-11-2007, 07:59 AM
As you may or may not know I am making a side stroller, like Jazz Jackrabbit, but more like Abuse. And to do this, I will be in need of a map engine, but as the framework (Sexy App Framework aka Popcap Framework) I am using doesn’t have one, I am going to write one myself.

I want it to be easily usable between many tile-based games, this is where you come in, I want you to tell me what you think of my map engine design.

And here it is (I will put up the complete specifications of the individual components later):

There is a tileset, it is the object that stores the tiles the map will be using and only one will be allowed per map. The tilesets(which can be set in the tileset) will come in four flavours; unobstructed(to save memory), boolean obstructed(either obstructed or not), rectangle obstructed(to save memory and processor time), and pixel-perfect obstruction.

The map will have a tileset associated with it and multiple layers, with one being set as the main layer. The other layer will have parallax scrolling, auto scrolling, etc. (I am not sure what features I will include, but suggestions would be welcome). In the map file there will be triggers, which will handle the game specific stuff, i.e. spawning monsters, traps, springs and so on, they will be passed to the game object, that will handle what to do to them. You will be able to render all the layers at once or one at a time so you can render sprites and so on between them. I will make this easier by letting you say what range of layers are background layer and what range are foreground, which you will then be able to render with a single function call.

The sprite will be the individual characters and I am not yet sure how I am going to design them.

The game engine will handle all the game specific stuff, like rendering the monsters, updating the AI and letting the player control his character.


Additional specifications:
-The engine will be made so that the only thing you would really need to change is the game engine.
-All files will be straight text file, as it makes it easier for me to make files while I am making the editors. The map engine will be universal as well, with a text file saying what triggers there are and what their parameters are.

Please point out defects and shortcomings. Thanks.

ShadowMaster
16-11-2007, 08:56 AM
ShadowMaster’s Universal Tileset Specifications v0.01

Tileset tiles will be stored in on file with another black and white file (not to be confused with the greyscale alpha map of the image file) representing the obstruction map (with black representing an obstructed pixel). Both the images must be the same size. The obstruction image might not always be used depending on the type of tileset.

The are four types of tilesets:
-Without obstructions: They won’t load a black and white image or text file and are intended for games like Tyrian2000.
-Boolean Obstruction: They are either obstructed or not. The obstruction map will be stated in a separate text file and not in a separate image file.
-Rectangle Obstruction: As the name implies the obstruction will be handle with only rectangles. The obstruction map will be stated in a separate text file and not in a separate image file.
-Pixel-perfect Obstruction: Enough said.

The frames will have a width and height and both images’ widths and heights must be multiple of this. The image will then be divided into frames of the specified width and height. The frames will be numbered from 1, going left to right and from top to bottom. Frame number 0 will be invisible and unobstructed.

There will be animated tiles and you will be able to choose if you want to use the first frame’s obstruction map (you can change the order of the frames without affecting the animation) or the every frames obstruction map as it is shown. The animation speed will be constant, with a constant delay.

Tiles in the tileset will be numbered sequentially from 1, with 0 being a static, invisible and unobstructed tile. The number is the number that will be used in the map engine.

The file will be a straight text file to ease editing without a text file.



File Format (Note lines don’t matter, they only help reading, you can separate the tokens with spaces instead):
line 1: SMUTileset
line 2: <version> (e.g. 0.01)
line 3: <width>
line 4: <height>
line 5: <type> (0-no obstruction, 1-boolean obstruction, 2-rectangle obstruction, 3-pixel-perfect obstruction.
line 6: <image name> (Obstruction map will be file with “_obs” added to the end, don’t type the extension. Engine will automatically load image or text file depending on the type of tileset)

(Each tile will be on it’s own line to improve readability, but it isn’t necessary)

Static tile:
< frame nr> (the number of frame to use)

Animated Tile:-1 (Says it is an animated tile,
<type> (use –1 for an animated tile that uses the first tiles obstruction map and –2 for an animated tile that uses the current tiles obstruction map)
<delay> (The time in milliseconds between frame switches)
<frame nr> (same as in static tile)
.
.
.
< frame nr>
-1 (says when to stop reading frames)

How to end reading tiles:
-2 (says to stop reading tiles)



File format for boolean obstruction map:
(Again lines don’t matter)
(The first line is for the first frame, the second for the second and so on)
line 1: <obstructed> (0-unobstructed, 1-obstructed)
line 2: <obstructed>
.
.
.
line n: <obstructed>
(The tileset will only read this file until it has read values for every frame, so you don’t have to end it. Just make sure you have one for each tile)



File format for rectangle obstruction map:
(Again lines don’t matter)
(The first line is for the first frame, the second for the second and so on)
line 1: <x> <y> <width> <height> (these values must result in a rectangle that lies within the tile, note the top-left corners of all frames are (0,0) )
line 2: <x> <y> <width> <height>
.
.
.
line n: <x> <y> <width> <height>
(The tileset will only read this file until it has read values for every frame, so you don’t have to end it. Just make sure you have one for each tile)

PS the map specification will be typed at a later time when I have rested from typing this. ;)

dislekcia
16-11-2007, 11:59 AM
Sounds like you're putting a lot of thought into this. Do you have the map editor article I write for NAG some indeterminate amount of time ago? If not, it's time to put it on the site anyway...

-D

ShadowMaster
16-11-2007, 12:37 PM
Sounds like you're putting a lot of thought into this. Do you have the map editor article I write for NAG some indeterminate amount of time ago? If not, it's time to put it on the site anyway...

-D

No, sorry, but I would love to see it.

Yes, it's quite contradictory, but I'm atually spending so much time making and designing the map engine, because I'm being lazy.

I am going to write the header file for the tileset in this week and I will post it for everyone to judge and tell me what needs improving.

Just for everyone curious on what I plan to make first with my engine; it is not going to be De Kulling, but rather a block man clone, Cave Escape, more on that later, when I will post the first demo of the game I made using my old code.

EDIT: On second though I won't post it, as the version that works has memory leaks(it only leaks when it closes, using a ! when I shouldn't have) and doesn't work on Vista, and I can't seem to get the source to compile into working version(ie responding to input) and I sure as hell don't want to struggle with abanoned code.

Thaumaturge
17-11-2007, 12:44 AM
It looks good to me thus far, ShadowMaster. It sounds as though it could be a useful editor.

I do have a few thoughts on triggers (although of course you may have thought of these things already):

1) (From what you've given us I believe that you already have this much; I mention it, I suppose, to be confident of clarity in the system that I am describing.) The trigger stores an "event name", such as "player has reached batcave". When the player reaches that trigger, that name is sent to the game engine, which then responds as desired (such as by calling an external script).

2) Triggers may be set to react to the player, enemies, non-hostile NPCs, or any or all of the above. This system could, of course, be made more complex, depending on your desires - you could, for example, allow NPCs (including enemies) to be assigned to groups, and have triggers react to certain groups.

3) Triggers may be activated or deactivated by the game system, although it might be a good idea to allow their starting state to be set in the editor.

What do you think?

ShadowMaster
17-11-2007, 07:29 AM
It looks good to me thus far, ShadowMaster. It sounds as though it could be a useful editor.

I do have a few thoughts on triggers (although of course you may have thought of these things already):

1) (From what you've given us I believe that you already have this much; I mention it, I suppose, to be confident of clarity in the system that I am describing.) The trigger stores an "event name", such as "player has reached batcave". When the player reaches that trigger, that name is sent to the game engine, which then responds as desired (such as by calling an external script).

2) Triggers may be set to react to the player, enemies, non-hostile NPCs, or any or all of the above. This system could, of course, be made more complex, depending on your desires - you could, for example, allow NPCs (including enemies) to be assigned to groups, and have triggers react to certain groups.

3) Triggers may be activated or deactivated by the game system, although it might be a good idea to allow their starting state to be set in the editor.

What do you think?

Great ideas.

But the map engine really has nothing to do with the triggers other than loading and storing them. The game manager does all the game specific stuff like moving sprites, triggering triggers and so on, but it would however be useful for the game manager to have that functionality out of the box, so to speak. And especially thanks for the idea on grouping the characters into groups. I think it would also be useful to be able to group them to multiple groups, for instance to "metal" and "ice", which would make it react to magnetic and fire triggers. Ohh, perhaps I should have groups for triggers as well and have an array which says which type affect which?

Perhaps I should allow Python to be used as a scripting langauge? (Now to read up on that...)

Progress so far:
I am currently making the obstruction obects, that will provide a universal obstruction map for all objects. All types of obstructions will be able to query if they are obstructing any other type of obstruction. This for instance will allow you to use rectangles for small or square enemies, but pixel-perfect for larger round enemies.

Thaumaturge
18-11-2007, 06:09 AM
I'm glad to have been of help, and I like your idea of grouping triggers as well. ^_^

As to a scripting language, from what you've written here thus far, it sounds as though the scripting language would be tied into the game engine, and not the map engine.

I'm afraid that I haven't used Python myself, that I recall, so I have little to offer there, I'm afraid - I've tended to put together my own little simplistic scripting systems thus far, although that has, I think, been limiting.

ShadowMaster
18-11-2007, 08:29 AM
I'm glad to have been of help, and I like your idea of grouping triggers as well. ^_^

As to a scripting language, from what you've written here thus far, it sounds as though the scripting language would be tied into the game engine, and not the map engine.

I'm afraid that I haven't used Python myself, that I recall, so I have little to offer there, I'm afraid - I've tended to put together my own little simplistic scripting systems thus far, although that has, I think, been limiting.

I'd actually say Python is easier than BASIC and probably more powerful too. It is also a nice langauge to do quick prototyping in.

Thaumaturge
19-11-2007, 04:54 AM
Fair enough; In terms of not having much to offer, I think that I meant in advice on choice of scripting language (for example, I haven't used either Python or Lua that I recall, and so don't feel that I'm in much of a position to comment on the comparison).

As to it being limiting, I meant, I think, rather that my little scripting languages have been limiting, not that scripting languages in general are limiting.

ShadowMaster
19-11-2007, 05:38 PM
I basicly have the design of the map engine nailed down, but I was wondering, what features would you want non-main layers to have?

It will currently have:
-Parralax scrolling
-Auto Moving
-Wrap around

Without this information I won't be able to post the specifications for the file format. In the mean while I will post the spesifications for the map engine and later the tileset.

Current progress:
I am still stuck on the Obstruction sets, but they are nearing completion.

EDIT: They are basicly completed now, but I am going to do some border case testing, just to make sure they work and I never have to bother with them again. ;)

Thaumaturge
23-11-2007, 12:51 AM
I'm glad to hear that you have your obstruction sets pretty much complete (hopefully entirely complete by this point). ^_^

As to features for non-main layers, I think that I would like to be able to play animations in them - think of having animations of people to give life to a village background, or animals prowling them, or even having future opponents and obstacles foreshadowed in them (the dragon sweeping through the sky in the background, for example, or the dark tower looming against a stormy sky, green energy swirling and pulsing from it).

Note that, being assigned to a particular background layer, they should be obscured by any occulting features of the layers in front of them.

ShadowMaster
23-11-2007, 04:56 PM
I'm glad to hear that you have your obstruction sets pretty much complete (hopefully entirely complete by this point). ^_^

As to features for non-main layers, I think that I would like to be able to play animations in them - think of having animations of people to give life to a village background, or animals prowling them, or even having future opponents and obstacles foreshadowed in them (the dragon sweeping through the sky in the background, for example, or the dark tower looming against a stormy sky, green energy swirling and pulsing from it).

Note that, being assigned to a particular background layer, they should be obscured by any occulting features of the layers in front of them.

Yeah, they are finished now and I hope bug free. I am just doing the documentation now.

You will be able to do animations in all layers with animated tiles and if you want to use sprites in background layers it will also be possible, but I will think of a way to make it easier to move them, instead of doing it manually.

Current progress:
I am going to write the spesifications for the map and the sprites.

ShadowMaster
02-04-2008, 10:20 PM
Well after a long delay I'm working on this thing again and I'm glad to report the Obstruction handling parts are done, even the loading and saving thereof.

To start it off I finished the specifications of the sprites:

ShadowMaster’s Universal Sprite Specifications v0.01

The sprites will be basically the same as the tileset, but instead of tiles it will have “directions”, each with a label associated with them.

This label is used when animating the sprite, and allows you to set the “direction”. Note the “direction” can be anything, not only “north”, “south”, etc. but stuff like “crying”, etc.

The sprite will feature basic things like being able to reset the "direction", etc.

File Format (Note lines don’t matter, they only help reading, you can separate the tokens with spaces instead):
line 1: SMUSprite
line 2: <version> (e.g. 0.01)
line 3: <width>
line 4: <height>
line 5: <type> (0-no obstruction, 1-boolean obstruction, 2-rectangle obstruction, 3-pixel-perfect obstruction.
line 6: <image name> (Obstruction map will be file with “_obs” added to the end, don’t type the extension. Engine will automatically load image or text file depending on the type of tileset)

(Each direction will be on it’s own two lines to improve readability, but this isn’t necessary)

Static direction:
<label> (this has to be a single token, ie no spaces and it must be unique)
< frame nr> (the number of frame to use)

Animated direction:
<label> (this has to be a single token, ie no spaces and it must be unique)
-1 (Says it is an animated tile)
<type> (use –1 for an animated direction that uses the first tiles obstruction map and –2 for an animated direction that uses the current tiles obstruction map)
<delay> (The time in milliseconds between frame switches)
<frame nr> (same as in static tile)
.
.
.
< frame nr>
-1 (says when to stop reading frames)

ShadowMaster
03-04-2008, 01:18 PM
I have seem to have forgotten an important part of the specifications, the extensions of the files.

Anyway here they are(note you only have to specify the part before the extension):
Boolean obstruction file: .bool
Rectangle obstruction file: .rect
Pixel Perfect obstruction file: _obs.* (with * being the image extension, for instance bmp)
Tileset: .smt
Map: .smm
Sprite: sms

Dipso
07-04-2008, 08:16 PM
Have a look at TuDee, a tile based level editor:
http://www.clickapps.com/moreinfo.htm?pid=16691&section=WIN32

It should be able to do most of what you need for building your levels.
The maps are saved as binary or xml, and you can write your own exporter for it.

ShadowMaster
07-04-2008, 08:29 PM
Thanks for the info Dipso will check it out.