Collision to run player-player, with server checking?
Soul_Rider
Mod Bean Join Date: 2004-06-19 Member: 29388Members, Constellation, Squad Five Blue
Mod Bean Join Date: 2004-06-19 Member: 29388Members, Constellation, Squad Five Blue
in Modding
I was inspired by a post in the collision thread in the General Discussions forum, about making collision, peer-peer. Obviously, in itself, that's not a good idea, but what if....
Collision was an independent engine thread, with the server portion just checking data, and the implementation running peer-peer.
I am not sure if it would work, but feel free to shoot this down with genuine valid reasons, not proof from previous implementations but problems, that we can then try and solve.
Clients (in a seperate thread) do movement predictions for all players in a field of distance, it could be whole map, or it could be a smaller radius if having a larger number of players per game. Players send movement data to each other in radius about where they all should be, this is checked by each client, to see how all the data from each player compares. each update is sent to the server thread, and on each operational tick, could be server tick rate, could be independent tick rate, it reads all the clients info and checks against itself and it's other gamestate knowledge, hitboxes, movement, firing, etc.
Should the collision thread detect (n) inconsistencies in (t) time period, the thread takes over the running of the collision detection, rather than just checking.
Is this beyond scope? Can such a switch be programmed? Would spawning another thread to do the collision detection be another way to begin to multi-core the engine?
I couldn't program this myself, currently beyond scope, but is such a design feasible? or even possible?
I'd like to hear constructive feedback, as peer-peer would surely offer better collision detection for players?
Collision was an independent engine thread, with the server portion just checking data, and the implementation running peer-peer.
I am not sure if it would work, but feel free to shoot this down with genuine valid reasons, not proof from previous implementations but problems, that we can then try and solve.
Clients (in a seperate thread) do movement predictions for all players in a field of distance, it could be whole map, or it could be a smaller radius if having a larger number of players per game. Players send movement data to each other in radius about where they all should be, this is checked by each client, to see how all the data from each player compares. each update is sent to the server thread, and on each operational tick, could be server tick rate, could be independent tick rate, it reads all the clients info and checks against itself and it's other gamestate knowledge, hitboxes, movement, firing, etc.
Should the collision thread detect (n) inconsistencies in (t) time period, the thread takes over the running of the collision detection, rather than just checking.
Is this beyond scope? Can such a switch be programmed? Would spawning another thread to do the collision detection be another way to begin to multi-core the engine?
I couldn't program this myself, currently beyond scope, but is such a design feasible? or even possible?
I'd like to hear constructive feedback, as peer-peer would surely offer better collision detection for players?