Territorial Warfare Without Timers

[CaptBewil]

Why?

All you need to ACTUALLY collide is your player and the objects immediately surrounding it that it could feasibly collide with; so that movement is restricted as to give the illusion that the player is colliding with something.  Collision should be handled locally.  Projectiles don't have to actually collide (use physics) they mearly have to have the illusion of colliding and that comes in the form of "touch" messages.  An object doesn't have to collide with another object to know that it's passed through (or "touched") a surface being drawn in the scene.  You also don't have to calculate the physics of other players.  That's just crazy.  Why would you calculate physics on other players when all you need locally is their position and animation ("pose")?  That's just extra processing work.  There's your "layers" of optimization.  Forget the binning nonsense...

[Vinadil]

Wouldn't you need to calculate physics on players if you wanted them to be able to "push" or "knock back" other players?  And, what if you use physics (how fast the character is moving) to determine damage as well?

[CaptBewil]

Wouldn't you need to calculate physics on players if you wanted them to be able to "push" or "knock back" other players?  And, what if you use physics (how fast the character is moving) to determine damage as well?

Only your collision physics with them, otherwise you'd just update their position and sync the animation.  You wouldn't need to calculate the physics they are acting onto something else, locally on your system.  They are calculating that on their system, so why make the server and client do double work?  The position of the other player is already being updated every so many ms anyways.  Let that players client calculate the physics and send back the updated position based off the results to the other client systems across the network (like it already does).

On your second question, you wouldn't need to calculate collision physics to add the movement value to a damage calculation.  Something like:

getPlayerVelocity()  Local  // where PlayerVelocity is a varible that tracks the local players movement speed.

getPlayerDamageOutput () Local // calls the PlayerDamageOutput variable
PlayerDamageOutput = getPlayerStatDamage() + (PlayerVelocity/10) // calculates an increase of damage based on the players stat damage and 10% of the players movement speed at the time of attack

There's no collision physics calculation involved.

The bottom line is, if the local player isn't touching it (or about too due to proximity), then the collision boundaries don't need to be calculated.  A lot of engines do needlessly calculate this stuff.  I've always forced collision to be disabled based on what I've said and the result is the same with lower overhead.

[Stephen Zepp]

Why?

All you need to ACTUALLY collide is your player and the objects immediately surrounding it that it could feasibly collide with; so that movement is restricted as to give the illusion that the player is colliding with something.  Collision should be handled locally.  Projectiles don't have to actually collide (use physics) they mearly have to have the illusion of colliding and that comes in the form of "touch" messages.  An object doesn't have to collide with another object to know that it's passed through (or "touched") a surface being drawn in the scene.  You also don't have to calculate the physics of other players.  That's just crazy.  Why would you calculate physics on other players when all you need locally is their position and animation ("pose")?  That's just extra processing work.  There's your "layers" of optimization.  Forget the binning nonsense...

Dude....you have a hidden assumption here that your simulation has a way of determining locality, without implementing that locality.

The binning system (or a similar optimization layer) is how you "Collision should be handled locally [sic]". Inside your memory space, objects are just a linked list (or set, or whatever ADT you happen to be using), and if you don't implement a locality mechanism, any check at all has to be applied against every object in the scene.

Long story short: if you don't have a system that allows you to relate and track how "close" objects are to each other, than for every "locality" check you want to do, you have to iterate over every object possible and say "are you within XXX distance of me? yes--you're local. no? move on".

Projectiles don't have to actually collide (use physics) they mearly have to have the illusion of colliding and that comes in the form of "touch" messages

That's totally dependent on genre, and desired game play.

In addition, as I've been cross-editing my two posts above, it sunk in--you are combining two separate game dev concepts (collision detection/response, and physics)...collision does not require a physics response, and while a collision event is most commonly a result of the physics system updating individual object's physics states, it's not the only way to generate collisions.

Consider the situation where a player enters a trigger area (a trigger being defined as a region a level editor places in his mission to detect when a player enters it). While it's not the only way to implement it, triggers are commonly implemented as objects that have collision detection, but not a physics collision response. When the player enters (or stays) within a trigger region, the collision detection systems report that as a collision event, and the level designer/scripter commonly handles that event callback to do whatever the trigger region is supposed to do.

To me that's a clear separation of "physics" and "collision"--sure, the player can only enter the trigger region by the physics system moving him there, but the trigger collision itself does not affect the physics of either object in any way--it simply generates a collision event for further processing.

[Stephen Zepp]

Wouldn't you need to calculate physics on players if you wanted them to be able to "push" or "knock back" other players?  And, what if you use physics (how fast the character is moving) to determine damage as well?

Only your collision physics with them, otherwise you'd just update their position and sync the animation.  You wouldn't need to calculate the physics they are acting onto something else, locally on your system.  They are calculating that on their system, so why make the server and client do double work?  The position of the other player is already being updated every so many ms anyways.  Let that players client calculate the physics and send back the updated position based off the results to the other client systems across the network (like it already does).

That's broken on many fundamental levels.

