About muilt-user application question of the Raknet

i want to develop a web application like the second life,it is support 2000 preson up，if i use the unity3d Pro,will fully developed yet?

thanks.

 

Unity and our built-in multi-player support are not something you'll find well suited for thousands of players. In all reality our implementation is targeted at smaller scale casual multi-player titles where you have a few, up to dozens maybe, of users at the same time. If you want to create something quite that large then you should look to our HTTP support, our socket connection support and third party back-end tools like SmartFox and/or NetDog. Both are multi-player servers that are scalable and quite cost effective. SmartFox even has a Unity API set ready to use right out of the box!

 

Raknet works just fine for thousands of players.
SmartFox makes the web interface easy.
Raknet is geared to clustering with an average of 500 players per cluster member. Jenkins can go into more detail on this from his support site as far as the actual machine specs for this layout.

If I recall, the 'out of the box' implimentation of Raknet is set to a max of 1000 connections for the master server code. The twist is the networking example for peer to peer or using a Unity based client, the demo is setting up the server with only 32 players:

Network.InitializeServer(32, listenPort);

The actual maxValue for this is 65556, but the reality is that you don't have enough ports to handle that many. The happy medium based on load testing is ~500 unless you are on a Cray.

I know nothing about Unity's directly built in version of RakNet, what is in Unity 2.1, is what ever they say it is, and if it is not really made fore more than a handfull of active players, then you will need to build your own dedicated server and client software to integrate with Unity.

 

Yeah, I was wondering myself about how to do something like this. My question is can Unity, or Raknet for that matter, connect to multiple servers at once? If so, problem solved. If they can, just have a Unity-based server cluster that shares a database and have the players be handed off when they cross regions. That's the real issue, since no seamless world could be made If Unity couldn't talk to multiple servers. No, wait.... what if... no..... :?

I want to make one myself, so I'll keep thinking.

 

To use Unity's implimentation of Raknet successfully and modify the master server base code, requires information that Unity is not willing to share at this time. Your best bet if you are serious about wanting a large player environment is to build your own interface for Raknet or some other tool and go from there. Don't rely on Unity for base code information questions unless you pay them for it, and at that, there is another thread on this where Unity acknowledge that the implementation they have provided is for less than a handfull or so players, so it isn't designed for anything more than a taste of multiplayer ability beyond things like strategy games, racing games, or the like. All of which are fine in Unity's core design. Out of the box you can do these things, other people have proven that it can be done, some seems to have issues at times with loss of player data, but that could be anything.

There is an alternative, I am hoping to post some info about it this weekend after I do more testing, it also uses Raknet, I am just stuck on 1 thing at the moment, but what I am stuck on is on the Mac side, not the Windows side. Anyway, as it stands, using Unity as just-the-client, you can have seamless zoning between server cluster members while you do your loadlevel on the Unity side, it doesn't need to know which server it is getting data from, only that it is getting data. So to the answer of that question, yes, Unity can handle it just fine.

 

Agreed, as per my reply above.

Correct. Source code access requires separate licensing which you can inquire about by dropping me an email or by writing us at sales@unity3d.com.

I'll again reference my post above where I state that our implementation is not targeting anything on a large scale so much as it's meant for small scale multiplayer.


Using 3rd party tech for your back-end is well within reach, it's what Cartoon Networks is doing for FusionFall and what many others are doing with NetDog, SmartFox or whatever back-end tech you want to use.

 

If anyone is actually interested in using RakNet as a solution for a server, you can build a carbon bundle in xcode and apply this to your client and build a carbon application with xcode for the server itself. Another solution by the example in the attached picture, I created an xcode carbon project, built up RakNet in Carbon after adjusting needed items, then using Unity 2.1 built in networking calls, tested the actual connection to the running server. Now, behind the scenes of 2.1 is a core base of 3.0 RakNet which you can get from the archives on the RakNet website to build up your server. You can also use 3.3.0.2 to build up the server in carbon if you like to use it instead, more work is involved though. For the most part, to get you going, you can use Unity's built in commands and adjust the packet calls or translate them on the server side.

