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

            天行健 君子當自強而不息

            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麻豆| 国产精品欧美久久久久无广告| 久久青青草原精品国产不卡| 久久SE精品一区二区| 国产成人久久精品区一区二区| 久久99久久成人免费播放| 亚洲国产精品无码久久一区二区| 91精品国产9l久久久久| 欧美亚洲国产精品久久久久| 99久久免费国产精品热| 久久精品中文字幕大胸| 国产精品久久久久9999高清| 久久九九久精品国产免费直播| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 久久伊人五月丁香狠狠色| 77777亚洲午夜久久多喷| 免费精品久久久久久中文字幕| 精品蜜臀久久久久99网站| 久久久午夜精品| 久久91精品综合国产首页| 99久久99这里只有免费费精品| 亚洲欧美精品一区久久中文字幕| 青青热久久综合网伊人| 久久久久久久久无码精品亚洲日韩| 久久综合日本熟妇| 婷婷久久综合九色综合绿巨人| 精品免费tv久久久久久久| 国产精品美女久久久| 国产Av激情久久无码天堂| 久久精品aⅴ无码中文字字幕重口 久久精品a亚洲国产v高清不卡 | 久久这里有精品视频| 99久久精品久久久久久清纯| 久久久91精品国产一区二区三区| 99久久精品国产麻豆| 老司机国内精品久久久久| 蜜桃麻豆www久久| 久久久久久久综合综合狠狠|