views:

241

answers:

5

I have an image of a basic game map. Think of it as just horizontal and vertical walls which can't be crossed. How can I go from a png image of the walls to something in code easily?

The hard way is pretty straight forward... it's just if I change the image map I would like an easy way to translate that to code.

Thanks!

edit: The map is not tile-based. It's top down 2D.

+1  A: 

I need more details.

Is your game tile based? Is it 3d?

If its tile based, you could downsample your image to the tile resolution and then do a 1:1 conversion with each pixel representing a tile.

FlySwat
A: 

If you don't need to precompute anything using the map info. You can just check in runtime logic using getPixel(x,y) like function.

Lucas S.
+1  A: 

I suggest writing a script that takes each individual pixel and determines if it represents part of a wall or not (ie black or white). Then, code your game so that walls are built from individual little block, represented by the pixels. Shouldn't be TOO hard...

stalepretzel
+1  A: 

I dabble in video games, and I personally would not want the hassle of checking the boundaries of pictures on the map. Wouldn't it be cleaner if these walls were objects that just happened to have an image property (or something like it)? The image would display, but the object would have well defined coordinates and a function could decide whether an object was hit every time the player moved.

Ed Swangren
A: 

Well, i can see two cases with two different "best solution" depending on where your graphic comes from:

  1. Your graphics is tiled, and thus you can easily "recognize" a block because it's using the same graphics as other blocks and all you would have to do is a program that, when given a list of "blocking tiles" and a map can produce a "collision map" by comparing each tile with tiles in the "blocking list".

  2. Your graphics is just some graphics (e.g. it could be a picture, or some CG graphics) and you don't expect pixels for a block to be the same as pixels from another block. You could still try to apply an "edge detection" algorithm on your picture, but my guess is then that you should rather split your picture in a BG layer and a FG layer so that the FG layer has a pre-defined color (or alpha=0) and test pixels against that color to define whether things are blocking or not.

  3. You don't have much blocking shapes, but they are usually complex (polygons, ellipses) and would be unefficient to render using a bitmap of the world or to pack as "tile attributes". This is typically the case for point-and-click adventure games, for instance. In that case, you're probably to create path that match your boundaries with a vector drawing program and dig for a library that does polygon intersection or bezier collisions.

Good luck and have fun.

sylvainulg