This image is using Unity 2.1 built in Network.Connect command to a standalone RakNet carbon build. So don't get too discouraged, what they are doing is trying to make life a little easier to get on your feet if you don't have someone who knows anything about network programming.

 

Many thanks, but my problem still exists. Unless I'm missing something, a seamless MMO world cannot be built with Unity's networking because raknet cannot be used with multiple servers simultaneously. i.e. If you are in region one (server 01) and move past its edge, you will pass into region two (server two). However, if you are on the edge, you should see the people and objects to your right (server one) and see the people and objects to your left (server two). This would require state synchronizations from both servers at the same time, something raknet will not do. Only a custom system would have this ability, which requires "reinventing the wheel", so to speak.

Sigh Back to system architecture design. But when I think about it, a perfectly seamless world doesn't even make sense for my project anyway.

 

Actually, Raknet can do this, you just have to create a table of adjacent zones (servers) from current zone. Say player starts in zone 1, adjacent travel zones are 2,3,4 and 5. Use a threaded model to start the zone connections from the client. Each server is running Raknet as a server on it, and see an incoming player connection and connects the playe then returns to that player the unique ID of the player on that server which then you store back in your array. You then have your game setup to set the adjacent zone visible once you get to a certain range from that zone. Each zone is nothing more than a grouping of objects. Your players environment can receive on demand zone specific data that should render.

What you are overlooking is that your client will have the zone static data, this is the terrain with all static elements on the terrain. Zone 2-5 can be hooked up to just load on the client in a background thread when the player gets close to it, the dynamic data is on zone server 2-5, so as you appraoch zone 2, your client just sends a request to zone 2 for information, once you 'cross' over into zone two, zone 1 is sending you less data the farther you get away from it.

This is more work on the client side than the server side, and in actuality, the current system using RPC's that Unity has in it would do this also. This is really not that big of a problem once you draw it out on paper, and you really don't have to reinvent the wheel, you just need to get creative with the current system.

Looking at the current MMO's out there, not to many care to do this anyway, take World of Warcraft, it does this, and you can easily see graphical chops while flying on the mount as it queues up the up and coming resources, the mount will look like you slow down for a second or two. Everquest (all flavors) don't bother, they force zone loading and a nice little splash screen between zones and still make billions a year.

So to answer your question, in a nutshell, Yes, Unity's current system can do it, although they probably wouldn't recommend it, Raknet as a whole outside of Unity with its full features can easily do this, from reviewing SmartFox, it can do it also, not so sure about the other network backbone mentioned in the threads, but frankly I would be amazed it it had any limitations that didn't allow this to happen.

Frankly, you only need 1 scene, ever, in Unity. You can have your login screen in it, your first loaded zone in it, and then through object instansiation you can do the entire blooming game in that single scene so you don't even have to use Loadlevel, ever. (not recommended for large scale project).

 

Interesting. I tried my idea in a simple test and, although no errors were generated whatsoever, the second call to Network.Connect appeared to terminate the previous connection. I assumed it was either a Raknet limitation or, if Raknet could, Unity was incapable of accessing it. I never even thought about multi-threading.
So, to clarify, Unity's implementation of Raknet can connect to multiple raknet servers simultaneously?

Edit: What do you mean by "zone"? When I googled it, I ended up back here. Concidering how high this site is ranked, that's a bad sign.

 

How specifically would you do this? Is this possible with the current Unity networking?

As Omega mentioned, a second call to Network.Connect will terminate your first connection.

I would think that a separate thread would still access the same Network singleton object, but perhaps I am mistaken?

 

I can answer, with a most certain, yes, it is possible, see attached image:

(client broadcast is recognized by both servers at the same time, and each server is only recognized by the client, so the individual server message is treated as a single message at the individual client and independent of each server in the set)

 

More visual info for how the communication channels work in RakNet with multiple servers available to the single client.

 

