Reducing the cost of large numbers of players?

#1 One hack I've seen to make lag and general bandwidth issues less aparant, is to decrease the number of variables each object has that needs to be updated every tick. Like footstep puffs, and stuff like that. Create a different class for your turrets, that's suited for just that.. a turret, not a moving player. Etc.

I know this ain't very specific, but it works and is pretty general.

#2 RTS kit is definitely a good example of how stuff can be trimmed down. We can spout theory, too, if you like. :)

#3 Please! Real Code is always nice (even if I must part with some hard-earned cash to get it), but understanding the theory behind it will help me modify it to better fit my needs.

At least in theory.


And everyone knows the difference between practice and theory right? In theory, there's no difference between practice and theory. :\

Thanks folks.

#4 Keep this discussion moving, I'm pretty interested in this too :)

#5 A quick overview of what was done to optimize (thin down) the Player class for RTS-SK:

remove Z-axis
projectiles client side only (display only)
strip out anything having to do with movement physics (including gravity, et al, see above)
remove triggers (per unit)
scoping changed based on a server side "visibility manager"
very little data in the RTSUnit class--most updates handled by NetEvents and NetModifiers (just a "buff/debuff" dataset for that)
Use of a "selection set", and issuing orders on the entire set of selected units instead of individually

quite a bit more was done, that was just off the top of my head, and resulted in the ability to have hundreds of units in scope at once with extremely high performance, both net and client (as well as server) performance.

#6 @Stephen, just curious with the RTS SDK, did the changes have any effect on the number of real connected players there could be at a time? And if so, did you guys try to max it out and get any hard numbers?

I'm considering basing my next MMO project on RTS, but the only real point would be if there was a significant increase in the number of real players a single server could handle.

#7 I think there may be a general misunderstanding about how many clients can be connected to TGE, or RTS-SK, or any Torque product: there is no hard limit.

Yes, there is a constant or two that should be modified, since if your game never needs 2,000 connections, you want to optimize for it.

But what I'm getting at here is that it's not the engine that would limit the total number of connections--it's how you use it, and how you optimize for connections. If you use TGE improperly (ghost every object to every client, iterate over ClientGroup every tick for something in script, etc), then it will have terrible performance with a large number of clients. If you use the RTS-SK in a similar manner, then you will have the same.

There are a couple of things that could still be optimized in the RTS-SK specifically for number of connected clients, yes--first thing that comes to mind is how sendAttackEvent works at the network layer (IIRC, all attached clients get attack events sent even if the event itself isn't near scope), but again, it's not Torque that limits your network numbers, it's your hardware, your network backbone connection, your use of netcode, scoping, non-optimized processing loops, etc.

Any of the starter kits are not going to be doing this optimization for you, because it is so inherently tied to your game design and gameplay.

#8 Ok I think you might be mis-reading what I'm asking...
I realize that every game is going to have something funky chewing up the bandwidth, and I realize there are optimizations that can be done to just about any code to squeeze one or two more players down the pipe.
I also realize there are no hardcoded player limits.

That said, my question is pretty simple, in a default setup on pretty standard game server hardware, what's the most in terms of real players GG has been able to achieve simultaneously, using the RTS-SDK. Furthermore is this number significantly higher than similar tests done in TGE.

Another question which should probably be asked first, "Has garagegames, ever tried to do load testing to see how many simultaneous players can be handled by a single server running either TGE, TSE, T2D or RTS?".

If you've never tested this, then my whole question is moot.

At which point my nest question would be "In theory, would a game based on a stock RTS implementation be able to handle more players, than a game based on TGE, assuming of course no modifications to even one line of code, if so theoretically how many more or better as a function of percentage."

Anyways, thanx for the reply.

p.s. As a heads up, I HAVE tried to load test TGE in a local WAN (neighborhood wifi), situation. I was able to handle 80 players before there was a severe framerate drop, and 190 before the server completely puked and died. However after about 50 players, on a single server, if anyone fired a weapon, everyones framerate dropped to about 2 fps, for approx 2-5 minutes. This was done with completely stock TGE running starter.fps on a purpose built Gentoo Linux server, running nothing else. AMD Athlon 2200+XP, ATI Radeon 9200 SE (As if that mattered on a dedicated build), 1gig DDR SDRAM, and a 7200 RPM HD w/ a Gigabit LAN connection hardwired to the local neighborhood wifi router.

#9 I have that comlpete setup for a part of my game using the RTS Kit. Funny everyone always has the same ideas as me.

#10

Quote:p.s. As a heads up, I HAVE tried to load test TGE in a local WAN (neighborhood wifi), situation. I was able to handle 80 players before there was a severe framerate drop, and 190 before the server completely puked and died. However after about 50 players, on a single server, if anyone fired a weapon, everyones framerate dropped to about 2 fps, for approx 2-5 minutes.

As a follow-up to my statement, I'll ask you questions about this test case:

--Were all these players standing in visible (and scoped) range of each other?
--What user inputs were they giving while this happened?
--What was the packet throughput on your network? It sounds as if your clients were all connected via wireless, so what was your packet loss and packet rates for the wireless router? (unless you didn't mean "wireless" when you said wifi).

The point of my questions being that as I've said in both this thread and others, there seriously are no meaningful tests that can be performed on a stock core technology configuration. Raw performance/bandwidth metrics are even almost useless, because so much of a game design affects proper use of the available resources to your server environment and architecture.

And to answer your question, no I am not aware of any structured max client load tests performed with TGE 1.3--for one, GG simply doesn't have the bandwitdh or server/client infrastructure to even approach those numbers, even if it would be a meaningful and valuable test statistic. Anecdotal observations at IGC's are probably the best sample datasets available.

#11 Probably wildly offtopic, but I've seen/participated with the Tribes 2 incarnation of the engine and we had over 60 people in scope. (screenshot from a beta test run of tribes 2)
Screenshot
I can't for the life of me remember what hardware I was running at the time, but it wasn't anywhere near what I have now ;) I think I recall getting somewhere near 5-6 FPS.

#12 @Stephen, to answer your questions about the tests...

#1 No, many players were just hanging around close to the spawn points, so MANY of them were,within visible range, but at no time were all within range of each other.
#2 The ones who were there to play, treated it like a typical FPS and ran around shooting people, however since most people were there for the quick $5 (I bribed everyone with $5 to help out, all they had to do was install the program, and login at the aforementioned time), the majority of people stood around not doing anything.
#3 I'm not sure anymore about throughput and the like this was done a few months ago, again just as a proof of concept to see how many servers would be used to support x/# of people. Our conclusion was that you could comfortably host around 50 people per server in the stock fps, with modern server hardware on a WLAN setup. While it's not the most scientific way, we dedicded to slash that number for our purposes and set a target of 35 per server, this seems to work pretty good.

#13 Thanks for doing all that, dreamer! Seems like good stuff to know, anyway.

Can't believe you actually bribed people with $5, ROFL. That's awesome.

#14 @Dreamer: Network load testing on a stock TGE/Kit combo sounds like good stuff to know about. I'd love to see some data (in another thread?)

@Stephen Zepp: First, thank you Very Much for taking the time to reply. Really apprecaite it.

Second:

[qote]
projectiles client side only (display only)
[/quote]

Allow me to guess what this implies:

0) new type of projectile? This may just be a particle effect on the client, which wouldn't require any new classes, just a "novel/inobvious" use of an existing one. ;)

