Game Development Community

"Support 1000+ players per server"

by Arc · in General Discussion · 06/01/2009 (7:59 pm) · 11 replies

This is whats from T3D:

"For less latency sensitive simulations like MMORPGs, virtual worlds, etc., Torque can support 1000+ players per server."


Can anyone shed some light on this - it seems like a massive jump from TGEA. Also those who have the beta, are the physics for the rivers running? What is the world editor like? Is it drop down menu, point and click?

I've got the engine down to either T3D or Unity 2.5 Being able to play with Unity some, I really like the world creator engine, but not thrilled with network code. It looks like T3D is similar (at least from the video's I've looked at). I really like the river/road tool as well. While I'm sure I'll never need to go past 1000 players, its nice to know for the first year or so at least, I probably wouldn't have to worry about network code.

If anyone whose been playing with the Beta 2 of T3D could chime in, I'd me much obliged.

Thanks!

#1
06/02/2009 (2:10 am)
Actually, the 'networking' features for TGEA have the same clause about 1000+ players per server. As did, I think, TGE.
#2
06/02/2009 (7:12 am)
Torque has much better networking than those others engines (and its a heavily proven point). Its also the best not only because itself, but because the engine was designed around the networking.

The engines that are developed, and have added the networking layer on a later stage, could technically never reach the level of performance on that area that Torque has.

However that sentence, you have to put in the context, it was refering to mmogs, that are supossed to have infinite optimizations and changes against a fps game. Its like a general reference of something that can be done, not an out of the box feature.

Use the search box :P
#3
06/02/2009 (7:45 am)
A MMO isn't so much a simulation of the players running arouind. It's just a report of the locations and a message of the actions done.

In an MMO if player1 shoots player2, the game just sends that a hit has occurred. Collision detection is typically all client side and only occurs with the geometry.

In a FPS, the game creates and syncs an object for each bullet as it flies toward player2. So 64 players may equate to hundreds of objects that need to be tracked with full collision detection.

#4
06/02/2009 (9:10 am)
Thanks for the responses. Appreciate it!
#5
06/02/2009 (9:32 am)
So how did Asheron's Call do it then?
#6
06/02/2009 (5:56 pm)
Novack's point about networking not being an "afterthought" or something to be "plugged in at the end" is really important if you want great performing network code. Torque has always done this, sometimes even to a fault, but multiplayer networking is probably the last thing you'll need to worry about with Torque in your comparison to other engines.
#7
06/08/2009 (12:22 pm)
I guess I need to take a look at new versions of TGE/A. In older versions, collisions were detected in the server side sim. The server has many bottlenecks in the simulation, regardless of the networking code.

Older versions of TGE were architected towards an FPS with low latencies (or RTS, or what have you), and the architectural ties between tick rate and the networking code are not easily extricated.

In short, it wasn't easy to just tune some parameters in TorqueScript or C code and connect 1,000 clients to a server, even with fairly robust server machines.
#8
06/08/2009 (1:09 pm)
@Tim - That hasn't changed with TGEA and T3D. It's essentially still the same code as TGE.

GG is assuming that you're writing your own "Player" class and using the existing NetConnection class. This also means that you probably should not use the stock "Player" physics and you have to be careful with how you handle collision detection.

If you take your time and read and understand how the FPS / RTS Starter Kits work, you should be able to achieve 200 - 300 players per instance fairly easily.

1000? Maybe, but that won't have anything to do with Torque. 90% of that will be determined by your skill, knowledge of Torque, and the amount of effort you put into it.
#9
06/08/2009 (4:20 pm)
Well, I was able to get to 450 on older 64-bit AMD machines, with player collisions, but the simulation optimizations and networking changes necessary to make that happen were very much "non-trivial".

Certainly not something acheivable out of the box. Out of the box, we were topping out somewhere below 100, I beleive.
#10
06/10/2009 (2:57 pm)
You'll find that when 500 clients actually do typical things like running or shooting, it just won't be anywhere playable on a good home-server. Players standing still don't use up alot of CPU because the code returns early if no velocity exists.

Simplifying updatePos in Player and onTick in Projectile can go long ways. Lowering the TickRate can also work, if your game isn't twitch. WoW certainly doesn't tick every 32 ms, but it also doesn't suffer from it since the gameplay is like it is.

Wintergrasp is an area in WoW that can kill the server when around 150 or so players are around and in the same scope, and Blizzard ain't exactly staffed by morons.
#11
06/10/2009 (6:22 pm)
I seriously hope nobody expects to host an MMO or 1000+ players on a "good home server".... nor would I scope 150+ players to a single client. :P