Devlog 3 - Multiplayer Actually Works???

Okay, absolute good news is that I got the game running multiplayer. Took a while but I got there.

I didn’t use Godot’s built-in multiplayer features, I’m running a custom Python UDP server instead. Reason is I want full control over the netcode and the freedom to host this however I want later. Right now I’m using NGrok to tunnel connections for testing, which works fine for dev, but I’ll need proper hosting infrastructure before shipping. NGrok isn’t meant for production game traffic and the extra hop adds latency I don’t want.

I implemented AES encryption on the packet layer. It keeps casual packet sniffing out and makes the connection feel more solid, but really, it does basically nothing against actual client cheating, and the encrypt/decrypt overhead on every UDP packet is probably costing me tick rate. Might rip it out later or swap for something lighter if things get sluggish.

Server authority is in for shooting, which is the critical part. Movement is still client-side for now, which yeah… I know that means speed hacks and teleporting are basically free right now. Getting the server to authoritatively handle movement in a game this chaotic is tough, but I’ll need to add at least basic validation or reconciliation soon. “Wildcard” gameplay shouldn’t mean “the client decides where it is.”

Next up: finish the lobby UI, build out a SQL backend for user accounts, and set up a gateway to route players across server instances. I’ve got two Chromebooks I’m testing on, and while they’re fine for small playtests, 500 concurrent players is almost definitely not happening on that hardware. The server process might only eat 50MB, but RAM isn’t the bottleneck: Python’s GIL, CPU load, and network I/O will tap out way before that. If this actually gets traction, I’ll need REAL infrastructure. The Chromebooks are great for prototyping, not production.

Still. The fact that multiple people can connect right now and actually play is pretty hype. This is gonna be chaos.