專利名稱：Cs架構下的物理計算網(wǎng)絡同步方法
技術領域：
本發(fā)明涉及一種CS架構下的網(wǎng)絡同步技術，特別涉及在有物理計算情況下的網(wǎng) 絡同步。
背景技術：
物理引擎是由計算機模擬牛頓力學模型的一套完整API。它使用物體的質(zhì)量、速 度、受力情況等信息，來計算一定時間里物體的運動狀態(tài)。在多個物體的場景中，利用碰撞 檢測判斷物體之間是否有接觸，從而對受力物體施加力沖擊，以模擬真實情況下的物理碰撞。CS架構表示客戶端與服務端架構，可以將服務部署于用戶PC(客戶端)和大型服 務器(服務端)，客戶端可以向服務端發(fā)送數(shù)據(jù)和請求，由服務端處理后再返還給客戶端。 一般的CS架構下的一個服務僅涉及一個客戶端，不同的客戶端之間相互獨立，不存在網(wǎng)絡 同步問題。而在另一些領域，客戶端之間需要通過服務端進行交互，并且需要保證時間一致 性，例如網(wǎng)絡游戲、網(wǎng)絡會議等，那么客戶端之間就需要進行同步。目前，CS架構下的網(wǎng)絡同步在網(wǎng)絡游戲領域應用十分廣泛，客戶端主要發(fā)送一些 用戶的操作數(shù)據(jù)，由服務端進行計算得到狀態(tài)數(shù)據(jù)，然后轉發(fā)給這個服務涉及的所有客戶 端，服務的同步范圍因應用的不同而有差異。通常情況下，服務端計算的狀態(tài)數(shù)據(jù)計算量很 小。隨著物理引擎在單機游戲領域的使用越來越廣泛，我們逐漸體會到物理引擎給玩 家?guī)淼恼鸷澈驼鎸嵉捏w驗。物理引擎也開始在網(wǎng)絡游戲中開始了應用。對于現(xiàn)有的CS 架構，服務器端無法承受如此大量的計算任務。1.物理計算屬于實時計算，需要消耗大量處理器的計算能力。2.物理引擎中的非剛體計算，涉及的數(shù)據(jù)量很大，不適合通過網(wǎng)絡傳輸同步。3.物理計算的初始狀態(tài)會對后續(xù)計算產(chǎn)生累積的蝴蝶效應，對用戶的交互有影 響，同步要求很高。因此，本文中涉及的技術，需要就以上幾點進行改進，在有物理計算的情況下，解 決CS架構下的一些同步問題。

