Is it possible to actually create mmorpg with Unity ?

Is it possible to actually create mmorpg with Unity ?

 

http://www.fusionfall.com

 

What about something like a real mmo ? Not browser-based flash game ? ;]

 

Fusion Fall isn't a flash game.

 

Still browser based

 

For the most part, deploying content to a standalone or in a browser has no bearing on what is possible with Unity. I would consider launching a game in the browser to be a design decision more than anything else... there are, of course, technical constraints and advantages that are unique to different deployment options, but a web player game could be deployed as a standalone and a standalone game could be deployed as a web player.

 

As noted above Unity, along with a proper back-end tech, is plenty capable of developing just about whatever game type you like, including full-on MMOs whether in the browser or on the desktop.

FusionFall is one example, ArtPlant/Funcom are soon to join the fray with a second MMO done in Unity and I know of one or two other large scale MMO/virtual world projects underway in addition to that (under NDA, can't say what/who just yet).

 

It's browser based on purpose, but it's very much a full blown, 3D MMO. In fact, it was actually more difficult to put it into a browser and required some custom functionality that was later released in 2.5. The original client was written with Gamebryo, but we felt it was important to reach a larger audience by utilizing Unity's fantastic browser capabilities. Just for giggles, we clicked a radio button and built it as a standalone application. It was slightly faster (no IE getting in the way), but other than that, exactly the same code.

I should mention that Unity is the client side. You could utilize it on the server side, but that's a different discussion. Right now, Unity is better suited to create the client and utilize a separate back end. 'Creating a MMO' is a huge undertaking. Unity is an excellent tool, but it's not a silver bullet.

 

HiggyB, can you expand a smidge on "along with a proper back-end tech"?

 

Simple answer, yes.
Extended answer, not without effort for the server piece.

If you want to get real about MMO's and servers: (middleware)

RakNet
http://www.jenkinssoftware.com/

Quazal
http://www.quazal.com/

Hero Engine
http://www.heroengine.com/

Icarus Studios
http://www.icarusstudios.com/

Monumental Games
http://www.monumentalgames.com/

MultiVerse
http://multiverse.net/index.html

BigWorld Technology
http://www.bigworldtech.com/index/index.php

Bottom line, the middleware is the key to success, Unity is simply best suited for the client interface, if you are seriously considering an MMO project, get to know middelware. All middeware can be used with Unity as long as it plays well with the Mono interface.

 

Thanks for the list, I'd not looked into Quazal and Icarus. I'll check into those too.

To the question though, Unity looks to be outstanding for the client side and our team includes several highly skilled middleware guys. I'm trying to get a handle on the right roadmap for building an MMO with Unity on the front.

Is it so straight forward as I'll be plugging in a alternate engine for the middleware components? (e.g. RakNet, Quazal, Photon, NetDog, et al)

Or will Unity's middleware pieces suffice? (doesn't sound like it) How far will Unity's component take us?

Or shall I buy a source code license and extend Unity's middleware piece?

Thoughts, answers, and posts to relevant conversations and appreciated!

 

Sure. The point I was making is that while Unity has built-in multiplayer features, those inside our app by default just won't scale to a MMO level at all. So if you're interested in going this route you'll need to ensure that your back-end is a proper MMO/virtual world set up that allows for load balancing, moving players across servers based on real/virtual world location, that handles scaling from dozens to thousands of concurrent users, etc. The truth is that MMOs are very complex beasts and Unity is very capable at helping you create the front-end, but it's the back-end where the "MMO/virtual world" magic happens, and for that you'll need to check into third party solutions.

As to a source license I don't know that you'll need that as you can easily tie into the existing technologies that are out there. If a source license was desired then that can be discussed, but I just don't know that it's strictly necessary.

 

Multiplayer Baseball Online is an MMO being built with the Unity engine.

 

If you really wanted to do an MMO on the cheap, you could easily reverse engineer some of the code and techniques in projects like ArcEmu for your back-end. There are numerous emulated wow servers that have 5000 people on a single shard at any given time, so the network code works well.

You also shouldn't have such an aversion to a webplayer for your client. At least with the webplayer there's an extra step or two to gain access to your client's source code. With a stand-alone it's literally one click.

 

