Creating your own Collision Maps

This tutorial demonstrates how to create a collision map. The approach used is to take an image of your map and then draw the collision map on top of the image, using the image as reference, and then saving the collision map.


This example assumes the tile size is 32x32, but you can use it for any tile size. You should use an image editor that provides a grid along with snap-to-grid functionality. The editor I used is Graphics Gale, which you can download for free from the company's website.


Required

• Image Editor (paint.NET, Graphics Gale, GIMP, Photoshop, etc.). A free copy of Graphics Gale can be obtained from http://www.humanbalance.net/gale/us/
• A script that allows you to use collision maps, such as Collision Maps
• A way to get an image of your map, such as using Map Screenshot

Instructions
The following images describe one way you might create collision maps using Graphics Gale.








   





Closing


When you get used to creating collision maps for tile passage settings, you should find that it becomes much more flexible than relying on the editor's built-in passage settings. It takes a little more work to create them, but overall it should give you more tools to work with when building your maps.


Original posted at Hime Works.

I have a question: Is it possible to create a collision script with more precision? for example: Instead of the entire 32x32 box being passable or impassable, make it so that ONLY the portion covered in red is impassable while the portion cover in black is passable. In this method, it would give the creator a dynamic method of creating maps.

If this script is possible to make, would you be willing to make it?

A collision map with a smaller than 32x32 grid would not change the way your game works, unless you used a script that allowed pixel movement. Then it would need to be made compatible with the collision map script.

But, what if I want to mark a tile or range of tiles as 'above the character' ... would this method allow using a third color to denote insertion of a character or party member 'behind', such as the 'front wall'? (Possibly also using some alpha transparency on the tile(s) surrounding this character...)

Providing additional colors is straightforward.


I can't imagine how you would use that information to actually draw sprites under a tile though, since everything is drawn above tiles.


Someone modified the script and posted it in the script post's comments to allow you to use a second map to serve as the super-imposed layer which you can use to draw actors behind, though in that case I would just go with layered mapping.

What you're asking about is overlay mapping, or a parallax script. That's not what this script is about, though they could certainly be used together if you can overcome any incompatibilities you run into.

I am so happy someone commented here and I don't have to be quite so random when I say that I really wish I knew what a collision map was and what it was for....


I mean, if it isn't really for parallax mapping, then what is its advantage?


I've been having a hard time searching my way into understanding the basic idea here.

A collision map is basically an alternative way to set passability on a map.
RM defaults to a passability where each position in the map grid gets a X or O for passable or not - but that means that the entire 32x32 pixel block has the same passability.


With a collision map it's possible to give that information on a per-pixel-base, like color Black stands for O and color red stands for X.


That is only usefull if you combine it with pixel movement - you don't need pixel based passability of a collision map if you can't move outside the map grid.


That is also the reason why it's often used together with parallax mapping - it doesn't make sense to use pixel movement and pixel collision if your map is still grid-based. But in itself, the collision map has nothing to do with parallax mapping or overlay mapping, it's a concept from the movement part of the game, not from the maps.

Such a use-case is rather simple to explain; using a Mack-style character graphic (two tiles high), in the inside of a building, the wall(s) in room(s) at the bottom of a map overlap possibly two floor spaces.
In my idea, the main thinking is to "cut out" the tiles where the third color overlaps, and let the player move into that space, then re-paste the cutout part over the top of it. A 32x64 character moving one space under the foreground wall top, will be bottom-half-hidden by what is behind, and top-half-showing in the next map tile above it.


Of course, I understand if we had a mapping system where layers were possible, this would be ever-so-much easier.

If you think of the parallax mapping process, where or how would you specify the passage settings?

Typically, most guides suggest developers to simply draw invisible tiles to mark the passable and impassable tiles, but this typically also does not provide you the fine-grained control that you need, for example if you had non-rectangular areas that players can walk through.

As Andar says, a collision map basically describes passage settings.

The passage settings are pixel perfect, meaning if you had a circular island, you could draw a circle in your collision map and now the player could perfectly move along the edge of the circle without the 32x32 grid constraint, provided that you can change your movement options.

Now, unlike what Andar says, this script is also useful if you're using 32x32 grids.

Because this script changes the way passage settings are checked, instead of checking whether a tile is passable or not, it instead checks whether the specific tile is passable. Not only that, you can also change a tile's passage settings on the fly, which I realized just now.

There are, of course, many ways to address specific tile passage settings (eg: invisible events, duplicate tiles, etc.), but given that you cannot stack events in the editor AND you don't have unlimited tileset space, you would probably want to see if there was a way to store this information somewhere else.

If you have seen Shaz's passage map modding script, it does basically the same thing, except here you simply pull up your favorite image editor and then start marking which portions of the map can be passed and which ones cannot.

