(Help) 2D Game Map

I would think a geometric representation (line segments, boxes, spheres, etc.) would be more convenient than an image for the purpose of intersection testing. I'd also think that if you can write an editor that would allow you to create an image like the black and white one shown, you could just as easily write an editor that would allow the placement of lines and boxes that matched the elements of the scene.

There are probably other approaches you could take as well, but the geometric solution seems like it would be the most practical.

Yeah, jyk is right. you should define the intersection using a line data stucture. those lines will be tested against the hit. and the advantages are you can create dynamic things like it the player moves to a platform represented by line the door in front of him can open or close.

Quote:

Original post by rk_theone Yeah, jyk is right. you should define the intersection using a line data stucture. those lines will be tested against the hit. and the advantages are you can create dynamic things like it the player moves to a platform represented by line the door in front of him can open or close.

How would I do that? I'm kind of new to the whole process of game/graphics programming.

Quote:

Original post by ZeroTech How would I do that?

Well, it all depends. Are you a programmer? If so, what language or languages are you fluent in? What graphics API are you using? What platform will you be developing on?

Speaking abstractly, here's how I'd do it:

1. Create a simple editing program with the following features:

a) The image for the level (for example, the one you posted) is displayed in an editing area.

b) A simple interface allows you choose between various shapes, such as line segments, axis-aligned boxes and spheres.

c) Clicking and dragging in the editing area will dynamically place and size the selected shape accordingly.

d) The map geometry can be written out in a simple text or binary format describing the parameters of each shape.

2. When the game loads a level, the geometry data is loaded as well.

3. Dynamic objects in the game (such as the game character) are tested against the static geometry as loaded from the level file, and respond accordingly. How to do this depends on the shapes and speeds of the dynamic objects, but the algorithms required shouldn't be too complex.

The above is a fairly generic answer; depending on your answers to the questions posed earlier (what APIs you're using and so forth), someone might be able to suggest a more appropriate solution.

I solved exactly this problem using gradients and a tile map.

The mappy software supports "import map from big picture" - you might import your black and white one there.

Then for each unique tile with a gradient slope, I set the max and min heights of the tile, e.g. a slope with the function (g(x) = 0 + x * 16) would have the parameters 0 and 16 for the left and right of the block. (16x16 blocks)

Then when the center of the players feet are in a gradient block, I do a calculation to see how vertically deep into the block the players feet can go, then snap the feet to that depth.

For square blocks with no gradient, I simply set them as "hard blocks" which can't be passed through.

Quote:

Original post by Kada2k6 For your gamemap, I would go for the more classical tile-based approach rather than using a fixed background. Not only is it easier to work with, but allows for better-looking maps since more combinations are available.

That's how I'm doing it right now, and I'd also fully recommend it.

However, I'm thinking it might be better nowadays to a switch to a hybrid approach (if you're using DX/OGL) - drawing the map as a big picture to be rendered as effectively an overlay over the tile map.

The black and white image he used would be my tile map - used for collision detection calculations, etc. (but not rendered) The colorful image would be the one that's drawn as a single rectangle, perfectly aligned with the virtual tile map.

I'm planning on doing this with my engine, BTW, I've already written an editor for my game which would make setting up that kind of scenario a breeze.

Clearly though this is going to require two images both the size of the entire level in pixels, which is going to drastically restrict the level size.

If that is not a problem, fair enough, but this is why games with large levels tend to use tiles and per-tile heightmaps rather than the one-big-bitmap approach, or a list of geometric shapes as I think jyk was suggesting.

Quote:

Original post by jyk Well, it all depends. Are you a programmer? If so, what language or languages are you fluent in? What graphics API are you using? What platform will you be developing on?

Well, I'm most fluent with C#, and so far I've been using XNA GSE to do simple stuff.
I'm new to game programming but not too new to programming itself. I guess I could do an editing program like the one you said.

Quote:

Original post by jyk For your gamemap, I would go for the more classical tile-based approach rather than using a fixed background. Not only is it easier to work with, but allows for better-looking maps since more combinations are available. Writing a simple editor to produce tile-based maps shouldn't take longer than half an hour!

Well, I kind of need a fixed background since the game I intent to make will be an XNA version of the Metal Slug Serie.



I'll start working on the editor. If anyone has more suggestions or ideas please post them, it will be really appreciated.

Quote:

Original post by EasilyConfused Clearly though this is going to require two images both the size of the entire level in pixels, which is going to drastically restrict the level size. If that is not a problem, fair enough, but this is why games with large levels tend to use tiles and per-tile heightmaps rather than the one-big-bitmap approach, or a list of geometric shapes as I think jyk was suggesting.

Nope. Not two images - the tilemap is really virtual - I mean to use it for tile attribute, collision, and slope testing. What I meant is to have the big image drawn to the screen in exact alignment to where the tilemap would have been.

