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.

Devlog 2 - Core Systems Work (Sort Of)

I mean, it works. And tbf, That’s a win right now.

The foundation is in place, albeit held together with metaphorical duct tape. Godot decided to crash on me three times for absolutely no reason, so building this was more of an endurance test than a workflow. But we got there.

What’s Shippable:

Dynamic Inventory UI - Fully built out and functioning. It’s clean, it’s scalable, and it actually does what it’s supposed to do while looking like sh*t.

Overclock Meter - The core wildcard mechanic is alive. The meter builds when you chain movement, tricks, or high-intensity plays in a short window. Fill it up, and Overclock arms itself. Once armed, you can pop it at any moment during a match to slow everyone else down. It’s chaotic, it’s unfair in the best way.

What’s Next:

Overclock isn’t staying a one-trick pony. I’m planning a full suite of variants: time dilation, global weapon disable, and a few others that’ll really make matches unpredictable. The goal is to turn Overclock into a genuine match-altering decision, not just a “press button to win” scenario.

This game is going to be absolutely unhinged in the best way possible.

(P.S. - Yes, the gun thumbnails are placeholder. Yes, I could’ve done better. No, I will not be taking constructive criticism on them at this time.)

(I have yet to disable walking)

Devlog 1

Haven’t really done much but the player can walk (gonna remove that later) and the shooting mechanic works. I need to add walls and stuff along with fixing the gravity.

Ill cya in a bit.