Basically some information that has been popping up around the forums and such leads me to believe that each computer calculates the pathing/terrain deformation etc for all the different connected players... including spectators.
Is this true? I know that for the sake of security and making sure stuff happens right on everyone's computer and preventing cheating this makes sense... but it's also the "cause" of all the unsyncing... if we just stopped checking everyone's sync packets then there would be no unsyncing?
basically what I would suggest is this...
Game Server does set's up all calculations based on network commands from clients. clients do only calculations for their own units, game server sends out update packets to the connected clients... resyncing every cycle... no unsync...
trouble here is that the Server would need to be a really good computer in order to handle everything... so you would get CPU lag from the Server still... but doesn't the server already do all these calculations anyways? or is the idea of an "update" packet unrealistic...
Anyways... if you could get what I'm talking about working THEN hard calcs could be distributed... instead of calcing path costs those who have them calced the clients could send their path cache, and if no one had them yet... each player could calc a share of path costs and then return them to the server...
then in game when terrain deformation happens the server could set up "distributed processing" request to all of the clients with spare CPU cycles to recalc another master terrain map+path cost lookup table...
the cool thing here is that each spectator would have 0 local CPU processing, only 3D processing... and have 100% of CPU cycles free from hard calcs from the server... meaning more spectators would make the game smoother instead of choppy...
anyways... um... I have the feeling my solution is Insane, or at least a post 1.0 idea... but I like it a lot and would like some feedback.
Am I insane?
Moderator: Moderators
I fail to see what exactly your point is.
Just press b while playing and look how much cpu time actually is spend for terrain modification. Normally, here, its about 2 or 3 seonds in a normal game.
It just doesnt matter.
What DOES eat cpu-power is the unit housekeping and los/pathfinding, which would be prohibitive to calculate non-local.
Just press b while playing and look how much cpu time actually is spend for terrain modification. Normally, here, its about 2 or 3 seonds in a normal game.
It just doesnt matter.
What DOES eat cpu-power is the unit housekeping and los/pathfinding, which would be prohibitive to calculate non-local.
Now, if that is the case, why isnt the pathing cashed?
If you do it live on the fly, is there no way to combine that information into the cashed pathing for the map so that you wont have to do the same cpu intensive path calculation again? This would be a per game temporary pathing file that starts out as the current pathing file but is then modified as the game progresses. Once the game is over it is removed since the cashed information is only viable for the deformations that occured in that particular game.
I might want to add that I have no bloody idea what Im talking about so if it does not make any sense, please let me know
If you do it live on the fly, is there no way to combine that information into the cashed pathing for the map so that you wont have to do the same cpu intensive path calculation again? This would be a per game temporary pathing file that starts out as the current pathing file but is then modified as the game progresses. Once the game is over it is removed since the cashed information is only viable for the deformations that occured in that particular game.
I might want to add that I have no bloody idea what Im talking about so if it does not make any sense, please let me know
How do you think you could cache pathing?
If all units where ghosts and could move through each other and buildings, that would be perfectly fine.
Problem is that the pathfinding has to take into account all the building positions, for example.
The _deformation_ stuff should be neglectable in comparison (how much stuff is blocked in a typical game by deep craters compared to buildings/DTs/ect?
If all units where ghosts and could move through each other and buildings, that would be perfectly fine.
Problem is that the pathfinding has to take into account all the building positions, for example.
The _deformation_ stuff should be neglectable in comparison (how much stuff is blocked in a typical game by deep craters compared to buildings/DTs/ect?
Im not 100% positove on this but...
Im pretty sure it does cache up a new set of paths. A few versions ago there was this weird bug were, after serios deformation, units could go places they should not be able to go for a few moments after it had happend. We complained it was an annoying bug, and it turned out this was because the pathfinding was only updated everyso often, not all teh time. However someone modded the path finding, i assume it now runs a check on wether teh terrain is teh same or not first, and then wither does an on the fly calculation, or grabs the answers from the pathing file.
Either that is still the case, or it now totaly runs on the fly, either way thgough surly it can be recombined to make things more effecient. That way in a quiet period the game wopuld cache up the whole map again, untill the next serios battle.
Or i may be talking out my backside...
aGorm
Im pretty sure it does cache up a new set of paths. A few versions ago there was this weird bug were, after serios deformation, units could go places they should not be able to go for a few moments after it had happend. We complained it was an annoying bug, and it turned out this was because the pathfinding was only updated everyso often, not all teh time. However someone modded the path finding, i assume it now runs a check on wether teh terrain is teh same or not first, and then wither does an on the fly calculation, or grabs the answers from the pathing file.
Either that is still the case, or it now totaly runs on the fly, either way thgough surly it can be recombined to make things more effecient. That way in a quiet period the game wopuld cache up the whole map again, untill the next serios battle.
Or i may be talking out my backside...
aGorm
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
In a typical game, that would be so near continuous when taking all players into account so as to make the difference negligible.AF wrote:hmm I'm thinking pathign should eb updated on an event based basis than a cycle absis, that way when ti needs to change ti does and nto checking when it doesnt need to.
When buildigns are built/explosions occur/features/wrecks reclaimed etc....
I am glad everybody's starting to pay attention to this. I've already stated how I think this should be "fixed", given the choices (none of them good):
1. Maps should be able to have a "DoNotDeform" tag in their specification. Maps with this tag should, obviously, never deform, nor should that code ever run. That'd help tremendously- these maps would never, ever update their pathing data, nor ever run the deform code, and would probably run beautifully even with many more units than we see now.
2. We could have this be a Lobby option, and give that ability to all maps. This would be worth looking at, honestly- it'd make gameplay be really different, but, like tweaks to gravity, metal output, wind and other factors, which are currently defined by mappers, it would probably be fairly easy to implement, as an argument passed to the client on startup. I dunno how hard this would be, from a coding standpoint, within the engine, but I'm guessing that, aside from the DoNotDeform option, it'd be pretty easy.
3. Last, but not least... we could have a seperate tag within weapon TDFs for the amount of deformation, if any... and let modders control things when they want to.
1. Maps should be able to have a "DoNotDeform" tag in their specification. Maps with this tag should, obviously, never deform, nor should that code ever run. That'd help tremendously- these maps would never, ever update their pathing data, nor ever run the deform code, and would probably run beautifully even with many more units than we see now.
2. We could have this be a Lobby option, and give that ability to all maps. This would be worth looking at, honestly- it'd make gameplay be really different, but, like tweaks to gravity, metal output, wind and other factors, which are currently defined by mappers, it would probably be fairly easy to implement, as an argument passed to the client on startup. I dunno how hard this would be, from a coding standpoint, within the engine, but I'm guessing that, aside from the DoNotDeform option, it'd be pretty easy.
3. Last, but not least... we could have a seperate tag within weapon TDFs for the amount of deformation, if any... and let modders control things when they want to.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Seems like a better lobby/server side option then a map/mod option. Otherwize we'll have every modder and mapper releaseing parallel release for the can deform verison and can't deform version. Mappers can already effectively tell a map not to deform by giving the terrain infinate hardness values, so they really don't need more tools to be able to accomplish that. Moders can already edit impulse factor in in the TDF's.Argh wrote:I am glad everybody's starting to pay attention to this. I've already stated how I think this should be "fixed", given the choices (none of them good):
1. Maps should be able to have a "DoNotDeform" tag in their specification. Maps with this tag should, obviously, never deform, nor should that code ever run. That'd help tremendously- these maps would never, ever update their pathing data, nor ever run the deform code, and would probably run beautifully even with many more units than we see now.
2. We could have this be a Lobby option, and give that ability to all maps. This would be worth looking at, honestly- it'd make gameplay be really different, but, like tweaks to gravity, metal output, wind and other factors, which are currently defined by mappers, it would probably be fairly easy to implement, as an argument passed to the client on startup. I dunno how hard this would be, from a coding standpoint, within the engine, but I'm guessing that, aside from the DoNotDeform option, it'd be pretty easy.
3. Last, but not least... we could have a seperate tag within weapon TDFs for the amount of deformation, if any... and let modders control things when they want to.