"Zone" takes on many meanings in real life, but in the gaming world, a "Zone" is usually a given area that the user is confined to during game play. Each "Zone" usually resides on its own server do to the workload on the CPU/GPU of the server to maintain multiple entities working at the same time, which includes player information, physics, non-player entities, static and non-static objects, so on and so forth.

Even in a virtual world that is "seamless", you have zones (banks of servers housing data for each defined area). Think of a zoning block for a neighborhood in real life. This real life "Zone" is residential by definition, and has rules as to what is allowed in that given area. Each "Zone" in a game is also a set of defined rules. This is a core concept in both single player role playing games and online role playing games of all genre'.

To actually accomplish what I have shown, you will need to create a Carbon bundle and use Pro to use that package along with using the DLL that comes with RakNet precompiled. What Unity is lacking for this to "just work" is a client collection.

See, all components need to be in collections, Unity is by default not. It is highly simple for them to change, although probably not in there plans.

Instead of just setting up a server pointer and a client pointer, they setup an array of client pointers, and allow the user -aka us- to define number of client pointers. Basically they are looking at changing 6 lines of code to get this setup on their end. They don't even have to mess with the server code, this is strictly client code manipulation.
PSEUDO CODE (they are much better programmers than I am, I am a simpleton)

Code (csharp):

1.  
2. RakNetStatistics *rss[];
3. RakPeerInterface *clients[];
4. Packet* p[];
5. unsigned char packetIdentifiers[];
6. char ip[][]; // Notice the [][] instead of [], 2 dimensional array
7.  

Now it is a matter of iterations. They expand the client section of the docs and the code so that the user can define number of servers they want to connect too. This information is used to define the size of all of the collections, since they are all the same size.

To put this another way, say you wanted to setup a bank of 20 servers (aka zones or what ever terminology you choose), it would be a simple matter of the follow end result:

Code (csharp):

1.  
2. RakNetStatistics *rss[20];
3. RakPeerInterface *clients[20];
4. Packet* p[20];
5. unsigned char packetIdentifiers[20];
6. char ip[20][30]; // 20 ip sets filled with 30 character length information
7.  

There is more code to each line besides that and an instantiation beyond this, but this is just to give you a glimpse as to the designs simplicity. The overall point being, a simple call to the client setup routine passing in an integer as to number of servers in the server bank or structures, well, a single client can then talk to hundreds of servers if you so deem it. All with really a flip of an integer.

My demo I did to show here used the core, simple basic structure, not to mention all the other really COOL features in RakNet that I adore to death. Making this switch internally, well, that would take probably many people asking for it on the wish list. I can simply do it through the pro plugin without their internal coding.

You wanted to know if RakNet could do it, and if it could be done in Unity, the answer is simply, yes.

 

It's not just 6 lines though. The entire Network and Masterserver class would need to be reworked to allow for multiple clients and servers.

And how does a networkView know what NetworkClient it should be communicating to?

I think Unity chose their approach of single server xor client to keep things simple. And it seems to serve that purpose well.

Your experiments are pretty interesting though Zumwalt, I am curious to see where you take it. RakNet has a bunch of cool new features including the Lobby2 project that would further add to the MMO capabilities.

 

The entire network class does not have to change, all of this is 'strictly' client based changes. They do not have to change any master server code at-all, not a single line of it.

The entire solution sits at the client calling level, meaning that they need to start up the client as a collection of clients, not just a single client. You have individual servers running on individual ports, on individual IP's, you can have a bank of virtual servers, or you can have a bank of servers running on the same machine, when each server starts, it listens on its own dedicated port. The clients (collection in single application, not multiple client applications) in my example each are on the same machine just starting up on the same IP with different ports (10001,10002), since one of the test servers is on the client machine also (server running locally at 127.0.0.1 on port 10000), the remote second server is on my virtual server space at GoDaddy for this demo.

I could have simply started up X amounts of servers each listening on its own port locally, then started up X amount of clients=servers but each client listening on different port than the server collection.

That is the misunderstanding as to how this actually works, it has nothing to do with the masterserver or facilitator code, all of this is dependent on Unity 2.1 client based code, so in the simplest form, it is no more than ~6 lines of code change. The ones that start up the client and define how it communicates with the server, all client-> code needs to just become client[]-> code, or in other words, collections.

