Is Torque good for Multiplayer games?
by Shane · in General Discussion · 09/15/2008 (4:29 pm) · 19 replies
I am only here for multiplayer games. Before I start learning Torque, I want to know if it's good for creating multiplayer games. I heard the engine was really created for campaign type games, and if it goes multiplayer you can only have like 20 or 30 players or something like that. That's what I heard. If I wanted to make a multiplayer game, would Torque be the right engine for this?
About the author
#2
Just wanted to pile on :-)
10/11/2008 (1:49 am)
Torque is kickass for multiplayer. It's more the native intent, in fact, as Mike said.Just wanted to pile on :-)
#3
Torque has an MMO kit available which is what i am assuming your looking for.
10/11/2008 (6:22 am)
@fox Torque has an MMO kit available which is what i am assuming your looking for.
#4
Now THAT is impressive.
10/13/2008 (4:53 pm)
Torque has the best netcode in existence. Not even the Unreal engine can touch it. Here is an example... before Torque became Torque, it was owned by Sierra/Dynamix and was used to create Tribes2. On a 28.8kbs dial-up connection I could play on a server with 32 people and zero lag. That included people using jetpacks and vehicles driving/flying all over the place.Now THAT is impressive.
#5
If not anything else, the multiplayer functionality alone is a good reason to use Torque. It is actually what my deciding factor was when I originally scoped out the engine.
10/13/2008 (4:59 pm)
Oh, and there is no hard-coded limit to the number players that can connect to a Torque server. The number of players are only limited by your bandwidth, and of course the client's bandwidth. But Torque does some excellent prediction and prioritizing of data to be sent and received. So even tho the data being sent to the client might be a bit too much at times(depending what is happening around the player), Torque does a good job of making up for it to keep the game running smooth.If not anything else, the multiplayer functionality alone is a good reason to use Torque. It is actually what my deciding factor was when I originally scoped out the engine.
#6
and server CPU load and, depending on the situation, client rendering performance.
and yes, TGE's networking is quite good.
10/13/2008 (5:20 pm)
> The number of players are only limited by your bandwidthand server CPU load and, depending on the situation, client rendering performance.
and yes, TGE's networking is quite good.
#7
And that, too. :P Sorry, should have mentioned that.
10/16/2008 (12:40 am)
Quote:> The number of players are only limited by your bandwidth
and server CPU load and, depending on the situation, client rendering performance.
and yes, TGE's networking is quite good.
And that, too. :P Sorry, should have mentioned that.
#8
11/29/2008 (7:21 am)
Actually there are hardcoded limits to how many players can connect to a single server.
#9
11/29/2008 (9:33 am)
Hm, where ?
#10
It's apparently hardcoded in the networking code to support up to 120 connections if memory serves me correct.
Don't quote me on that, but that's basically what I was told, though I don't have the email here right now so I can't double-check it.
11/29/2008 (9:36 am)
I haven't looked into it, but that's what I was told by GG employee's numerous times when we've discussed licenses.It's apparently hardcoded in the networking code to support up to 120 connections if memory serves me correct.
Don't quote me on that, but that's basically what I was told, though I don't have the email here right now so I can't double-check it.
#11
Quake and Unreal engines in my opinion is just absolutely horrible at dealing with latency issues, its just really bad and frustraighting at times. It find it funny that after all of these years nobody has decided to sit down and correct Quake 3 Arena's lag compensation problems because I still see the exact same issues that I saw back in Quake 3 Arena and Wolf:ET that I see in Call of Duty 4 and all other current Quake 3 based games (anti-lag mode turned on servers makes things a lot worse). I believe even the current Quake 4 engine still has the same exact networking code from what I've been told, but I haven't touched any of those games as for as multiplayer to know for sure.
It still amazes me how very well Torque's networking stands up to today's other gaming engines' networking support. It was definitely designed perfectly well from the start and continues to work perfectly fine from all the various tests I've done with some friends a while back.
Now keep in mind that from the very second you grab Torque and begin to use it don't expect the networking to fit your needs perfectly right away. You will need to tweak it by changing packet sizes and what not. Such as you'll need to adjust these preferences in TorqueScript:
See Torque Console Objects -> Net Connection section for details.
11/29/2008 (10:23 am)
Even if there are hard coded limits since you have full source code access to the engine upon becoming a licensee then there's nothing stopping you from changing it to however you see fit. I also have to give praise for Torque's great networking support and keeping the game synced even during lag spikes and the like.Quake and Unreal engines in my opinion is just absolutely horrible at dealing with latency issues, its just really bad and frustraighting at times. It find it funny that after all of these years nobody has decided to sit down and correct Quake 3 Arena's lag compensation problems because I still see the exact same issues that I saw back in Quake 3 Arena and Wolf:ET that I see in Call of Duty 4 and all other current Quake 3 based games (anti-lag mode turned on servers makes things a lot worse). I believe even the current Quake 4 engine still has the same exact networking code from what I've been told, but I haven't touched any of those games as for as multiplayer to know for sure.
It still amazes me how very well Torque's networking stands up to today's other gaming engines' networking support. It was definitely designed perfectly well from the start and continues to work perfectly fine from all the various tests I've done with some friends a while back.
Now keep in mind that from the very second you grab Torque and begin to use it don't expect the networking to fit your needs perfectly right away. You will need to tweak it by changing packet sizes and what not. Such as you'll need to adjust these preferences in TorqueScript:
$Pref::Net::LagThreshold = "400"; $pref::Net::PacketRateToClient = "10"; $pref::Net::PacketRateToServer = "32"; $pref::Net::PacketSize = "200";
See Torque Console Objects -> Net Connection section for details.
#12
Seems too many people throw out numbers so they sound intelligent when referring to Torque Network Library. (doesn't apply to Nathans post above ).
(The TNL is built into the game engine or it can be purchased seperately.)
Read this thread from Ben Garney
and this one: www.garagegames.com/mg/forums/result.thread.php?qt=12049
You can even check the book "Multiplayer Gaming and Engine Coding" by Edward F. Maurina III, where he discusses this very question. ( I'll update this when i get the Page Number )
32 Players were handled on a 28.8k Moden back when Tribes2 was new. It no longer applies since Hardware and Bandwidth is now the limiting factors.
121 Players was the observed limit for the Afterworld game.
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=11978
The Master server itself should not have any limits.. perhaps tens of thousands?.. because the Master Server only lists the Game Servers IP address, and each ping to the Master server is just seconds or fractions of a second.
The Game Server is where one bottle-neck will be.
It is responsible for sending packets to each client when it receives a Client to Server command. roughly 32 to 64Kb per packet was bounced around the forums as a hard number.. but this is just an approximation since the Packet size is really based on your code.
Another Bottle-Neck will be the Bandwidth available for those Packets to be sent across and the Hardware you have to handle the load.
Another Bottle-Neck will be the amount of clients sending commands to the server at the same time and the type of information the Game server has to send back.
TNL is a smart and robust Network Library that when understood and mastered.. you'll know better how to make your game use less resources on the Game Server side and therefore allow your precious bandwidth to either reduce Latency or permit more players to connect.. or both depending on your game style, programming habits, and number of players connected simultaneously.
The hard-coded 120 player Myth should die here in this thread. It's not reality.
11/29/2008 (10:53 am)
I thought this question was covered is other threads.Seems too many people throw out numbers so they sound intelligent when referring to Torque Network Library. (doesn't apply to Nathans post above ).
(The TNL is built into the game engine or it can be purchased seperately.)
Read this thread from Ben Garney
and this one: www.garagegames.com/mg/forums/result.thread.php?qt=12049
You can even check the book "Multiplayer Gaming and Engine Coding" by Edward F. Maurina III, where he discusses this very question. ( I'll update this when i get the Page Number )
32 Players were handled on a 28.8k Moden back when Tribes2 was new. It no longer applies since Hardware and Bandwidth is now the limiting factors.
121 Players was the observed limit for the Afterworld game.
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=11978
The Master server itself should not have any limits.. perhaps tens of thousands?.. because the Master Server only lists the Game Servers IP address, and each ping to the Master server is just seconds or fractions of a second.
The Game Server is where one bottle-neck will be.
It is responsible for sending packets to each client when it receives a Client to Server command. roughly 32 to 64Kb per packet was bounced around the forums as a hard number.. but this is just an approximation since the Packet size is really based on your code.
Another Bottle-Neck will be the Bandwidth available for those Packets to be sent across and the Hardware you have to handle the load.
Another Bottle-Neck will be the amount of clients sending commands to the server at the same time and the type of information the Game server has to send back.
TNL is a smart and robust Network Library that when understood and mastered.. you'll know better how to make your game use less resources on the Game Server side and therefore allow your precious bandwidth to either reduce Latency or permit more players to connect.. or both depending on your game style, programming habits, and number of players connected simultaneously.
The hard-coded 120 player Myth should die here in this thread. It's not reality.
#13
...
Sorry Scott, but your first quote seems to sum up your own way of posting quite well. For one, it's impossible to contain 32 kb in one packet, let alone 64 kb. This has nothing to do with Torque. The maximum in Torque is set at 1.5kb (like many ethernet interfaces out there) and even that is quite a bit.
"ClientToServer" has nothing to do with how the server sends out packets. It's a script interface to an RPC system called NetEvents. The master server can't handle tens of thousands because your O/S won't be able to handle that many sockets (in the case of TCP/IP) without breaking and there's simply performance factors limiting 10k connections even in the case of UDP.
11/29/2008 (11:11 am)
Quote:
Seems too many people throw out numbers so they sound intelligent when referring to Torque Network Library.
...
Quote:
The Game Server is where one bottle-neck will be. It is responsible for sending packets to each client when it receives a Client to Server command. roughly 32 to 64Kb per packet.
Sorry Scott, but your first quote seems to sum up your own way of posting quite well. For one, it's impossible to contain 32 kb in one packet, let alone 64 kb. This has nothing to do with Torque. The maximum in Torque is set at 1.5kb (like many ethernet interfaces out there) and even that is quite a bit.
"ClientToServer" has nothing to do with how the server sends out packets. It's a script interface to an RPC system called NetEvents. The master server can't handle tens of thousands because your O/S won't be able to handle that many sockets (in the case of TCP/IP) without breaking and there's simply performance factors limiting 10k connections even in the case of UDP.
#14
11/29/2008 (1:08 pm)
Stefan just because Windows servers cannot handle 10k connections doesn't mean other operating systems can't (like BSD*, Linux, etc..). Not to mention UDP is connectionless and stateless.
#15
Quote:
"The master's client limit should be well above tens of thousands -- though it would be useful to write a stress-test program to be certain. All of the packet dispatch code within TNL is amortized O(1) due to hashing -- the only O(n) is a simple loop for checking packet sends. You may run into some issues with the public key crypto depending on your key size, but then that's a one-time hit when the connection starts up. Once a connection is established it assumes very little overhead."
From: Mark Frohnmayer ( GG Employee )
Quote:
"There's no upper limit. I would suggest doing some stress tests with your expected hardware and net connection to get an idea of what performance you can expect.
Er.. Given that Zap does not have several thousand players, the tech is relatively new, and so forth... how do you expect that anyone will have a hard answer to this question? :)"
From: Ben Garney ( Associate )
This is in fact used as a reference from the ZenEngine site.. in their forums .. to compare ZenEngine ability to TNL. ( Used to illustrate my point )
I purposely went to drag these quotes out of the forums.. They are the ones I read for reference.
About the only thing I wrote in my post that could be misguiding is
I should have written it more Technically for those people that know the language so it wasn't misunderstood to be a command that it wasn't meant to read like.
At the very least, my post was intended to show the engine doesn't have hardcoded 120 simultaneous player connections.
Forgive me for any inaccuracy or innability to communicate that point clearly enough.
11/29/2008 (3:23 pm)
@Stefan:Quote:
"The master's client limit should be well above tens of thousands -- though it would be useful to write a stress-test program to be certain. All of the packet dispatch code within TNL is amortized O(1) due to hashing -- the only O(n) is a simple loop for checking packet sends. You may run into some issues with the public key crypto depending on your key size, but then that's a one-time hit when the connection starts up. Once a connection is established it assumes very little overhead."
From: Mark Frohnmayer ( GG Employee )
Quote:
"There's no upper limit. I would suggest doing some stress tests with your expected hardware and net connection to get an idea of what performance you can expect.
Er.. Given that Zap does not have several thousand players, the tech is relatively new, and so forth... how do you expect that anyone will have a hard answer to this question? :)"
From: Ben Garney ( Associate )
Quote:32 to 64Kb per packet
This is in fact used as a reference from the ZenEngine site.. in their forums .. to compare ZenEngine ability to TNL. ( Used to illustrate my point )
I purposely went to drag these quotes out of the forums.. They are the ones I read for reference.
About the only thing I wrote in my post that could be misguiding is
Quote:Client to ServerI thought I was relating to the means in which a packet is sent.. not the "ClientToServer" command.
I should have written it more Technically for those people that know the language so it wasn't misunderstood to be a command that it wasn't meant to read like.
At the very least, my post was intended to show the engine doesn't have hardcoded 120 simultaneous player connections.
Forgive me for any inaccuracy or innability to communicate that point clearly enough.
#16
11/29/2008 (4:11 pm)
You have all been voted off the island ;P
#17
Nowhere does he say it would support 10k connections. No need to exagurate.
Honestly, either you're reading it wrong or the guys at the forum are wrong. There's no way you can stuff 64, 32, 16, or even 8kbit into a packet with most ethernet devices only allowing 1500 bytes MTU. The packet will drop somewhere between the peers. Even a 1480 packet is unreliable as you have to take the UDP header size into account. Someone comparing this between two engines and states it's a strength of either has no clue what he's talking about or is trying to gain cheap points.
This is all really basic stuff which you can look up at good reliable sources (ie, not a forum..). Referencing another forum as fact just makes this one look bad when the referee is incorrect.
For example, a 1500 byte packet, the largest allowed by Ethernet at the network layer (and hence most of the Internet)...
11/29/2008 (4:52 pm)
Quote:
Quote From: Mark Frohnmayer ( GG Employee )
Nowhere does he say it would support 10k connections. No need to exagurate.
Quote:
This is in fact used as a reference from the ZenEngine site.. in their forums .. to compare ZenEngine ability to TNL. ( Used to illustrate my point )
I purposely went to drag these quotes out of the forums.. They are the ones I read for reference.
Honestly, either you're reading it wrong or the guys at the forum are wrong. There's no way you can stuff 64, 32, 16, or even 8kbit into a packet with most ethernet devices only allowing 1500 bytes MTU. The packet will drop somewhere between the peers. Even a 1480 packet is unreliable as you have to take the UDP header size into account. Someone comparing this between two engines and states it's a strength of either has no clue what he's talking about or is trying to gain cheap points.
This is all really basic stuff which you can look up at good reliable sources (ie, not a forum..). Referencing another forum as fact just makes this one look bad when the referee is incorrect.
For example, a 1500 byte packet, the largest allowed by Ethernet at the network layer (and hence most of the Internet)...
#18
And you can dissagree with the employee / associates that wrote the comment.
I see your looking for arguement with me, I quit.
See I read the way you quoted me ( quoting somebody else ) to twist it into meaning what you perceive it to be and then argue a point for nothing.
I wouldn't care if you were Einstein himself, if you don't read the entire Post and comprehend it the way it was meant to be read, then sorry Einstien.. you need to read it again until it makes sense to you.
But please, don't partially quote me while I am quoting another persons post.. it just makes you seem arrogant.
Bah.. argueing with you in this thread doesn't make me sound any better.
11/29/2008 (4:56 pm)
Ok Stefan I give up on you. The information is out there for the forum readers to see for themselves.And you can dissagree with the employee / associates that wrote the comment.
I see your looking for arguement with me, I quit.
See I read the way you quoted me ( quoting somebody else ) to twist it into meaning what you perceive it to be and then argue a point for nothing.
I wouldn't care if you were Einstein himself, if you don't read the entire Post and comprehend it the way it was meant to be read, then sorry Einstien.. you need to read it again until it makes sense to you.
But please, don't partially quote me while I am quoting another persons post.. it just makes you seem arrogant.
Bah.. argueing with you in this thread doesn't make me sound any better.
#19
First off, I didn't say Master server. I replied to a post about a Torque server, thus assuming no changing of the source-code.
TNL is optimizedfor FPS multiplayer, and somewhere along the line the coders figured out that an ok number was around 120 something.
No, I do not have the exact numbers, I don't have the email here (From various GG employee's) but that's what they told me.
It's been optimized to not drop any packets etc. etc. etc. (No I'm not a network coder either.)
Just look at the source if you're arguing what sizes. Or call GG and ask them. lol
11/29/2008 (5:09 pm)
I'm smiling at this.First off, I didn't say Master server. I replied to a post about a Torque server, thus assuming no changing of the source-code.
TNL is optimizedfor FPS multiplayer, and somewhere along the line the coders figured out that an ok number was around 120 something.
No, I do not have the exact numbers, I don't have the email here (From various GG employee's) but that's what they told me.
It's been optimized to not drop any packets etc. etc. etc. (No I'm not a network coder either.)
Just look at the source if you're arguing what sizes. Or call GG and ask them. lol
Torque Owner Mike Rowley
Mike Rowley
If you want to see it in action, try Instant action.