Architecture
Our game servers are hosted on a dedicated Ubuntu server in Canada, rented through SoYouStart. In order to configure and manage our game servers and various community bots, we utilise Pterodactyl.
Pterodactyl runs all of our game servers in isolated Docker containers. We can then manage these game servers through the Pterodacyl UI panel, as well as the SFTP access it provides.
We use two BungeeCord servers, referred to as our Proxy server, to connect several servers together. These Proxies makes maintaining our whitelist easy across all these servers, and Proxy 1 plays an instrumental role in the Resource World experience. This is explained further below.
While all these servers sit alongside each other, the diagram below represents the visual hierarchy that takes place.
While detailed here in their own section, these bots are hosted and managed via Pterodactyl much like our game servers. In fact, for Pterodactyl and Docker there is almost no functional difference between a game server and a bot. Hosting these bots via Pterodactyl helps to keep most staff applications managed through a single functional UI.
We run bots on our dedicated server for the following use cases:
-
Applications bot
- Posts server applications in an #applications channel, sends whitelist command to our servers.
-
Modbot
- An IP sharing, FAQ posting, ping checking, timezone converting, server restarting, reminding (and plenty more!) bot.
-
Emoji Roles bot
- Assigning roles when reacting to certain messages, as seen in our #welcome channel.
-
Playerlist bot
- Handles checking player count and player statuses across Survival and Resource servers when !playerlist is used in #ingamechat.
-
Snacker/Inactivity bot
- Posts Etho-themed welcome messages in #general. Assigns member the Inactive role if they do not speak in the Discord for three weeks.
-
Music bot
- Plays YouTube and Soundcloud songs in our voice channels, utilising a publicly available bot.
Our proxy servers handle connections to all other game servers that sit 'below' them in the hierarchy.
Both Proxy servers utilise a shared set of MySQL databases for a number of use cases:
-
Whitelist database
- Writes to this database to whitelist new players.
- Reads from this database to authenticate connections.
-
AdvancedBan database
- Reads from this database to prevent banned members connecting.
-
LuckPerms database
- Reads from this database to synchronise permissions across the Bungee network.
-
PremiumVanish database
- Reads from this database to synchronise staff members vanished status across the Bungee network.
For all of our databases, phpMyAdmin provides a useful web interface for access and administration.
Our main network handles the survival and resource world, and collectively is considered to be our "Main" server.
In addition to the Proxy Databases, we use more MySQL databases in the main network for the following use cases:
-
Resource World Gatekeeper database
- Writes to this database to save entity data before transferring servers
- Reads from this database to load entity data upon transferring servers
-
CoreProtect database
- Writes to this database to log player progression and history
- Reads to this database to restore previous server data
-
Plan database
- Writes to this database to log player analytics
As noted in the diagram, the Resource server does not interact with the Survival server directly, and vice versa. Players transferring from one server to another will go via the Proxy. The same is true of chatlogs too - note that messages are also not sent from the Resource Server to #ingamechat directly.
While the above diagrams are broken down for easy visual reference and explanation, below is the complete network of all technical aspects of our community servers. Please note this is for completeness, rather than acting as aesthetic or extensive documentation, but should you have any questions feel welcome to ask us directly.
Rendered with Diagrams by mingrammer