Hello everyone, I’ll try my best to clarify my question since its a bit all over the place. But here’s what I want to do.
Have a LAN, realtime, websocket based game, where users can send commands to the game. So LAN would have minimal latency which makes real-time possible. Websockets so that the users can connect via any client in any language they like.
The godot instance would be the authoritative server, headless, but I would want to allow people to spectate the game in realtime from the browser, probably using Phaser or some other web engine and via websocket again connect to the godot instance running the game where you can see what’s happening.
Does this setup make sense? It’s pretty much for a local event and for fun, there wouldn’t be too many games going on, and I could distribute the binary of the actual game for users to play on which would allow the players to test their clients on their machine.
So in summary
user writes clients in any language that supports WS → request game from server (or use local instance) → connect to the game instance
Do you expect to write multiple kinds of clients? Writing a server in Godot can work, albeit with some extra work, but the more difficult part is writing the game code again for the client.
So this is entirely doable, and makes sense in certain cases ( e.g. you have multiple teams who all need to work with different tools for whatever reason ), just checking if it makes sense for your specific case.
E.g. if you want to be able to join from PCs and phones as well, I’d personally just build all of the project in Godot and export to both platforms. Godot can be run headless, so you can even reuse the desktop build as a server.
Or worst case, if there’d be significant difference between desktop and phone builds, you can move the game logic to an addon and use that addon in both versions. This way you don’t need to rebuild the game logic but you get to customize your builds much deeper.
Yeah the idea is to let the participants write their own clients, but the game logic should happen on the server. They would write AI for the characters and send predetermined commands like move, attack and such
Thank you! That confirmation is what I was looking for, glad to hear I was on the right track. If you have any general advice I’d love to hear it. I am still in the design phase on the general architecture and how I’ll handle the user inputs, how I’ll send the diff updates to the clients and such
Since this is LAN, I’d agree that latency should not be a concern - it would needlessly complicate the code
I think having a custom tick loop would make sense. If you don’t need physics for the game, you could set the physics tickrate to what you need and put all your network game logic there. Alternatively, you can take a peep at my implementation in netfox if you’re interested.
The tick loop could be useful, because that way everyone can just submit their inputs in a packet, which you can then put into a buffer and process in the next tick.
I personally like to have dedicated scripts for input ( see example ) - they contain a bunch of variables on what’s the user doing and that’s it. Then I add these as child nodes to my players and use them when updating the game state. You could update the input nodes based on the buffer and then run a network tick for example.
After that, it’s just a matter of sending out another message to players with the updated game state.
I think as long as you have a well-defined tick loop in your code somewhere ( apply received input, update game state, broadcast new state ), you should be good. For me the key was definitely laying down a unified system I can then attach my game logic to.
