Game Servers
To provide as flexible of a system for managing game servers, Redwood introduces several terms and database tables/models.
GameServerProxy
GameServerProxy
is an abstract representation of virtual world. When you want to "list the available games" or create a session, you are interfacing with the GameServerProxy
most likely. This database table/model stores any associated world data, game mode/map details, and access configuration (e.g. public/private and password).
A GameServerProxy
can only have 1 active GameServerCollection
at a time, but that collection may shutdown and a new one started later so the GameServerProxy
does have access to all prior collections.
GameServerProxies don't always need to have active game servers running to be listed as an available world to join; if someone requests to join it and there is no active GameServerCollection
, Redwood will start one with all the detail stored in the GameServerProxy
database entry.
GameServerCollection
GameServerCollection
is a collection contains 1 or more GameServerInstance
references. It represents the entire backing GameServerProxy
for a duration of time, including all of the zones and shards. The GameServerCollection
can be stopped/archived, which stops the associated server instances, but the associated GameServerProxy
doesn't necessary stop/end unless it's configured to do so. A GameServerCollection
isn't started again after it's stopped; a new one is created instead.
GameServerInstance
GameServerInstance
is a direct representation of a running game server instance/executable. It serves a single shard for a single zone (collectively identified in the instance's channel
database field). It has the associated connection URI stored in the connection
field (after it has become available post startup). It also has a providerId
field which stores the ID for the associated backing game server provider (e.g. Agones or Hathora). For example, if you're using Hathora, the providerId
is the associated Room ID.
GameServerContainer
GameServerContainer
is not often used directly, but it represents a virtual container (typically a Docker Container running on a Virtual Machine). Currently, only 1 GameServerInstance
can run in a single GameServerContainer
for Unreal games, but it's possible to add support multiple instances in a single container by using Unreal's FForkProcess
. After forking, each of those OS process would have their own port and Unreal game server, but running in the same virtual container. Redwood doesn't have any examples currently of this, but it's theoretically possible. GameServerContainer
also has a providerId
field which stores the ID for hte associated backing game server provider. For example, if you're using Hathora, the providerId
is the associated Process ID.