This is not a huge ordeal, it is a business decision, to allow for the games to have server banks or not. Meaning, either leave it as is, single client to single server, because like you said, a new Client->Connect call resets everything (so on load level, you do a new Client->Connect to the server that houses that level and then start chattering) or have a seamless Client[X].Connect collection.

Seriously, server code does not matter for this issue.

By ID

 

Yeah, I meant that they would need to change the MasterServer class on the client side. MasterServer.RegisterHost would need to take a parameter for the server being registered (since there could be multiple). But that is only if you want players to create multiple servers within Unity for some reason.
With the method you are talking about (specifically for MMOs), it seems more likely that you would have multiple standalone headless servers, so Unity could still be limited to being able to create 1 server I suppose. But could create multiple clients.

BTW, you seem to have a pretty good understanding of RakNet. Do you know why Unity modified the RakNet source files instead of just using it as a library? I was under the impression that RakNet would 'just work' out of the box.

From the Unity manual, there is this quote:

What does this mean?

Then you would need some sort of lookup table to link IDs to 'NetworkClient's. It may be easier to add a private variable like networkView.networkClient. But I haven't thought about it too much.

 

Just an educated guess, but mainly because they wanted to give people an easy-in for networked peer-peer gaming without having to know networking. RakNet as a server needs to start 'before' the game loop. [WE] have no control of the game loop with this engine. All we are doing is things after the game loop has begun. This means that when the server is started, technically it needs to be started up then the game started, then the two chatter.

The database is used for the lobby server mainly, now Jenkins has a MySQL version also and not just a PostgreSQL version. What other modifications they made would be specific to the implementation they choose for Unity. You see, RakNet was written in C++ on a PC. There is no direct Mac port in his distributions. There are steps on his site on how to compile it for both PPC based Macs and Intel based Macs to make the .a file, although I prefer to use XCode and Carbon bundle.

What else is in that modified version of the database is an unknown to me. The AdHoc version they are using from what I can tell is mainly a fire and forget system anyway. You have no way to store player state and allow for a player to log in and pick up where they left off (aka MMO). The way they have utilized RakNet was to bring forth a strong strategy game implementation which is also good for impromptu FPS games and racing games. All of which require no login to the game itself to retrieve last known player location and such. This probably means the database is designed around this concept.

Which also means unfortunately for them, it is more work to add in new expansions to RakNet or upgrade to the latest code based since Unity 2.1 is based strictly off 3.0 initial core, which doesn't play well with 3.3.0.2. The other problem is that RakNet alone, doesn't play well with C# Managed code base. This means that all script files have to be translated to a back end hook to RakNet, so even the call they make to Network.Connect (which actually requires 5 parameters and not 2), automatically assumes certain things.

They are making it easy on 'us' to have a game going without having to know about instantiating the packet pointer, the peer interface, or anything else to get it up and running. Look at the user base of the forums (not the client base of Unity itself), but the Indy's and the single person pro's. We have a mix of artists, developers, jacks of all trades, etc. To use RakNet out of the box requires some hand holding as to the very basics of the system to get it going in Unity. This is a business decision to bring in more funds and sell the product to a wider audience. I 'do not' know if we can bypass the network calls and use RakNet native calls within Unity based on there library that is included. Unless they exposed these methods, the answer will be a big no. If they have and never said they did, it changes the ball game entirely.

 

Having said all that though, a client for an MMO is, more than most games, hands-off. Most of the action goes on server-side, for example as far as Unity is aware, it would only be communicating with 1 server. You can still intercept the Network.* calls from Unity though, right? According to that list of ID's you posted in another thread.

 

I think they're counting on users with needs more advanced than Unity's builtin networking to seek/create a 3rd party solution. To use RakNet client sided you would either need a wrapper or port. There is the raknetdotnet wrapper that uses SWIG, which I assume uses P/Invoke. For an Indy license porting is the only option.