You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|[agones](https://github.com/BlueDragonMC/RPC/blob/master/src/main/proto/agones.proto)| Interacting with the Agones SDK | Agones SDK |
@@ -18,80 +28,135 @@ In production, BlueDragon runs in a [Kubernetes](https://kubernetes.io/) cluster
18
28
|[server_tracking](https://github.com/BlueDragonMC/RPC/blob/master/src/main/proto/server_tracking.proto)| Updating available instances on each server and their current states | Puffin |
19
29
|[service_discovery](https://github.com/BlueDragonMC/RPC/blob/master/src/main/proto/service_discovery.proto)| Finding an available lobby for a player to join | Puffin |
Inbound messages are messages received from other services in the cluster.
23
35
24
-
To receive messages, each game server starts its own gRPC server on port 50051. This port is exposed to other services in the cluster.
36
+
To receive messages, each game server starts its own gRPC server on port 50051. This port is exposed to other services
37
+
in the cluster.
25
38
26
-
Every game server's gRPC endpoint should implement all services which have "Game server" in the "Implemented By" column of the table in section 2.1.
39
+
Every game server's gRPC endpoint should implement all services which have "Game server" in the "Implemented By" column
40
+
of the table in section 2.1.
27
41
28
42
*See the [BlueDragonMC/RPC](https://github.com/BlueDragonMC/RPC/) repository for all of BlueDragon's proto files.*
43
+
29
44
### 2.3: Outbound
45
+
30
46
Outbound messages are messages sent from a game server to other services in the cluster.
31
47
32
48
To send messages, a gRPC client should be set up on each game server.
33
49
34
-
Game servers can send messages to (and expect RPC responses from) all services which have "Puffin" in the "Implemented By" column of the table in section 2.1.
35
-
The IP address of Puffin can be found because it is exposed as a Kubernetes service. The DNS name "puffin" should resolve to an existing server address. Puffin uses port 50051 for its gRPC server.
50
+
Game servers can send messages to (and expect RPC responses from) all services which have "Puffin" in the "Implemented
51
+
By" column of the table in section 2.1.
52
+
The IP address of Puffin can be found because it is exposed as a Kubernetes service. The DNS name "puffin" should
53
+
resolve to an existing server address. Puffin uses port 50051 for its gRPC server.
54
+
36
55
## 3: Database
56
+
37
57
### 3.1: Database Internals
58
+
38
59
BlueDragon runs [MongoDB](https://www.mongodb.com/), a document database with no rigid schema.
39
-
In the Kubernetes cluster, it is made available under the `mongo`[service](https://kubernetes.io/docs/concepts/services-networking/service/), so the hostname `mongo` should resolve to a valid MongoDB server address.
60
+
In the Kubernetes cluster, it is made available under
61
+
the `mongo`[service](https://kubernetes.io/docs/concepts/services-networking/service/), so the hostname `mongo` should
62
+
resolve to a valid MongoDB server address.
40
63
The service should be available on port 27017, the default MongoDB port.
64
+
41
65
### 3.2: Player Documents
66
+
42
67
Each player has their own document in the `players` collection of the database with the following fields:
68
+
43
69
*`_id`: The UUID of the player, represented as a string.
44
70
*`username`: The username of the player. Updated whenever the name changes.
45
71
*`coins`: The number of coins the player has.
46
72
*`experience`: The amount of experience the player has.
47
-
*`punishments`: A list of punishments that the player has. Punishments are not removed from the list when revoked or expired.
48
-
*`type`: A string from the following list: `BAN`, `MUTE`.
49
-
*`id`: A UUID (represented as a string) that uniquely identifies the punishment.
50
-
*`issuedAt`: The time the punishment was issued, represented as a Unix timestamp (milliseconds after Jan 01, 1970, 00:00:00 GMT)
51
-
*`expiresAt`: The time the punishment will expire/has expired, represented as a Unix timestamp (milliseconds after Jan 01, 1970, 00:00:00 GMT)
52
-
*`moderator`: The UUID of the player which enacted the punishment.
53
-
*`reason`: A short string description of why the punishment was enacted, provided by the `moderator`.
54
-
*`active`: A boolean representing whether the punishment is currently effective. If set to `false`, the expiration should not be considered. If set to `true`, the expiration should still be checked. Expired punishments will never be active, even though this field may be set to `true`.
73
+
*`punishments`: A list of punishments that the player has. Punishments are not removed from the list when revoked or
74
+
expired.
75
+
*`type`: A string from the following list: `BAN`, `MUTE`.
76
+
*`id`: A UUID (represented as a string) that uniquely identifies the punishment.
77
+
*`issuedAt`: The time the punishment was issued, represented as a Unix timestamp (milliseconds after Jan 01, 1970,
78
+
00:00:00 GMT)
79
+
*`expiresAt`: The time the punishment will expire/has expired, represented as a Unix timestamp (milliseconds after
80
+
Jan 01, 1970, 00:00:00 GMT)
81
+
*`moderator`: The UUID of the player which enacted the punishment.
82
+
*`reason`: A short string description of why the punishment was enacted, provided by the `moderator`.
83
+
*`active`: A boolean representing whether the punishment is currently effective. If set to `false`, the expiration
84
+
should not be considered. If set to `true`, the expiration should still be checked. Expired punishments will never
85
+
be active, even though this field may be set to `true`.
55
86
*`achievements`: TBD - Not implemented
56
87
*`cosmetics`: A list of cosmetics which the player owns. Non-equipped cosmetics are included in the list.
57
-
*`id`: A string identifier for the cosmetic
58
-
*`equipped`: A boolean representing whether the player has the cosmetic equipped or not.
88
+
*`id`: A string identifier for the cosmetic
89
+
*`equipped`: A boolean representing whether the player has the cosmetic equipped or not.
90
+
59
91
### 3.3: Database Behavior
92
+
60
93
* Every time a player log in to a game server, their player document should be fetched using their UUID.
61
-
* If their username does not match the name in the document, it should be updated to reflect the username change.
94
+
* If their username does not match the name in the document, it should be updated to reflect the username change.
62
95
* Map data should be lazily fetched for a map when it is loaded.
63
-
* Player documents are fetched by other services (mainly Puffin) to look up players' metadata. This is typically just their usernames (UUID <=> username conversion) and name colors for display in chat.
96
+
* Player documents are fetched by other services (mainly Puffin) to look up players' metadata. This is typically just
97
+
their usernames (UUID <=> username conversion) and name colors for display in chat.
98
+
64
99
## 4: Server Behavior
100
+
65
101
### 4.1: Proxy Connection
66
-
Every game server is connected to at least one proxy. Connections are registered/handled by the proxies, but player information forwarding must be setup.
67
-
The server receives a Velocity forwarding secret using the `PUFFIN_VELOCITY_SECRET` environment variable. If this is present, Velocity modern forwarding should be enabled using the provided secret. If not, Mojang authentication (online mode) should be enabled.
102
+
103
+
Every game server is connected to at least one proxy. Connections are registered/handled by the proxies, but player
104
+
information forwarding must be setup.
105
+
The server receives a Velocity forwarding secret using the `PUFFIN_VELOCITY_SECRET` environment variable. If this is
106
+
present, Velocity modern forwarding should be enabled using the provided secret. If not, Mojang authentication (online
107
+
mode) should be enabled.
108
+
68
109
### 4.2: Lobbies
110
+
69
111
Each server has at least one lobby, which is initialized on startup.
112
+
70
113
### 4.3: Agones Integration
114
+
71
115
When a server starts up, it should contact its local Agones gRPC or HTTP server and send a "Ready" request.
72
-
Periodically, health pings should be sent to the same endpoint. If they are not sent, the server will be shut down due to a health check failure.
116
+
Periodically, health pings should be sent to the same endpoint. If they are not sent, the server will be shut down due
117
+
to a health check failure.
118
+
73
119
### 4.4: World Loading
120
+
74
121
Worlds are currently stored in the Anvil format and mounted into each game server's container.
75
122
The directory structure looks something like this:
123
+
76
124
```
77
125
/
78
126
server/
79
127
worlds/
80
128
game_name/
81
129
map_name_1/
130
+
level.dat
131
+
config.yml
132
+
region/
82
133
other_map_name/
134
+
level.dat
135
+
config.yml
136
+
region/
83
137
other_game_name/
84
138
map_name_1/
139
+
level.dat
140
+
config.yml
141
+
region/
85
142
other_map_name/
143
+
level.dat
144
+
config.yml
145
+
region/
86
146
```
147
+
87
148
### 4.5: World Configuration
149
+
88
150
Each map can have a `config.yml` file inside the Anvil world folder with a few keys.
89
151
All map-specific keys are namespaced under the `world` key.
152
+
90
153
*`world`: (the parent key)
91
-
*`name`: A display name for the map
92
-
*`description`: A short description of the map, shown to every player at the start of the game.
93
-
*`author`: A string with the names of the map's builders.
94
-
*`spawnpoints`: A list of spawnpoints for the map.
95
-
* Each spawnpoint is an array of numbers with the format: [x, y, z, yaw, pitch]
96
-
* The numbers may be integers or doubles. It is the responsibility of the client to convert the numbers to the correct format (usually Double).
97
-
*`additionalLocations`: Each map or game may define additional locations. This field is a list of lists of coordinates. The coordinates are in the same format as above.
154
+
*`name`: A display name for the map
155
+
*`description`: A short description of the map, shown to every player at the start of the game.
156
+
*`author`: A string with the names of the map's builders.
157
+
*`spawnpoints`: A list of spawnpoints for the map.
158
+
* Each spawnpoint is an array of numbers with the format: [x, y, z, yaw, pitch]
159
+
* The numbers may be integers or doubles. It is the responsibility of the client to convert the numbers to the
160
+
correct format (usually Double).
161
+
*`additionalLocations`: Each map or game may define additional locations. This field is a list of lists of
162
+
coordinates. The coordinates are in the same format as above.
0 commit comments