以在揹包、倉庫中操作物品為例
維護到乙份**看到如下的流程：
假設現在我在揹包中把物品從a格仔移動到b鴿子
已經有的關鍵字:
物品型別:普通，特殊，消耗。。。等等
放入函式:使用物品型別掩碼判斷
(1,2表示步驟)
c1:從落點範圍判斷是否合法(比如揹包格仔是1-20，倉庫是40-60)。如果滿足，傳送要移動的包給伺服器。這時候ui不做更新，即不執行實際的更新函式
s1:收到包進行校驗，比如是否能存放，如果是裝備則如何如何(放入函式)。同步計算完後，傳送確認包給c
c2:收到後執行實際的更換操作，更新(放入函式)
維護的需求如下，任務物品不能放入倉庫，並且給玩家提示。兩套方案
1:維持舊的結構，放的時候發乙個包，靠伺服器返回的乙個包來說明是否可以放入。後來發現交換協議包中沒有這個成功的字段
2:不發包。伺服器的校驗直接返回，客戶端做本地判斷，條件不符合就不發包。比較彆扭的地方來。如果不發包，那麼伺服器就不會發確認包，沒法執行客戶端的實際"放入函式"。所以只好在c1的座標中判斷這個物品來自**，然後直接操作。
另人感到很不快的是，為什麼要通過落點判斷呢？物品本身不是有物品型別的設定嗎？只要在容器和物品間設定好掩碼不就行了？現在就好比有兩套的資源結構，又可以落點判斷，又可以物品實際屬性判斷。
想起以前工作中碰到的物品操作流程:
c1:本地做乙份操作(實際操作)，成功後發給伺服器乙份通知資訊，滑鼠鎖定
s1:收到後做乙份同樣操作，發乙個解鎖命令
c2:解鎖
這兩套方案中，我本來還比較排斥第二種，現在反而喜歡了。操作物品的時候最本質的需求是兩邊要同步，
從**維護上來說：
一號方案是讓伺服器先做，然後自己再做。如果是這樣那中間就無所謂在判斷是否合法了。但是一些基本的判斷你又不得不做。
二號方案中是直接做，也不要預判斷什麼。因為一件物品是否能放入，怎麼放入，這兩個邏輯應該是內聚在一起的。比如通過掩碼的方式。然後通過乙個解鎖命令來同步。如果再通過一些額外的點範圍判斷，實在是費解
很多人會說鎖會不會影響了操作？其實一樣的，一號方案也要在等待服務包的更新通知。(不知道大家有沒在遊戲中拿起一件物品放乙個位置，卡住的時候老放不下。)重要的本質是什麼，是同步。即使你這個時候讓玩家繼續操作(影響到他剛才移物品的),也是無效的。而在實際的表現過程中，網路順暢時(60-120ms響應)，0.15-0.2秒很快就解掉鎖了。
寫到這，想起其實可以對一號方案進行改進，c1中直接進行乙個放入的步驟預判斷，如果成功發訊息請求。伺服器成功後傳送確認，c1再執行最終的放入。還是一分為二的做法。這樣的**你敢重用嗎？
遊戲中的網路同步
在網路遊戲中遊戲資料和狀態的同步是整個遊戲的基礎，而遊戲中對網路同步要求最高的就是戰鬥狀態的同步，它影響玩家的遊戲體驗。同時，不同型別遊戲的戰鬥狀態同步對網路同步要求又不一樣，所以產生了不同的網路同步機制。網路是有延時的，因為每個玩家的網路情況都不盡相同，而且每個玩家機器效能也不盡相同，這還會導致遊...
遊戲中幀同步與狀態同步
幀同步 什麼是幀同步 幀同步常被rts 即時戰略 遊戲常採用。在遊戲中同步的是玩家的操作指令，操作指令包含當前的幀索引。一般的流程是客戶端上傳操作到伺服器，伺服器收到後並不計算遊戲行為，而是 到所有客戶端。這裡最重要的概念就是 相同的輸入 相同的時機 相同的輸出。實現幀同步的流程一般是 同步隨機數種...
實現滑鼠與遊戲的互動（與遊戲中的物品互動）
我們這裡用到的是射線中的滑鼠螢幕射線 screenpointtoray 射線 ray ray new ray position startposition,position endposition 返回滑鼠座標 input,mouseposition 以上部分可參考開發者文件 拿到滑鼠在螢幕的射線 ...