I'm building a game using SFML, with disconnected logic & screen systems that run on different threads and communicate through synchronised buffers. Now, this system worked perfectly well when I only ran independent AI units, but now comes the time to handle player input, and I'm not sure what's the best way to handle it.
Currently, when a player clicks the screen, the input manager creates a
MouseClick event, which goes to the logic buffer. The logic manager checks if that spot contains a controllable entity, and if it does, creates a
SelectUnit event with the relevant information in the display buffer. When the display manager reads that event it updates the screen with the relevant piece of GUI, and any click on the GUI again sends an update to the logic component. The two problems I see are that the
SelectUnit event will need to contain a lot of logic info which might harm the info decoupling, or just make it useless, and that I fear (still not tested) that since the communication will bounce several times between the two threads, some might be lost.
Now, I wonder if this system could be handled better, with less transferred information.
Note about the tech: SFML creates a
RenderWindow object which handles input and display. I'm still not sure what library to use for GUI (probably GWEN.net), so I can't currently name tech limitations on it.
EDIT: this is supposed to be a RTS multiplayer game. So far, it seems to me there'll have to be a central logic unit (on the host computer?) that'll receive all the inputs from all players, and send the responses accordingly. This, obviously, makes this system even more complex. Again, suggestions are welcome.