64 player support may be possible

[Eater1]

Yes, we could add support for it to the engine however that would take a lot of time, and as of right now I know of no plans to do so.

Ouch... on behalf of software engineers everywhere I hope you don't condemn yourself to such a horrid fate. Not that it has anything whatsoever to do with player limits, but still...
Anyway, why is the U2.5 engine limited to 32 players? I would think it would be quite trivial to increase that number. Now, having a server that can chug all those 64 players is another issue, but I just don't get why Epic doesn't let server admins shoot themselves if they really want to...

 

[Waffel]

Ouch... on behalf of software engineers everywhere I hope you don't condemn yourself to such a horrid fate. Not that it has anything whatsoever to do with player limits, but still...
Anyway, why is the U2.5 engine limited to 32 players? I would think it would be quite trivial to increase that number. Now, having a server that can chug all those 64 players is another issue, but I just don't get why Epic doesn't let server admins shoot themselves if they really want to...

To increase the number of players to 64 is trivial, but there is no need to do that when the server software has its problems with memory leakage / bugs. When i read some threads over in the 'Dedicated Server Support' forum i almost choked my coffee over specs you need on the server to run with > 30 players.

IMHO I think the server software need alot of coding effort to support > 32 players.

 

[[CoFR]BeerHunter]

I don't know the details of UE3, but rest assured that once someone develops a game engine that uses multiple threads that run on multiple cores, the complexity of infantry combat games will skyrocket... Alas, so will the cost of computers.

Not to mention the cost of serves , internet connections etc. etc.

 

[Eater1]

Well, if cheating was not such a big concern, more of the calculations could be moved to the client. I think you can do that with replication code without even touching the engine itself. Maybe VAC provides sufficient cheat protection to move more of the functions client-side? Then again, I would hate to see something like "ballistics cheats" in case, for instance, projectile physics are moved client-side.

 

[Avenger]

Yes, I would like to see ballistics and even hit detection moved client-side. Hell, if you can make a game secure enough to make all the physics work on a peer-to-peer system, and then let the server just referee, you could make maps that would supports HUNDREDS of players.

 

[ButchCassidy]

At this moment RO is a long way from moving off the 32 player mark.

Even with 32 players on a server you will struggle with anything less than a 3.2 Xenon.
It also helps to have a large amount of pyhsical memory to throw at the game if you can.

Quite simply as RO servers stand right now the serverside engine would need a really massive optimization boost before even thinking about moving to 36/40 players.

I am not saying it can't be done but more like I can't see it being done unless TW do something amazing with the UT2 engine.

 

[OneInchPunch]

i have played on a server with 40 players(32 real and 8 bots). Is it normal?

 

[ButchCassidy]

No its not, looks like the game failed to kick them as players joined.
It does happen quite a lot.

 

[Eater1]

Yes, I would like to see ballistics and even hit detection moved client-side. Hell, if you can make a game secure enough to make all the physics work on a peer-to-peer system, and then let the server just referee, you could make maps that would supports HUNDREDS of players.

I'm really looking forward to the super-exciting sync issues here. Who, for instance, gets to decide if a projectile hits or not? Because if I get to decide whom my projectiles hit, I can just pull the ethernet cord and spray all the poor frozen sods just standing around, and plug it back in before the server times me out, and without the slightest bit of hacking, watch the kill commands trickle into the server and kill my enemies (who by now are probably five miles away, but not as far as my machine is concerned). If the person getting hit gets to decide if he's getting hit, same thing - pull cord, run into a room, throw nade, run out, replug - your machine couldn't pick up on any of the shot information the server was sending you, so you didn't get shot, but the nade was sent to the server at the first opportunity and cleared the room. Of course, these are extreme examples, but even unintentional lag can cause some weird results for other clients. The big benefit for server-side processing is that only one party gets to decide who gets hit - the server - and this party know precisely what kind of connection it has and everyone else know what kind of latency THEY have to the server. It really ****s when the quality of the game depends not just on your own ping, but also on that of everyone else on the server.
That being said, moving more of the processing client-side would be really cool, and probably quite possible with the current Unreal replication code, but it would not be as simple as flipping a switch.

 

