October 26, 2026
ALPHA
Good morning beautiful people. After the success of our previous matchmaking post and then the similarly well received postmortem I decided the next server team blog post should probably introduce the server team to you, what we do, how we do it. All that good stuff.
It has come to my attention that the "mono a mono" I used in my matchmaking post which I thought to mean "one vs one" actually means "monkey vs monkey". I am sticking with my choice of words so MM now means "Monkey vs Monkey".
The server (also called "Teiserver" as the name of the program) is a program you interact with via Chobby. It handles user login, messaging, listing lobbies, joining lobbies, changing lobbies, lobby balance and game rating changes to name some. There's a whole load of webpages on it too, these include things like moderation reports, user management, metrics (so far line does go up most of the time) and more.
When I first joined the project as a player we used something called Uberserver and I decided I could do better. I made "Teiserver" and then a few months later we swapped over to it.
As with almost every part of BAR the server is open source and you can view the source code, issues and pull requests on github.
A server is nothing without the team to develop and maintain it; Teiserver is no exception. While we have large selection of occasional contributors we also have 3 core team members. Two of us (Myself and Lexon) are employed by BAR to develop the server in a professional capacity and with the responsibility that comes with that. BlackMelon volunteers a huge amount of time and effort focusing mostly on the new Tachyon protocol (more on that in a moment).
It is worth noting behind the server team is an infrastructure team handling things like the servers themselves. The three mentioned here are just one part of a larger group making all this work smoothly.
The protocol is sort of the language your game and the server use to communicate, it's how you can request a list of lobbies and send/receive chat messages. Tachyon is a new protocol we (Server and Client teams) have been developing for BAR which will allow us to do things we're not able to with the existing protocol. The new client uses Tachyon and is part of what will allow us to bring in things like matchmaking and scale to a Steam release.
As mentioned above, the SPRING protocol doesn't allow us to scale the way we need to so we have been working on something better. That something is Tachyon and Lexon's focusing primarily on that.
The other side of the scaling process is taking the server from one box to multiple boxes.
In both cases the name here is just the primary developer, both of us are supported by a wider team and neither is working alone.
A server release is when we update the server with a newer version of the software. Typically we've added a new feature, improved something or fixed something. To do this we compile the code, send it to the server and then tell the server to use the new version. It is slightly more complicated than I've suggested here.
The release process means we have to disconnect all players (and lobby hosts) from the server when we do the release. We want to improve the situation and make it so this is one day not the case.
We sometimes get asked what we changed, where are the patch notes or changelog? The server handles a lot of behind the scenes work, the vast majority of changes are completely invisible to players so we typically only announce changes when they are player facing.
For those who are especially interested you can always inquire in or look at the commit log in github. We try to maintain informative and useful commit messages though they are intended for a technical audience.
Finally we come to the most important part of a Beyond all Reason Server release. The pet picture. No server release is complete without one, I have 4 cats and a dog; I have family members with their own pets and I am trying to bully the admin team into buying Lexon something too.
While we've not hit it in a while, if we get another sudden influx of players you may notice there is a queue to login when things are getting popular. This is 100% a server limitation. We have taken a lot of steps to increase the number of much as possible but it's a bit like a Jenga tower. If we push too hard then you don't just lose a few blocks (players), the entire tower (server) comes down.
The root cause is mostly the SPRING protocol we're using. It was designed over a decade ago for a project with maybe a few dozen people online at once. Unfortunately that means it doesn't scale well. This is one of the biggest pieces of work we are handling as part of our planned Steam release.
For those saying "get a bigger server", that's one of the things we have done a few times but the issue is exponential nature. Doubling the players at minimum doubles the messages sent by the server.
Short answer, it's not. The server is a single point of failure and if the server throws a wobbly then everybody will feel it. It's important to note that a (until now) volunteer built server is able to handle approximately 4,000 games, 40,000 messages (lobby, direct, game etc), 20,000 logins and more every day.
The biggest problem is when a bug reappears frequently; we recently had an issue caused by a change in discord bot rules which caused repeated restarts. Each time it would appear to players that the server was stable again before everything disconnected again. These are few and in nearly all cases have an external cause.
The vast majority of the time everything is going smoothly and the server sits invisibly in the background. If we do our jobs well it looks like we didn't do anything at all; if we make a mistake then everybody knows about it!
Why go to all the effort of making something work across a network of computers when we could just get a bigger computer? First off, at some stage it becomes cheaper to put the effort in to write multi-node software than get a bigger computer. We're expecting to hit that as part of the steam release. There are other advantages though, we may be able to do some updates to the server without interrupting things.
Lots of people want to help with the server and join team. The developer experience has improved over time though if you don't already know Elixir then we suggest checking out something like elixirschool.com to get the basics down. The language itself is fairly small and regarded as fairly easy to learn.
The best idea is to clone the Teiserver repo and then follow the local setup and development guides to get everything ready.
After that I would suggest finding a good first issue and taking a shot at it. We're not expecting new developers to land the perfect PR first try and we try to be as supportive as possible so don't be afraid to ask questions.
I hope this has been an interesting read. As always if you have questions please feel free to ask in the teiserver channel.
