Best practices for connecting the player actor and the GUI
- Edited
[deleted] All game logic should go via an overseeing script that's above GUI and Actors. That's Game in your case. If GUI needs something from an Actor then Game should get it from the Actor and push it onto GUI. Same For stuff that Actors need form GUI. Actors and GUI don't need to be in any way directly connected.
For example. If a command is issued via GUI, GUI signals that to Game and Game calls corresponding Actor::command_such_and_such(). If a GUI element needs to be disabled/enabled due to Actor state, the Actor signals that to Game and Game then calls GUI::disable_button_such_and_such(). Etc. Having some brain script that controls an actor wouldn't change anything in this setup. The important thing is that hierarchy of control is established and adhered to.
- Edited
No, the code that controls an actor should be in the actor. The code that controls game logic that affects actors should be above.
I don't like abstract programming talk. What's the exact type of this game?
- Edited
@"Aaron"#p129346 Design the actor as a component (scene) that can be fully controlled via its API calls. So actor's top node should implement an API like this:
- methods that trigger actions e.g.
move(direction),cast_spell(spell),acquire_spell(spell).. - methods that query its state e.g.
get_equipped_spells(),get_hitpoints()... - signals that communicate realtime state change e.g.
hitpoints_changed,died,spell_ready...
Once you have a well designed self-sufficient actor component, it doesn't really matter what controls is as long as it plays nice with actor's interface (API). The player actor can then be controlled via GUI, and npc actors can be controlled from a script. GUI can also be a self-sufficient component that communicates directly with any actor you give it a reference to at runtime. Same for the "ai brain" component.
Weird, what happened to the OP and their posts?
