Jump to content
Sign in to follow this  
  • entries
    53
  • comments
    225
  • views
    69741

Proximity Triggers

Sign in to follow this  
Milkshake

508 views

After a brief siesta for SIGGRAPH and a wonderful family holiday, my cow and I are back.

This week I've been looking at adding the first smatterings of game logic. Like probably every other game engine on the planet, I have scripting support that allows you to drop a script onto any object to handle any events that are passed to that object, and generally tell the object what to do. Now scripts have their place - they're great for orchestrating unique events, cut scenes, dialogs, etc. But for basic game objects (like switches opening doors, or turning off the lights), I wanted something more like a toy box. You drop a switch and a door into the level, then you connect the output of the switch up to the input of the door.

So rather than creating loads of different door types to implement all the different ways a door can be opened, I create a single door node (that purely knows how to open and close a door), and then I can connect any kind of opening mechanism to it I want (like a proximity sensor for automatically opening doors, a lock for a door opened by a key, a switch for remotely opened doors, a pressure pad, etc). Any of these input devices can also be hooked up to any other output device (like a light, a conveyor belt, a lift, etc). I also have the usual set of AND, OR, NOT nodes for building more complicated logic (e.g. the door opens when the switch is ON and there's something on that pressure pad). You can obviously throw a script node in the middle if you need it, but I'm hoping I can keep things graphical (even though right now the connections are made by typing in console commands as I haven't written the graphical UI yet).

The first input device I decided to setup was the ProximitySensor. This input device gives you the list of (mobile) entities within its sensor shape (usually a sphere, but could be anything). I've thrown a transparent red shader on the sensor shape so you can see it below:

Disabled

Enabled

Like most things, implementing this turned out to be the tip of a moderately large ice-burg. My physics code used to spam messages every frame (X is touching Y, X is touching Y, X is touching Y, etc). Any controller trying to process these messages was responsible for filtering them to turn this stream of repetition into a more digestable set of changes (X has started touching Y, X has stopped touching Y). To make matters worse, these messages were being sent per-contactpoint per-frame. Not only did this add complexity to all the Controllers, but in a large scene, this could be a real performance killer (lots of virtual function calls, and lots of timers being setup to workout when the stream of messages stopped). So my first job was to refactor the physics code to only send a message when something changed. This turned out really well - I'm very happy with it.

The second thing I was missing was the ability to use a shape as a sensor or trigger. Rather than having any logic/AI "search" the scene to work out which entities are nearby (e.g. an orc AI might have a perception radius of 4 units, and it wants to know if anyone is close enough to be noticed), I wanted to leverage the efficiency of the collision system (which already has all the spatial optimisations, and only tests intersections when things move). Not only is this more efficient, but it re-uses all the same collision code I already have to let me use any shape as a sensor volume. Shapes in the game already had a set of flags which tell the engine what it's used for (Do I render it? Can I hit it? Does it cast shadows?), so adding a new "Is this a sensor" flag and adding some code to propagate and test the flag in a few places, and bingo!

Now, I'm off to create a switch!


Sign in to follow this  


2 Comments


Recommended Comments

I wish I had gone to siggraph. It always looks like such fun, though I hear it's too advanced for my level of graphics smarts.

Looks good; can your triggers 'activate' a physics object directly, or do they have to do it through some kind of controller intermediary? It'd be fun to hook up a switch to a flying log or something.

Share this comment


Link to comment
I actually don't usually get to attend the sessions at SIGGRAPH - too many meetings. I did make some time to watch some of the LucasArts/ILM presentations though: very cool demos of Indy 2007 and behind the scenes of Dead Man's Chest. They seem to be recruiting too =)

As far as hooking up a proximity sensor to a switch, I've defined most of the properties (like the switch state) to work as both inputs and outputs, so
you certainly could do it. The data would happily propagate through the switch (playing the on/off animation) and then continue off to whatever's been connected to the switch.

Given both the switch and the proximity sensor are basically "input" devices, I'm guessing you wouldn't do it very often. But I suppose it might be handy of you wanted to have the switch automatically turn on/off when the player entered a certain region.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!