You could break it up into as many images as you like, then load and unload them from memory as appropriate - the images are effectively like big tiles.

You could then overlay animations, etc, over the image.

Anyway, I think jyk's methods are good also - but consider mine, since, in hindsight, that's how I would have implemented the map rendering on the game I"m working on now.

I can't help but think that tile maps are somewhat outdated and unsuitable nowadays. They were super when directly supported in hardware as they gave cheap "compression" of level data, lots of variety and were dead quick to draw. Fast forward to now though, and they're looking less great. Drawing speed isn't an issue now, so you can draw tons of images, anywhere, without a problem. And we've got much more memory so we can afford to have more raw image data.

Instead of limiting ourselves artifically to tiles, we could instead make levels out of bigger images more suitable for what we're trying to convey. Instead of having lots of tiles which need to be arranged into a tree, lets just have a big tree sprite and let the level editor place it anywhere (ie. not snapped to a grid). You'd end up with lots of chunks of level (floor pieces, sky pieces, crates, trees, other decorations, etc.) which you just slap together as you wanted. Not only does it make creating the art easier, but you get lots of flexibility but without the blocky-ness that a tiled map tends to have.

Collision and gameplay data is another kettle of fish though. You've got three choices IMHO:
1. Big colour coded image (like your black and white image).
2. Tile based (solid/empty/water/etc. tiles, possibly with slanty surfaces)
3. Geometry based (lines/boxes/etc. placed where needed).

For 1, it'd be easy to create but require lots of memory. Plenty of flexibility and variety though.

For 2, you'd need a custom tool (or an already built one) to make the levels. But tile editors are easy to knock up. Light on memory and fast to use in game. Restricts your level design though, as you've got to use the grid.

For 3, you'd need a slightly more complicated tool. But it'd be even lighter on memory than the tile approach at the cost of slightly slower to check collisions. Greater flexibility too, as you can put stuff anywhere.

IMHO '3' would give you the best trade off, but it requires more work. It depends really on where you're willing to make the trade offs between memory, flexibility and variety.

Well, right now I just want to finish some game. I don't really care much about performance (up to a point) at the moment.
I'm going to give a shot at Geometry Based first, but if that takes me too much time i'll just finish the game with option 1 then when I go to a second game I'll continue with Geomerty Based.

Thanks for the help everyone.

Quote:

Collision and gameplay data is another kettle of fish though. You've got three choices IMHO: 3. Geometry based (lines/boxes/etc. placed where needed). IMHO '3' would give you the best trade off, but it requires more work. It depends really on where you're willing to make the trade offs between memory, flexibility and variety.

The more I think about it, the more I like the idea of Geometry based. You could probably use some level editor, and place things as billboard polygons, and give them attributes to define what kind of object they are, and how the game should react to it on collision, etc.

Does anybody have any suggestions as to whether there is a level editor out already which could be suitable for constructing these kinds of levels?

Quote:

Original post by laucian Quote: Collision and gameplay data is another kettle of fish though. You've got three choices IMHO: 3. Geometry based (lines/boxes/etc. placed where needed). IMHO '3' would give you the best trade off, but it requires more work. It depends really on where you're willing to make the trade offs between memory, flexibility and variety. The more I think about it, the more I like the idea of Geometry based. You could probably use some level editor, and place things as billboard polygons, and give them attributes to define what kind of object they are, and how the game should react to it on collision, etc. Does anybody have any suggestions as to whether there is a level editor out already which could be suitable for constructing these kinds of levels?

I'd love to find one, but nothing so far. Everything available for 2d seems to be tile based. It's annoying as I want to try this approach again myself, but I don't want to write yet another massive editor when I could reuse something that already exists.

I'll jump right into this discussion since I'm looking into it myself these days. While the power of GPUs has made a huge leap the past few years, ironically for 2D games, it doesn't necessarily make things easier on our part. You can blit tons of sprites and tiles with special shader effects in no time, but then you are stuck with collision detection.

Geometric CD isn't really solving anything when you think about per-pixel collision detection in combination with highly irregular sprites. It can be a boost when you consider a broad-phase bounding volume test to narrow down the possible colliding entities.

Memory consumption isn't that big of a deal using a BW collision mask as you can bake that mask in the alpha channel of the color image (if you can do that to begin with, i.e. the alpha channel is unused). Old games did this, but that doesn't mean you shouldn't do it now. Take a look at their art once you unpack the game, they have a similar scheme going on as the OP intended all along and more importantly: it works.

Tile-based engines don't differ from full-bitmap (first post) engines an awful lot, and can be in fact a perfect substitution when you consider each tile to be a part of the bitmap (with the added bonus of efficiency in some areas due to tile-based constraints, e.a. broad-phase CD).

