Hi, I'm still trying to understand how game works, so I have a noob question, how to implement a trigger system in to a game ? Then an object enters an area, then an object get's hit, and so on...
Can someone explain a bit, or at least tell me about a book or something where I could find something about this...
Question about a trigger system
A trigger such as a door opening when the player walks past is simply a matter of collision detection to decide when the trigger has been activated, and some sort of script that is called to engage the doors open mechanism. That being said, simply is relative.
If you are using C++ and SDL you could have a look at these tutorials at
http://lazyfoo.net/index.php , it would help even if you dont use C++ and SDL just to see how collision detection works.
http://lazyfoo.net/index.php , it would help even if you dont use C++ and SDL just to see how collision detection works.
As mentioned above, the first step is to implement some sort of collision detection.
Most collision engines allow designating each object with a user-chosen "collision type" tag. For a door, for example, create a box around the door and set its collision type to (something like) OBJECT_EVENT, OBJECT_EVENT just being one of the user chosen enum's for collision object types.
Most collision engines also provide for a collision callback function. I.e., during the collision phase of the game (when all the collisions are being collected), a user function is called with information on what two objects are colliding, the position of the collision, etc.
Setup an event-callback function for each OBJECT_EVENT and push information about each collision onto a stack or add the info to a std::vector.
When the collision phase is complete, iterate through the event collisions and determine what actions to take. E.g., a collision between the door event box and a player - if the door is not open, open it, etc.
Most collision engines allow designating each object with a user-chosen "collision type" tag. For a door, for example, create a box around the door and set its collision type to (something like) OBJECT_EVENT, OBJECT_EVENT just being one of the user chosen enum's for collision object types.
Most collision engines also provide for a collision callback function. I.e., during the collision phase of the game (when all the collisions are being collected), a user function is called with information on what two objects are colliding, the position of the collision, etc.
Setup an event-callback function for each OBJECT_EVENT and push information about each collision onto a stack or add the info to a std::vector.
When the collision phase is complete, iterate through the event collisions and determine what actions to take. E.g., a collision between the door event box and a player - if the door is not open, open it, etc.
Author
I think one thing is collision detection, and another is a trigger... I don't think there must be a collision detection check, to see if the object enter an area... And if an object hits another, to trigger a trigger, it's not about collision detection...
If you intend for an object to set off the trigger by doing something in the world, collision detection WILL factor in some how. Perhaps a more thorough explanation of what you are attempting to do would help.
As far as I know you can have a collision detection checking if x has hit y , or you can trigger events by time ( if time >= this time then do something ) , or by location ( if playerX == thislocation then do stuff ), or even by checking some variable status and doing some action if the variable equals a specified value.
Definitely need more info on your particular problem to provide any advice.
Definitely need more info on your particular problem to provide any advice.
This is a good application for a Bloom filter. It can reduce the necessary processing when there are thousands of triggers.
In a client-server setting, you could even offload this task to the client and only verify its validity on the server after the client reports a hit. Since Bloom filters regularly report false positives, there is not much potantial to exploit the "secret knowledge", either.
In a client-server setting, you could even offload this task to the client and only verify its validity on the server after the client reports a hit. Since Bloom filters regularly report false positives, there is not much potantial to exploit the "secret knowledge", either.
Quote:Original post by Sillencer
to see if the object enter an area...
That's the definition of collision detection: "is one thing inside another". Collision response is then dealing with moving things around that need to be moved around so they are no longer inside each other.
A trigger is simply an object that has collision detection but does not have collision response. That's why all collision detections systems: havok/PhysX/etc have built in triggers. They're basically trivial to add if you already have a collision detection system
-me
Author
Let's say there's a mage, and he casts a spell that does not have any animation, it just hits the target, don't see what collision detection has to do with it...
So, if i understand right, what you are supposing is just to use a built-in trigger system of an collision detection system ?? Did I understood it right ? Is this a good idea in practice ?
So, if i understand right, what you are supposing is just to use a built-in trigger system of an collision detection system ?? Did I understood it right ? Is this a good idea in practice ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
