※ 引述《GKy (GKy)》之銘言： : ※ 引述《yoco315 (眠月)》之銘言： : : 目前研究室在進行的一個專案， : : 是要把智慧型代理人系統放進 RPG/MMORPG， : ..43.. : : 有沒有前輩有過開發OLG的經驗， : : 能不能指點一下在運動座標同步化這個地方是怎麼克服的？ : : 萬分感謝。 : 提供一點我的經驗, 之前試做過 2~4 人的對戰型 2D 橫捲 ACT, : 我用的方法是追蹤各 Client 的操作輸入狀態, : 只有在 Client 有鍵盤輸入時才需要送資料, : 然後各 Client 端在收到別人的輸入資料後, 對應的角色 : 則開始依得到的資料開始模擬移動. : 簡單一點想就有點類似遠端來搖控角色的感覺, : 然後大概間隔幾秒在做座標的同步, 角色就能移動的很順暢了. : 就不曉得 MMO 是否適用此方式了, 總之參考看看吧~ YA~ 難得有我可以回的主題 關於同步的方式 我就我看過的研究提出看法 網路遊戲和OLG的同步方式不一樣 不同類型的遊戲 其同步機制...也不一樣 如果你是設計FPS OR其他即時性強的GAME 如CS Q3 我看過的都有 固定週期的座標更新動作 如果是大型OLG 如MMORPG的話... 我個人看過的說法是 利用預測玩家動作的方式來降低運算量和流量 不過 詳情就不知道了 PS. MMORPG的頻寬耗用 相當少... 記得 <10kbps吧不過這是天堂1的時代 製作 MMORPG的引擎 會有兩種地圖的分割方式 比較簡單設計的是 切許多小地圖 要進入其他地圖再LOADING broadcast 僅需要發送在同一小地圖的玩家即可 而更新週期則是依據在小地圖內的玩家數來決定 通常通一小地圖內的玩家越多 更新週期要越快 更新的MESSAGE 只需要送玩家的動作即可 如傳送玩家的位置 只送相對移動量 如果有玩家IDLE 那就不需要送他的MESSAGE 如果覺得流量大 就壓縮送出的封包吧 PS. 加密... 好像也是必須的 最後講感想(這不是我看到的) client 對 server的 update message 和 server對client的 update message 應該是分開設計的 如application包裝的header OR 壓縮加密 至少他們在流量的表現上面 是明顯的不同 封包的長度 與MESSAGE的更新週期 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.129.36.82