People like OrangyTang are doing great things (may I advertise? ;-)) with todays hardware to spice up the old-school 2D genre, yet so is EasilyConfused (even without fancy shader tech). The point is, we've got the hardware to make things happen graphics wise, perhaps we could find other means too to speed up CD (I'm thinking occlusion queries and PhysX hardware => geometric CD?).

Note also that no-loading-times is a big deal these days, but this could easily extend onto 2D platformers: page subsequent parts of the level in and out of hardware (possibly in a background thread).

This is a very broad subject so I'm sure there are lots of solutions to your particular conundrum and lots of other things to talk about :-).

EDIT: in response to the last post: Soldat features geometric CD and some third-party editors have been built too. While they are specific to Soldat, it should prove viable that there exist other examples.

EDIT: also, fair enough, successful series like Super Mario Bros have gradually transitioned from 2D to 3D. The New Super Mario Bros game for the NDS features a mix of 3D platforms, 3D characters and 2D sprites and guess what, I love it :-).


[Edited by - Todo on January 15, 2007 5:00:23 AM]

Quote:

Original post by Todo Geometric CD isn't really solving anything when you think about per-pixel collision detection in combination with highly irregular sprites. It can be a boost when you consider a broad-phase bounding volume test to narrow down the possible colliding entities.

I'm going to be contravercial and say that most of the time pixel-perfect collision is a false idol, and not really useful.

By representing my collision and logic with geometric shapes (circles, rectangles, line segments, polygons) you can still have accurate results but gain reliability, smoothness and predictability.

1. Discrete/pixel methods don't scale well. Zooming in will make movement along a pixel surface jaggy, whereas geometry remains smooth.

2. You can't get sub-pixel collision with pixel-perfect methods. An object just skimming over a surface is likely to get unexpectedly snagged even when it should be able to just about move.

3. Pixel methods don't deal with rotation well. If you were rolling a sprite along a surface then it'd be easy to do this with a geometric approach. Try doing that with pixel collision and you're going to get all sorts of jitters and snags.

4. Pixel methods don't give you very good feedback when a collision actually occurs. If (say) you wanted to bounce a grenade off a surface you need the normal at the point of collision to bounce correctly. This is trivial with geometry but very error prone and unpredictable with pixel methods.

Quote:

Original post by OrangyTang Quote: Original post by Todo Geometric CD isn't really solving anything when you think about per-pixel collision detection in combination with highly irregular sprites. It can be a boost when you consider a broad-phase bounding volume test to narrow down the possible colliding entities. I'm going to be contravercial and say that most of the time pixel-perfect collision is a false idol, and not really useful. By representing my collision and logic with geometric shapes (circles, rectangles, line segments, polygons) you can still have accurate results but gain reliability, smoothness and predictability. 1. Discrete/pixel methods don't scale well. Zooming in will make movement along a pixel surface jaggy, whereas geometry remains smooth. 2. You can't get sub-pixel collision with pixel-perfect methods. An object just skimming over a surface is likely to get unexpectedly snagged even when it should be able to just about move. 3. Pixel methods don't deal with rotation well. If you were rolling a sprite along a surface then it'd be easy to do this with a geometric approach. Try doing that with pixel collision and you're going to get all sorts of jitters and snags. 4. Pixel methods don't give you very good feedback when a collision actually occurs. If (say) you wanted to bounce a grenade off a surface you need the normal at the point of collision to bounce correctly. This is trivial with geometry but very error prone and unpredictable with pixel methods.

1. True, and although you could probably even things out a bit, I didn't even bother to think it trough.

2. True, but anyone who has ever touched rigid body physics knows about the stability issues when putting bodies to rest and stacking them on top of each other, not to mention inter-penetrations.

3. True, for the same reason as 1: it's discrete.

4. This is probably the main reason why I myself am a bit put off by CD at the pixel level.

Quote:

Original post by OrangyTang Quote: Original post by laucian ... Does anybody have any suggestions as to whether there is a level editor out already which could be suitable for constructing these kinds of levels? I'd love to find one, but nothing so far. Everything available for 2d seems to be tile based. It's annoying as I want to try this approach again myself, but I don't want to write yet another massive editor when I could reuse something that already exists.

I've made one for my game a long time ago in VB. It doesn't have a lot of advanced options, but it can be used to create simple levels made of polygons quite easily. I based it on the editor for a game called Elastomania, which used very similar level structure.

Download Link here. The level editor is located in the levels folder, along with some sample maps.

It was compiled a long time ago with an old version of VB, so it might need some dlls to run. I'm not home atm, but when I get there I'll try to update the zip file with a readme I wrote for the level editor back then. But basically you can just click around to create polygons and figure it out. The output is plaintext, in a GPC readable format.

I'm planning to rewrite and update it in C# sometime.

Update: I threw in the readme for a (much) older version of the level editor, in case you need help figuring it out. The download link is updated.

[Edited by - shurcool on January 15, 2007 11:36:23 PM]