First and foremost: You should never allow a client to be authoritative in any multi-player client/server simulation where cheating is a possibility--and that's any game you produce (that has multi-player). As soon as you let client executables determine authoritative physics responses, you open up multitudes of cheating techniques, from dissembling the executable and re-wiring physics, to simply intercepting packets before they are delivered to the server and re-writing them.

Secondly, this doesn't take into account the fact that by definition, all clients (and the server for that matter) are in different time slices at any given real time slice, and due to the time required to send updates to the server, then propagate to all other clients, those clients are going to disagree. It's extremely rare to have a setup where you can have what could be called "multi-simulation authoritative updates"--EA did this for their very controlled and limited design requirements for NASCAR, but it's an extremely rare, and extremely difficult functionality.

How do you handle desychnronized simulations if any client can say "my current state is authoritative"--what if that client (intentionally or unintentionally) doesn't have the full game state? They could have lost packets, or simply be too far behind the "average game state" of the rest of the simulations to have the right information.

On your second question, you wouldn't need to calculate collision physics to add the movement value to a damage calculation.  Something like:

getPlayerVelocity()  Local  // where PlayerVelocity is a varible that tracks the local players movement speed.

getPlayerDamageOutput () Local // calls the PlayerDamageOutput variable
PlayerDamageOutput = getPlayerStatDamage() + (PlayerVelocity/10) // calculates an increase of damage based on the players stat damage and 10% of the players movement speed at the time of attack

There's no collision physics calculation involved.

You are being very loose with your definitions, and I think this is why there is disagreement here. By definition, PlayerVelocity is a physics state, and therefore you are performing a physics calculation. It's an approximation (and a very basic one), but again by definition every single physics calculation in a game engine is.

I will concede that in your specific example there is no direct modification to the target's physics state based on a result of the collision, but it's also pretty common to have the (false) assumption that collision implies a game state physics reaction. As you've demonstrated, you can (and in many cases should) detect collision but respond without physics, or at least decouple the collision response and the physics response. That doesn't mean that the collision detection doesn't occur--it has to for you to know that the two objects are touching.

The bottom line is, if the local player isn't touching it (or about too due to proximity), then the collision boundaries don't need to be calculated.  A lot of engines do needlessly calculate this stuff.  I've always forced collision to be disabled based on what I've said and the result is the same with lower overhead.

Back to what I said in the post above--you are assuming here that your simulation stores a way to determine locality, without allowing (in a theoretical sense, not your implementation example) that system to exist. Some form of binning, or other locality information storage system, is required to determine is a player "isn't [sic] touching it (or about too due to proximity"...and as it turns out, a binning system provides both that functionality you just used, in addition to acting as an optimization level for collision checking.

[Stephen Zepp]

Accidental double post.

[CaptBewil]

The "Local" identifier means that that code will only be run on the client's computer.

