An application is the top level namespace for the game server you are developing. For example, if you are developing two games, Uno and Poker, you would have two corresponding applications for them.
You would also create an application if you begin developing a new major version of your game, for example PokerV2 which is a rewrite.
All the entities below are scoped to a particular application.
A deployment represents a version of your application. It consists of:
- A build of your game server
- Deployment configuration pertaining to the build
Deployments are versioned, so the first deployment you create will be version 1, the next will be version 2, and so on. Whenever you create a new room, it will use the build and configuration from the latest deployment. Pushing a new deployment doesn't affect existing rooms in progress and only applies to future rooms, thus providing simple no-downtime upgrades.
A process represents a runtime instance of your game server. In Docker terminology, a process is equivalent to a Docker container. A process includes:
- The deployment version it's on
- The host and port that it's bound to
- A starting, running, idle, or terminated status
Hathora Cloud provides logs and CPU/memory metrics for processes so you can monitor and debug your game servers. Hathora also tracks active connections to processes and automatically spins down processes that are idle for longer than five minutes.
A room represents a game session or match. The
roomsPerProcess deployment configuration parameter governs how many rooms can be scheduled in a process.
If your game server only supports running a single match per server instance, you should set
roomsPerProcess to 1, and for your purposes you don't need to think about the distinction between a room and a process.
On the other hand, if your game server supports running multiple matches concurrently in the same instance (e.g. you're using something like Socket.IO), you can set
roomsPerProcess to a higher value and Hathora will schedule multiple rooms in the same process. Rooms scheduled on the same process will share the same host and port for connecting, and your server must be able to distinguish network packets coming from different rooms.