This update is more technical than the previous ones. This article aims to describe what have changed and why.
When I began my journey on MultiQuest I added content in a naive approach that had the merit to get me started. I just added stuff as I needed to and early in the process I knew that I wanted to make a networked game (even my first game was networked, the code was terrible but it’s good to remember where you came from).
Therefore I created a server and a client both on the same module (it was my first mistake). The client would connect directly to the server and send/receive packets. The network architecture was pretty lame to say the least. See by yourself on the following schema:
This architecture had many flaws. First of all the security issues. Since the client and the server where in the same module, it was rather easy to decompile the executable (jar file) and to see what the server does. This process is called reverse engineering and due to the nature of Java byte code it is actually very easy to do.
If one can see how the server behave, it can look for vulnerability to exploit and degrade the game experience or worse compromise the host server.
Add to that the fact that the server was pretty much open to anyone! There was no firewall preventing access to the services running on the machine and if any of these programs were vulnerable to an attack my server would have been an easy target.
The other issue I had with this architecture was the scalability. When all the game run as a single program the only way you can increase performance is by vertical scalling which means increasing the computing power of the machine the game is running on. This solution cost you more money and is still very limited in term of scalability.
Opposed to this approach there is the horizontal scaling. Basically you connect multiples entities so that they work as a single logical unit. This is actually the standard and recommended approach used by most of the IT industry from game like World of Warcraft to website like Facebook.
My last concern about this architecture was the maintainability of the project. As the game grows and more and more stuff were added into it, separating the game concerns in sub-modules felt the way to go. The logic behind it is simple, you want to separate your game concerns, it is the same reason why people split their source code in multiples files rather than putting everything in a single one, but one abstraction higher.
After reading a lot of articles about MMORPG architecture and using my own professional experience I decided that I was going to need at least 5 servers (for now) and they will form what I refer to as the game platform: a group of servers that work as a single unit. The section below will present each one of them with their specific tasks.
The authentication server is the only server that is not a part of the game platform, instead it provide an entry point to it. Once you authenticate successfully it send you the game platform information (address and ports) as well as a token to connect to it. This also allowed me to bind the website accounts to the game accounts. It is no longer needed to register on both ends anymore. I made this transition transparent to previous users so they could retains theirs players.
The proxy server is the frontal server on the game platform and the clients can only talk to it directly. It is responsible for checking the clients token validity when they connect for the first time and it then sending messages back and forth to the platform servers.
The world server is responsible for any data that is global to the game such as the future market place for example. It also handle the character selection/creation procedures.
The game server handle everything related to the game state (entity position/state, AI, etc.)
The chat server as its name implies handle messages between players.
All the servers in the game platform can communicate with each others. For example, when you send a proximity message, the chat server needs to know about the players around you so it can forward them your message, to do so, it simply ask the game server about it.
On top of that I added a firewall that only allow an access to the services that I want to be accessible.
After a month and a half here is the result of my hard labor:
I also took this chance to write the chat server in Kotlin and it works pretty nicely.
From now on will I try to ensure that each server specialize in one field and I will delegate any heavy work on a dedicated server. For example I could add an AI server that only process heavy AI calculation and send the data back to the game server and the players but for now this seems a bit overkill, even for me.
I really enjoyed all the part of this development process: thinking about the game architecture, how the systems will communicate with each others, the database migration, etc.
I have the chance to work on every part of such a big project, from the gameplay to the AI going through the
executables deployment.
It is a lot of work for a one man army and it can be exhausting (I have a full time job and others hobbies) but it definitely worth it.
After putting that much work on the game I like to contemplate it and reflect on its current state before starting over on new tasks. I think it is necessary in order to keep my motivation and avoid to burnout.
Anyway for the next version I plan to go back on the gameplay mechanics. I want to polish some aspects of the game and also add features that are lacking at the moment such as: a party and a trading system.
I hope you learn something from this devblog. Feel free to ask me any questions/remarks by mail or on my twitter account (comments on the website are coming soon).
See you next time.