"Large amount of characters"

#1 in one scene?

1 to 32 depending on your video card the the complexity of the models and other resource eating aspects of the game.

No first person game is going to get "massive" battles like in Braveheart or even like what occured in World war I or II. Ever wonder why all the games only show a tiny part of the war with only a few people attacking on each side? heh.

I don't think the number really matters. All I can say is it will have enough. Tons of people usually means lamer newbies can just go for gank kills (cheap no skill kills) then run away. By the time someone notices where they are they are hiding somewhere out of reach like cowards.

We really don't know (I'm speaking for everyone cept GG) what will be coming from this game or where it's heading. All I think we know is what can be found on the site itself, and GG won't be around the forums for the next week to answer questions.

So let's brainstorm ideas instead of ask technical questions about a game that is basically just passing the first few steps of design and into implementation. This isn't a game right now, and I'm pretty annoyed to see how many people aren't bright enough to see it.

Don't like that it's only one map, one model, and one gun? too bad, it's not a game yet...

#2 Per "map" I'd probably go with the comfortable figure of 64 people. Although it does tend to require those 64 people have more modern systems and video hardware then that which was available during the release of T2.

If you've read the design docs (which I do recommend if you are interested in doing work on this project) you'll notice that what I described above would be but a small portion of the entire game world.

The Realm Wars game design brings together alot of elements that I know some Modders and Ladder teams have thought of since the early days of Tribes 1.

Persistant Universe, where you are able to keep your character through many battles, possibly earning special weapons or armor, thousands of other players not just fighting on other servers... but fighting battles in another part of your world. Overall it looks to be a very ambitious project, and I hope RL cuts me some free time so I can get some time to get back into the swing of MODing / Scripting again.

#3 256 is the MAX that T2 is SUPPOSED to handle.. now if you can find 256 people who have true supercomputer's then im sure its possible... of course new map's would be in order. but id safly say that for T2 its around 64 (thats about all i can handle without MASSIVE FPS loss)

#4 How does asking a simple question get me a rant about newbie kills?!?

I just wanted to know if there was going to be much more of a difference than a like T2...since i kept seeing things like "epic battles" and "large amounts of players". I wasnt gonna try and criticize this game for any lack of technical merit it had. I was trying to get an estimate of the number of people on a side....especially if we are gonna design "close formation fighting".


JDub

#5 The limiting factor will also depend on the number of polys being used by all the models and what type of terrain detail and textures are being used in the area of large battles. I want to put in a few myself. The other thing that can really cut down the FPS rate is over-using the emitter effects. The first flame thrower weapon script I made wasn't very frame rate friendly. Viewing the FPS when experimenting is really helpful.

#6 128 is the limit in Tribes 2, and I doubt that limit was ever reached in a game!

Over 64 required good hardware and a great server, but 100+ wasn't uncommon to occasionally see.

With persistant characters you're going to need to come up with some extensive way to ensure balance. Otherwise you're going to have some newbie pick up a sniper-like character and mow down the "higher level" players which would really kill the fun quickly.

Of course... the higher level guys SHOULD be able to mow down newbies, but that would really annoy newbies quickly.

#7 I just thought of something. How about as more and more people get on your screen, the player models get worse and worse to compensate for the increased load on your computer. It should be something like, assuming the poly's for a single person is 1000:

8 people: 1000 poly models

16 people: 800 polys

24 people: 600 polys

32 people: 400 polys

40+ people: 200 polys

It'll get really, really ugly once there are a lot of people, but frankly, I'd be more worried about those 4 guys wielding broadswords than what the models look like. Also, it could adjust the terrain/building detail, texture detail, etc. I think if you can get 8 people in a battle with 1000 poly's, then 40 people with 200 polys will look terrible, but be playable (same number of polys, slightly more load because of multiple people and more weapons). But I'm not sure on the exact poly count (I bet it's somewhere in the design docs, but I haven't checked) or the amount a person could render before the game is unplayable. Well, that's enough on this.

