I am writing a game engine in C++.
I have been considering how to implement controllers in the 3D world such as a lever or a control panel with multiple buttons.
Now, the line of though I'm not sure about is whether these 'world-controller' objects could implement the same interface as for the users Input-device? Essentially they are a 'virtual' input devices where the inputs are mapped onto game events or the users button presses.
The issue here is this could be implemented by other means that may be better. Possibly the 'world-controller' explicitly sends specific events for example. I thought gameDev would be a good place to start and couldn't find much help searching the web other than on controllers in general.
What do most people do to implement objects in the world that in turn control other objects or other controllers?
Cheers,
Craig
User-Controller 'controlling' world-controller!?
You probably want some kind of messaging system -- when a control is activated, it posts a message to "interested parties" (whatever object or game systems care about that event) and they respond by performing whatever action they respond with -- say a door becomes open, or a draw-bridge lowers.
Physical input from the player should also be decoupled in some way, and this same message system can provide a suitable solution (though a more-tailored system might be better). Basically, there should always be a middle-man between the cause-and-effect of player input -- you should never have code like "IF(IsPressed(Button.Right)) THEN Player.X += 2", instead, a message of some kind should be fired when a button is pressed, and the player object should respond to that message by moving in the requested direction, after the message has been filtered by the Collision-Detection object [GRIN].
Physical input from the player should also be decoupled in some way, and this same message system can provide a suitable solution (though a more-tailored system might be better). Basically, there should always be a middle-man between the cause-and-effect of player input -- you should never have code like "IF(IsPressed(Button.Right)) THEN Player.X += 2", instead, a message of some kind should be fired when a button is pressed, and the player object should respond to that message by moving in the requested direction, after the message has been filtered by the Collision-Detection object [GRIN].
What would be a good idea is if you had an in-game script object. So you have a scripting language (python, ruby, whatever), and have an in-game script object that wraps the update of a script in that language that you can connect to other game objects through your engine specific code.
Each script object can have multiple inputs and multiple outputs which you then connect to other game objects.
So, we have some game objects: Switch_1, Switch_2, SwitchScriptController, Door.
1. Player presses Switch_1
2. Switch_1 fires it's output 1 to input 2 (any output should connect to any input) on SwitchScriptController
3. SwitchScriptController gets the input and stores it since we want to wait until both switches have been pressed
4. Player presses Switch_2
5. Switch_2 fires it's output 1 to input 3 on SwitchScriptController
6. SwitchScriptController sees that both have been pressed
7. SwitchScriptController fires it's output 1 to input 1 on Door
So, each game object will have it's own set of inputs and outputs, you can make them named, but it's probably easier to just leave them as numbered, that way you can just connect them or disconnect them without worrying too much about renaming them. The script is just a game object with a script inside, so you can just bundle up whatever logic you want in it for a whole or part of a puzzle.
Each script object can have multiple inputs and multiple outputs which you then connect to other game objects.
So, we have some game objects: Switch_1, Switch_2, SwitchScriptController, Door.
1. Player presses Switch_1
2. Switch_1 fires it's output 1 to input 2 (any output should connect to any input) on SwitchScriptController
3. SwitchScriptController gets the input and stores it since we want to wait until both switches have been pressed
4. Player presses Switch_2
5. Switch_2 fires it's output 1 to input 3 on SwitchScriptController
6. SwitchScriptController sees that both have been pressed
7. SwitchScriptController fires it's output 1 to input 1 on Door
So, each game object will have it's own set of inputs and outputs, you can make them named, but it's probably easier to just leave them as numbered, that way you can just connect them or disconnect them without worrying too much about renaming them. The script is just a game object with a script inside, so you can just bundle up whatever logic you want in it for a whole or part of a puzzle.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement