服務器端物理實現(二)

參考： http://fabiensanglard.net/quakeSource/quakeSourcePrediction.php

http://fabiensanglard.net/quakeSource/johnc-log.aug.htm

https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

服務端物理的broadphase階段處理基本有3種方案：

1：uniform grid, 統一尺寸網格

2：sweep and prune

3: dynamic aabb tree

其中sweep and prune 能夠參考box2dx, 而dynamic aabb tree 參考現代版本的 box2d實現。

服務器上若是使用相似box2d的精確物理碰撞實現，例如支持多邊形碰撞，消耗確實不小，略微看了box2d的多邊形碰撞實現，計算量仍是比較大的；

退而求其次，首先將物理世界以unity單位0.5*0.5尺寸，切割爲網格，將障礙物的aabb所佔用的網格標記起來，當 坦克移動的時候，和網格進行碰撞檢測，只作簡單的AABB碰撞檢測，運算量較小，與傳統的基於網格的網絡遊戲，相比，複雜度是高一些的，但比box2d物理引擎要簡單不少。

服務器上實現了aabb 軸對齊 統一網格障礙物斷定以後，客戶端就能夠只須要同步速度到服務器上便可，而服務器來進行位置計算，流程：

1.客戶端發送當前控制速度到服務器；
2.服務器房間啓動一個物理更新的Task協程處理，按期根據玩家的速度更新服務器上玩家位置，同時進行物理碰撞計算
3：服務器將玩家在服務器上的位置廣播給客戶端

這裏咱們的服務器採用固定幀率，例如100ms一次向客戶端廣播服務器上玩家位置；另一方面，服務器上以固定50ms做爲物理世界刷新的頻率， 每50ms計算一次玩家的當前位置。

若是客戶端沒有移動預測，就會存在一個問題，客戶端上的玩家須要等待100多ms纔開始運動，所以須要引入客戶端移動預測，當

1.玩家操控的時候，當即將操控的移動速度傳給玩家狀態機，由狀態機開始運動；

2.同時將玩家操控信息發送給服務器；

3.當服務器上玩家位置廣播回來時，將其轉化爲一個操控命令，傳送給狀態機，這樣對於玩家客戶端狀態機來說，其都是隻接受一個移動速度命令，而不關心這個命令是客戶端預測發送的，仍是服務器廣播的。