One last thing, it could also simply take into account ping time and adjust it to a comfortable setting, which is increased slightly in pitched battles (who cares about who you hit, when there are 3 people in a row, you're gonna hit one of them). Well, that's just my 2 cents.

#8 I am curious about the feasibility of his model switching idea. I was thinking of doing something along those lines.

What do you guys think? How feasible is this? How much would it help? How else can you help performance? Ditch all particle effects completely if there are too many players perhaps?

#9 Well, of course you need to have a good model LOD system! This talk of 32 models on screen at once -- pshaw, I say, pshaw! My Voodoo3 card ran the Serious Sam demo smoothly with well over 100 characters on screen. You have to realize that if you have 128 people surrounding you, only a small fraction of those people will be close enough to render at full detail. The rest can render at progressively lower levels of detail; I know I never noticed any 'model-switching' effect with Serious Sam. And that's with enemies that are *all* homing on you; good level design would prevent massive clustering, so the fighting would be spread out over several areas, and especially if a significant portion of the fighting occured indoors.

And there *were* 128-person Tribes 2 games, and they didn't take a super-computer necessarily -- well, any more than the game does normally. :P I never noticed any additional slowdown over the memory leak problems and the UE problems . . . but my ping was still eminently playable to those servers.

#10 The limit also is not just graphics hardware based. If you have 100 players that are all close to you, it requires a very large amount of bandwidth to keep every updated on where they other players are. Remember, since RW/Torque/T2 are client-server based, as the number of players increases, the amount of bandwidth goes up factorially.

Josh

#11 Leaning on Torques ability to comfortably do Server side maps rather well, we could "simmulate" a world of thousands in hunks of 32 and 64.


Very simply, the idea works like this:

You have a central "Realm Server". This server hosts and manages the persistent state of the Meta Universe. It uses a large, campaign styled, map. Every multiplayer map Realms has could be represented on the campaign map as a territory or province.

Now, whenever one of the dedicated community servers roll over and prepares to load a map in its rotation (just like any normal FPS dedicated server would do), it asks the Realm server, "We're about to play MapA, what is the state of MapA?".

The Realm Server then replies with something like, "MapA is currently controlled by Team 2. Team 2 has fortified the map, it is nighttime and there is a rain storm. You should play a seige game type."

The community server then takes that and pieces together a map with "prebuilt" settings it has for MapA. So it would use the MapA terrain. It would setup the global effect of rain and lightning with heavy fog. It would use the nighttime lighting file and it would use the building set of a fortifide outpost with a seige gametype.

The players play the map for that rotation and when a winner is declared, the server reports back to the Realm Server with "We played MapA, Team 1 was the victor".

The Realm Server then records a +1 in the current tally for MapA favoring Team 1. After a set time, the Realm Server (for example, every 10 hour period) tallies up all the wins and loses recorded for MapA from every dedicated server that reported to it. The Realm Server then decides what changes are warrented for MapA. Most likely it would change "Nighttime" to "Early Morning", "Rain Storm" to "Cloudy or Drizzle" and it would use the win/lose tally to decide if the gametype should change. Perhaps there is a global consensus that Team 1 has a decisive number of wins and so the Realm Server downgrades MapA to a "village" in controll of Team 2 and plays a Capture and Hold gametype for the next round.

Next time our Community Server rolls over to play MapA it will receive new settings. Hence we simmulate an ever changing world where thousands have an effect on its progress by playing it one, 32 or 64 player game at a time.

#12 "factorially" isnt a word. :) I think I knew what you meant (exponentially?), but that doesnt make sense. The amount of bandwidth should increase linearily as you add more players, correct?

Yes, you could probably split it up into smaller battles. But that isnt as cool. :) It is much cooler to have lots of people fighting in a small area, at least IMHO.

I am glad to see that serious sam was able to pull off a 100 characters without slowdown...

Does anyone know what kind of an effect dynamic model switching would have on performance? Meaning, if we made it based on both distance and performance, would it have appreciable benefits? Is there some other way to optimize? What takes the most processing power/cuts down the framerate the most? I have no idea, and woul dbe glad if someone could enlighten me... :)

#13 I think 64 players in an action based game is a very busy game. Sure "epic" sized battles would be fun, but hard to balance and keep from bogging down into mayham that goes nowhere. Hard to keep the focus of a large number of players contained on the goal of the gametype as is it seems (judging from current action games). Though I love a challenge :P and it would be cool.

#14 If it isn't, Factorially should be a word...

Factorials are those things that go 4! = 1x2x3x4, 5! = 1x2x3x4x5, and so on...

Can't go up in linear fashion cause every extra player that connects sends their data, which gets sent to all existing players... As players increase, the amount of extra bandwidth per player goes up faster than the number of players.

I hope all that makes sense...

#15 Yeah, thats right. I meant that it goes up linearily for the players, not the server. I wasnt thinknig about the server, but that is a perfectly good point.

#16 About level of detail and other schemes: (This is a pretty interesting subject)

Ever play Messiah? Messiah used a method where character models were calculated on the fly, added to and subtracted from based on performance. I won't get into the problem but there are many with that sort of approach.

The basic LOD approach is to model a character at full res, then say half res, then half res again, etc. (Numbers chosen for convenience) Note that 1 + 1/2 + 1/4 ... = about 2. So the LOD scheme uses twice the disk space (and potentially twice the ram for vertex data and such) as no LOD.

A common problem in LOD schemes is when you switch from one version of the model to the other and you can see it "jump" from one version to the next. Getting the distance right on switching depends on a lot of factors. Generally erring on the side of less jumpiness looks better but you may end up losing most of what you would gain from the lower res model. Dynamic systems like in Messiah can appear to bubble or boil which is very disconcerting, sort of a 3d equivalent of aliasing problems when you scale images. (Dynamic system also run into caching issues, as in you can't really use cache effectively)

It depends on all sort of factors. What are the bottlenecks, how quickly do characters move and how close are they on average?
---------------
I have no idea if the Torque engine has any support for this, or whether it would be worth adding. It it does have the support I would assume it will be used. However it seems safe to guess that whatever LOD scheme T2 used or didn't used will carry over to RW, so I wouldn't look to that for a source of improvement.

If the Torque Engine doesn't have the support and the GG people think that support would benefit the Torque engine you just found yourself an interesting problem to work on :) Computer graphics problems are fun!