Hi there, my name is Kristoffer Blasiak, and I’m the CEO and Lead Programmer at Rigid-Soft.
I just wrote a document, detailing what I learned after months of hard work on a project called “Lifeless”, which is a full MMO. Fully made in Unity. It’s actually gotten to the state where you can actually call it a MMO, because it’s just that. Not a couple of demo scenes slapped together, no it’s a fully functional MMO.
The original purpose of this document was internal use, but I figured that more people could learn from it than our internal teams, so I am posting it here for anyone to learn from.
The document covers a lot of topics, ranging from what our internal server architecture looks like, to what shortcomings we found in Unity, and how we fixed them, to the tools we used for things such as patching.
I’ve been writing an FPS, not an MMO, but this was still a nice little read.
Thanks for taking the time to write this up! I especially liked how you tried as hard as you could to make it look like you weren’t completely dissing the standard Unity networking workflow, even though you were.
Thank you I was interested in what you did for networking and you gave very nice detail. Good read, bookmarking for future.
Did you guys look into other networking solutions before writing your own on top of Unity? If so, can you elaborate? Did you look into photon networking etc? Thanks
Not making an MMO myself but interested in the topic
Thanks! Yeah I try to be fair to Unity, the groundwork is good, but once you get into more advanced topics, it gets a little different.
Thank you :).
We evaluated other solutions, and no other solution really gave us the stability and scalability we wanted.
There are other very good solutions, but we felt that the idea of having a third party developer do something as important as the networking in the game itself was a too big of a risk for us to take. So we took the hit and made our own.
Furthermore, a lot of the networking solutions are closed libraries, and we don’t want to fix someones elses library, and then still have to pay a license fee for it.
As well as the simple fact that some of the things we want to do, are not supported by these libraries.
Fantastic! Eventually, you may run into issues with Dead Reckoning - the bobbling, jittering, warping you get with 3-5 updates per second. If you do, you might find my chapter, ‘Believable Dead Reckoning for Networked Games’ (in Game Engine Gems 2) useful.
Gigi
PS - PM me with email address if you want a PDF of the chapter
I have been experimenting with a lot of the same approaches as you guys have been through and technologies you are using, so it’s a nice verification to see others use some of the same methods. Can’t wait to get through the entire document and learn from it.
From what I can tell you haven’t even released the games alpha yet. I think that makes it a little too early to say you have successfully built an MMO.
The game has been in closed Beta for a while now, they are adding some polish and doing the marketing ground work. Myself and Hippo have assisted in this project, whilst 99% of the work was done by the lifeless team it was good to see how it all came together and assist in any way I could.
Allow me to rephrase, the architecture presented seems to define something that would work for a large multiplayer FPS with some persistent state. I would be quite surprised if what presented can handle thousands of real players in the same persistent world.
I see use of JSON which is small compared to XML but massive compared to a custom binary format, I see a single MySQL server. How is the data shared between game servers? Is there a distributed cache of some kind? Surely a database round trip is too slow for gameplay decision. How do players move between servers, or does one Unity Game Server impose the limit on number of players per “world”? etc
I think maybe the definition of MMO changed in the last few years to mean anything with persistent state and more than few players.
EDIT: Not to say that this isn’t a great achievement, just a personal peeve of mine about what gets called an MMO, particularly with all the people selling “MMO kits” that really aren’t.
I’m surprised there isn’t a decent MMO backend kit. Something with login, database, and client infastructure already established. I know there are services like Photon, but you still have to setup the networking for it. Considering the vast amount of other assets that cover game design, I figured it would only be a matter of time before some full scale solutions pop up.
Yes, so it’s exactly as you stated, a Multiplayer FPS with persistent state, and the game servers hold around 25-100 players each :).
But please keep in mind that a MMO doesn’t neccessarily mean 1000 players per server, rather the fact that you can play with hundreds of other players, together, not that the hierarchy in itself has to handle 1000 players within the same exact area.
Once you join a Game Server, you play on it until you leave, you don’t jump between them. Which is how the database question you asked is handled.
It has all the normal traits of a MMO you would expect, Quests, Achievements, Groups, etc. The only difference being that you play on smaller servers.
The only thing differentiating us between a traditional MMO (from a player perspective) is that you play on a slightly smaller scale. But you can switch servers any time you want, and your items and progress will load into any server you choose. So I would still argue that you can classify us as a MMO.
I would think this is a risky path (as the person selling), also you’ll end up with too many people that expect you to make most of the game for them, and they just add the fun parts. So you’ll end up with a bunch of 12 year olds that rage at you for making something too complex for them to understand :).
Perfect answer, I’m still stuck in the old school of believing MMO to mean thousands of players interacting in the same world, and I don’t want to change!
I have to say, that I actually agree :).
We wish we could make something like that, we just don’t have the knowledge and resources to pull it off (which we were well aware of, so we knew the scope of a project we could pull off, and did just that).
We understood how far we could push it, and still make it. So we decided on smaller world, and splitting up players into smaller chunks, to keep it more manageable. While keeping the internal structure open to actually support bigger worlds in the future :).
Completely disagree. A lot of complex assets are on the store, including NGUI, A*, FPS Control, and more. The point is to make assets that reduce the time and work of other developers in exchange for money. If everyone was too afraid to publish because some people might email them, the asset store would be empty.
Will kids who haven’t written a single line of code expect to make WoW v2? Sure. Asset publishers don’t have to help them with anything outside the scope of the asset. If nobody understands how to use the asset, then it’s a poor asset.
@Justei do you know if some of the tips you provide in your document could also apply to Photon Unity Networking?
I am currently working on a Multiplayer RPG MOBA-style Game using Photon Unity Networking. While the Game Sessions will Only consist of probably 3 vs 3 Players, I also have tons of NPCs (mobs) in a single world (game instance). I found that the one thing that was consuming the most resources and killing our FPS was the Movement Scripts of our NPCs. We have since Optimized it, but I believe there is probably much more we could do to optimize the updates. Such as not sending messages to Players about NPCs on the other end of the world, which I think currently that’s still happening. I’m wondering if we could apply some of the same techniques from your document into our game. Note I didn’t fully review it only briefly reviewed it just now and thought it was interesting and something we could learn from.
By the way… When is Lifeless going to be Released? Seems Awesome! I want to Play it! or Beta Test it, Sign me Up!
