Question on capability of the engine

News & General Discussion
1

I’m looking to design an online game. I guess you could call it a MMORPG, but before everyone starts dissing out the newb word realize that I know what I’m doing.

I am (or, should I say “was”) in the process of designing my own 3D engine for use in my game project. I have done extensive 2D development in the past (online as well), and have been looking to upgrade to 3D.

I’m about 2 months into my engine, and realize how much of a waste of time it is. I am basically re-inventing the wheel, and it’s not nearly as optimized as some of the other engines are out there. By the time I get to actually coding my game I will be uninterested.

So enter game engine via stage left. I’ve looked at Truevision3D, GameStudio, and now Unity. So far Unity is taking the cake, but it’s only run on the mac! Ugh. But it’s still a very good possibility.

Now, I noticed Unity 2.0 has come out with some networking capabilities, and optimized features for the game engine in general.

So my question is… besides the design work and general experience in developing a game, is Unity capable of developing a MMORPG?

I’m not looking to make the next W.O.W. Realize that I will be cutting a lot of material out that most MMO’s have (thus saving a lot of dev time), and saving on some extensive AI work in the process. I can potentially limit my bandwidth because of limited user interaction, and keep my packet size down as well.

I’m looking to have a server that can hold 500-1000 players simultaneously, in a 24/7 world. Each client will render their own version of the game on their system, and use the server to update their status and to verify their actions. The server will also send them data about nearby players and their actions.

So, what this means is that Unity will need to be able to handle numerous server requests, as well as render quality images on the client side of the game. I’m not looking to make a high-detailed FPS looking game, but rather a third person bird’s eye view (so I can cut down on some graphic qualities).

If anyone is still reading this post, please comment on what I have said and if Unity is ready to handle what I have to throw at it!

-Gardon

2

In my opinion, yes. But if you’re serious you would probably want to write the server in something else.

Understood. If you take this to an extreme (e.g. Eve Online, or – even more extreme – Kingdom of Loathing) Unity would work brilliantly, and you could use something fairly simple and robust on the server-side (a bunch of code written in C or Perl in front of some large tables that get flushed to a conventional database).

Sounds a lot like Eve Online in terms of requirements. Again – this would gel with my suggestion of writing the server in something else.

It’s possible that Unity could run a server – but I don’t think it’s very practical.

The question is what you mean by “numerous” server requests. In my day job one of our ad servers handles ~1000 requests per second (for text based ad code). That’s ~60,000 requests a minute. But all they’re doing is finding the first record on a table that matches a filter function and then spitting back a few hundred bytes of text, with no GUI, etc. Assuming your server supports 500 players simultaneously, and sends and receives just TWO messages per second, that would max out one of our highly optimized ad servers … coded in C, and not bothering to figure out what’s going on in a 3d world, etc.

It’s pretty clear that a WoW “server” is a cluster of machines, each of which is running a number of “zones” and “instances” of the overall game world. Each machine is, therefore handling a relatively small number of players at once (maybe 500 for a really heavily loaded zone on an exceptional, such as “the day they opened up Silithus”) … and you see massive degradation in such cases.

On the client-side – absolutely and without question.

On the server-side – possibly for demonstration / prototype purposes.

3

podperson said exactly what I was thinking, only better. :stuck_out_tongue:

Unity can run the client easily, but it’s less than completely optimal as a high-volume server.

4

Hey, thanks guys.

What I meant by “numerous server requests” is updates for the game.

ie. Client sends the server updates 1 or 2 times a second. In between times, each time a player does an important action (moves, attacks another player, equips a new item, or whatever), the message is queued in a packet that will be sent out at the appropriate time (perhaps less than .5 seconds later).

So if there are 500 players online, and each one needs to both send and receive a packet once or twice a second, we’re looking between 2 and 4 packets. Now, that means that assuming the server is optimal in packet sending, it would have to not only send/receive between 1000-2000 packets a second (roughly), but would also have to verify and make calculations on that data.

Now, podperson, are you serious about the maxing out your server with those 1000 requests per second? That doesn’t seem right to me. Something like raknet (rakkarsoft.com) has a demo of 25,000 messages a second. 1000 seems very low for an optimized, dedicated server.

Nonetheless, I will look into this engine. Like you both said, it’ll be great for client side processing.

5

Also, take a look at runescape.com

Each world has over 1000 people on it. Is that because the graphics are bad, or because it’s a browser based game?

Do browser based games take the need for server requests because you’re essentially connected to the server the entire time, and don’t have to send packets?

6