[Mobius One]

Oh man, just played a 32 player full server on Berezina. That was intense. Imagine 64 players or even 128 on that map!

 

[PermenentMarker]

RO World
With bombers and fighter planes
and 256 players lol

on UT5.0

 

[Avenger]

if I get to decide whom my projectiles hit, I can just pull the ethernet cord and spray all the poor frozen sods just standing around, and plug it back in before the server times me out, and without the slightest bit of hacking, watch the kill commands trickle into the server and kill my enemies

The way I envisioned it, both the shooter's machine and the target's machine would have to agree on a hit. Furthermore, the server would send timing data to all the clients, and the clients would send position information along with the time it was sent back to the server. So with that in mind, if you lost your connection to the server, your game clock would stop and you wouldn't be able to do anything.

 

[lumberg]

RO World
With bombers and fighter planes
and 256 players lol

on UT5.0

it can probably be done on unreal 3..or 4..have you read about the upcoming game huxley? they came up with some pretty creative ways to get a large amount of players in a world

 

[Eater1]

The way I envisioned it, both the shooter's machine and the target's machine would have to agree on a hit. Furthermore, the server would send timing data to all the clients, and the clients would send position information along with the time it was sent back to the server. So with that in mind, if you lost your connection to the server, your game clock would stop and you wouldn't be able to do anything.

Well, if they disagree, who gets to decide? You still have the invulnerability issues then, not to mention a lot more traffic going up and down the pipe. Every bit ****ed [EDIT: that should be s ucked... how is that a curse word?] through the pipe uses up bandwidth, and the notion of "losing connection to the server" is really not a well-defined one, as it is dependent on a timeout. If this timeout is too short, then people will experience frequent "hickups" (assuming they don't simply get disconnected), if it's too long, you can do crazy stuff like unplug your ethernet. In the end, it will probably be a non-ideal solution, but something we can all live with - e.g. something that will allow some lame behavior with artificially-induced invulnerability, but this behavior would be difficult and in general not effective enough to be useful to cheaters. High-lag games though (like when the server is not on a very wide connection) would become a lot worse.

 

[AVATAR]

Is the 32 player limit hard coded into the game? I think you should try to increase the player count and let server administrators experiment with more players as I believe the new intel processors (or high end AMDs) perform significantly better then the previous processors like a 3.2Ghz intel xeon processor as someone said could run a 32 player server.
I could be wrong, but these graphs (on the bottom of the page) from Toms Hardware clearly shows that performance is higher on the intel Conroe processors. The over clocked one has nearly double performance over the Pentium EE 965 which I believe can be compared to the (socket 604) Xeons processor.

Although to sacrifice a server with the most modern processors exclusively to run a Red Orchestra server might be questionable, the option should still be there.

Has there been any experimenting on with 32+ servers on these new processors? Or is the performance lacking somewhere else? Memory? Network bandwidth? Because I think it should be possible to try to run servers with 32+ players, or is this possible already? If so, why is nobody trying to then? Not even something like a 34 player server to be seen.

 

[Rak]

Ouch... on behalf of software engineers everywhere I hope you don't condemn yourself to such a horrid fate. Not that it has anything whatsoever to do with player limits, but still...
Anyway, why is the U2.5 engine limited to 32 players? I would think it would be quite trivial to increase that number. Now, having a server that can chug all those 64 players is another issue, but I just don't get why Epic doesn't let server admins shoot themselves if they really want to...

Also, bear in mind that most stock maps are not designed for 64 players. So, even if the support is here, they need a huge work to get them suitable for 64 players. Even if they do, I'm sure there will be problems.

 

[Yoshiro]

Some of you seem confused on the issue. Let me say it again. We are not limited by engine. Engine hard limit is 64. We are limited by hardware.

 

[radix]

- we are running an x2 3800+ 2G ram and barely can handle a 32 vehicle map without dropping the pings too much.

- don't forget that the cpu load increase exponential with the player numbers. So maybe with a core 2 duo 6700 you could run a 34 - 36 player (vehicles) .. even if i doubt it.