We’re on the run up to our 2-year anniversary of taking over the development of WISP, and we’ve been hard at work behind the scenes on a long overdue major update 🌴
Recently, we’ve been on a war path of optimizing backend infrastructure & improving reliability, ripping out (far too many) legacy systems & replacing tech debt, and formulating a new vision going forwards for how the administrative process and user experience of a game panel should work.
We’ve decided that it’s time to shake things up and make some necessary breaking changes to pave our path forward. There’s a lot of features we’d be unable to ship without a major update and some breaking changes. For a TL;DR on what happens next, what’s breaking and what you need to do, feel free to scroll to the end.
TODO
TODO
Nests were always a fun little way to organize… eggs. Ha-ha. But that’s kind of all there was to it. Nests were merely a way to group eggs, and didn’t really fit into the wider ecosystem of games we have today: what nest should I put Hytale under? Windrose? DayZ? There’s a lot of games now that don’t really fit into any particular nest, and it stood out to us that this feature is mostly redundant.
We rarely used nests to activate specific features, outside of mainly just knowing how to query the number of players on the server, which was unclear, and hacky. More on that later.
We decided Nests need to go. We discussed what would be a useful replacement, and decided it’s time to introduce a Tags system.
For a game panel built to be automated and talk to a billing system, the node deployment system as it stands is… incomplete, and a lot of what was implemented felt like an afterthought, with some poor design decisions and rushed, redundant functionality implemented in all those years ago. From the WHMCS module to the panel itself, this functionality needed some critical rethinking.
🏷️ Firstly, tags have opened up a lot of new functionality here, and closed a lot of missing gaps. Moving forward, tags are going to be the first-class strategy for how we handle automatic node deployments.
By attaching tags to nodes, you can specify what kinds of eggs are allowed to be automatically deployed to each of your nodes. That means you can have game-specific nodes, whereas previously the idiomatic way of doing this was by making a “Location” for each of these groups. This was semantically wrong, and when building the Egg Switcher, we realized this was going to bite us in the butt; the Egg Switcher relies heavily on automatic node deployment rules and policies, so Tags were a must for shipping the Egg Switcher.
The concept of “allocations” in relation to eggs is entirely disjoint as it stands, despite them actually being deeply intertwined. Let’s take Rust as an example. Rust uses a whopping four ports, which must be passed down to the game’s config to define: the game port, the query port (for Steam A2S queries), the RCON port, and the Rust+ companion app WebSocket port. This highlighted some high-friction issues with our current concept of eggs:
These gaps in what an egg can express led to some complicated and fragile setups in terms of automation, e.g. WHMCS. It also meant that we could not faithfully ship the Egg Switcher without shipping something that would just lead to tickets from customers who need a specific number of ports, and worse yet, where to even put those ports in their respective configs.
We have closed this gap entirely by moving the responsibility of port allocations to eggs. Eggs are now able to express, “I need this many ports, and I need these startup/environment variables populated with those port numbers when I boot up.”
We’ve also made it so that allocating a port to the QUERY_PORT environment variable automatically tells Gamedig which port to query on.
TODO
TODO
TODO - talk about component classes in html, possible future plans for better extensibility + perhaps even addons