Non newbie MMORPG thread

Unity Engine
1

OK. I know there are a lot of threads by newbies who’ve never programmed a line of code in their life wanting to know how to make Skyrim or WoW…

But for those of us who are a little more experienced in game making/web developing/etc. Let’s have a proper discussion on the practicalities of making an MMORPG focused on indie developers rather than big companies with a lot of money.

Here’s my thoughts on how one would go about it. Please feel free to add your own optimisation ideas:

A basic top-down 2D Unity MMOPRG using

  • Unity3D
  • A cloud engine (e.g. Google Cloud, Amazon AWS, or Microsoft Azure.

We assume that the game world will be stored on the cloud. (This is not a given since feasibly it is possible to create a distributed file system like Napster where the world data is shared amongst players).
There are basically two methods of using the cloud:

  • To use a cloud engine to run instances of your Unity Game as a server
  • To use as an advanced player matching service.

The general idea is that the world is broken up into sections. As you move through the world new sections are loaded through background AJAX calls. As you move into new sections you update the cloud database with your position. You also check how many other players are within adjacent sections of the map.

So far, nothing very complicated, it has the same basic functionality as Google Maps.

The tricky bit is when two or more players are in the same section and need to react. Again there are several options

  • The movements of the players are sent to the server. This may be slow if you are writing the positions to databases instead of communicating with an instance of Unity on the server.
  • The server establishes a P2P connection between the players. This has it’s own difficulties.

Also consider the scenario: Players A,B,C
A------B------C

A and B are near enough for P2P and so are B and C. We need to establish separate P2P between each pair. (Otherwise potentially every player on the game would have to be on the same P2P network which would cripple whichever player is the “server”). I’m not even sure this is possible in Unity.

Also, consider that player A has made some changes to his section, maybe pushed around some rocks, but the world has not yet updated to the server. Then player B enters that section. You must decide whether the section should be continually updated on the server, or the current state of the section is just shared between the players by P2P and only occasionally updated on the server.

Part 2 - Storing the world
Some games like Minecraft store the game world sections in a binary tree folder structure as files.
Another method would be to store the sections in a giant database or datastore either as files or “blobs”.
Some methods are more scalable than others. For example SQL databases are not very scalable.
Also, don’t forget that your system should include away to extend your world if you suddenly decide you’d like it 4x bigger. (Or perhaps it dynamically increases as more players join.)

Part 3 - Finance
Using a cloud engine is a good way to scale, as assuming that all your players are subscribers, the game should pay for itself in terms of cost of the could engine. A one time fee and then letting your players play the game indefinitely is a more risky way to go. It is also important to design the game so that not too much data is sent from the servers.

OK. Well, those are my thoughts. I have begun creating a game using these principles but am at the very early stages. So take some of what I said with a pinch of salt. And please offer your own experience and better ideas! :slight_smile:

2

I’m working on something similar as a hobby as a way to teach myself html5 game programming(2d topdown multiplayer simulation, think oldschool MUDs but with basic graphics).

I’m using websockets and plain html5/javascript for the client at the moment until I see how Unity pans out with their html5 support and pricing, but since most of the logic is handled server side swapping out or even supporting multiple front-ends is not critical as long as they support websockets.

For server side I have tried both a Node.js instance and a Python Twisted server, I’m still going back and forth on it as there are things about both that I like. I use a tick system where server updates are sent out at regular intervals to update player and npc actions and do pretty efficient area of interest culling on server side to limit bandwidth. Running a full blown Unity instance on the server is wasteful and too much hackish stuff you have to do to make it work as a server in my opinion, unless you need realtime physics simulation.

I don’t consider P2P viable, just look at the hoops many players have to jump through to get that working for games like Borderlands, doing it on the fly would result in lots of network errors and dropped connections. There is also security concerns there.

Financially I think the days of paid subscriptions for games is dead(at least for now) and you’ll have a hard time getting anyone to play at all. This is why MMO’s are so hard in my opinion since you need to foot the bill for all that traffic and hosting for a payoff in the distant future which will most likely never come.

I have some VPS servers I host my stuff on and I expect that will be enough to handle the minor amount of players and traffic. If somehow it was popular and I had to scale it would probably need financial backing and some sort of plan as to how it would make money(microtransactions).

I think the more likely scenario is offering the server and client as a package so people could run their own servers. I store my world, items, mobs, etc. as flat files on the server that players can easily mod and run their own servers etc. Again, same way most MUDs did it, trying to take those learned lessons and apply to current game design.

1 Like
3

It would be nice if WebGL comes out on Unity soon then we wouldn’t have to choose between the two!

It’s interesting how we are going about the same thing but in two very different ways. I think it depends on how much control you want over the server side of things. For me, I’m happy to let the cloud companies deal with that and pay that bit extra in case of scalability.

Connecting people on the fly with P2P might be a bit tricky, at least with the current Unity networking setup. (Although I think HTML5 will support this.) But I think if you could get it right it would solve a lot of latency problems. I’m not sure it would be that slow especially if you connect people when they are someway off-screen. But it’s worth testing.

Apparently they use P2P in this web app: Banana Bread

4

I’m not sure what you mean by letting the cloud engine handle stuff. Cloud services like google or azure just provide you a platform to host your code and easily scale it. I can run my Node.js on Azure no problem, or on my own server, there is no difference to how I write my server for the most part(game logic anyways). The key is to make it modular enough so that you can scale it if you wanted, ie. keep the part that clients connect to as a straight message router and then have separate processes/clients that provide the npc/world updates.

P2P I don’t understand how you would prevent rampant hacking as well as sync issues when clients can’t connect to each other.

+1 to Unity releasing WebGL already :slight_smile: I’m getting pretty good at javascript now but it is no C#.

5

With the cloud service I just meant in terms of automatic scaling. Granted that’s only important if you have thousands of players.

P2P. With hacking, you’d have a password system. Imagine connecting players to each other when they are 10 seconds away from each other. That way, you’d only have to update the player database every 10 seconds and have a 10 seconds to connect. Plenty of time. With the new WebRTC system for HTML5 I’m sure they’ve got ways against hacking.

I suppose if you did go with P2P you’d maybe have a fallback where if two players couldn’t connect for some firewall reason or something, the server could take over.

Well all this technologies quite new so I don’t know if it would work well. But its worth a try I think!

6

Nice link, checked out that Banana Bread and saw it uses WebRTC for it’s P2P. Went and read up on it at: با WebRTC شروع کنید  |  Articles  |  web.dev Looks like it uses a signaling server to setup connection between two clients, and if it fails then it uses traditional server based communication as a fallback. Seems like a lot of work just to have two clients talk P2P to me, and what happens when you have more than 2 clients in a area?

Here was the relevant server requirements they listed:

7

Can’t you have multiple p2p connections? Yes. It does seem like a lot of work. But I think there are a lot of advantages in terms of latency and most importantly saving on bandwidth. Also, scalability since you could have thousands of players and hardly any bandwidth since they would all be P2P. Hence the difference between a MORG and an MMORG. :slight_smile:

I reckon its one of those things that seems more difficult than it really is. And imagine if you got it to work!

8

Sure it is definitely possible to have multiple connections open. That being said I think there is a reason most games have a server, even if it is hosted by one of the players. The complexity of managing game logic where there is no central server seems like it would lead to sync hell and chaos once you actually tried to do anything beyond connecting.

9

Also sorry if tone came off wrong, not saying it should not be tried, I would be genuinely interested if such a model could work.

10

You know what I’ve been looking at this WebRTC thing and it really is very complicated! I think for now Unity’s networking solution is much better. Even if it can’t do multiple P2P connections. Maybe the new uNet system will solve that.