Interaction with an engine / interfaces?
Author
Hi there!
I wasn´t exactly sure where to put this, but here seems fitting to me.
I´m rather unsure how to deal with interaction with my graphics engine, that is how to handle input (not only by the player, but by a script for instance)... my current idea would be to use some kind of message / event system.
All the logic and graphical entities would "subscribe" at one hub for the events and messages it wants to receive. Every message / event will first be handled by the hub, which just passes it on to the entities that subscribed to it. The Mediator pattern seems to describe the same or a similar setup.
I think this system would work fine for input, but would fail for things requiring output. The problem is that it is not known when a message / event will be processed and there is no possibility to return a value through this system (except sending another message containing the return value, but again it is not known when this message would be processed).
For example if someone writes a script that would require the knowledge where the player character currently is. With the event / message system this information cannot easily be retrieved, as you don´t know when your request for it will be processed.
Normally I´d say it would be nice to have some sort of function in the engine that can be called from the script, something like GetPlayerPosition() or anything like that. But I obviously don´t want implement loads of specific GetThis() GetThat() GetFoobar() functions for every logical entity and every property they might have.
So, to sum it up:
I´m interested in how to design an interface to use with a scripting language like LUA, or an application built using the engine, or with a console inside such an app and so on...
of course I know there isn´t something like _the_ solution to this problem, but I would really appreciate any insights and tips, perhaps someone wants to share how he / she solved this.
Thx for reading and your help!
You're thinking of design in a fairly impractical way. A good rule to use when designing a system is that information should only flow one direction whenever possible. So for instance, you should not need information flowing back and forth between your Player object (for, say, the current position) and your Input code (for, say, turning left).
Instead, information should flow one direction through the system, and the system should know how to handle it at the right time. To use the player-turning-left example, you should be able to do a logic process that looks something like this:
A common name for this pattern is chain of responsibility. Any time the action_player_turn_left command goes through the chain, nobody knows what it means; any given handler is free to interpret that action in any way it likes. Of course, to make sense, you should have a handler that interprets it in the obvious way, and actually makes the player turn left.
In other words, you should never have tight coupling between an input source and the code that responds to the input itself. If you implement a generic chain of responsibility (a good idea), you can have your Player object act as a subscriber to the chain. Any other subscriber will ignore the action_player_* set of messages, but the Player class catches them and handles them. Since the input handling code is in the same organizational unit (i.e. class) as the player state data, you don't need to worry about passing stuff around throughout the entire system.
Hopefully that makes sense... I'm a little behind on sleep at the moment [wink]
Instead, information should flow one direction through the system, and the system should know how to handle it at the right time. To use the player-turning-left example, you should be able to do a logic process that looks something like this:
- Get a key in from the keyboard - it's the left arrow key
- Look up the key mappings table; left arrow = action_player_turn_left
- Pass action_player_turn_left to each input subscriber in your input chain
- Any subscriber that can handle the action should do so, and optionally "eat" the action to prevent it from getting passed to other subscribers
A common name for this pattern is chain of responsibility. Any time the action_player_turn_left command goes through the chain, nobody knows what it means; any given handler is free to interpret that action in any way it likes. Of course, to make sense, you should have a handler that interprets it in the obvious way, and actually makes the player turn left.
In other words, you should never have tight coupling between an input source and the code that responds to the input itself. If you implement a generic chain of responsibility (a good idea), you can have your Player object act as a subscriber to the chain. Any other subscriber will ignore the action_player_* set of messages, but the Player class catches them and handles them. Since the input handling code is in the same organizational unit (i.e. class) as the player state data, you don't need to worry about passing stuff around throughout the entire system.
Hopefully that makes sense... I'm a little behind on sleep at the moment [wink]
Author
erm, I guess there´s a misunderstanding here I should clear up:
I´m not talking about keyboard input for moving the player character or shooting or anything like that.
For player input I totally agree with you that there is no need for output from the engine at all, as I would just drop a message (action_player_turn_left) to the player object or any object interested in player input.
I need an interface that I can use for scripts. In scripts it would be useful to be able to get information about the current game state, e.g. for a button that should only open a door once I would like to know whether the door has been opened, whether the button has already been pressed and so on.
So with scripts I need a way to get info _from_ the engine, at least I think I need it. Perhaps I´m wrong there, but I just can´t imagine how I would write a script that for example should make a decision based on the player character´s health without being able to get that value from the player character object.
Thx for your answer Apochi, but still my question remains:
The event / message hub I described would work just fine for any kind of "pure" input (like keyboard or mouse input, or even scripts not interested in the game´s state), but I think it would fail miserably when trying to get some information about the game´s state for scripts that might involve some decision based on it.
As this hub-thingie would only work for the way in, I thought about a system that might handle both ways in a nice manner, but haven´t come up with one yet, and I didn´t even come up with a nice system to allow retrieving game state information from the logical entities that might exist in the game.
Again, thx for the answer, and thx to everybody who read this and might have a clue for me :)
I´m not talking about keyboard input for moving the player character or shooting or anything like that.
For player input I totally agree with you that there is no need for output from the engine at all, as I would just drop a message (action_player_turn_left) to the player object or any object interested in player input.
I need an interface that I can use for scripts. In scripts it would be useful to be able to get information about the current game state, e.g. for a button that should only open a door once I would like to know whether the door has been opened, whether the button has already been pressed and so on.
So with scripts I need a way to get info _from_ the engine, at least I think I need it. Perhaps I´m wrong there, but I just can´t imagine how I would write a script that for example should make a decision based on the player character´s health without being able to get that value from the player character object.
Thx for your answer Apochi, but still my question remains:
The event / message hub I described would work just fine for any kind of "pure" input (like keyboard or mouse input, or even scripts not interested in the game´s state), but I think it would fail miserably when trying to get some information about the game´s state for scripts that might involve some decision based on it.
As this hub-thingie would only work for the way in, I thought about a system that might handle both ways in a nice manner, but haven´t come up with one yet, and I didn´t even come up with a nice system to allow retrieving game state information from the logical entities that might exist in the game.
Again, thx for the answer, and thx to everybody who read this and might have a clue for me :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
