All right, so our last talk of the day is 20 years of yourbuttal.net.
I expect you from the PVPGN server and its open source ecosystem by Clemen.
Thank you.
Yeah, so I have to compress 20 years into 40 minutes, so let's get started.
So here battle is basically an unofficial work of 3 multiplayer server, so if you have a
bunch of friends, you want to play work of together, we are the place to be, I guess.
So the server was set up in 2003.
It is initially a small community in Poland.
Later we kind of became a European and global server.
So the original logo, which is on the top right, still has like a Polish and English
form sections, the major gain that is played today on our server since 2005 is Dota
all stars.
For those that don't know, Dota all stars, which gave us Dota 2, leave a glad legend, etc.
It all started on the workcraft, because workcraft shipped a word editor.
With word editor, you could create whatever maps you wanted, so minigames, tower defense maps,
hero, or in assets, etc.
And because of so many maps were created, there are thousands of them, the game is still
kind of relevant 25 years later.
So according to Google Trends, our server was most popular around 2009.
Then I checked our counter-editration numbers, and it's maybe 2013, so like 5 years
later.
But whatever, like the best year was, if you joined the server in like the evening hours,
there were like 4,000 players online, you could hop into some game lobby, find people
very quickly.
Today it's maybe a little less, much less, so 200 to 300 online people in like evening
hours.
So today it takes maybe 10, 15 minutes to find 10 different people to join a lobby.
Most statistics from our data leagues, so 2015, we had 25,000 games per month.
Then in 2020, I guess we all know why that peak is there, because people had really
logged on, had nothing better to do, and a lot of old players came back for a couple of
months.
Before 2015, unfortunately we had an accident, so I don't have the data and the culprit
might be in this room today.
These are technical stack, so the core component that we run is a BNAD demon or server.
It is also known under the name of PVPGN.
Then you have a PD manager, which is kind of a chatbot, you can ask it to host a game
for you.
It will then instruct one of the ghost instances to actually host something, so we have
them in different regions, so if you are from Asia, you can get the ghost instance from
Asia and you will have better latency to play.
Finally, there is this G-Proxy component, which stands between the game client and the ghost,
and this is a TCP proxy.
So now we will deep dive into each one of these cedar history and how they came to be.
So BNAD was a reverse engineer, implementation of the Bethelnet V1 server protocol, the initial
release in 1998 supported Starcraft, and later they added support for all the classic
Blizzard games like Diablo and of course Workraft, which we host.
Fortunately, in 2002 Blizzard opened a lawsuit against the project and took down the project.
The KJ was pretty famous, you can check a bunch of stories on Slavdoc, they are interesting
read.
Legally, it was about enforcing end user license agreements, so the wall of text that you
agree when you installed the game against reverse engineering, so they were claiming that
because you agreed to the terms you couldn't reverse engineer the game.
After this happened, the project was forked under a new name, PGM, player versus player
game network.
They added west to the online support, so now you could play Red Alert and CNC games.
When it comes to the code, it is licensed under GPLV2, initially it is a C code and later
it is supported to C++.
So a few words about the protocol itself, it is proprietary and encrypted today, the easiest way
to look at it is to open Wireshark and BNAD V filter.
Once you capture some traffic, BNAD V filter will translate the protocol, so you can look
at all the fields.
The protocol itself is documented on a community website called BNADdocs.org.
This is a very old community of reverse engineers, hackers, who were trying different
stuff, documenting every packet, trying different things, so you have the whole packet
index on this site today and you can check each packet and hit the description.
When it comes to workraft itself, there are kind of two sub protocols that it needs.
The first one is SID protocol, which implement things like chat rooms, login, etc.
The important thing to know is that once you as a player create the game lobby, you enter
a peer-to-peer protocol.
So you are no longer in the BNAD realm, all the traffic goes through the player host and
it's all within the game client, and this second part is called W3GS protocol.
So when TPUN was created, they chose a European-based coding platform, Beryllios, the
Berlin open source, which no longer exists today, it wasn't able to research, but I suspect
they chose a European-based platform because of the previous lawsuit.
The project kind of died down in 2011 because of lack of developers and lack of interest.
Then a year later, it was forked under the name of PGN Pro, this fork had quite a lot
of conductivity for the next 10 years, it stopped for years ago, unfortunately.
They added a bunch of stuff like modern C-Make, JSON config files, Lua plugins, you could
write Lua scripts and hook into various server events with that.
Unfortunately, not many unit tests were written, so something's also broke, and it is perhaps
a bit unstable, but if you wanted to run your own instance, this one is like the latest
and best version to run.
Because of some of those disabilities, we never transitioned to this fork on our server,
so we still use the old one dot 99, and we have added some patches on top of that.
The most important one is command flooding prevention, so the issue is that when
you play against someone, you could do denial of service, floods you with packets, for example,
if that player dropped, then you automatically win.
It was a huge problem, one of our former admins kind of scrambled the patch and it was
upstream later.
So original problems, as I said, players are the game hosts, so especially in competitive
delta, that's not really something you want, because your latency will depend on where
the player is coming from, how good their internet speed is, so the second demand from
the delta community was to have competitive games, so tracking player stats, having
ladders, tournaments, everything.
The final problem in the original protocol is that you can fake your username.
When you join the lobby, you can lie, you can impersonate staff members, administrators,
as you can imagine, this is not good.
So those projects were created to tackle these problems.
It is essentially a bot that can simulate player hosts, so you will deploy it on some dedicated
server or VPS, so everyone in the proximate region will have good latencies to play.
You communicate with the bot through chat channels, you can issue it commands like load
me this map, create me this game, and it will do it for you.
It can natively capture all the game events, so each kill in a dot again, each hero pick,
all the winners, all of that is collected, and it can store that in a mySQL database.
So after you have that, you can write your own websites, platforms, tournaments, whatever
you like.
For other maps, it also added some generic WVNMD protocol, so if you are a map maker,
you can emit generic key value events and go to capture that and store it for you.
Finally, how it solved the name spoofing issue, when you join again, goes towards the lobby,
you have to send it a private message.
After you do that, goes to a chat with BNFD, and ask it in which game is this player
currently supposed to be, and if there is a mismatch with this information, we know that
you are doing something funky and we teach you all basically.
So initially, the project was written in VBNF, and it was called those panel project,
done in 2008, it was ported to C++ by Trevor Hogan, and this is the main product used
today.
One interesting fork was Ghost One, which added Windows UI, so a lot of players who were
less technical like to use this one.
Support the development discussions on two different forums, one was CodeLane.com, and GhostPp.com,
decides unfortunately no longer exists today, so you can check it on on internet archive,
for example.
The code itself was in Google Code SVN repo, which no longer exists of course, and one
useful thing about the forums was that you could download pre-compiled DLLs for the
dependencies, otherwise you'd have to build everyone from source, and that was quite complicated
back in the day.
So some of these dependencies of the Ghost Project, the first one is BNCS Util.
This is a small C++ library that implemented the login sequence, which is quite complex
to implement, so most chat bots just use this one to get the login working.
We comment in this today with binaddocs.org community, it is basically feature complete,
so just basic maintenance is needed at this point.
We have GitHub releases with DLLs, RPMs, and Debian archives.
We would like to maybe push this one to various Linux distros, so it's easy to install
that's why.
The second dependency is Tomlip.
We can manage NPQ archives, NPQ archives are property formats by Blizzard for game assets
and custom maps.
Ghost needs this library, so it can read information like how many players this map supports,
and how many teams.
Based on this information, it can then construct the correct login for the game.
Finally, that is a bunch of boost components for basic stuff like threading, date time, projects.
Yeah, this is purely maintenance, I guess, because boost is continually evolving,
and maybe in the future we will get rid of some of these components,
because we have some modern C++ alternatives today.
So within our server community, two different Ghost folks kind of independently appeared.
I don't have much time, so I'll just talk about one of them.
It's called PDManager.
It was created by an independent data leak, which after a few years we merged together,
and we comb and taint this code until today.
So the problem of the original project was that if two players want to create a game at the same time,
and you have one ghost instance, they can do it.
You have to wait for the first one to start, and then the second one can reuse that instance.
Obviously, when you have thousands or hundreds of players online, that is a big bottleneck, so we need a solution.
The solution was to split the bot into two bots.
So one is a manager bot, which sits in some public chat channel, let's say.
And then we connect multiple ghost instances to this bot.
They use a UDP protocol to communicate between each other.
So when the player requests a game from the manager bot,
we'll find one of the three ghost instances and instruct it to actually host the game.
Manager also can give you information like which lobbies are currently open,
and how many players are in each lobby.
So if you see that one lobby has eight out of ten players, you can join that one,
because you know, it will fill up very quickly, and you don't have to wait as much time.
Just last year, we got some new players from Asia and South America, so we added support,
so that when you create a game, you can request a specific region for the bot.
For scoring, we have PSR scoring system.
It is kind of an ELO based algorithm scoring system.
We also enforce that you can start the game unless the teams are balanced.
So you can't have a team one that is all professionals with high scores and team two that are like noobs with low scores.
So we enforce that either you manually or automatically balance the lobby before you start.
When it comes to the code itself, we have modern CMake support today.
We have added column two and VC package for dependency resolution.
Before the original project came with a make file and Visual Studio 2008 solution file.
So compared to that, there is big progress, I guess.
We also have a Docker file and a proposed support, so you can get up and running quite fast with that.
Okay, final component is G proxy project.
So the 2000s were the age of early DSL and dial up and the connections were flaky.
One annoying limitation of the work of the game client is that if you happen to lose your internet connection in the middle of the game,
you only have like 70 seconds to reconnect.
Otherwise the game will just drop you out and you're basically done.
If you have to reset your router or anything like that, there is no chance you will do that in 70 seconds.
So G proxy found a clever way to extend this reconnection window.
So the name itself stands for game proxy.
It was developed by the same person to our home in 2010.
It is a client side binary that each player will run on their computer and it is basically a TCP proxy.
So the game connects through this binary and to the ghost distance.
The way it works is that ghost and G proxy will do a GPS protocol handshake when you join the lobby.
After that, G proxy will start inserting empty actions for each game action.
So this sounds like a big increase in packets and it is, yeah, it's an timing increase.
A practice is not really an issue, it turns out.
But why do we need these empty actions?
So when you lose the internet connection, G proxy will start feeding one empty action per minute to the game client.
This way we kind of lie to the game and keep it interested that, hey, we haven't actually quite loved the connection yet.
So this way each empty action will give us one extra minute of reconnection time.
And this is great solution, very clever, and it works.
Finally, in our fork of this binary, it turns out that if you force every player to run something or the computer, you can add a bunch of other stuff random features it with.
So the first one is that it will automatically spoof jack for you.
Instead of having to write that private message manually each time you join a lobby, G proxy will automatically spoof jack, that's the green line in the chat there.
We can also enforce that all the players that join the lobby have the same work of client version.
So usually you can miss a match patch versions, but it's not really recommended because there is a small possibility that players will go out of sync during the game and then they drop and the game is ruined basically.
We have also added some random stuff like out a login feature, so it kind of simulates key strokes to get you logged in into the game.
One weird feature is chat history, so if you press up and down arrows in chat, it works like a Linux terminal, it cycles for your chat history basically, so we have stuff like that.
Finally, let's do a live demo.
So the game itself works quite okay on wine, so I'm running here, there be a testing with wine staging on fourth and Wi-Fi so many things could go wrong, but let's try.
This is one, this is our small QT desktop client, the only reason we need this is so that it will start G proxy and game in the appropriate order and configure stuff behind the scenes to make everything work basically.
So when I click this button, it will launch the game and G proxy is secretly running as a background processor and it's listening on local forest.
So before we connect, we can check the gateway we are connecting to and we see that we are connecting to a G proxy gateway.
So this behind the scenes is Windows registry entry, you give it a gateway name and IP or DNS and in this entry there is basically just local host.
So now that we can connect all the traffic will go through local G proxy and upstream from there.
Now please everyone close your eyes.
So once we are in the battle net, it's classic UI, it's basically the same as if you joined an official server.
We just have some custom banners and stuff like that, custom icons.
Now we are in a chat room and we can ask one of our manager bots to host the game for us.
So we can do that through a private message.
Legabuse.com is the name of our manager bot and the command to load a map is dot map and we give it a name.
So today we are going to play.
It's a random custom map I like to play sometimes, it's like a dodgeball, you pick up a ball and throw it with your opponent basically that's the whole story.
So now the map was loaded and we can create a private or a public game.
So we create a private game called false them.
The game was created. Now we can enter the game list.
We can type our game name here.
So we can see the map we are playing is Magos Arena and we have 12 player slots.
If we check the chat lobby.
So this is the initiation of the G proxy handshake with ghost instance.
Then we have like a welcome message from our ghost bot.
It's in the EU region.
Finally ghost required us to spoof check and we G proxy did that for us automatically.
And we can see that the G proxy protocol was successfully established.
So now I don't have anyone to play against me, so I guess I'll just set computer to slot 2.
And we also have to change teams so that the game engine will see as a opponent and not be in the same team because otherwise we can't kill each other basically.
So now everything should be ready.
We have a 10 second countdown.
You can abort if you messed up something.
Best directions. Pretty clear. Pick up the ball.
Throw with R.
We can choose multiple arenas. We'll just go with the first one.
A few options last man standing speed killing is whoever comes to like 10, 15 kills whatever.
So because I'm almost out of time let's just go last man standing.
And after the game starts we can pick some balls and throw it.
So what's important to know here is that unless we are playing the standard strategy games here.
The computer doesn't, the game engine doesn't know how to play this specific map right.
So unless you actually code your own AI into the map, the computer has no idea that it has to pick up the ball and throw it to the right.
And yeah, I guess I'm almost out of time and this concludes my presentation.
All right, there should be some time for questions.
So thank you for your talk.
I don't know if I've missed it before, but do you handle and if so, how do you handle the host migration?
If the host changes, for example, if the host leaves?
So we actually don't because host never leaves because it's hosted by ghost and we control ghost.
Yeah, never leaves basically.
But in original protocol if the host player human host leaves, it will just negotiate a new host basically.
All right, my questions.
First off, thanks for your talk.
In the part about proxy, you say send empty actions and then if the players disconnect, you send empty packets for 60 seconds.
So what exactly is the use of those empty packets when a player does an action?
I don't think I quite got that.
So you lose connection and unless you send something to the game, it will drop you, right?
So you take one of those empty actions, which you have in reserve.
And you feel it to the game.
Basically, yeah, that's how it works.
Okay, my questions.
Maybe a little unrelated to your presentation, but how did the release of the work referee
forged impact your project at all?
Did it impact it at all or not?
Which project specifically?
The Euro Battleman.
Basically, we are only hosting work of free.
So we never hosted any other game like Starcraft or Diablo.
So yeah, without work of free, I guess, we didn't exist before work of free and we wouldn't exist without work of free.
Just follow up, but did not.
Didn't Blizzard replace regular work referee with re-forged.
So you can't get base work referee anymore, is that?
Yes, excellent question.
We are staying on an ultra patch.
We, the new remaster, they destroyed a lot of things.
The protocol is no longer compatible.
So we are basically staying on like eight year old work of patch.
That's how we did it.
All right, my questions.
All right, then I guess we are done.
So thank you.
Thank you.