hey guys, im researching the concept of an MMO that is twitch based instead of stats based, and im curious for your input. To the best of my knowledge, SOE's PLanetside is the closest commercial title to use such an arrangement. my problems with planetside are many, the actual stability of the game isnt aweful but the delivery creates several networked based problems(stutters, mis-hits based on CSD), the actual game mechanic is also geared to nullify user skill. Instead they use a watered down version where just about anyone can kill anyone else so long as they are paying attention. for example in most twitch based shooters i can kill 5 or 6 or even 7 people in the space of a few seconds without being killed. In planetside, if 1 skilled player meets another unskilled player and they both shoot in the appropriate direction, the skilled player might win after having lost roughly 50% of their health, barring healing or repair this creates a state where skill truly means less, as the next such encounter results in that players death. Perhaps this design choice was meant to make balancing easier, as the player skill is generally the unknown in the equation, but when teamed with the other network blackeyes i cant help but think the design was choosen to mitigate the "looseness" of the update time. whereby the server as authority honestly doesnt know who shot who first or where.(or at least doesnt know in a timely enough manner to maintain the illusion of liquidity) The finest of the FPS's appear to limit the number of players to 30 or 40 people . In these you'll typically find so accurate an approximation that people who say otherwise are quickly labelled "whiners". Long story short, is an FPS containing (lets say) 500 people in a single zone(map, instance, whichever terminology makes the most sense to you) possible, and is it possible in a way other than planetsides "watering down" of the player skill? if so, what are some examples that fit in this description?

The 'skill' behind most of fps games is 80 % reactions, speed and accuracy.
The other 20% is often knowledge of the environment/physics and planning.
Your question sounds to me like 'what can I do to increase the skill gap?'.

You could make weapons more deadly, like UT's instagib. It requires so much speed and accuracy that 'Newbs' are bound to die, but these skills are learnt pretty quickly. So you can't really do this to increase the skill gap for a mmo - because its supposed to be played for a long amount of time.

So you have to increase the other 20% - make it so there are lots of nuances to be learnt and have complex interactions between things so people will figure out what is the best and what isn't.
Maybe a good example is chess - a new player knows how each piece acts initially, but he doesn't know long range tactics or how to use the pieces together effectivly.

I can't think of any good relevant computer game examples of this though ;/
Or how to apply it in a fpsmmo. I'll think about it.

Quote:

Original post by Anonymous Poster Quote: Original post by Dreddnafious Maelstrom Long story short, is an FPS containing (lets say) 500 people in a single zone(map, instance, whichever terminology makes the most sense to you) possible, and is it possible in a way other than planetsides "watering down" of the player skill? Yes, but it requires a skilled server developer, and very few games companies have decent server developers (most have barely competent ones). If you devote time and effort to learning the skills of a network developer and those of a server dev, you could implement this yourself. Might take you years, though.

it's odd, but having read a lot of papers by self-proclaimed experts in the field, this is the same impression i get. how is it that AAA title games are so stagnant in the network code area? (if this impression is true)

and if this impression IS true, is the lag between what is possible and what is generally implemented similar to the lag between what some of the better engine programmers here are doing and what a AAA title is releasing or is it even greater?


As to taking years to become a skilled server developer, sounds about right. I began using DirectPlay and found it simple, and then of course it became deprecated and i found out how interesting sockets programming can be. Long story short, i still have more 3d engines written than servers, but there is something addictive about socket programming as well. :)

A properly designed network architecture should easily be able to handle an action game with 500 players. I don't even think it would be a stretch to fit all of them on the same physical CPU.

For reference, right before we shipped Tribes 2 at Dynamix we did some test games with 100 human players on a 1.4 GHz Pentium 4 that didn't even max out the CPU. Bandwidth per client was fixed at 3 kbytes downstream, which was plenty to present a smooth, consistent world view to the clients, continuously updating dozens of the most relevant objects for those clients.

After we wrote Tribes 1, Tim Gift wrote an article describing http://www.garagegames.com/articles/networking1/ everything we'd learned about network programming up to that point. It's a little bit out of date at this point, but it explains some of our methodology up to that point. Last year we released as open source (also available under closed source licenses) a much updated version of the networking technology totally divorced from the rest of the engine as the Torque Network Library. You can read the doco and info at http://www.opentnl.org. TNL, from a networking perspective, should definitely be able to handle the type of game you're talking about.

Quote:

I don't even think it would be a stretch to fit all of them on the same physical CPU.

The question is how expensive your simulation (physics) is, not how expensive your networking is :-)

Quote:

Original post by hplus0603 The question is how expensive your simulation (physics) is, not how expensive your networking is :-)

In the Tribes 2 case the 100 player game had player physics, projectiles, complex vehicles (hover-tanks), etc. -- not totally a worst-case, but close, considering even today's gaming landscape. Also, if you make poor algorithmic choices in your networking it CAN be the most expensive part as it scales up in # of players :)

Quote:

Original post by Anonymous Poster Scaling the players up doesn't scale the CPU usage linearly, if anything, without increasing the size of the world to keep the density of players down it would result in a gemoertic increase in CPU usage as playes being to interact more.

Well this is only true if your players are actually colliding constantly with each other. Even in a highly dense environment, this is still rarely the case. So player physics/simulation should scale nearly linearly with the number of clients.

Quote:

I've read the papers on Torques network model, it's quite impressive. Though I haven't played it, from the papers I can see that it sacficies accuracy to reduce the bandwidth, which is why I chose a game like CS to base the bandwidth measure on. CS in my opinion has one of the best and most accurate network model of the games I've played.

