I'm a Senior Software Engineer who is building a free multiplayer browser RPG. Here's how I did it for about $10/month. 1. Separate game rules from visuals Problem: Mixing server rules and client visuals in the same scripts tangles the codebase and makes it hard to tell which side owns a behavior. Solution: Keep everything in one Godot project, and split game/ into four folders: Folder Runs on What goes inside game/server/ Server Combat, enemy AI, quests, and WebSocket connections. game/client/ Browser 3D models, animations, camera, UI, and fog of war. game/data-model/ Both Network message formats, character stats, and quest definitions. game/level/ Both Shared 3D terrain, collision boxes, NPC spots, and spawn points. 2. Sync players without complex netcode Problem: Building client-side prediction and rollback upfront takes weeks and causes sync bugs. Solution: Use a simpler model for cooperative games: Send only inputs: Browsers send player inputs; the server runs the game and broadcasts the same world state to every player 20 times per second. Glide between updates: Each browser hides enemies inside fog of war and smoothly slides characters toward their latest server positions. 3. Host the entire game 24/7 for ~$10/month Problem: Standard hosting options each have a catch: Virtual Machine (VM) (~$35/month): Browsers block https:// games from connecting to raw ws:// IPs, leaving you to manage reverse proxies (such as Nginx) and SSL renewals yourself. Managed containers: Scaling to zero ($0 when empty) forces a 20–30 second cold start on the first player, while running unpaused 24/7 costs ~$34/month because Godot still runs physics 120 times per second in an empty world. Solution: Host the client for free and put the warm server container to rest when empty: Free browser client ($0/month): Azure Static Web Apps serves the website and Web game build for free with a global CDN and automatic HTTPS. Resting server container (~$10/month): Run the server on Azure Container Apps and pause physics when the last player leaves so it bills at Azure's idle rate and wakes in under 0.2 seconds when a player clicks Play. 4. Use CI/CD to keep the architecture and cloud bill from drifting Problem: A future update can accidentally import a client script onto the server or leave a background timer running while the server is resting. Solution: Run two automated Continuous Integration / Continuous Deployment (CI/CD) checks on every Pull Request (PR): Architecture test: Scans the codebase on every PR and fails if client/ and server/ ever import each other. Idle CPU test: Boots the empty server for 30 seconds before deployment and blocks the release if resting CPU exceeds the idle billing limit. Limitations Limitations: This architecture has two intentional trade-offs: Latency and scalability: Sending only inputs and broadcasting the full world state works well for a small cooperative RPG, whereas fast-paced shooters may need client-side prediction and larger worlds may need per-player state filtering. Exploitability: Broadcasting the full world state without server filtering means a modified client could inspect packets to reveal enemies inside fog of war. Why they're worth it for now: As Donald Knuth put it, "premature optimization is the root of all evil." For an early-stage game, keeping the architecture simple lets you build the core gameplay first and optimize only when player count demands it.   submitted by   /u/SummonerRPG [link]   [comments]