Hotseat and multiplayer #8

New Issue

veclavtalica · 2024-09-02T05:34:31Z

veclavtalica commented

2024-09-02 05:34:31 +00:00

Games that are likely to be made in Townengine can benefit from having simple and almost-no-effort multiplayer. Think of something like Worms.

It could be as simple as adding a concept of player ids attached to inputs, so that each client can keep their simulation, without any synchronization or explicit messaging.

One question remains: what method of communication to use for intermachine multiplayer, especially that we are willing to have web builds. Settling down on WebSockets could be good. WebRTC is good, but is not easy to integrate and build.

Games that are likely to be made in Townengine can benefit from having simple and almost-no-effort multiplayer. Think of something like Worms. It could be as simple as adding a concept of player ids attached to inputs, so that each client can keep their simulation, without any synchronization or explicit messaging. One question remains: what method of communication to use for intermachine multiplayer, especially that we are willing to have web builds. Settling down on WebSockets could be good. WebRTC is good, but is not easy to integrate and build.

veclavtalica added the

feature

label 2024-09-02 05:34:31 +00:00

veclavtalica commented

2024-09-16 06:18:44 +00:00

One problem, - late-join players, or reconnecting ones. They need to somehow get the latest state, but as only way of syncing is inputs, one would need to send them all inputs in history to play them back, which is potentially quite a lot. Also history would grow with time, preventing long sessions, or any game with persistence.

Simple way could be is not to do anything, - if your game requires it, - user must write serialization methods for their state exchange. There could be an api introduced to facilitate raw byte transfer at least.

One problem, - late-join players, or reconnecting ones. They need to somehow get the latest state, but as only way of syncing is inputs, one would need to send them all inputs in history to play them back, which is potentially quite a lot. Also history would grow with time, preventing long sessions, or any game with persistence. Simple way could be is not to do anything, - if your game requires it, - user must write serialization methods for their state exchange. There could be an api introduced to facilitate raw byte transfer at least.

Sign in to join this conversation.