發(fā)明內(nèi)容
物理計算的特點是實時性較高、非剛體計算涉及數(shù)據(jù)量很大、初始條件的設置對 后續(xù)計算結果影響很大。針對前兩點，物理計算需要放在客戶端進行。對于第三點，需要有 精確的同步性。為了兼顧計算的效率和同步的精確，對CS架構下含有物理計算的交互服務，針對 物理計算相關部分和客戶端服務端之間的通信流程做改進。服務端不進行物理計算，僅負責接受客戶端數(shù)據(jù)，并同步到其它客戶端。客戶端對 用戶控制的物體進行物理計算，將其狀態(tài)發(fā)送給服務端。
本發(fā)明是在客戶端和服務端具備雙向通訊機制，在客戶端進行物理計算，并發(fā)送 數(shù)據(jù)；服務端只接收數(shù)據(jù)，并據(jù)此發(fā)送同步信號，不進行物理計算；客戶端和服務端雙向通 訊實施同步的步驟，其中對于受控物體是(1)客戶端接受客戶受控物體操作；(2)對受控物體進行物理量計算；(3)更新場景中所有物體物理信息；(4)向服務端發(fā)送受控物體狀態(tài)數(shù)據(jù)；(5)服務端接收客戶端發(fā)送的受控物體狀態(tài)的數(shù)據(jù)；(6)服務端更新鏡像物體狀態(tài)數(shù)據(jù)；(7)服務端向客戶端發(fā)送鏡像物體狀態(tài)數(shù)據(jù)；(8)客戶端接收服務端的同步信息；(9)選擇更新；(10)結束；其中對于非受控物體，同步策略為“碰撞交換控制權”，即由客戶端的受控物體撞 擊非受控物體獲得物體的數(shù)據(jù)“發(fā)送權”，其步驟是(1)對非控受物體進行物理量計算；(2)檢測碰撞；(3)如有碰撞，檢測碰撞類型；如無碰撞，直接更新“發(fā)送權”；(4)如有碰撞，碰撞類型是一般物體，則向服務端發(fā)送碰撞信息；如碰撞是其他客 戶端受控物體，則直接更新發(fā)送權；(5)檢測有、無“發(fā)送權”，如無，直接更新發(fā)送權；如有，則向服務端發(fā)送物體的物
理信息；(6)服務端接收碰撞信息；(7)更新用戶“發(fā)送權”；(8)服務端接收客戶端物體的物理信息；(9)檢測“發(fā)送權” 一致否？(10)如不一致，則向客戶端發(fā)送更新的“發(fā)送權”；(11)如一致，則更新物體物理信息后，再向客戶端發(fā)送更新的“發(fā)送權”；(12)結束。本發(fā)明的優(yōu)點是，服務端節(jié)省了大量物體物理量計算，加快了實時控制的速度。


