How feasible would it be to implement MMO server on JVM?

Hi, I’m thinking about options for writing a multi player server, and I wonder how much work it would take if I was to use Java/Scala without running Unity on backend.

The game will be something like Second Life, so it doesn’t feature fast paced actions. But there can be complex interactions that might involve rigid body physics.

So, how much work would it take if I’m going to write a multi player server for such a game on JVM without Unity, and what sort of obstacles I can expect in the process?

I’m moderately familiar with writing distributed network applications, so building and deploying a distributed cluster itself is not really a concern for me. But I’m not sure about things like dealing with physics or compensating for lags, and etc and I wonder how difficult it would be to implement these things from scratch without running Unity on the server side.

All I can imagine at this point is that I might need some sort of a headless game library(like libGDX) and somehow load Unity’s assets into it to create collision shapes then use something like Java port of Bullet or ODE to calculate their interactions before sending the result back to the clients to synchronize.

So, I’m wondering is it even feasible for a single hobbyist to achieve? And if so, what would be the best approach to achieve that?

Any kind of input would be appreciated. Thanks!

A lot of work.

You’d need to deal with raw packets instead of UNET’s abstractions like SyncVars.
If you want to use LLAPI then you need to call the DLL functions from Java, that’s difficult.
If you don’t want to use LLAPI then you need to deal with TCP/UDP yourself, that’s very difficult.

If you want physics then the server needs to know about the map, rigidbody sizes, speeds, etc. - so you’d have to export those out of your Unity project and import them in Java.

Depending on your skill set, that sounds like at least half a year of work for just a basic prototype, and implementing more features will be a huge pain. Hence why so many Indie MMORPGs fail - it just becomes too much work.

Compare that with using UNET. The server and client are one project. They share 90% of the code.
My uMMORPG asset uses about 5000 lines of code for a huge amount of features like monsters, skills, items, equipment, npcs, pvp, pve, chat, etc. Pretty much an MMO alpha version, with 5000 lines of code. You’d need that many lines for just the importing/exporting part in your Java setup.

It’s definitely not stupid to do the server in Java. Especially if you use something like Clojure where concurrency is basically free. You’d achieve huuuge amounts of concurrent players. But then with UNET the chance that your MMO ever sees the light of day is actually somewhat realistic.

Personally I’d rather release an MMO with 1000 CCU limit than work on a 10.000 CCU Java project that takes 6 years of my life and might not even be finished. Not to forget that computers get faster all the time, so those 1000 CCU could easily be 2000 just by buying a better server in a few years…

@mischa2k Thanks much for the very detailed answer. It’s really illuminating and it helped me understand the scope better.

As I said, the physic and model parts is the one that I’m in the vague as to how properly to it on the server side. What I have in mind is not extracting information about speed, weight, and etc from unity scenes to the server but vice versa, I mean storing them primarily on the server side and feed them to the clients via network when necessary.

Isn’t it the right approach, since those attributes are ones that should be persisted on database, rather than on each client’s Unity resources?

But still, I’ll still need to load a terrain, obstacles, and etc on the server and simulate physics somehow (possibly with things like jBullet/jODE with libGDX) and it’s the part I have the vaguest idea. Could you give me some hints about how to approach this problem too?

As to other things like dealing with TCP/UDP or implementing entities like monsters, items, and etc, I feel relatively more confident about it. You mentioned of Clojure, and actually I had a similar stuff in mind when I begin wondering about writing a server on JVM.

I always thought Akka with its Event Sourcing support would be a perfect match for such a task, and it’s the part I have the most concrete ideas about how to proceed. And fortunately, I’m doing this purely as a hobby so if I could make a functional prototype in 6 months, working on weekends, then I’d be very happy about it :slight_smile:

Actually, the reason I’m considering this path was not the CCU limit, but that I wanted to try this idea, and also because I wanted to have an opportunity to hone my Scala skills too as it’s my main language of choice.

Anyway, thanks again for a very helpful answer. And I have no doubt your asset is very handy for those who want to run Unity on backend (probably most people, I guess :p) from what I’ve read in the forum.

So you’re deciding to reinvent the wheel with regard to physics and networking. When using a Unity back end, physics is already a turn key feature, and there are several readily available networking packages of varying quality to choose from. So you’re deciding to dedicate a considerable amount of development time tackling problems already solved before even getting to the “game” part. It sounds really interesting, but not something particularly productive, and unlikely to see a finished project in a single person’s spare time.

My 2 cents.

Well, it performs really well if you write a java server, can handle a lot of players and hundreds of thousands of entities huge maps etc. However… I run a game server, written in Java… you are looking at several 10’s of thousands of lines of code, probably closer to around 200k lines of code just for a basic system, the more advanced your game gets the more in depth that code is gonna get. If you are by yourself like most unity devs starting out, I don’t think you will get there soon. However I don’t like to say no like most people. If you are willing to put several years into it youll get it.

That being said there is an open source game server project that isn’t updated often but you can check out github for leaf.go or google for golang leaf game server. Its a great starting point, in golang nice and fast, compatable with java so it would be a jumping off point if that is the route you want to go.

1 Like

To iterate a little further I just did some line counting for you. The basic communicator, the core. Keep in mind this is not everything calculated and translated, this is just the system that organizes the data, serializes it, encrypts it and sends it in a non blocking byte buffer in java from client to server and vice versa, just 1 package 800 lines.

Your point about running unity on the backend is valid. There is just no way possible it can handle as much as a pure code server, or ever be as secure, but Vis has done a wonderful job and keeps updating constantly. It may never handle 1000 players smoothly, but that is just because of server bloat holding so much stuff that a classic server would only have on the client.

A friend of mine who has quite a few years professional java game dev experience recommends libGDX so thats a good call on your part.

That being said, you don’t need java libraries to get unity going talking to the server, that is just tcp connections, all you need is to write a matching byte buffer system that talks. The challenge I would think would be Java is string based, c# is not, however iirc Unity has some force string stuff in its core that may help. There is a youtube video some guy started, unity zero to hero, he was tutorialing a .net standalone server talking to unity, he didnt get far before quiting, but its perfect to get an idea of the first handshakes to a standalone server from unity.

I have a bit of experience with java game servers if you wanna hit me up for a more detailed chat about it. However my last point in this post will be, Notch and Rolf took almost 2 years to get a beta test up in java back in 2005-2007, and even then people were all looking like Link from zelda and standing on horseback lol. Java is fun, but its a LOT of work.

1 Like