※ 引述《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