Dani's Race was supposed to be a straight forward sequel to
Moria's Race, but in a game form. The GTA Clone aspect of it was chosen due to Moria's Race already having a city built for it, which could be simply repurposed into being a game world. That was the whole idea in the beginning. Make an open world game that continues the story of Moria's Race. But then, people got to play it. One thing led to another and on
July of last year the game got the first implementation of Multiplayer.
The multiplayer, or the lack there of, at the moment is so utterly broken and so lacking of being properly made that for a long time, I was just not bothering with it. Seeing it as something unnecessary. Something that does not need to be touched, because other things, like the story or some gimmicky thing is more important for the game than the multiplayer. But people's demands for it didn't stop. So I thought now is a good time to actually properly design it.
Dani's Race version 2025-03-17 ( which is currently under petition ) will have probably the most broken multiplayer experience to date. I was trying to maybe fix the broken stuff I have at the moment, but that just made me realize that a good rewrite is very needed and it's needed right now.
As you maybe know, this website blenderdumbass.org is hosted using my own custom made server software called
BDServer. I thought that using the same type of server would be a good idea for, what is essentially, a racing game. I thought that spawning a simple stupid JSON API HTTP server would be enough for a fast paced multiplayer experience. Let me tell you that: it is the worst possible decision I could ever make.
HTTP is the protocol that powers the net. It is very useful for so many applications. Websites use HTTP because it is very convenient for basic things like websites. For example: When you type blenderdumbass.org in your browser, your browser connects to my server. And my server does all it needs to do to render an html document of the page. And then it will send it to you. But there is a catch. That html document will also contain links, to other things: The CSS file, or the theme of the website. Which is a separate request to the server I made. Then your browser will separately download every single image that is used for various things on the web-page. Like the little icons on the button. Or the thumbnails of the articles. All of those are separate connections to the server. Separate, almost unrelated requests.
I thought that a similar mentality could be used for a multiplayer server for a game. Instead of url requests, the client software will be sending JSON formatted data. And instead of html documents and images, it will receive back more JSON formatted data. So for example, when you join a game, the game will send something like:
{"username":"blenderdumbass",
"room":"Game",
"userId":null}
The server will receive it, read it, and due to
userId
being
null
it will assign a random string of characters as the
userId
which it will send back like so:
{"userId":"8dhj579fn30djk86"}
This
userId
will then be used to identify that any further request comes from the same player. So for example if suddenly location data comes in and the
userId
is
8dhj579fn30djk86
, the server will understand that this player changed position in the game. And will know to queue this information to send it to any other player.
In theory this could have worked. It would totally work for non-time critical games. Like if somebody is playing chess or something. That would have been perfectly fine. But Dani's Race is a racing game. And not just that, it has a lot of stuff in it. It has breakable cars. Meaning you don't only sync the location and rotation of a car, but also the health of every single breakable part on it. Cars could be upgraded with nitro and body parts. Those need to be transferred too. And also people can get out of the cars. And get into any other car. So players should be able to switch between cars. Making a need for the server to keep track of it, so it knows who to send what update information to.
And while all of this is technically possible with enough data in the JSON payload. The amount of it becomes a problem. See, HTTP servers are easily DDos-able. Every request that comes in, needs to wait for the server to be not busy, in order to go through. So if two players are trying to send their data simultaneously the server will pick one of them, do all it needs to do, send the response. And only then start dealing with the next one. Now imagine 10 players. Each sending the entire world full of updates to the server. And receiving 9 times that amount. Just to describe one car you need to have like 1 KB of data when it is in JSON. This is not much, but when 10 people with various internet speeds are competing for attention from one poor server. The experience of playing that game will not be good.
The obvious first thing that I immediately started thinking about dealing with was that amount of data. You don't need the entire payload if the payload is the same each time. You only need to send the changes. Maybe have a full on update once every so often to be sure. But for example, if the car's color stays red for the entirety of the race, why does the server needs to constantly be reminded of that the car is red? So I started changing the code of the server a little bit to accommodate for this reduction of data. But then I realized that it will need to be a major change to the server.
I thought about it and decided that I better start from scratch and think everything through. So I started a
project to develop a server thingie, which is not some stupid HTTP. At the moment I'm using direct TCP connection with each player. And keep that connection for the entirety of the game. It is not yet fully working. But I believe it should be much better than having to compete for attention.
I guess this will be the end of my rant. I'm a bit tired and I want to go do something else. So I will remind you again that
Dani's Race version 2025-03-17 is currently under petition. To sign this petition you need to follow
RowdyJoe on Mastodon. The reasons for that are in the petition page. Thank you very much. And...
Happy Hacking!!!