• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            loop_in_codes

            低調做技術__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

            網游中的玩家移動

            Kevin Lynx 6.22.2010

            MMORPG中,玩家的移動主要邏輯都放在客戶端進行,包括自動尋路和響應玩家的操作,服務
            器在這里擔當一個被動角色。但是服務器端的玩家數據卻是真正的被其他邏輯模塊參考的數
            據。

            在這樣一種C/S主從關系中,如何保證C/S兩者各自維護的玩家坐標數據的一致性?為了保證
            數據的一致性,我們需要進行數據的同步。而導致數據不同步(不相同),也就是C/S之間
            玩家的坐標不一樣,主要來源于兩大原因:C->S數據的網絡延遲、S->C數據的網絡延遲。考
            慮到這兩個重要的因素,首先需要盡量減少C/S之間數據的交互。

            在一般的邏輯模塊中,客戶端發送一個請求到服務器,服務器作了驗證后返回驗證結果,客
            戶端接收驗證結果繼續之前的邏輯。這對于MMO中諸如物品操作而言是足夠的,但無法應用
            于玩家移動。

            這里的做法是:客戶端每走一步,都發消息(網絡封包)給服務器,服務器做驗證;客戶端
            停止走動后,通知服務器,服務器返回自己保存的坐標,客戶端在這個時候才使用服務器端
            的數據同步一次本地坐標。其操作序列如下圖:

            -----------------------------------------------------------------
            Client                                            Server
            移動、本地坐標改變    ---->            驗證C/S之間的坐標是否差距過大,
                                                驗證失敗通知客戶端停止移動
            停止移動              ---->            驗證同上
            同步本地坐標為服務器坐標   <---
            -----------------------------------------------------------------

            此外,客戶端保存一個請求計數,每一次發送一個移動請求時,遞增該計數;服務器收到該
            請求后,驗證成功,返回一個消息,客戶端收到此回應消息后遞減該計數。當該計數超過某
            個配置數值后,客戶端將忽略玩家的移動操作。客戶端還可以將玩家的多個移動操作合并為
            一個,即,只在角色到達玩家最后一次點擊的坐標時,才發送停止移動消息給服務器。

            配合請求計數機制,當C->S的消息出現延遲太久時,此時也意味著請求計數過大,客戶端會
            強迫玩家等待;服務器終于收到消息后,逐個處理,直到處理完后,客戶端的請求計數恢復
            時,玩家才可繼續移動。同樣,當S->C的消息(只考慮停止移動的消息回應)出現延遲時,
            這個時候客戶端很可能在本地做了另一次移動操作,在終于接收到上一次移動操作的服務器
            端回應時,因為這個時候客戶端毫無條件地將本地數據同步為服務器端發過來的數據,那么
            ,出現這種情況后,客戶端角色就會出現拉回去的現象。這里的一次移動,可能是多個地圖
            格子的移動,一般為角色當前坐標到玩家點擊的目標坐標。

            posted on 2010-06-22 21:27 Kevin Lynx 閱讀(4758) 評論(8)  編輯 收藏 引用 所屬分類: game develop

            評論

            # re: 網游中的玩家移動 2010-06-22 21:34 小時候可靚了

            搶沙發!  回復  更多評論   

            # re: 網游中的玩家移動 2010-06-22 21:39 小時候可靚了

            客戶端每走一步,都發消息(網絡封包)給服務器,服務器做驗證;客戶端
            停止走動后,通知服務器,服務器返回自己保存的坐標,客戶端在這個時候才使用服務器端
            的數據同步一次本地坐標。

            這樣會不會導致本地角色看到其它玩家的移動不自然呢?  回復  更多評論   

            # re: 網游中的玩家移動 2010-06-22 22:34 evoup

            每一步,不至于吧,應該是a點到b點間一定時間內修正客戶端的位移吧,該時間內按照玩家點擊的位置客戶端自己位移才是吧,真的實時怎么吃得消。  回復  更多評論   

            # re: 網游中的玩家移動 2010-06-23 08:52 Kevin Lynx

            @evoup
            話說你沒有看清楚我說的內容。每一步發的消息僅用于服務器的驗證,不同步客戶端數據。
            @小時候可靚了
            這個屬于另一個話題了,客戶端會粗略估算其他角色的移動情況,如取得方向模擬其行走,以達到自然的效果,改天細談下。  回復  更多評論   

            # re: 網游中的玩家移動 2010-06-23 09:35 keror

            “考慮到這兩個重要的因素,首先需要盡量減少C/S之間數據的交互。“
            “服務器收到該請求后,驗證成功,返回一個消息”

            這個有減少數據交互么?  回復  更多評論   

            # re: 網游中的玩家移動 2010-06-23 09:39 Kevin Lynx

            @keror
            這里返回的消息,客戶端僅用于遞減請求計數。不會立即影響客戶端的移動效果。  回復  更多評論   

            # re: 網游中的玩家移動 2010-06-24 22:29 evoup

            呵呵有道理  回復  更多評論   

            # re: 網游中的玩家移動 2010-07-08 15:21

            這個是誰啊、、、我暈的。。。我是goole來的。。。  回復  更多評論   

            欧美久久久久久| 国产精品午夜久久| 国产69精品久久久久APP下载| 天天做夜夜做久久做狠狠| 久久亚洲国产精品123区| 久久精品国产亚洲av麻豆蜜芽| 免费久久人人爽人人爽av| 婷婷久久久亚洲欧洲日产国码AV | 精品乱码久久久久久夜夜嗨| 欧美色综合久久久久久| 国产精品禁18久久久夂久| 999久久久免费国产精品播放| 久久久久亚洲AV成人网人人软件| 国产精品99久久久精品无码| 久久精品无码专区免费东京热| 亚洲成色WWW久久网站| 亚洲伊人久久大香线蕉苏妲己| 亚洲国产高清精品线久久| 91精品国产9l久久久久| 久久九色综合九色99伊人| 久久亚洲日韩精品一区二区三区| 久久久久中文字幕| 思思久久精品在热线热| 国产精品成人久久久久久久| 久久人人爽人人爽人人AV东京热 | 伊人久久大香线蕉成人| 久久精品这里热有精品| 亚洲AV无码1区2区久久| 香港aa三级久久三级老师2021国产三级精品三级在 | 久久露脸国产精品| 国产麻豆精品久久一二三| 国内精品伊人久久久久777| 四虎亚洲国产成人久久精品| 精品多毛少妇人妻AV免费久久| 69国产成人综合久久精品| 色综合久久无码中文字幕| 久久精品国产久精国产果冻传媒| 久久久久久av无码免费看大片| 久久不射电影网| 91久久精品视频| 精品久久久久久久久久久久久久久 |