• <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)自強而不息

            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 閱讀(207) 評論(0)  編輯 收藏 引用


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


            公告

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            隨筆分類(178)

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

            搜索

            最新評論

            久久精品成人欧美大片| 久久精品国产精品亚洲精品 | 精品久久久久国产免费| 亚洲欧洲中文日韩久久AV乱码| 精品久久久无码21p发布| 久久无码人妻一区二区三区| 久久亚洲中文字幕精品一区四| 色8久久人人97超碰香蕉987| 中文字幕无码久久久| 国产成人99久久亚洲综合精品| 精品久久人人爽天天玩人人妻| 久久99国产精品99久久| 亚洲综合久久夜AV | 久久精品9988| 亚洲精品乱码久久久久久蜜桃不卡| 久久天天躁狠狠躁夜夜不卡 | 欧美色综合久久久久久| 国内高清久久久久久| 91精品国产91久久久久久| 久久亚洲日韩看片无码| 精品人妻伦一二三区久久| 久久99精品国产麻豆宅宅 | 无码国内精品久久人妻麻豆按摩| 久久精品国产91久久综合麻豆自制| 久久久久亚洲AV无码麻豆| 一本久久综合亚洲鲁鲁五月天| 人妻丰满?V无码久久不卡| 久久久WWW成人免费精品| 99久久国产综合精品五月天喷水| 久久精品国产精品亚洲精品| 久久婷婷五月综合色高清| 无码任你躁久久久久久老妇App| 久久无码专区国产精品发布| 性高湖久久久久久久久AAAAA| AV无码久久久久不卡蜜桃| 久久久午夜精品| 亚洲日本久久久午夜精品| 97久久国产露脸精品国产| 97久久婷婷五月综合色d啪蜜芽| 久久er99热精品一区二区| 亚洲AV无一区二区三区久久 |