One limitation is that you can't really specify directional-based passage settings (eg: 4-dir), but that's because I haven't figured out what would be the best way to do it.

I can understand the use case.

Cutting out images and separating them onto a second sprite placed above the player seems easy enough. I don't know how you would actually "cut out" the tiles (while excluding any other sprites over it), but that's where other scripters come in.

The script was designed with boolean values in mind (black = passable, non-black = impassable).

An idea I had was to provide a configuration that looks like this

Color_Map = { [0, 0, 0] => 0, [255,0,0] => 1, [0,255,255] => 2, # ...}So you can basically choose which color will assign which value in the collision table, and then you can write your scripts accordingly.I'd either have to figure out how to pass that table to the dll function call, or do a second pass in Ruby after the image has been parsed...

So wait, are you saying that your collision script's color code works pixel for pixel and if I were to color a circle, my sprite would be able to walk in that circle perfectly? Because if that's the case, then I my issue is user-end error on my part and I can still use your script. I just need to fine tune VE's pixel movement script along with your collision script settings so they work together.

I was under the impression it was restricted to a 32x32 pixel box and could go no smaller or in any other shape outside of what the square pixel grid allows.

Yes, the collision table stores every pixel in the image.


You typically use the character's (x,y) coords to check whether it is passable or not.


It's just that in the default system, each (x,y) coord follows the grid map, so (0,0) in tile coords is (0,0) in pixels, but (0,1) in tile coords is (0,32) in pixels.

Do you have detailed instructions on how to set this up? Because if this is the case, then what I need to know is what settings I need to change in your script so that my 64x64 sprite can walk in that circle perfectly. I mean, you do have it set up so that the default sprites can do this yes? Just point me to the line(s) in the script where I need to make that sprite size changes.

Edit: Looking over your script now, I see that it's actually very short and there's only two settings to change along those lines but the last time I changed this line:

# The width and height of your tiles. This is really only used for # optimization purposes Tile_Width = 32 Tile_Height = 32To anything other than the 32 number, my sprite couldn't move on the map AT ALL.

What are safe settings to change these numbers to and what tile sizes would you recommend for a 64x64 size sprite?

As I've mentioned, the script is not compatible with victor's pixel movement as it is provided, but I'm not sure how to make it compatible.

The tile width and tile height don't really do much on their own.

It's just so that I have a convenient way to specify the grid size when I am using it to check whether a tile is passable or not.

This method at the very bottom determines whether a particular tile is passable, and demonstrates how you check the collision map.

class Game_Map alias :th_collision_maps_check_passage :check_passage def check_passage(x, y, bit) if use_collision_map? x = x * TH::Collision_Maps::Tile_Width y = y * TH::Collision_Maps::Tile_Height return Cache.collision_map(@map_id)[x, y, 0] == 0 else th_collision_maps_check_passage(x, y, bit) end endendHere, I've assumed that black pixels are passable (all black pixels are given the number 0, while all other pixels are given the number 1)The purpose of the width and height is to perform the tile-coords to pixel-coords conversion, because (1,1) on a 32x32 grid is not the same as (1,1) in a pixel map.

This information may be useful for anyone that is trying to figure out the necessary changes required for other pixel movement scripts to point to the collision map.

Okay so just covering all my bases here(forgive me, I just don't wanna muck anything up)

That section of your script. if i change the x and y in these lines:

x = x * TH::Collision_Maps::Tile_Width
y = y * TH::Collision_Maps::Tile_Height

To lets say, the size of my sprite's size, would it work or is this section of the script simply an alias method to call back to the dll?

I'm probably just clinging to air at this point but I'm hoping there's at least SOMETHING I can try on my own without consulting a scripter...

x and y are the coordinates in the collision map to check.


If you actually want to use sprite-based collisions, then you need to do a lot more than just checking whether a single point collides or not.


The default system has it so that no matter how big your sprite is, it will only check whether the tile you want to go is passable or not, which can be done with a single check. Different story if you need to check whether any pixel on your sprite touches any impassable pixel.

okay, I am at my wits end with this, I have the maps color coded as you instructed yet my sprite is being blocked by INVISIBLE barriers on a tile i coded in BLACK.

Is your script messing up in its calculations or something?

Because I even removed VE's pixel movement script and STILL hit that invisible barrier so his script is NOT AT FAULT.

I've noticed that if I color in a flat strait and up and down fashion, it seems to read it just fine but the moment I try to get really precise with it which is how you say it is able of doing perfectly well, this kind of thing happens every time almost.

What do you mean by "really precise"? If you're moving on a 32x32 grid, your colors should be 32x32 blocks attached to a 32x32 grid with its origin at (0, 0).


You should show an example of the part of the image that is having problems.