Game Development Community

Network bandwith

by Steve Yeager · in Torque Game Engine · 08/18/2003 (4:45 pm) · 11 replies

I've heard that Torque has a really nice networking system, so I'm looking to try it out.

I'd like to find out approximately what size pipe would be needed to support different levels of players. 8, 16, 32, 64 and 128. T1? T3? If I could find out how much bandwidth each player uses I'd appreciate it.

I've searched and googled, but have not been able to find this data so far.

About the author

Recent Threads


#1
08/18/2003 (5:41 pm)
It depends. :)

On your game, on what people are doing, etc.

To pull a number out of my ear, try 4k/sec upload per player for the server.

Or just try some benchmarks on your own. :)
#2
08/19/2003 (7:23 am)
I figured it would depend on the game of course. Thanks for not taking the easy out...

4k/sec per player being your guess (I take it that is bytes per second right?), or about the equiv of the actual throughput on a 33.6k modem connection per player?

I'm just wondering how large a game could be hosted by someone with a minimum of DSL 128k upstream. If that's 4k bytes then that's only ~4 people which seem a little low to me.

Has anyone had any practical experience testing out the default FPS game to see how many they can host on a DSL/Cable/T1?
#3
08/19/2003 (8:01 am)
I can comment on T2 server - I dont think the netcode has changed all that much, but I might be mistaken

A 512 kbit/s DSL can host approx 12 players before ping loss and bad ping appears.

A 2 mbit game is very good for a 10v10 game, but close to the limit for a 14v14 (still playable though)

So the 4 k per player sounds like a good shot.

I should add that it all depends on your network settings. They can be trimmed on both client and server side on # of packets per second as well as max size of packets.

So the usual answer is 42 - it all depends.

To add a little to that, I heard about ppl on these forums who have simplified some of the netcode. It appears that especially the player objects have a larger data payload than necessary. Try searching and contacting the authors if you need more info.
#4
08/19/2003 (8:54 am)
There's a lot of room in the engine to trade data quality for bandwidth. If you rewrote most of the stuff in game you could get Torque using /very/ little bandwidth per player.

Of course, the link would only be suitable for a game with little in the way of physical interaction, but...
#5
08/19/2003 (9:24 am)
It is not about whether the netcode has changed or not, it is about how much information is being passed, which is solely based on the GAME. you add lots of additional attributes that have to be passed back and forth or remove some, or add lots that don't get up dated often or remove some but the rest that are there get updated every frame, like Ben said originaly "it depends".

Profiling is the ONLY way to make these kinds of measurements.
#6
08/20/2003 (8:23 am)
Thanks for the info.

It makes me wonder how the big MMORPG games are piped considering the amount of bandwidth needed to run something like that. Must be some big fat pipes to handle that sort of bandwidth. 4kps per player * 3000 players is 12 Megabytes per second, yow!

My plans are much smaller, but I'd like to get to a point where a 512k connection could handle ~30-40 players in a TPS/RPG type game. Seems like it could work. I just wanted to see if it was even in the realm of possibility.
#7
08/20/2003 (9:09 am)
MMORPG aren't fast action games like Torque was designed for, by and large. The players move slower, so you can get away with less frequent updates. Easy, eh?
#8
08/20/2003 (9:18 am)
And on that note:
I capped a flag at 130kph last night in tribes 2

:)
woot!
#9
08/20/2003 (11:17 am)
Hehe - my record is 150. Crash grabbing on Katabatic and Slapdash.
#10
08/20/2003 (11:24 am)
Gw man
this one was on Minotaur!!!
#11
08/21/2003 (9:07 am)
@Steve, Mark, Jarod: Like I said, you can trade quality/rate of updates for bandwidth. If you only send a basic positional update every half second, it takes a LOT less bandwidth than heading/position/speed/status updates at 32Hz.

This would be accomplished by modify the pack/unpack functions of the relevant game objects.