NPC Collision
Hi
I just wanted to know if there was a simple way to implement collisions in my tile based game. I''ve already written some code to stop the player from colliding with nonwalkable tiles, but how should I do it with NPCs? First of all, unlike the tiles, the npcs move around. I want it so that the player can walk up to an npc and stop moving in that direction of there is a colision. Can anyone help? Thanks
-Spark
well theres a number of good ways to do this... I''ll just discribe the ways I know how...
if your useing a variable ID to identify what kind of tile its(like 1=player 2=monster 3=weapon ect.) then just test for the kind you don''t want the player to be able to walk through...
I personaly like setting a flag in the tile data to idecate if the tile is walkable. 1 if it is. 0 if it is not... it might be a water tile or a monster. it realy dosen''t matter... this is cool to make what looks like a soild wall but realy isn''t...
Great Milenko
if your useing a variable ID to identify what kind of tile its(like 1=player 2=monster 3=weapon ect.) then just test for the kind you don''t want the player to be able to walk through...
I personaly like setting a flag in the tile data to idecate if the tile is walkable. 1 if it is. 0 if it is not... it might be a water tile or a monster. it realy dosen''t matter... this is cool to make what looks like a soild wall but realy isn''t...
Great Milenko
Words Of Wisdom:
"Never Stick A Pretzel In Your Butt It Might Break Off In There."
http://www.crosswinds.net/~milenko
http://www.crosswinds.net/~pirotech
The Great Milenko"Don't stick a pretzel up your ass, it might get stuck in there.""Computer Programming is findding the right wrench to hammer in the correct screw."
To test for collisions with NPCs (and any other objects) you need to keep track of which NPCs are visible on screen, then test the player''s coordinates against the coordinates of each NPC.
Another method you could use (especially for objects or NPCs that don''t move much) is to divide the viewport into zones (4 is good). By tracking which zone the player is in, you test for collision only against the objects in that zone.
Another method you could use (especially for objects or NPCs that don''t move much) is to divide the viewport into zones (4 is good). By tracking which zone the player is in, you test for collision only against the objects in that zone.
--- Official D Blog | Learning D | The One With D | D Bits
When I made a 2D Side Scroller, I took the players position in the whole world, then you divide his x by the tiles x, and his y, by the tiles y, and subtract 1, on each and add 1 on each, then you got the 4 tiles around him,
IF the player is bigger than four tiles, lets say he twice as big as the Tiles, then just subtract 2, then you have 8, not as fast but hey
Oh, and for this to work the BIG Requirment is that all the tiles are the same size, which sucks, inless you got some good coding idead(cant think of one at the moment sorry)
IF the player is bigger than four tiles, lets say he twice as big as the Tiles, then just subtract 2, then you have 8, not as fast but hey
Oh, and for this to work the BIG Requirment is that all the tiles are the same size, which sucks, inless you got some good coding idead(cant think of one at the moment sorry)
It really depends on the type of game.
I''m doing an isometric RPG, so extremely precise Collision Detection isn''t required -- I''m just going to do cell-based collision-detection (determine what cell the PC is in, the cell the NPC is in, and figure out what they can do from there (ie, they will never be standing in the same cell -- also, to talk, the NPC needs to be standing in a cell adjacent to the PC). This same concept will work for most RTS games, as well (where precision isn''t as important as AI speed, so using extra cycles to determine collisions is useless).
Non-movable objects (even if they''re represented using sprites) will be considered part of the terrain for collision-detection issues (my tool will update passable/impassable tiles on the terrain depending on where you place the objects)
If you''re doing an action-based game, I would recommend using bounding boxes (or circles, if the accuracy is REALLY important). This would allow you to get to the near-pixel level of comparison.
Those are the two best approaches I can think of -- if you have questions on either of them, email me and I''ll try to get back to you ASAIC (as soon as I can )
-Chris
---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com
I''m doing an isometric RPG, so extremely precise Collision Detection isn''t required -- I''m just going to do cell-based collision-detection (determine what cell the PC is in, the cell the NPC is in, and figure out what they can do from there (ie, they will never be standing in the same cell -- also, to talk, the NPC needs to be standing in a cell adjacent to the PC). This same concept will work for most RTS games, as well (where precision isn''t as important as AI speed, so using extra cycles to determine collisions is useless).
Non-movable objects (even if they''re represented using sprites) will be considered part of the terrain for collision-detection issues (my tool will update passable/impassable tiles on the terrain depending on where you place the objects)
If you''re doing an action-based game, I would recommend using bounding boxes (or circles, if the accuracy is REALLY important). This would allow you to get to the near-pixel level of comparison.
Those are the two best approaches I can think of -- if you have questions on either of them, email me and I''ll try to get back to you ASAIC (as soon as I can )
-Chris
---<<>>---
Chris Rouillard
Software Engineer
crouilla@hotmail.com
---<<>>--- Chris Rouillard Software Engineercrouilla@hotmail.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement