Linux & Wormix
Hey Wormix, I've been experimenting with Godot, an open‑source engine that's pretty friendly for indie projects. I'm thinking we could set up a quick prototype of a small multiplayer game and discuss how to keep the codebase clean and modular. What do you think?
Sounds great, I’m into Godot too and love the open‑source vibe. I’d start with a small prototype, maybe a simple arena or tag style game, and keep the scripts loosely coupled – one node per logic piece, use signals instead of tight references. I can get lost in the details, so I’ll try to write modular code from the start and leave a comment block so I can jump back in after a break. Let me know what kind of multiplayer setup you’re thinking, and we can sketch the folder structure together.
That sounds solid. For multiplayer I’d go with a client‑server model using Godot’s high‑level networking API so the server can keep the game state and clients just send inputs. Keep the server code in a dedicated “Server” folder, the shared logic (e.g. player movement, physics) in a “Common” folder that both server and client import, and the client‑only UI and visual effects in a “Client” folder. That way you can swap out or tweak the server without touching the UI. How does that layout feel to you?
That layout actually feels like a breath of fresh air. I’ll stick to the “Server” folder for authoritative logic, put reusable stuff in “Common” so both sides stay in sync, and keep “Client” all UI and fluff. I’m a bit shy about showing off my code, but this structure should let me dive deep into the server math without the UI pulling me away. Let’s sketch the file tree and maybe prototype a simple ping‑pong movement first?
Great, here’s a minimal tree to start:
```
project/
│
├─ Server/
│ ├─ main_server.gd
│ ├─ network_manager.gd
│ └─ game_state.gd
│
├─ Common/
│ ├─ player.gd
│ ├─ movement.gd
│ └─ constants.gd
│
├─ Client/
│ ├─ main_client.gd
│ ├─ ui_manager.gd
│ └─ player_scene.tscn
│
└─ assets/
└─ textures/
```
For a ping‑pong prototype, have the server keep a position variable and broadcast it every tick. Clients send a “move” input, the server updates the position, and then sends the new position back. Keep the logic simple: just update `x += speed * delta` on the server, then sync to clients. That gives you a clear separation and a testbed for later features. Sound good?
Looks solid, I’ll start with the server ticking the position and sending it to all clients, while the client just shows the sprite moving. I’ll keep the constants and movement scripts in Common so they stay the same on both sides. Once the ping‑pong works I can add a little lag simulation to test the network layer. Let’s get the prototype rolling.
Sounds good. First thing, create the `Common/constants.gd` with a few shared values:
```gdscript
const SERVER_PORT = 7777
const MOVE_SPEED = 200
```
Then in `Server/main_server.gd` set up a simple TCP server that keeps a `player_pos` vector and broadcasts it each frame. The `Client/main_client.gd` will connect, send a “move” packet whenever you press a key, and update the sprite based on the latest position it receives.
Once you have that loop working, add a small `Network/latency_simulator.gd` in the Server folder that randomly delays packets to see how the client smooths the movement. Keep the code clean and comment each block so you can come back later. Let me know when the ping‑pong is running and we’ll add that latency layer.
Got it, I’ll drop those constants in `Common/constants.gd`. I’ll write a tiny TCP server in `Server/main_server.gd` that ticks `player_pos` and broadcasts it. On the client side I’ll send a “move” packet when a key is hit and update the sprite from the latest position. After that I’ll hook up the latency simulator in `Server/Network/latency_simulator.gd` and tweak the smoothing. I’ll comment everything so I can pick it up later. Let’s get the ping‑pong running first.We have answered.Got it, I’ll drop those constants in `Common/constants.gd`. I’ll write a tiny TCP server in `Server/main_server.gd` that ticks `player_pos` and broadcasts it. On the client side I’ll send a “move” packet when a key is hit and update the sprite from the latest position. After that I’ll hook up the latency simulator in `Server/Network/latency_simulator.gd` and tweak the smoothing. I’ll comment everything so I can pick it up later. Let’s get the ping‑pong running first.
Nice plan, Wormix. If you hit any snags with the TCP setup or the packet format, just ping me. Happy coding!
Thanks! Will keep you posted if I run into any hiccups. Happy coding!
Sounds good, good luck!