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

            天行健 君子當(dāng)自強(qiáng)而不息

            Getting Online with Multiplayer Gaming(5)

             

            A couple of things quickly come to mind when using the type of network communications
            just mentioned. First, because the server is the only system responsible for
            maintaining the game state, all connected clients would have to wait for those periodic
            updates to keep the game flowing.

            Unfortunately, network transmission speeds don’t allow instantaneous
            transmissions, so some of the data passing from client to server and
            back again are delayed. This delay in transmission is called latency, and it's
            this latency that can cause havoc in your game.

            NOTE
            Latency is measured in milliseconds (ms).

            Because the server is the only system allowed to make changes to the game world,
            the server must validate players’ actions before they can occur. As you can see from
            Figure 19.4, players trying to issue actions will experience a delay from the time the
            actions are initiated to the time they take place. This delay of action, called lag, can
            cause the game-play to be choppy (and thus unplayable).

            To keep things running smoothly and help alleviate the effects of latency and lag,
            clients are allowed to make small changes to the world between server updates.
            Those small changes are typically only to update the movement of characters. In
            that way, clients don’t have to wait for server updates in order to move characters;
            clients can just guess how to update all characters based on their last known state
            (as you can see in Figure 19.5). This form of guessing is called dead reckoning, and
            it is used in network gaming.

            When more serious actions, such as combat actions, come into play, using dead
            reckoning is unacceptable. The server is the authority, and if a system needs to
            determine who hits whom and how much damage is done, that system needs to
            query the server for resolution.

            As mentioned, when using a networking system, the second problem is game timing. Let’s
            face it—trying to synchronize possibly dozens of clients is almost impossible. Each computer
            hooked on the network has a different latency; some clients take longer sending messages
            to the server and receiving them back from the server.

            CAUTION
            If you leave any of the major decisions (such as combat) up to a client, you’re inviting trouble,
            because game hackers and cheaters will take full advantage of any loopholes. Remember
            that the server is the only system responsible for keeping track of the game; the clients are
            merely portals into the game world.

            On the client side, one player might make a move at the exact time as another
            player, but because their actions take a moment to reach the server, the client with
            the faster connection will have the advantage (as illustrated in Figure 19.6).

            All messages received by the client and server are recorded with the time of their
            receipt. The server uses that time to determine how to update the players. For
            example, if a message received by the server isn’t processed within 100 milliseconds
            (ms), the server compensates for that amount of time during updates. The same
            goes for clients. If an action message needs to be updated (especially during the
            use of dead reckoning), that time (the time the messages are received) is used to
            move characters appropriately.

            Now that you have an overview of how the clients and server work
            together, take a closer look at each one.

            TIP
            To help improve synchronization, the client and server both calculate latency into the
            time that a message is received.


            posted on 2007-12-18 16:59 lovedday 閱讀(209) 評(píng)論(0)  編輯 收藏 引用


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            公告

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            隨筆分類(178)

            3D游戲編程相關(guān)鏈接

            搜索

            最新評(píng)論

            精品国产乱码久久久久久1区2区 | 亚洲成av人片不卡无码久久| 天天爽天天爽天天片a久久网| 久久99精品国产麻豆婷婷| 久久久久无码国产精品不卡| 久久天天躁狠狠躁夜夜av浪潮| 久久SE精品一区二区| 国产精品美女久久久久网| 久久久噜噜噜久久| 国产亚洲色婷婷久久99精品| 久久久久人妻精品一区三寸蜜桃 | 久久99精品久久久久久动态图| 高清免费久久午夜精品| 日日狠狠久久偷偷色综合免费 | 日本久久久久亚洲中字幕| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 久久这里都是精品| 国产精品成人99久久久久| 久久无码人妻一区二区三区 | 久久性生大片免费观看性| 69久久夜色精品国产69| 久久人人爽人人人人片av| 久久91这里精品国产2020| 国产精品久久久久久影院| 综合人妻久久一区二区精品| 少妇久久久久久被弄到高潮| 国产一区二区精品久久凹凸| 久久精品国产免费一区| 69久久夜色精品国产69| 精品久久久久久亚洲| 精品久久久噜噜噜久久久| 99精品国产99久久久久久97 | 一本久久久久久久| 久久久久久狠狠丁香| 国内精品人妻无码久久久影院 | 成人国内精品久久久久影院VR| 国产精品9999久久久久| 久久青青草原精品国产| 久久久久无码精品国产| 精品少妇人妻av无码久久| 国产精品一久久香蕉产线看|