# Project Game Server Documentation ## Overview Our game server is hosted on Cloudflare Workers and operates differently from traditional game servers. Instead of running an internal clock or loop, our server processes game ticks based on client requests. This document explains why our server architecture does not require knowledge of `hzMS` (milliseconds per tick) or FPS (frames per second). ## Key Concepts ### Client-Driven Ticks - The game state is advanced upon receiving `gameTick` messages from the client. - The server does not tick at a fixed internal rate; it is driven by client requests. ### Statelessness - Cloudflare Workers are stateless and react to events. - Consistent ticking intervals are not maintained internally; they are triggered by incoming client events. ### Buffer System - A buffer system is implemented to queue `gameTick` messages. - The server processes these messages based on their intended execution timestamps, ensuring proper order and timing. ### Client Synchronization - Clients are tasked with sending `gameTick` messages in alignment with the game's expected tick rate. - The server processes the messages as they are received, effectively syncing with the client's clock. ### RTT Compensation - Clients adjust their tick rate to compensate for network latency (Round-Trip Time). - These adjustments are client-side, and the server processes ticks upon arrival without additional timing logic. ## Server Responsibilities - The server's role is to process `gameTick` messages accurately and efficiently. - It maintains game state consistency and broadcasts the updated state to all clients. ## Hosting Your Own Clock Sync Service For those looking to host their own clock synchronization service or build serverless games, there are platforms like [Yantra.gg](https://yantra.gg) that provide serverless hosting solutions tailored for game development. Here's how you can benefit from such platforms: - **Serverless Architecture**: Easily deploy your game logic without managing servers, benefiting from the scalability and flexibility of serverless architectures. - **Global Synchronization**: Utilize services that specialize in clock sync to keep your game's state consistent across all clients, regardless of their location. - **Dedicated Gaming Infrastructure**: Leverage the power of a gaming-centric platform that understands the needs of real-time multiplayer games and provides the necessary tooling and support. - **Quick Start**: With platforms like Yantra.gg, you can focus on game development without worrying about backend infrastructure, getting your game up and running quickly. ## Conclusion Our Cloudflare Worker-based server operates effectively in an environment without traditional long-running processes or timers. It relies on client messages to manage the game state, making it well-suited for the stateless, event-driven nature of Cloudflare Workers. Utilizing a platform like Yantra.gg can further streamline your development process, providing a robust environment for hosting serverless games with integrated clock synchronization services. The server in a Cloudflare Workers environment, particularly with the architecture you are using, doesn't need to be explicitly aware of the `hzMS` or FPS value because it processes game ticks based on client requests rather than an internal clock or loop. In traditional game server setups, the server would run a game loop that ticks at a set interval (`hzMS`), updating game state and sending out state snapshots to clients at each tick. However, in your Cloudflare Worker setup, the server advances the game state when it receives a `gameTick` message from a client, which means the timing of the game state updates is driven externally by the client messages. Here's why the server doesn't need to be aware of `hzMS` in your current architecture: 1. **Client-Driven Ticks**: The server relies on the receipt of `gameTick` messages from the client to advance the game state, rather than ticking at a fixed rate internally. 2. **Statelessness**: Cloudflare Workers are stateless and event-driven, so maintaining a consistent ticking interval like `hzMS` internally isn't possible without incoming events to trigger the ticks. 3. **Buffer System**: You have implemented a buffer system that queues `gameTick` messages and processes them based on their timestamps. This system ensures that ticks are processed in the correct order and at the appropriate times, based on when they were supposed to be handled, not at a set interval defined by `hzMS`. 4. **Client Synchronization**: The clients are responsible for sending `gameTick` messages in sync with the expected tick rate of the game (`hzMS`). The server then processes these messages as they come in, effectively being driven by the clients' clocks. 5. **RTT Compensation**: Clients can compensate for network latency by adjusting their tick rate slightly, as discussed previously. This adjustment is made on the client-side, and the server simply processes the ticks as they arrive. In summary, in your setup, the server advances the game state in response to client-driven events rather than running an internal game loop at a set `hzMS`. This approach is particularly suitable for the Cloudflare Workers environment, which doesn't support traditional long-running processes or timers like `setInterval`. The server's job is to ensure that it processes the incoming `gameTick` messages accurately and efficiently to maintain game state consistency and to broadcast the updated state to all clients.