Locality referees to "Client Side" and not x,y,z location.  All object templates are preloaded into memory when the client launches.  Then the objects (actual art assets such as 3D models and Textures) are rendered to the screen based off of the proximity to the player.  This is all done locally on the client side and are swapped out of memory as needed.  Generally speaking, assets would be preloaded regionally.  Then, the only art assets that have to be done on the fly are player models, equipment/weapon models, and textures (but, these days, only if more complex then WoW's characters...such as SWG or CoH characters...otherwise the combinations would be preloaded when the client launched).  I've never heard of 'regional binning' which seems to be what you are suggesting other then in Sector based games (otherwise known as "Portal Engines") such as Crystalspace3D and many many many of the early 3D games (such as DooM, Duke Nukem 3D, Tomb Raider, The Sith Engine (Lucas Arts engine used in a number of their early 3D games), etc).  But these were used before the days of culling and RVTCS (Ranged Vector Thing Creation Systems).  In newer engines like Crystalspace3D, you could avoid Sector Binning by implementing these newer systems and just having one large Sector Bin for each major region.

Cheating, the other primary concern, is avoided by the server verifying that an action is occurring within a certain tolerance (min and max value range).  If it isn't, then it cancels the action.

An efficient server system, IMO, is designed so that the majority of the events it handles are boolean returned values.

[Stephen Zepp]

I did a bit of quick research on your term "RVTCS", and came across a couple of your posts from a few years ago, and wanted to highlight something:

Code:

...
# Cog used to supliment as a primitive object culling system for JK. Good for up to 10 objects.
...
Int Used=0 #How many objects youve used. (Just put the number of the last object)
...
For(I=0;I<=Used;I=I+1)
{
If(Vectordist(Getthingpos(Object0[I]), Pos_t) <= Max_range && Vectordist(Getthingpos(Object0[I]), Pos_t) >= Min_range)
SetThingCurGeoMode(Object0[i], 4);
# Set the object visible...
Else
SetThingCurGeoMode(Object0[I], 0);
# Set the object invisible...
}

That loop indicates that you are looping over every object in your simulation (client side, server side, whichever), and doing a vector distance check (twice) for a max and min range. In other words, you are doing a straight iteration over every object in your sim, and if I read the context of the post you made correctly, you are doing that for rendering optimization (occlusion is mentioned in the thread), which means you are doing this for every frame render (hopefully at least 30 times a second[/url].

There is absolutely no way any client machine is going to be able to handle this type of occlusion, or this type of big O search for any reasonable value of Used in a game where Territorial Warfare is going to make sense--in other words, an MMO style game. It is easy to expect values of Used (which is your total number of objects in a simulation as far as I can tell) in any reasonable map size in an MMO environment. Hell, even if you limit your number of users per "mission/area" to 1k, you will barely be able to run that kind of search every frame for just player's rendering, and that doesn't even begin to cover collision detection or physics.

And food for thought: the occlusion benefit of doing  a view frustrum occlusion test is most probably much less than the performance hit necessary to do the math of the test itself--you may want to look at not bothering to render objects not in your view frustrum.

[CaptBewil]

The RVTCS cog (used for the Sector based Sith engine) was a work around piece of code that ran client side.  The Sith engine (like many sector based (or Portal based, if you prefer)) was plagued with issues when it came to creating large open areas.  You could divide a large area into multiple sectors, but if the origin of objects near the edge of the rendered scene was not within the Field of View (the rendered scene) then the entire object would not render at all (even though it should).  This only occurred when the object was in a separate sector from the player.  The other issue with portal engines is that they render everything that it thinks should be on the screen regardless of distance.  It is important to note that this particular code had nothing to do with character player models or any other non-static object.  The code used for that particular game actually served two purposes.

1.  It allowed you to tell the engine to stop rendering an object if it was beyond a certain distance from the player.
2.  It allowed for you to have it stop rendering that specific object at a particular minimum distance to switch to a higher resolution model.

So, it there were two great optimizations that were made that finally allowed for the creation of large open areas to be created using that engine which were previously not possible.  That also looks like and older version of the code.  New versions were object template specific and thus not limited to 10 objects.  But this is all besides the point because this is specifically about work arounds for old portal based engines, and not what I was discussing...

On an interesting side note, i later designed a piece of code that allowed for virtual sectors to be created within one single sector.  It essentially a "trigger zone" that would allow you to trigger events when a player entered a certain x,y,z perimeter without having to deal with the issues relating to using multiple sectors.

[Stephen Zepp]

The RVTCS cog (used for the Sector based Sith engine) was a work around piece of code that ran client side.  The Sith engine (like many sector based (or Portal based, if you prefer)) was plagued with issues when it came to creating large open areas.  You could divide a large area into multiple sectors, but if the origin of objects near the edge of the rendered scene was not within the Field of View (the rendered scene) then the entire object would not render at all (even though it should).  This only occurred when the object was in a separate sector from the player.  The other issue with portal engines is that they render everything that it thinks should be on the screen regardless of distance.  It is important to note that this particular code had nothing to do with character player models or any other non-static object.  The code used for that particular game actually served two purposes.

1.  It allowed you to tell the engine to stop rendering an object if it was beyond a certain distance from the player.
2.  It allowed for you to have it stop rendering that specific object at a particular minimum distance to switch to a higher resolution model.

So, it there were two great optimizations that were made that finally allowed for the creation of large open areas to be created using that engine which were previously not possible.  That also looks like and older version of the code.  New versions were object template specific and thus not limited to 10 objects.  But this is all besides the point because this is specifically about work arounds for old portal based engines, and not what I was discussing...

On an interesting side note, i later designed a piece of code that allowed for virtual sectors to be created within one single sector.  It essentially a "trigger zone" that would allow you to trigger events when a player entered a certain x,y,z perimeter without having to deal with the issues relating to using multiple sectors.

I don't mean to be redundant, but what you describe in your side note is built in to a binning system...

I'm also not dogging the optimizations you guys made--I simply was pointing out that given the problem state in the general thread, higher levels of optimizations are pretty much mandatory.

[CaptBewil]

I don't mean to be redundant, but what you describe in your side note is built in to a binning system...

Yes, but the point was that the "binning system" was causing objects to not render simply because their origin (center point position for the object) was outside the same sector (bin) and out of view.  That was the optimization "working as intended" and for small objects, that wasn't an issue.  For larger objects that spanned two more sectors (bins) it became an issue.  So, again, it was a work around for that issue.  To elaborate; the pieces of code i designed for the Sith engine were designed such that they canceled the "binning" optimization by having your entire level be in one sector (or bin, if you prefer).  Since eliminating this optimization causes the frame rate to take a huge hit, a supplemental optimization (the RVTCS) was used to limit how many objects were rendered on the screen at one time (it also bypassed a hardcoded limit of ~350 object to the entire environment).

I'm also not dogging the optimizations you guys made--I simply was pointing out that given the problem state in the general thread, higher levels of optimizations are pretty much mandatory.

I don't think it was a question of higher level optimizations being needed, but more precisely, what those optimizations were...which will very between engines.  My preference, is to do as much client side as possible and validate limits (prevent cheating) server side.  In the MMO I'm designing now, health bars will only be client side (most things will be killed in a few hits), no "fly text", etc.  I'm taking a page for online fps games such as BF1942 when it comes to combat.  I haven't decided what to do about chating.  Right now chat is implemented with chat bubbles, etc.  But I'm considering taking it out and using a separate VOIP program that communicates with the client and server...

Cheers!