FYI, Raknet is the API that UT used for the networking system in Unity. That should give you an idea.

-Jeremy

7

For things like state synchronization we’ve implemented a lot of that under-the-hood for you so you won’t have to be the one sending the information (and we’ve done that in highly optimized ways of course). That’s true for objects under physics control (rigid bodies) or other objects you choose to have serialized and state-maintained. I’m personally not 100% of the overall server load capacity but have to think that’s going to be based more on your bandwidth pipe and server processing power more than the engine. But to help answer that…

Paging larus to the white courtesy phone, larus please. He’s our network guru and the one who did the bulk of the work - I’m off to ask him to drop in on this thread.

8

The network engine is for the moment optimized for “normal” client/server based games with the server and client both implemented in Unity. Alot of stuff happens behind the scenes which optimizes this and makes the network capabilities simple to use.

That doesn’t mean it cannot be used for an MMO but I believe it would be hard. I.e. you would need to be a network programmer and know what you are doing. MMOs are complicated beasts, just take a look at your 500 players example above:

The update rate there is very low, 1 or 2 updates a second will not do for a fast paced game (Half-life 2 had 20 per second) but I feel like that is not what you are aiming for so lets say thats OK. You say the server needs to send/receive 1000-2000 packets a second for 500 players, but thats maybe a bit optimistic. In the most simple terms that number suggests each player only sees one other player and no more. You would need to filter what is sent to whom as the worst case is that all 500 players come into contact with each other which means the server needs to relay every single player to all the other players and thats ca. 500*500 or 250.000 messages. All that stuff would potentially need to be squeezed into 1000 packets (maybe thats what you meant you would be doing, wasn’t sure).

If you do your own server solely for synchronizing the clients you would need to handle all the internal processing Unity clients spew out yourself. Just to make sure they don’t crash and burn. This is mainly during the connect phase where certain things are set up. Again, it can be done but it’s not simple without internal knowledge of the networking engine. I might possible to do with simple trial and error tho.

I hope I don’t sound too pessimistic. MMOs are a possibility, its just hard to do, beefy server and a lot of bandwidth a must. RakNet has been used for MMOs so the capability is certainly in there. Keep in mind that networking is brand new in Unity and it will definitely be improved as we go on.

9

Hi Laurus, can you post a drawing or schematic of how networking works in Unity.

From what you are saying an MMO is not possible with the way Unity networking is now.

Is it possible to have different instances of the Unity server handling different zones in your world to make it possible.

What about something like Second Life, or PS3’s Home service?

Actually, let me rephrase the questions:

How can someone make a realtime interactive world with Unity’s networking as it is now?

Would that entail running multiple instances of the Unity server on different server hardware controlling different zones within the world?

10

Hi dingo

Lars had some nice diagrams in his presentation at Unite. As I understand it they will be available to download.

Em, I didn’t say that, just said it was hard.

Like I said in the previous post, the networking layer at is is now is designed for server/client based games or “normal” sizes. Simply put: You can do this but it is hard.

To do MMO’s you need to think about all the MMO aspects yourself and thats just general MMO “theory” and bandwidth optimization techniques which you would need research yourself. Synching together multiple Unity servers is not a feature and you would need to do that yourself. What you are asking is in essence very complicated, like asking “How do I do an MMO?”. There is no simple answer, and like I said, it’s not directly supported (at the moment at least).

And to quote myself :slight_smile:

11

So for a lurking comment/question:

Does Unity have a fixed update schedule? Are major releases annual or on some schedule or just when they’re ready? The same for minor releases/updates?

And finally, would serious improvement to unity’s networking be a major or minor release?

tia

12

No, we don’t have any sort of a fixed update schedule for either major or minor (dot) releases. Before we attempt to create any form of a time-line we must first scope out all the work we might put into it and make our first guesses (for internal consumption only, sorry) from there. But as happened with 2.0 there are many surprises along the way that maybe delay schedules (example: the 2.0 effort started long ago but many 1.x updates were interleaved as they became necessary and appropriate).

With the 1.x product line there were a few dot-release updates that contained both bug fixes and new features and it’s likely that you can expect that to occur again with 2.x. But as of today we cannot say that you should or should not expect networking updates (or any particular feature additions/updates) in dot-release to the 2.x product line. They may come out as dot-release updates or they may only become available with a 3.0 release (or beyond). Of course the third option is a mixture of both…

13

That is correct, all presentation materials as well as session videos will eventually get posted for all to view. The next question is always “when?” and for that the best I can say “in the next few weeks”.

