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

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