Collision Maps

[Tsukihime]

This script allows you to replace your tile passage settings with a collision map. Collision maps are optional; a map can use the default tile passage settings. However, you can only choose between one or the other.


The collision map is straightforward: it is an image the size of your map. Anywhere that is colored red is cannot be passed. The collision map can be created in any image editor of your choice.


This is a very simple collision map and only supports two passage settings: Passable, not passable.


Note that this script only overrides the passage settings for a tile: all other tile settings (such as the * tile behavior) are preserved.

Download


Get it at Hime Works!

 

[Engr. Adiktuzmiko]

I hope this can be made to work with the default (for the star passability and the other passability options like the directionals)

 

[Tsukihime]

This is just a prototype I quickly threw something together in hopes that someone will see it and go "ooh that is really easy I can make it better"


In fact it does not work with victor's pixel movement, though I am not too sure why.


For the script to be actually usable, that pixel checking function will need to be written in something faster than Ruby. At least, the way I have designed it you just need to load the passage settings once and all of it is cached.


At some point, I will add the ability to change the collision settings using script calls, so you can basically change the passage settings of each and every tile without actually swapping the tiles.


This script's goal is to separate passage settings from the tiles themselves.


EDIT: figured out why it doesn't work for victor's pixel movement: there are floats instead of integers.


So rather than just treating each pixel as a single (x,y) coordinate, it uses some strange mapping from tile coordinates to...some partial tile coordinates.

 

[djDarkX]

LOL!  Nice work.  Looks like me mentioning it in that other thread didn't fall on deaf ears. xD

 

[seita]

Will you be making this compatible with victors now that you know what to do?

 

[Tsukihime]

Will you be making this compatible with victors now that you know what to do?

I've tried a couple things, like multiplying each floating point value by 32 to get the pixel coordinates, but the pixel movement script does not seem to like it when I do that...


Not really sure if it's because my script is bugged or something else.

 

[Marian Hurricane]

I hope you're able to get it working with pixel movement... They'd be a great combination! TuT

 

[seita]

victors pixel movement goes by every 4 pixels in case that helps, so the events movement can only be divided up to 8.

 

[Tsukihime]

victors pixel movement goes by every 4 pixels in case that helps, so the events movement can only be divided up to 8.

You're right, I just looked at the round_x methods and they're changing by 0.125 instead of 1.


One problem I'm having is the actual hit collision check: rather than checking whether the sprite collides with any red pixel on the collision map, I'm checking whether the character's position collides...which isn't right because your sprite is much bigger than one pixel (so you could literally walk halfway into a tree before you stop moving)


This may be related to why I'm unable to get it to work with the pixel movement script.


I'm not sure how to solve this.


The collision map script's only purpose is to allow you to create collision maps and load them into the game. It's not supposed to provide collision check functionality as that is specific to how your movement works.

 

[seita]

I know his script also allows an event to have a specific size depending on the comment call <event size: x y> inside the appropriate page, perhaps whatever method he uses to check the players collision and the events collision may help? The default for the collision of the event is also the size of the sprite.

 

[ShadowFox]

I'm curious, can this script allow the player to move behind walls and buildings as well walk through hidden passage ways and be hidden by the correct tileset?

 

[seita]

I believe this script only deals with walk passability, the over and under tiles would still be governed normally through the default scripts.

 

[Engr. Adiktuzmiko]

actually, via the first statement, you need to choose between either this or the default...

Collision maps are optional; a map can use the default tile passage settings. However, you can only choose between one or the other.

 

[Tsukihime]

ShadowFox brings up a good question.

I'm curious, can this script allow the player to move behind walls and buildings as well walk through hidden passage ways and be hidden by the correct tileset?

Yes. In fact, you can set ALL your tiles to * and then use a collision map to specify where you can or cannot pass. Then you can be hidden behind ANY tile you want.


Ok, the editor prevents you from doing that by preventing you from setting auto-tiles to * passage, but we can always get around that by writing another script that specifies visual layering.

I know his script also allows an event to have a specific size depending on the comment call <event size: x y> inside the appropriate page, perhaps whatever method he uses to check the players collision and the events collision may help? The default for the collision of the event is also the size of the sprite.

I'll have to look into that at some point.


However I will leave that to a separate script for actual collision checks.

actually, via the first statement, you need to choose between either this or the default...

That statement only applies to passage settings, and not all tile settings.


You can still set it to O, X, or * and the graphics will still behave as usual.

 

[ShadowFox]

I see. Would love to have a demo of this script as it sounds very interesting.

 

[Tsukihime]

I have updated the script.


The collision map creation is now done in a dll function so it should be faster.


For extremely large maps, you will still notice delay (for example, a 100x100 map takes me an extra 0.02 seconds to load, which is obviously slower than immediate)


Currently there is no "padding" done, so if you are working with 32x32 tiles, you must make sure that you are aligned to a 32x32 grid. If you partially color a tile, you will find that it is still passable.


I will figure out how to sample the tile at a later date.


I have also added a demo.

 

[Erojiji]

Wow, this is script I looking for, btw it is possible to reduce the collusion smaller than 32x32 tile?

 

[Tsukihime]

The collision map already supports pixel collision checks (1x1 in size), however it doesn't provide any functionality for the actual collision checks as the purpose of this script is to load the collision map.


You will need to look for another script that will provide the appropriate collision checking.

 

[Erojiji]

Ah, so I need another script, okay thanks for the information =w=/