14

Let me see if I can ask this better.

Is it possible to create a 3d chatroom where each avatar(bipedal huminoid) is interacting in realtime with other 3d avatars? (An example is people meet in this ‘chatroom’ and arrange competitons between each other, like a race).

Does the current networking features allow for a 3d race(ie. mario kart) style racing between 8 simultaneous players?

On a scale of difficulty of 1-10(10 being the hardest), how hard would it be to implement this using only Unity 2.0 without any custom programming outside of Unity?

15

I put that sort of thing in the 2-4 range (meaning easy). I believe we’re even preparing to post a networking demo project in which folks can drive around a simple environment together, I’m not sure on the status of that. What you’ve described is definitely in the sweet-spot of what we’re trying to target. Saying you want 4, 8 or even 16 people is a very different target than anything on a MMO scale where the demands and needs are exponentially more complex.

16

thanks for the response Higgy. But what about the other part…

The chat room asking each other to race, and the server knowing where they are etc. Would that chatroom only allow up to 16 people? Would we need a server (software) and server(hardware) for each chatroom of 16 avatars?

What about multiple races(of 8 people) occuring simultaneously?

And yes this is a very general question, but the whole idea of Unity 2.0 is to make networking easier for non-programmer artist types. These types of questions inevitably are going to be asked.

Are there any benchmarks to go on regarding networking? I’ve read and re-read the docs, but need a little more…

Can just some of the stuff from Unite be posted? Even if it is just a powerpoint?

It may not seem like it but I have read and re-read the Multiplayer documentation but have not come across any guidance on hardware or examples of different scenerios.

What was used internally as a test for multiplayer, can’t that be posted as an example?

17

Well UDP is a faster, less reliable protocol. This is TCP/IP sitting behind load balancers, etc. We’re also talking about non-trivial stuff (they’re doing 35k messages… but what are they doing to generate / respond to those messages?).

This is kind of a nonsensical statistic. It’s not a use case.

18

This is a well defined and easily repeatable benchmark that would give an accurate measure of the overhead of the messaging system. Networks vary greatly, but can generally be accounted for. Trying to account for the differences in networks AND overhead of the messaging system would be very difficult.

19

Chatrooms are very very easy, thats non-real time data, latency is a lot less noticeable. 16 players could be handled by any client posing as a server also. We will supply a chat example soon which you can use for reference.

Races are actually one of the worst kind of networking games as latency is very noticeable here (maybe not as much in a kart type game). Making it run would be easy but optimizing so it looks perfect and is fair to all players is harder, depending on fast the game is.

General networking theory applies here, the hardware and bandwidth required varies with the game being developed. It’s hard to conjure some numbers here, just look at game types in general and you can imagine what is required. For example real time strategy games often had a limit of 8 players and then a limit on the units you could have. FPS’s go around 16-32 max players (or more) and the high numbers usually required dedicated high bandwidth servers. Of course commercial games are highly optimized so you would need to work hard to get the same performance but network characteristics in general apply here. How many players, how many objects synchronized, how many updates per second, etc.

There will be samples posted soon which can get you started on networking. They are simple and to the point so you can quickly see how networking is used and what you can expect from it.

Edit: Mentioned turn based strategy but meant RTS, turn based would of course be as easy as chat.

20

It’s the overhead of the messaging system of a server talking to itself. It may be well defined and easily repeatable and even “accurate” for certain values of the word “accurate” – but it’s not useful since it’s not exercising any of the key bottlenecks of a working system.

It’s like being asked how powerful a CPU is and replying with just the clock speed.

You could attach two boxes and have them talk to each other, over a network, you could also stress the system by having each server run a multi-gigabyte application that slams all the caches. This would be a lot closer to a use-case and equally well defined and repeatable.

Going back to my original point – we use very expensive hardware to serve ads, serving ads is, fundamentally, pretty trivial, and our code is both optimized and custom-written for the job. In this, very real world, situation, our servers can process ~1000 requests per second.

Now, if you use UDP, you’ll have lower overheads. Also, you can do lots of dumb tricks based on the fact you’re writing a game with persistent connections versus serving ads to 1000 random TCP/IP addresses (e.g. broadcast stuff to lists of addresses known to be close to each other in the game world). That said, one server isn’t going to host 1000 players all in the same place and each getting 15 world refreshes/updates every second.

Your example guys are basically able to send 25k empty messages via UDP from their server to itself per second. No calculation, no content, no thrashing the caches. (Oh and let’s not forget about writing out to external databases.)