I really am a huge fan of mysql and unity. They work together very well.

I have developed a set of database calls that work very well. In fact it helps my game communicate with my website since my website uses php and mysql and php work well together.

 

The network interface loop for the client must be outside of the client loop and encapsolate unity inside that loop for an mmo to work smoothly, not the other way around and the only way to truely accomplish that is through source code purchase. You simply can't rely on unity game loop first then network loop. Don't believe me then ask when raknet is actually started.

 

Don't believe you and the simple reason is that the most efficient and cleanest way is not A in B or B in A but A and B (distinct threads) and using the observer pattern to handle the received messages

With source you naturally have more control, but I really fail to see how it is a requirement to have it.
Many other engines don't give you that option too but execute the networking as a service (AoC with Gamebryo on the client end for example, which is not that different structure wise)

Any approach that includes "hack the main loop" is more than just slightly broken.

That hardwired components also require to be initialized before the actual simulation (commonly as part of the main loop) happens is a clear thing, but if the networking isn't needed till the login button is pressed with menues before as its common in MMOs, then the actual simulation does not start far longer and you can startup the distinct thread at that point too.

That works with NetDog, that works with SFS Pro, that works with Photon and I would bet it works with a RakNet plugin too.
What you can't do is rely on the integrated network as UT has stated more than once that it is not targeted at any such usage, point. No reason to discuss nor to daydream that enough hacking around will make it work, it just won't.

 

And here is where your experience and mine differ, I'll take the word of Kevin Jenkins over yours on this one any day of the year. Over two years ago I had a conversation with him directly on this very subject and the outcome was simple, you have a network loop started first, in the same code base, then you start up the client, why is simple enough, the network sync state happens indifferent than the game loop but between game loops you have to send a heartbeat back to the server otherwise you are either (A) flooding the server with too many check states or (B) not enough check states. So if you want to sit there and tell me that the creator of RakNet is wrong I don't think I will take that as a serious position.

Packet *p = peer->Receive();
That must be called prior to every game loop so that you can process those packets. If you think that Unity magically starts up RakNet without calling :
RakNetworkFactory::GetRakPeerInterface();

Which btw has to be setup prior to starting the client inside of Unity, that is done outside of the game loop during initialization of the engine. Later when you want to use RakNet in Unity you are using a global interface of both the peer and the server depending on which end you want to use, so they both are started by Unity prior to the game loop and use global variables that we hook into, even they know that.

Not to mention that same exact call is called to setup the initial server interface otherwise you can never start the network server which happens in the game loop. It is not a matter of believing me it is a matter of startup order. Unity has 2 global settings, rather in this case PEER's, one peer is setup specifically for the server and one peer is setup specifically for the client, these two are running the moment that Unity begins either the editor or the game build, that all happens before a single game loop even starts.

When we start either the client or the server all we are doing is asking either peer to call its startup with the values we pass based on their overloads. The peer->Receive() call is being made every 10 seconds inside Unity, I have timed it, which BTW they are calling again outside of the game loop.

When peer->Receive() is called, the Packet *p is filled with the packet information, the header (first 8bytes if I recall, that or first 4bytes) is translated, this is data element 0 of the array of bytes, that is the ID enumeration, again, all outside of the game loop. This is the most efficient way to handle this. Trusting Unity to handle it inside an EGO when you have no trust of the execution order of any object in the game is insane to say the least. You of all people are very aware that the architecture of Unity means that we can't guarantee that object 1's code runs before objects 10's code no matter where you put it in the scene, sure running the network code off of an EGO or other game object will in theory "work" but it will not work correctly and for long.

If I am not totally mistaken, the build of Unity probably goes something like so

Code (csharp):

