有了客戶端的無限大地圖，服務(wù)器端也可以做做嘗試了，服務(wù)器比客戶端單純了很多，不用做裁減等復(fù)雜的計(jì)算工作，但是要維護(hù)大量的信息通訊，最棘手的問題就是，如何讓“身邊”其他玩家知道你在哪里，player數(shù)量那么巨大，如果所有的player的狀態(tài)通知所有的人那就是n的n次方的通訊，可以看來這樣的通訊方式是完全不合理的，所以如何確定“身邊”這個(gè)概念就至關(guān)重要了。
有了客戶端無限大地圖的實(shí)現(xiàn)，這個(gè)思路就豁然開朗了，有個(gè)圖例：
把服務(wù)器打上格子，把整個(gè)地形來個(gè)定義
定義為 blocks_Tx_Ty_Bx_By
Tx Ty 代表的是 Tile的第幾行第幾列
Bx By 代表的是該Tile下Block的第幾行第幾列
把每個(gè)block的范圍給筐定，這個(gè)可以事先計(jì)算出來的，很簡單
人物一旦發(fā)生了移動(dòng)就會(huì)發(fā)出udp的信號，服務(wù)器改變每個(gè)人物所在的位置
那么客戶端的Role(玩家所操縱的角色)最關(guān)心的是周圍9個(gè)tile里面活動(dòng)的其他玩家的信息
因?yàn)榭蛻舳艘M(jìn)行視錐剪裁，
反過來說，角色A移動(dòng)了，就要通知周圍9個(gè)tile里面所有的角色，你當(dāng)前的位置
另外，移動(dòng)的時(shí)候還要看你所在的block發(fā)生了改變沒有，如果發(fā)生了改變，這個(gè)信息也要發(fā)出去
那么客戶端可以更新所觀測的角色所在的block，這樣客戶端的tile作culling和rending以及collising的時(shí)候就方便了
客戶端要作的只是簡單的terrain.AddSenceModel 和 terrain.RemoveSenceModel就能動(dòng)態(tài)更新block中的角色模型了
一個(gè)block好歹也有33x33，被觀測對象只有block改變了才會(huì)做(terrain.AddSenceModel 和 terrain.RemoveSenceModel)這樣的操作
這樣的操作應(yīng)該不會(huì)特別頻繁，客戶端應(yīng)該開銷的起
客戶端，應(yīng)該存在一個(gè)可觀測的9個(gè)tile的rolelist，每次發(fā)過來的其他玩家的udp positionpack還是要作即時(shí)更新的。
目前根據(jù)這個(gè)思路我就要開展工作了，效率是至關(guān)重要的。
按照這個(gè)工作實(shí)現(xiàn)了再來測試效率，預(yù)計(jì)本周之內(nèi)搞定角色之間位置信息的相互通訊。
激動(dòng)人心的時(shí)刻就要到來了。。。。。。
目前只是嘗試，更多的細(xì)節(jié)和感受我會(huì)逐步發(fā)放上來。