1) After the initial "fire" event, there's no more network traffic. The result of the shot is decided on the server, though it may not be displayed until some point in the future (involving more traffic)

2) The graphic of a given projectile may appear to miss (or hit), but that won't have anything to do with whether or not the projectile ACTUALLY missed (or hit). Return traffic from the server could let each projectile know to "stay on target" if it's going to hit, but that sounds optional.

3) instant-hit weapons are actually easier than the usual projectiles. The optional "stay on target" traffic vanishes, and there's no need to schedule weapon damage (less server overhead).

4) Projectiles are normally (outside the RTS kit) full objects with velocity, transformation (loc/rot/scale), a model and so on. They're positions are updated along with everything else across the network.

5) The stock RTSUnit isn't going to do me much good (no 'Z' coordinate), though it shouldn't take a Stroustrup to put it back in.


This suggests to me a number of things:
1) A wing of fighters could be a single object until it's close enough to matter (break formation, loose members, etc). At the range these guys would exist, you'd really only need low-poly versions of its members.

2) A wing of fighters could stay a single "object"... one with no collisions of its own, and a whole slew of mount points for its damageable members. Each mount point could then be targetted and fired through a single AI player. (I like the sound of that quite a bit, though the formations would have to be RIGID, which isn't so great... perhaps formations could be composed of sub-groups (wingment), and allowed to shift around at that level).

But that implies mounting an object reduces/removes its traffic (which is almost certainly not the case). Hmmm...

On the other hand, this is almost exactly how I'd want to handle one of our electronic warfare ideas: a drone that projects the image of a fighter group. The player would need to have researched/constructed better sensors/ECM to see through the illusion. The drone could be invisible until detected (but with collision detection)... all the 'fighters' would just be holograms.

#15

Quote:--What was the packet throughput on your network? It sounds as if your clients were all connected via wireless, so what was your packet loss and packet rates for the wireless router? (unless you didn't mean "wireless" when you said wifi).

from personal experience at my college (it being set up through a lot of wireless connections... when you load a lot of people onto one (or even a couple) wireless access points(or routers), it kills the connection, especially in gaming.

#16 @Mark: No questions that I could find, but yes, your observations are all pretty valid! And I agree on the "formation is one object"--you can use a variety of herding/flocking algorithms for the rendering, and things would "look" pretty cool, but not take nearly as much bandwidth (assuming it's optimized well). Based on playing Medieval:Total War, I think this is how they do their unit squads myself.

There is some tech in the Garage that uses this concept to AMAZING effect as well...but the fxReplicators use the same idea, and could be extended for what you are describing.