[程式] 問題，物件的地形移動與框選

[gmking (帝王之心)]

大家好，目前HOE團隊已經開始實作部分，以下是我們第一階段想要實作的系統
https://drive.google.com/file/d/0B_BC8XSz8r3tZzRuZHFLbVBORUE/edit?usp=sharing
目前還缺少對於unity有開發經驗的程式
會處理物件移動或者是讀取系統時間進行數值計算，還有製作動畫等
美術部分缺少會製作｢地形模組｣的高手~~
====================================================================
廣告結束，下面是問題......
因為我們經驗還不夠，目前有幾個問題想要請教一下大家
1.物件移動，因應地形改變移動速度問題
不知道您之前是怎麼做地形的？
因為我們想要做到單位移動可以因應不同地形而改變速度。unity可以內建地型模組但是
不好用(因為之後地圖很大很大，用他的內建程式沒辦法模組化)，所以我們想要自己建模
。
但是不知道是直接定義物件的高度然後計算斜率，還是把地形模轉成矩陣之後利用高度差
來求斜率呢？

2.框選物件問題
因為我們想要製作RTS，利用滑鼠左鍵框選來選擇單位，右鍵點擊地面來移動，請問要如
何製作這種框選功能呢？利用UI？可是這是動態UI.....

====================================================================
問這種問題應該不會被打吧 囧

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.114.200.150
推 GoalBased:很開心看到你們已經開始實做了  先推再來看系統
其實我們這裡有做功能展示品XDD 但等之後弄完整再給大家看吧
※ 編輯: gmking          來自: 140.114.200.150      (02/23 01:16)
→ azureblaze:2. http://ppt.cc/jY2d
→ azureblaze:1.地圖資訊和地圖模組分開 模組只是顯示用的
→ azureblaze:然後我覺得以要做的東西的難度,你們應該學習自行找答案
→ azureblaze:以2.來說 http://ppt.cc/ObXZ
推 GoalBased:你都PO聞了 卻只有文字..既然有展品就放上來吧
→ gmking:謝謝您的回答！那個是功能展示品(PPT做的XD) 但還不完全
→ gmking:真的要等我們功能做完再傳= =
推 Ansaga:地型的話要不要參考看看banished用的那個套件
→ Ansaga:http://www.axisgamefactory.com/
→ Ansaga:同事試用了一下感覺滿好玩的
推 cjcat2266:幾個ray cast同時往下探測地形高度，用得到的資料算斜率
→ gmking:感謝樓上XD這方法昨天晚上我們有想到
→ gmking:看來真的就那幾個方法...剩下是pathfinding的問題了
→ gmking:雖然A*有些瑕疵 不過應該會先用這個演算法
→ gmking:謝謝A大的提供 這應該可以省不少時間= =(我們美術不會地形.
推 Killercat:erh, 我個人是有個比較不討喜的建議 就是圖像面先用2D
→ Killercat:來做Prototype，再用地圖的Alpha channel來模擬高度
→ Killercat:這樣可以先聚焦在遊戲的邏輯面 而高度部分一樣可以得到
→ Killercat:然後又不需要複雜的3D系統也可以做出prototype
→ Killercat:缺點的話大概就是高度會僅僅只有256階 但是系統會簡單
→ Killercat:非常多 也暫時不用接觸複雜的ray cast問題
→ Killercat:說比較明顯的缺點的話呢 就是這個沒辦法用A*很常搭配的
→ Killercat:導航網格做A* 但是普通柵狀的A*一樣能做 也一樣能及時
→ Killercat:filter掉不能走的框框 其實不會差太多
→ Killercat:人力是很有限的 很難一邊做3D引擎一邊做遊戲邏輯同時解
→ Killercat:決兩個毫不相干的問題 我會建議先盡可能簡單化遊戲邏輯
→ Killercat:以外的部分，專新先prototype遊戲邏輯會比較好
→ Killercat:另外我說真的 幾乎所有的PF演算法都是based on A*....
→ Killercat:最多最多就是heuristic function寫的好不好而已
→ Killercat:所以不會存在什麼「A*有些瑕疵但是還是暫時得用」這問題
→ y3k:1.我建議你們先用2D做... 2.物件可以常駐在場 只差顯示不顯示
→ gmking:詢問許多人意見後，問題已經解答，謝謝大家
推 dreamnook:喔喔有實際進度了嗎？ 推
推 LayerZ:第一個問題...我沒做過手機開發，以下回答有錯請指正
→ LayerZ:1.你確定你要在遊戲中"即時"運算?
→ LayerZ:地圖去掉Z軸後也只是2D，地圖固定的話，很多資訊都是可以
→ LayerZ:在設計過程中預先算出來，以純資料方式載入
→ gmking:sry沒說清楚我們後來的方法導致誤會，會先用矩陣存起來
→ Killercat:3D的做法通常分兩種 一種是打前後左右四個點ray cast出
→ Killercat:z以後可以算出四方向斜率 二的話則是拿這個mesh的三個點
→ Killercat:套公式也可以得到斜率（也可以額外參考相鄰三角）
→ Killercat:兩種做法其實各有好處 預算也可以，只是你要花點心思
→ Killercat:去存這些東西，索引時間不見得會比算的划算
→ Killercat:2d就簡單了 直接拿附近八個像素的alpha channel就好
推 LayerZ:我沒想到索引成本..那真的不一定比較划算@@
→ Killercat:因為斜率可以用GPU在shader算 這一定是最快的 XD
→ Killercat:不過普通CPU來講的話 大概就是多吃一塊記憶體 快慢難講
其實斜率讀取部分，我們也可以改成這樣？
比如說每隔0.1秒在去讀取下一個移動格子的資訊。(不然每走一個就讀取下一個路徑會走
到的格子好像蠻耗效能的)
因為一開始先把地形存到矩陣裡面了，剩下的就是看路徑演算法選取哪幾個格子去走了。
這裡的斜率是高度值的變化，也就是delta z，然而值得注意的是，一個角色的大小不是
對應到一個方格，最少也要對應到9格方格(物件比地圖格子還大)
不然走起來會超卡啊！(一支角色一個格子的遊戲玩起來很難控，特別是RTS...)
但不知採取隔一段時間再去讀取位置座標的方式會不會比較節省效能？
※ 編輯: gmking          來自: 140.114.200.150      (02/27 04:06)
→ Killercat:這部分有個比較妙的解法 就是在算導航的時候一定會算
→ Killercat:導航格 再最後一步把路徑拼接起來的時候算沿路的斜率
→ Killercat:這做法有很多意想不到的好處，以前前公司這樣做過
→ Killercat:這樣你就可以在每段導航路徑順便加入速度資訊
→ Killercat:重點是這樣計算會快很多
→ y3k:我真的建議你們先用2D概念去做 不會浪費太多時間在這種細節上
→ azureblaze:先能在平地上走再來考慮這種問題
推 StupidGaGa:推樓上，這句話是重點，也是基礎
→ StupidGaGa:我第一次寫遊戲時，前輩就是給這句
→ StupidGaGa:前輩：「你先會走，再來跟我談其他的」
→ StupidGaGa:另外，你上面說依照不同地形決定移動速度，又說到高度
→ StupidGaGa:你是想讓角色爬山的變慢，還是走過泥濘地的時候變慢？
→ StupidGaGa:如果你是鳥瞰視角的話，建議你直接做2D
→ StupidGaGa:不少遊戲程式都是以2D再寫，但是看起來3D
→ StupidGaGa:2D就不用算斜率，只要把「斜坡」本身當成一種地形就好