1.  
2. class Server
3. {
4.     public:
5.         Server()
6.         {
7.             peer = RakNetworkFactory::GetRakPeerInterface();
8.         }
9.         ~Server()
10.         {
11.             RakNetworkFactory::DestroyRakPeerInterface(peer);
12.         }
13.         void Start(void)
14.         {
15.                     //........
16.                 }
17. //......
18. }
19. class Client
20. {
21.     public:
22.         Client()
23.         {
24.             peer = RakNetworkFactory::GetRakPeerInterface();
25.         }
26.         ~Client()
27.         {
28.             RakNetworkFactory::DestroyRakPeerInterface(peer);
29.         }
30.         void Startup(void)
31.         {
32.                      //......
33.                 }
34. //........
35. }
36.  
37. int main(void)
38. {
39.     Client clients;
40.     Server server;
41.  
42.         Unity unity;
43. //........
44. }
45.  

Then in the main loop, they pull our client.Start() or server.Start() when we want to use it, and since there is only 1 peer for the client and 1 peer for the server, we can't setup chained client -> many servers, the main loop would require more than 1 server peer.

 

And where does your posting and Kevin Jenkins view now differ from mine?
Before the networking thread is started, no message processing can happen as the thread handles all message receiving, processing / callback calling and sending of pending messages, that simple it is.

As such, neither of the 4 possible networking options I mentioned that are started in their own thread when you connect to the server to login actually has a problem.
Actually my description is completely network library independent. You could thus just as well use lidgren or an ENet plugin if you want or anything else including own socket based implementations.

From your posting I've to guess that you primarily base your thoughts and ideas around Unity Networking and that will not work the moment we talk of long time running server or even worse MMO.

You can use Unity Networking in the environment it was target at, multiplayer games with something between 32 and 128 players where one of the players hosts the game and the server then goes down when the game is over.

But you can not use the networking for persistent world applications as it lacks by far too much control and efficient hooking up of the processing or many player action oriented games where many messages come in to the server at a high frequency.

That really leaves it to player hosted "during play time" servers like it is with WC3 custom games or Diablo 2 rounds and similar things or simply "to what it was meant for"


I'm aware not all will like that and likely some will not agree.
Thats up to anyone naturally but I personally prefer to find solutions instead of fighting against granted dead ends that won't get me any closer to the solution.

 

Actually I believe Diablo 2 uses a peer->peer model, which is why they were not only incredibly hack prone but also why the game doesn't end until all the players disconnect, irrespective of what the 'server creator' does.

I don't believe stock Unity networking can do peer->peer.

 

One thing me and Dreamora have in common in all of this is that the "stock" Unity setup is not MMO ready, this is not because they are using Raknet, it is because of the number of peer limitations in place. In my instance, I say connect the client to the server in a hub and spoke setting where the client network interface is started before the client game interface, this way the client game interface can monitor the client server interface through hooks.

In Dreamora's reference, he is suggesting that the client network interface be started after the client game interface has began, thus asking the client game interface to monitor the client networking thread which can be done through async call back routines during fixedupdate()

Unity "stock" can do peer->peer using Authoritative server model but again, bottleneck is that, as you have stated, like C&C if the server goes away, no one becomes the authoritative server, passing the buck as it were. "WE" have no control over the network loop using internal Unity networking code. Sure we can control the master server that keeps track of the games, but there is nothing we can code into the internal client or internal server components of the "stock" unity that allows for smooth transition and reassignment of the "host".

You do realize, that the C&C model, everyone is technically a ghost host with 1 master host. When you join a game, you have the host running just in idle state, but you are queued up to become the host in the event the game crashes on the actual game host. That is a bit much at the moment for Unity to build into their system and I doubt it is on their emmediate plate.

However, the question stands, can Unity be used to build an MMO and the answer is "YES". Dozens of these threads spawn over the years, and now there is a production browser based MMO in place with more to come, and as far as I know, those who are seriously doing an MMO with Unity have purchased the source, but I don't work for Unity, this is only speculation.

 

Anyone have any updated info?

 

These are all up to date infos.

You can create an MMO but you will have to do it. There is no magic that will take away the work from you to implement a suitable network solution, all client functionality and naturally an MMO targeted backend solution

 

Of course, everything you can imagine.
Here is a link with a ton of RPG tutorials:

http://www.burgzergarcade.com/hack-slash-rpg-unity3d-game-engine-tutorial

 

Dude, necro posting or what.

This thread is like, 2 years old?

 

We have an article on this question
Is it possible to make a MMO with unity?
And an article on Choosing your networking middleware for unity games