• <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

            低調(diào)做技術(shù)__歡迎移步我的獨(dú)立博客 codemaro.com 微博 kevinlynx

            網(wǎng)游中的玩家移動(dòng)

            Kevin Lynx 6.22.2010

            MMORPG中,玩家的移動(dòng)主要邏輯都放在客戶端進(jìn)行,包括自動(dòng)尋路和響應(yīng)玩家的操作,服務(wù)
            器在這里擔(dān)當(dāng)一個(gè)被動(dòng)角色。但是服務(wù)器端的玩家數(shù)據(jù)卻是真正的被其他邏輯模塊參考的數(shù)
            據(jù)。

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

            在一般的邏輯模塊中,客戶端發(fā)送一個(gè)請(qǐng)求到服務(wù)器,服務(wù)器作了驗(yàn)證后返回驗(yàn)證結(jié)果,客
            戶端接收驗(yàn)證結(jié)果繼續(xù)之前的邏輯。這對(duì)于MMO中諸如物品操作而言是足夠的,但無法應(yīng)用
            于玩家移動(dòng)。

            這里的做法是:客戶端每走一步,都發(fā)消息(網(wǎng)絡(luò)封包)給服務(wù)器,服務(wù)器做驗(yàn)證;客戶端
            停止走動(dòng)后,通知服務(wù)器,服務(wù)器返回自己保存的坐標(biāo),客戶端在這個(gè)時(shí)候才使用服務(wù)器端
            的數(shù)據(jù)同步一次本地坐標(biāo)。其操作序列如下圖:

            -----------------------------------------------------------------
            Client                                            Server
            移動(dòng)、本地坐標(biāo)改變    ---->            驗(yàn)證C/S之間的坐標(biāo)是否差距過大,
                                                驗(yàn)證失敗通知客戶端停止移動(dòng)
            停止移動(dòng)              ---->            驗(yàn)證同上
            同步本地坐標(biāo)為服務(wù)器坐標(biāo)   <---
            -----------------------------------------------------------------

            此外,客戶端保存一個(gè)請(qǐng)求計(jì)數(shù),每一次發(fā)送一個(gè)移動(dòng)請(qǐng)求時(shí),遞增該計(jì)數(shù);服務(wù)器收到該
            請(qǐng)求后,驗(yàn)證成功,返回一個(gè)消息,客戶端收到此回應(yīng)消息后遞減該計(jì)數(shù)。當(dāng)該計(jì)數(shù)超過某
            個(gè)配置數(shù)值后,客戶端將忽略玩家的移動(dòng)操作。客戶端還可以將玩家的多個(gè)移動(dòng)操作合并為
            一個(gè),即,只在角色到達(dá)玩家最后一次點(diǎn)擊的坐標(biāo)時(shí),才發(fā)送停止移動(dòng)消息給服務(wù)器。

            配合請(qǐng)求計(jì)數(shù)機(jī)制,當(dāng)C->S的消息出現(xiàn)延遲太久時(shí),此時(shí)也意味著請(qǐng)求計(jì)數(shù)過大,客戶端會(huì)
            強(qiáng)迫玩家等待;服務(wù)器終于收到消息后,逐個(gè)處理,直到處理完后,客戶端的請(qǐng)求計(jì)數(shù)恢復(fù)
            時(shí),玩家才可繼續(xù)移動(dòng)。同樣,當(dāng)S->C的消息(只考慮停止移動(dòng)的消息回應(yīng))出現(xiàn)延遲時(shí),
            這個(gè)時(shí)候客戶端很可能在本地做了另一次移動(dòng)操作,在終于接收到上一次移動(dòng)操作的服務(wù)器
            端回應(yīng)時(shí),因?yàn)檫@個(gè)時(shí)候客戶端毫無條件地將本地?cái)?shù)據(jù)同步為服務(wù)器端發(fā)過來的數(shù)據(jù),那么
            ,出現(xiàn)這種情況后,客戶端角色就會(huì)出現(xiàn)拉回去的現(xiàn)象。這里的一次移動(dòng),可能是多個(gè)地圖
            格子的移動(dòng),一般為角色當(dāng)前坐標(biāo)到玩家點(diǎn)擊的目標(biāo)坐標(biāo)。

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

            評(píng)論

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-22 21:34 小時(shí)候可靚了

            搶沙發(fā)!  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-22 21:39 小時(shí)候可靚了

            客戶端每走一步,都發(fā)消息(網(wǎng)絡(luò)封包)給服務(wù)器,服務(wù)器做驗(yàn)證;客戶端
            停止走動(dòng)后,通知服務(wù)器,服務(wù)器返回自己保存的坐標(biāo),客戶端在這個(gè)時(shí)候才使用服務(wù)器端
            的數(shù)據(jù)同步一次本地坐標(biāo)。

            這樣會(huì)不會(huì)導(dǎo)致本地角色看到其它玩家的移動(dòng)不自然呢?  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-22 22:34 evoup

            每一步,不至于吧,應(yīng)該是a點(diǎn)到b點(diǎn)間一定時(shí)間內(nèi)修正客戶端的位移吧,該時(shí)間內(nèi)按照玩家點(diǎn)擊的位置客戶端自己位移才是吧,真的實(shí)時(shí)怎么吃得消。  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-23 08:52 Kevin Lynx

            @evoup
            話說你沒有看清楚我說的內(nèi)容。每一步發(fā)的消息僅用于服務(wù)器的驗(yàn)證,不同步客戶端數(shù)據(jù)。
            @小時(shí)候可靚了
            這個(gè)屬于另一個(gè)話題了,客戶端會(huì)粗略估算其他角色的移動(dòng)情況,如取得方向模擬其行走,以達(dá)到自然的效果,改天細(xì)談下。  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-23 09:35 keror

            “考慮到這兩個(gè)重要的因素,首先需要盡量減少C/S之間數(shù)據(jù)的交互。“
            “服務(wù)器收到該請(qǐng)求后,驗(yàn)證成功,返回一個(gè)消息”

            這個(gè)有減少數(shù)據(jù)交互么?  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-23 09:39 Kevin Lynx

            @keror
            這里返回的消息,客戶端僅用于遞減請(qǐng)求計(jì)數(shù)。不會(huì)立即影響客戶端的移動(dòng)效果。  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-06-24 22:29 evoup

            呵呵有道理  回復(fù)  更多評(píng)論   

            # re: 網(wǎng)游中的玩家移動(dòng) 2010-07-08 15:21

            這個(gè)是誰啊、、、我暈的。。。我是goole來的。。。  回復(fù)  更多評(píng)論   

            99999久久久久久亚洲| 欧美精品一本久久男人的天堂| 无码人妻久久一区二区三区| 久久夜色撩人精品国产| 久久91亚洲人成电影网站| 亚洲AV日韩精品久久久久久| 女同久久| 日本福利片国产午夜久久| 国产亚洲精品美女久久久| 久久影院综合精品| 久久久久99精品成人片直播| 婷婷久久综合| 亚洲欧美一区二区三区久久| 波多野结衣久久一区二区| 亚洲乱码日产精品a级毛片久久| 精品久久久久久久久久中文字幕| 精品国产91久久久久久久a| 国产女人aaa级久久久级| 久久精品国产精品亜洲毛片| 久久久久国产成人精品亚洲午夜| 久久久艹| 色欲久久久天天天综合网| 日日躁夜夜躁狠狠久久AV| 久久99热只有频精品8| 国产精品九九久久免费视频| 欧美日韩成人精品久久久免费看| 亚洲美日韩Av中文字幕无码久久久妻妇| 99精品国产免费久久久久久下载| 亚洲国产精品无码久久| 亚洲嫩草影院久久精品| 久久人人爽人人爽人人片AV不| 久久久久亚洲Av无码专| 久久久黄片| 久久ww精品w免费人成| 精品久久久久久无码人妻热| 久久精品亚洲AV久久久无码| 久久久久久久99精品免费观看| 婷婷久久综合九色综合绿巨人 | 久久精品人妻中文系列| 精品午夜久久福利大片| 国产精品久久婷婷六月丁香|