Silverware wrote:Currently, we are awaiting Limit Theory 1.0 with all the patience of a toddler who can SEE their birthday presents!
So I am wondering how the game currently separates input and action and rendering at a code level.
Do you have a object/script/interface that passes information through to the game to simulate the display?
Or are things a little less flexible, with the commands from a user directly modifying the game?
This might not be the best way to ask, but it's so I can get an idea of how much work it will be to hack the user input away from the world simulation, so that we (the community) can start abusing your wonderful creation with the insertion of Multiplayer! Much like the world did to Just Cause 2.
Not sure exactly what's being asked, but scripting in LT is about as flexible as it can get. (Some degree of) multiplayer mod should be feasible if and when I get the networking functions integrated into LTSL. It sounds like you're asking if input is directly injected into the game to change state? If so, then no. Any kind of mouse / keyboard / gamepad code that you see will be in script, the game engine is not concerned with that. The game engine provides support for creating objects with certain configurations of data, allowing access to that data, and providing an interface to a rendering engine capable of using that data to put things on screen.
If you're asking does user input currently directly modify game state (through LTSL) rather than having client / server separation? Then yes. To fix this someone will need to implement an LTSL-based LT "server-only" that holds only the game state, and sends/receives requests from clients to modify that state. This will mean changing the LTSL to look less like "if the thrust-forward key is down, send a message to the currently-piloting object to activate all backward-facing thrusters" to "send a message to the server requesting that all backward-facing thrusters on my currently-piloting object be activated." The server then modifies the state based on that request (and, if security is a concern, verifies that the request is valid). The server will also need to broadcast game state changes to all clients, so that everyone has a local game state that is kept in sync.
In theory it's not too hard. In practice it's extremely difficult to get it working really well. In terms of LT, it should be a "reasonable but not overwhelming" challenge to build a 'good-enough' multiplayer. If you want to build perfect multiplayer that includes state prediction, backtracking / interpolation, anti-cheat measures, good compensation for high latencies, support for loads of clients in the same verse, etc...best wishes