It's a stretch to say that Torque sacrifices accuracy -- there's some positional compression code in there that ends up being accurate to the "virtual" centimeter or 0.01 world units -- objects nearby to the camera get positions compressed better than objects far away. This is in any case, an imperceptible loss in precision. If CS is doing a 16 player game at 5 Kb per second, it has a primitve networking model -- that's positively wasteful, especially given what's actually going on in the game in a highly occluded environment -- which is to say, not much.

Quote:

Lets take markf bandwidth measure and see what we get. From the last post we can see that the player used 3Kb and updates dozens of objects. 3KB/24 = ~ 128 bytes/object. I assume by object we include players. The total percent of the 100 players acutally updated is like ~20%. Just scaling linearly, we get 15KB/player. Thats ~7.3 Megs/sec upload for the server n total. So depending what your gameplay is like, and how accurate you want it to be, the game proably will fall between those 2 spectrums.

Those numbers are way off -- I wasn't suggesting dozens of objects updated per second -- rather I was suggesting dozens of objects updated continuously. Here's the key for TNL: the actual per-client bandwidth in Torque/TNL is FIXED (at whatever the application wants), no matter how many objects are "in scope" for that client. If there are 16 players in a Tribes 2 game, each gets 3K/sec down from the server. If there are 100 players in a Tribes 2 game, each gets 3K/sec down from the server.

Object updates are prioritized based on a heuristic function that can take into account how far the object is from the "camera", how fast it is moving, how many packets have been sent without an update, etc. The actual per-object size of the update varies, but a typical player update will be on the order of 40-50 BITS, not 128 bytes.

The magic comes from two main factors - first, squeezing as much actual information as possible into each update (no wasted space) and second, always giving each client the information that is most relevant for that client. You may have 100 objects in view, but there's no way you can accurately track that kind of data -- and the game knows it. A good heuristic can with a high degree of accuracy "guess" which objects you really care about and update them with a high frequency, letting the others be updated less frequently. Add in some good interpolation and extrapolation and you have a smooth simulation with gazillions of things going on in 3K per second.

Quote:

Original post by markf_gg Object updates are prioritized based on a heuristic function that can take into account how far the object is from the "camera", how fast it is moving, how many packets have been sent without an update, etc. The actual per-object size of the update varies, but a typical player update will be on the order of 40-50 BITS, not 128 bytes.

What % of the CPU is used for the heuristic function? Compression would also work well too no? If you have two very fast computers and a slow network connection, compressing the data would lower the bandwidth requirement and when the data got to the other end, it would be decompressed fairly rapidly. It seems like the current limitation is bandwidth related not hardware related (CPU, RAM, etc.). Is that right?

Quote:

Original post by firefly2442 What % of the CPU is used for the heuristic function? Compression would also work well too no? If you have two very fast computers and a slow network connection, compressing the data would lower the bandwidth requirement and when the data got to the other end, it would be decompressed fairly rapidly. It seems like the current limitation is bandwidth related not hardware related (CPU, RAM, etc.). Is that right?

The heuristic function takes up a minimal amount of CPU - I'm not sure it ever even showed up on our profiles. And yes, compressing the data is an absolute must. In Tribes/Torque/TNL, we employed a number of different compression strategies -- from bit-compressing every number to its minimum necessary representation to huffman coding all string data.

Quote:

Original post by Anonymous Poster We're talking about fast twitch games here, where CS is the model. I've played massive FPS (like battlefield and the like where they use heuristics to reduce the bandwidth usagae but they end up with artifacting like Maelstrom describes, warping, inconsitent state and general slugishness).

The net play of the Tribes games and the BF games are not in any way alike. Tribes had a smooth consistent simulation with a twitch feel, vehicles, players, projectiles, etc. at 2Kbytes/sec. BF had a laggy, inconsistent simulation at (initially) around 10-15 Kbytes. We used heuristics to determine the priority of object updates.

Quote:

That's not what were going for. Were going for a fast no-compromise twitch game like CS but with 500 players. It's easy to interpolate/extraplate motion to make it smooth, even sync physically colliding objects if they are non-critical to game play. Using scaling algorithims to reduce the bandwidth will invariably reduce the level of sync and responsiveness leading to the orignial problem, FPS lite. A watered down FPS, with semi-quasi synced world where you can never know what your trully shooting at.

Bottom line: if you want a game with the feel of CS but with 500 players, you are going to have to have better netcode than CS. You have a limited amount of bandwidth per client. You can figure out what that is -- whether its 3Kbytes, 5Kbytes or whatever, it's some fixed amount, based on the total number of players and the cost of your server bandwidth. What you need to do as a network programmer is figure out how to deliver the best possible view of the world to each client given that fixed bandwidth. What I'm telling you is that what you're trying to do is possible, has been done before, and is available in a low-cost library that will save you a lot of lost hair.

Quote:

If a person is going to be jinking in and out while his friends provide cover with their full automatic weapons, in the mean time mortars fall onto the enemy positions causing massive explosions throwing up smoke, dust and people. I think you'll need to do more than a simple bounding collision calcualtions in this case. Perhaps we just have different crietrions for interaction. I'm imaginging a fully interactive world, with physics/player interaction firing raphid shot weapons, kinda like BF1942 but better and larger.

You've clearly never played the Tribes games. Imagine BF1942 in the future minus all the network wonkiness. It has mortars, it has vehicles, it has big explosions and projectiles and automatic weapons and a twitch FPS feel. My criteria for interactivity probably match yours pretty closely.