Making collisions only trigger for specific things
by Spencer Grey · in Torque Game Builder · 06/30/2006 (7:23 am) · 1 replies
Hey,
My newest test project is to figure out how to make a top down puzzle game, where you control multiple creatures, etc etc. One thing that I would love to do is to have doors/vents/etc that can only be passed through by certain creatures (ie: a vent can only be entered by a tiny creature, not a medium/large/etc).
Idealy, I'd like to create my rooms and whatnot out of tiles (using their collision polys) and use the level editor to place sprites for my doorways/vents/other objects. I could make everything in the tile editor and just use a* based off of my tile custom data, but that would cause a bunch of other problems for what I want to do.
At first I thought I could just assign different groups to creatures, so the tiny creatures would be BIT($TINYCREATURE), etc, but what if I want to have the tiny creature walk up to a large, have the large creature boost the tiny one up, which allows the tiny creature to reach a venter that he otherwise couldnt have?
This is all just a learning experience at this point, so whether or not having a different heights on a vent for a top down game makes sense doesn't really matter to me. I'm just curious *how* I would do it.
If anyone has any ideas, I'd love to hear them.
Edit -- the more I think about this, the more I think a* and tile data is the way to go.
My newest test project is to figure out how to make a top down puzzle game, where you control multiple creatures, etc etc. One thing that I would love to do is to have doors/vents/etc that can only be passed through by certain creatures (ie: a vent can only be entered by a tiny creature, not a medium/large/etc).
Idealy, I'd like to create my rooms and whatnot out of tiles (using their collision polys) and use the level editor to place sprites for my doorways/vents/other objects. I could make everything in the tile editor and just use a* based off of my tile custom data, but that would cause a bunch of other problems for what I want to do.
At first I thought I could just assign different groups to creatures, so the tiny creatures would be BIT($TINYCREATURE), etc, but what if I want to have the tiny creature walk up to a large, have the large creature boost the tiny one up, which allows the tiny creature to reach a venter that he otherwise couldnt have?
This is all just a learning experience at this point, so whether or not having a different heights on a vent for a top down game makes sense doesn't really matter to me. I'm just curious *how* I would do it.
If anyone has any ideas, I'd love to hear them.
Edit -- the more I think about this, the more I think a* and tile data is the way to go.
Torque Owner Spencer Grey
With individual sprites, I could walk up to a computer, press space, and have it call that computers onUse function. That onUse function would then get the correct tree of data for the given computer, and create a nice branching dialog in a gui screen.
If I place the computer as a tile, give it the correct custom data, then have my character walk up to it and press space ...
It would
(a) figure out the correct tile to check depending on the direction of my guy
(b) check the "class" of the obect stored in that tile (by looking it up in an array)
(c) reference an already made script object, calling the onUse function to the computer class, passing in the
correct tile to apply it to?
I guess I could figure out a way to make something like that work ... but it seems needlessly complicated.
Hmm. What if I stored all of my collision data in an array but created a sprite for every object at the correct location. The sprites would never collide with anything, but could be used. So if I walk up to a computer object now, I cant walk through it because the array lists those tiles as closed to me. But when I hit space, it figures out which object is infront of me, and calls the onUse function like I originally said?
Sorry for my rambling, this is helping me sort through my thoughts. And ofcourse, I'm interested in feedback.