圖1客戶端與服務端同步示意圖；圖2客戶端與服務端交換通信流程圖；圖3非受控物體“發(fā)送權”更新策略流程圖。
具體實施例方式請參圖1中所示的網(wǎng)絡環(huán)境中，客戶端各自有一個受控物體，客戶端1可操縱物體 A，那么在這個環(huán)境中，客戶端1具有物體A的數(shù)據(jù)“發(fā)送權”。而在其它客戶端上，他們雖然可以在交互的環(huán)境中看到物體A，但是他們僅有數(shù)據(jù)“接收權”。也就是說，他們可以對這個 鏡像物體進行物理計算，任意改變位置，但這僅僅位于客戶端，這些改動是其它客戶端不可 見的，最終這個鏡像物體會由服務端進行同步，告知這個物體真實的狀態(tài)。在一般的應用中，除了客戶端可操控物體外，還有一些是無法直接操控的一般物 體，但是它們?nèi)匀痪哂形锢韺傩?，允許它們與玩家進行交互。對這些物體的處理，也可以使 用數(shù)據(jù)的“發(fā)送權”和“接收權”的概念。最簡單的權利分配策略是對最 佳客戶端分配“發(fā) 送權”，這里的“最佳”是一個綜合的概念，例如可以由網(wǎng)速、機器性能綜合考慮得到。一個 更復雜的策略，可以采用交互時“發(fā)送權”轉移的策略。這種動態(tài)策略的好處是具有更好的 運行效果，可以應用于大型場景，可以根據(jù)距離，或者根據(jù)是否發(fā)生物理碰撞來移交“發(fā)送 權”。本技術方案可解決的問題包括1.在客戶端進行物理計算，可有效地降低服務器負載。2.客戶端發(fā)送數(shù)據(jù)，服務器進行同步，保證客戶端操控流程，各個客戶端一致。3.發(fā)送接收策略由服務器分配物體的物理計算后結果提交的權利，避免由服務器 端進行非用戶控制物體的物理計算。圖2是客戶端與服務端的通信流程。在一個典型的CS架構中，由一個服務端與若 干客戶端組成，服務端與客戶端具備雙向通信機制。在一個需要物理計算的應用中，客戶端 與服務端需要進行同步以保證物理計算在各個客戶端上一致。參閱圖2，以一個客戶端與服務端之間的通信流程為例，對本文中的技術進行介紹?？蛻舳松贤ǔ０芸蛻舳丝刂频奈矬w和若干個非受控物體。對于受控物體，客 戶端需要進行輸入設備的處理，轉化為對該類物體的控制信息，用于改變物理參數(shù)。對于非 受控物體，客戶端只需要保存物理參數(shù)即可。對所有的物體需要更新它們的時間相關量，然 后送入物理引擎進行物理計算，并得到結果，用于更新所有物體的物理信息。當計算完成 后，客戶端發(fā)送受控物體的物理信息給服務端。需要注意的是各個客戶端的受控物體是互 相獨立的，不允許多個客戶端在同一時刻控制同一個物體鏡像?？蛻舳私邮辗斩税l(fā)來的 物理同步信息，這些信息包括場景中所有物體的同步信息，客戶端忽略受控物體的信息，更 新其它場景物體完成單個同步通信流程。服務端接收客戶端發(fā)來的受控物體的物理信息，負責將數(shù)據(jù)發(fā)送給所有的客戶 端，這個物體在其它客戶端上的鏡像是非受控物體，更新后完成同步?？蛻舳伺c服務端在進行同步時，會根據(jù)物體的ID號進行判斷。同一物體的所有鏡 像擁有相同的ID，最基本的同步過程就是基于物體ID號的。各個的客戶端本身擁有客戶端 ID用以區(qū)分不同的客戶端。因此本技術的物理計算同步需要借助物體ID和客戶端ID來判 斷“發(fā)送權”。服務端的物體鏡像會記錄擁有“發(fā)送權”的客戶端ID作為身份識別。客戶端 在發(fā)送數(shù)據(jù)時需要給出物體ID以及自身客戶端ID，組成數(shù)據(jù)包發(fā)送。服務端在收到數(shù)據(jù)包 時根據(jù)物體ID查找鏡像物體，在比對客戶端ID確定數(shù)據(jù)包是否有效，即該客戶端是否擁有 這個物體的數(shù)據(jù)“發(fā)送權”，如果無效直接丟棄。在服務端處理完正確數(shù)據(jù)后，會向所有客戶 端同步這個物體的鏡像。擁有該物體“發(fā)送權”的客戶端直接忽略同步數(shù)據(jù)，其它客戶端則 會進行普通的同步，這個過程稱為“選擇同步”。
在這個機制下，避免了服務器端進行物理計算，同時又使用戶擁有單機情況下流 暢的體驗。所有的操作在客戶端進行處理，物體的控制不受網(wǎng)絡延時的影響，可以立即得到 響應。服務端的工作僅僅是負責數(shù)據(jù)的轉發(fā)，向其它客戶端提供一些基本的信息。無法避免的是，場景中的其它物體的同步會受到網(wǎng)絡延時的影響。可以利用二次 量來提高預測精度，提高用戶的實時體驗。圖3是涉及場景中非受控物體的同步技術。對一個客戶端來說，場景中的物體分 為三類。一是自己可以控制的物體；二是由其它用戶控制的物體，自己無法控制；三是非受 控物體，不由任何用戶控制，但又需要進行物理計算。第二和第三類物體都屬于非受控物 體，但是第三類更特殊。本文中的同步策略為“碰撞交換控制權”，即由客戶端的受控物體撞擊非受控物體 獲得該物體的數(shù)據(jù)“發(fā)送權”。這樣做的優(yōu)點是，用戶看到的物理碰撞效果和單機情況下是 一樣的，而其它用戶又能保持數(shù)據(jù)一致。
下文將結合圖3對這類物體的同步進行闡述?？蛻舳诉M行物理計算，可以得到非 受控物體的物理信息。檢測是否發(fā)生了碰撞，如果不是則跳過后面一些步驟，直接更新非受 控物體信息“發(fā)送權”。隨后檢測碰撞的物體是否是非受控物體，如果不是則更新非受控物 體信息“發(fā)送權”。如果檢測通過，則向服務端發(fā)送碰撞信息，包括客戶端受控物體的ID號。 如果擁有非受控物體信息“發(fā)送權”，則可以向服務端發(fā)送物體物理信息，否則即使發(fā)送了 信息，服務端也會忽略?？蛻舳藭邮辗斩烁碌摹鞍l(fā)送權”信息，以改變自己對非受控 物體的信息“發(fā)送權”，避免占用帶寬。服務端負責接收客戶端發(fā)來的碰撞信息，以更新“發(fā) 送權”。當服務端接收到任意客戶端發(fā)來物理信息，會比較客戶端ID來確定其是否擁有真 正的“發(fā)送權”，從而改變該物體的物理信息。最后服務端會將因發(fā)生碰撞而改變的“發(fā)送 權”通知所有客戶端。在這個策略下，原先擁有該一般物體“發(fā)送權”的客戶端仍然可以發(fā)送物體狀態(tài)信 息，但是服務端在比較后會忽略這些信息。直到這個客戶端在收到“發(fā)送權”移交信息后， 自動停止發(fā)送。而在發(fā)生交互的客戶端上，先假設自己擁有“發(fā)送權”，并開始發(fā)送信息，此 時服務端已經(jīng)可以接收并更新信息，當收到“發(fā)送權”移交信息后，則真正獲得“發(fā)送權”。這樣的處理不會對帶寬造成持久影響，“發(fā)送權”的移交的延時至多等于兩次數(shù)據(jù) 通信的時間間隔加上網(wǎng)絡延時。無用數(shù)據(jù)包的數(shù)量相當于一次的發(fā)送量。下面舉例說明典型的聯(lián)網(wǎng)賽車游戲例子。本技術針對CS架構下的高實時要求的物理計算同步服務，一個聯(lián)網(wǎng)賽車游戲通 常包含4 6個客戶端，它們都連接到服務端形成一個CS體系，并且在這個小環(huán)境中，客戶 端之間必須進行交互同步。不同于一般的剛體計算，賽車的相關參數(shù)很多，因此為了得到較好的操作體驗，使 用物理引擎進行賽車行駛的模擬。在整個場景中除了各個用戶控制的車輛外，還有一些帶 有物理特性的障礙物，增加競賽的隨機性。在使用本技術進行游戲同步前，需要客戶端與服務端之間有定時的網(wǎng)絡同步機 制，用于高實時要求的網(wǎng)絡同步；需要客戶端安裝有物理引擎，對場景中的物體進行物理運
笪弁。啟動服務端后，由客戶端連接服務端并開始游戲。此時在服務端首先生成物體包括車輛(受控物體)和障礙物(非受控物體)，對于連接到服務端的每個客戶端，生成這些 物體的鏡像，并且為客戶端分配數(shù)據(jù)“發(fā)送權”。車輛的數(shù)據(jù)“發(fā)送權”分配非常簡單，因為每個客戶端只能控制一輛車，因此客戶 端將得到自己受控車輛的“發(fā)送權”。場景中的障礙物由于未發(fā)生任何碰撞，因此其“發(fā)送 權”的分配遵循“先來先得”的原則，也就是說由最先發(fā)送準備信號的客戶端來進行數(shù)據(jù)發(fā) 送。因為在游戲開始時各個客戶端已經(jīng)開始進行物理計算，只是不具備“發(fā)送權”，而最先發(fā) 送準備信號的客戶端，無論在網(wǎng)絡帶寬和機器性能方面可能都優(yōu)于其它客戶端，因此將“發(fā) 送權”分配給它是合理的。在隨后的競賽過程中，賽車的“發(fā)送權”在最初分配完后直到比賽結束不會改變。 根據(jù)圖2的通信流程，對于用戶控制的車輛，需要處理用戶的操作，然后客戶端需要對場景 中所有物體進行物理計算，實時更新它們的物理狀態(tài)，包括位置、朝向、速度、角速度等，對 于車輛還有額外的操作狀態(tài)，如加速、剎車、轉向等。為了保證畫面的流暢，物理計算需要實 時進行，服務器的網(wǎng)絡同步提供修正功能。對于非線性變化的物理變量，通過實踐可以知道 同步二次變化率進行變量修正，可以提供較好的預測效果。在輕度網(wǎng)絡延時情況下，實時物 理計算附加非線性量預測的結果，與同步修正的結果偏差可以忍受。而且本技術讓偏差僅 發(fā)生非受控物體上，對于玩家受控物體完全與單機情況下一樣。因為受控物體的數(shù)據(jù)由客 戶端發(fā)送給服務端，而對于服務端返回的數(shù)據(jù)簡單地忽略。在嚴重的網(wǎng)絡延時下，預測偏差 會很大，場景中非受控物體位置發(fā)生突變，影響游戲性。理論上這種情況是無法解決的，由 于物體的運動非線性，并且無法預測其它用戶的操作，因此無法近似估計其它物體位置。在場景中的障礙物屬于第三類非受控物體，最初的“發(fā)送權”交給最先發(fā)送準備信 號的客戶端(A)，當其它客戶端(B)與障礙物發(fā)生碰撞時，在客戶端B的物理引擎會進行碰 撞回調(diào)，通知客戶端程序發(fā)生了碰撞，并給出碰撞的物體對。只有當碰撞的兩個物體分別為 客戶端B的車輛(b)和障礙物(c)時，才會進行完整的“發(fā)送權”更新策略流程，否則當某 步檢測不通過時，回到循環(huán)起點繼續(xù)檢測。當車輛b與物體c發(fā)生碰撞，并且通過物體屬性的檢測，則會向服務端提交碰撞信 息，包含客戶端B的ID，車輛b的ID以及物體c的ID。同時物理計算隨后會實時計算碰撞 后的物理效果，例如撞飛后在地面上滾動等。在提交碰撞信息的時刻，服務端的物體c “發(fā) 送權”因網(wǎng)絡延時未發(fā)生改變?？蛻舳薆將先假設自己擁有“發(fā)送權”，不再接收服務端的該 物體的同步信息，轉而開始發(fā)送信息，包含車輛b的物體信息以及自身客戶端ID號。在數(shù) 據(jù)包順序到達的情況下，服務端會先收到碰撞信息，立即就可以改變“發(fā)送權”，而隨后的同 步數(shù)據(jù)有自然是有效的。如果數(shù)據(jù)包由于網(wǎng)絡問題錯序到達，那么在碰撞信息之前的數(shù)據(jù) 包都無效，因為“發(fā)送權”未改變。本技術中“發(fā)送權”的改變?nèi)Q于碰撞信息，與使用“發(fā) 送權”進行數(shù)據(jù)同步無關。只有服務端確認了碰撞信息，“發(fā)送權”才真正改變。隨后服務 端需要將新的擁有物體數(shù)據(jù)“發(fā)送權”的客戶端ID進行公布，公布過程可以和同步過程放 在一起，也就是同步的同時提供當前擁有物體“發(fā)送權”的客戶端ID。當各個客戶端收到數(shù) 據(jù)時，核對ID如果一致，則擁有“發(fā)送權”或確定自己擁有“發(fā)送權”;如果不一致，則同步客 戶端鏡像物體的數(shù)據(jù)，包括位置、朝向、速度等物理信息，假設擁有的“發(fā)送權”也立即取消， 停止發(fā)送無效數(shù)據(jù)?！鞍l(fā)送權”的分配以服務端為準。對于賽車這種第一視角游戲來說，用戶一般對受控物體周圍的物體比較敏感。在單機情況下，物體無需同步情況簡單；在聯(lián)網(wǎng)情況下，所有物體都需要經(jīng)過同步，保證在各個客戶端顯示一致。碰撞后交換“發(fā)送權”的策略可以有效處理非受控物體的網(wǎng)絡同步問 題。用戶視野范圍內(nèi)的障礙物在被撞擊后產(chǎn)生的物理效果將是流暢的，可以提高用戶的真 實感體驗。
權利要求
一種CS架構下的物理計算網(wǎng)絡同步方法，該方法是在客戶端和服務端具備雙向通訊機制，在客戶端進行物理計算，并對其操縱的物體具有發(fā)送權，并發(fā)送數(shù)據(jù)；服務端只接收數(shù)據(jù)，并據(jù)此發(fā)送同步信號，不進行物理量計算；客戶端和服務端雙向通訊實施同步包括受控物體和非受控物體，其中對于受控物體的同步步驟是(1)客戶端接受客戶受控物體操作；(2)對受控物體進行物理量計算；(3)更新場景中所有物體物理信息；(4)向服務端發(fā)送受控物體狀態(tài)數(shù)據(jù)；(5)服務端接收客戶端發(fā)送的受控物體狀態(tài)的數(shù)據(jù)；(6)服務端更新鏡像物體狀態(tài)數(shù)據(jù)；(7)服務端向客戶端發(fā)送鏡像物體狀態(tài)數(shù)據(jù)；(8)客戶端接收服務端的同步信息；(9)選擇更新；(10)結束；其中，根據(jù)受控物體ID和客戶端ID來判斷數(shù)據(jù)“發(fā)送權”，服務端負責決定數(shù)據(jù)改變以及分發(fā)數(shù)據(jù)，客戶端進行“選擇同步”；對于非受控物體，采用“碰撞交換控制權”的同步策略，即由客戶端的受控物體撞擊非受控物體獲得物體的數(shù)據(jù)“發(fā)送權”，其步驟是(1)對非控受物體進行物理量計算；(2)檢測碰撞；(3)如有碰撞，檢測碰撞類型；如無碰撞，直接更新“發(fā)送權”；(4)如有碰撞，碰撞類型是一般物體，則向服務端發(fā)送碰撞信息；如碰撞是其他客戶端受控物體，則直接更新發(fā)送權；(5)檢測有、無“發(fā)送權”，如無，直接更新發(fā)送權；如有，則向服務端發(fā)送物體的物理信息；(6)服務端接收碰撞信息；(7)更新用戶“發(fā)送權”；(8)服務端接收客戶端物體的物理信息；(9)檢測“發(fā)送權”一致否？(10)如不一致，則向客戶端發(fā)送更新的“發(fā)送權”；(11)如一致，則更新物體物理信息后，再向客戶端發(fā)送更新的“發(fā)送權”；(12結束；其中，處理場景中非受控物體的物理計算，采用“碰撞交換控制權”的策略進行同步；服務端負責仲裁“發(fā)送權”和同步數(shù)據(jù)，客戶端需要提交碰撞信息，用于“發(fā)送權”的客戶端發(fā)送數(shù)據(jù)，其它客戶端同步數(shù)據(jù)。
全文摘要
本發(fā)明提供一種CS架構下的物理計算網(wǎng)絡同步方法，為了兼顧計算的效率和同步的精確，對CS架構下含有物理計算的交互服務，針對物理計算相關部分和客戶端服務端之間的通信流程做改進，服務端不進行物理計算，僅負責接受客戶端數(shù)據(jù)，并同步到其它客戶端?？蛻舳藢τ脩艨刂频奈矬w進行物理計算，將其狀態(tài)發(fā)送給服務端。本發(fā)明是在客戶端和服務端具備雙向通訊機制，在客戶端進行物理計算，并發(fā)送數(shù)據(jù)；服務端只接收數(shù)據(jù)，并據(jù)此發(fā)送同步信號，不進行物理量計算。
文檔編號H04L29/06GK101841538SQ20101014917
公開日2010年9月22日 申請日期2010年4月16日 優(yōu)先權日2010年4月16日
發(fā)明者朱德棟 申請人:上海亞圖軟件有限公司