楼主:
gmking (帝王之心)
2014-02-23 00:48:29大家好，目前HOE团队已经开始实作部分，以下是我们第一阶段想要实作的系统
https://drive.google.com/file/d/0B_BC8XSz8r3tZzRuZHFLbVBORUE/edit?usp=sharing
目前还缺少对于unity有开发经验的程式
会处理物件移动或者是读取系统时间进行数值计算，还有制作动画等
美术部分缺少会制作｢地形模组｣的高手~~
====================================================================
广告结束，下面是问题......
因为我们经验还不够，目前有几个问题想要请教一下大家
1.物件移动，因应地形改变移动速度问题
不知道您之前是怎么做地形的？
因为我们想要做到单位移动可以因应不同地形而改变速度。unity可以内建地型模组但是
不好用(因为之后地图很大很大，用他的内建程式没办法模组化)，所以我们想要自己建模
。
但是不知道是直接定义物件的高度然后计算斜率，还是把地形模转成矩阵之后利用高度差
来求斜率呢？
2.框选物件问题
因为我们想要制作RTS，利用鼠标左键框选来选择单位，右键点击地面来移动，请问要如
何制作这种框选功能呢？利用UI？可是这是动态UI.....
====================================================================
问这种问题应该不会被打吧 囧
作者:
GoalBased (Artificail Intelligence)
2014-02-23 01:00:00很开心看到你们已经开始实做了 先推再来看系统
作者:
GoalBased (Artificail Intelligence)
2014-02-23 01:44:00你都PO闻了 却只有文字..既然有展品就放上来吧
楼主:
gmking (帝王之心)
2014-02-23 01:46:00谢谢您的回答！那个是功能展示品(PPT做的XD) 但还不完全真的要等我们功能做完再传= =
几个ray cast同时往下探测地形高度，用得到的资料算斜率
楼主:
gmking (帝王之心)
2014-02-23 09:27:00感谢楼上XD这方法昨天晚上我们有想到看来真的就那几个方法...剩下是pathfinding的问题了虽然A*有些瑕疵 不过应该会先用这个算法谢谢A大的提供 这应该可以省不少时间= =(我们美术不会地形.
erh, 我个人是有个比较不讨喜的建议 就是图像面先用2D来做Prototype，再用地图的Alpha channel来模拟高度这样可以先聚焦在游戏的逻辑面 而高度部分一样可以得到然后又不需要复杂的3D系统也可以做出prototype缺点的话大概就是高度会仅仅只有256阶 但是系统会简单非常多 也暂时不用接触复杂的ray cast问题说比较明显的缺点的话呢 就是这个没办法用A*很常搭配的导航网格做A* 但是普通栅状的A*一样能做 也一样能及时filter掉不能走的框框 其实不会差太多人力是很有限的 很难一边做3D引擎一边做游戏逻辑同时解决两个毫不相干的问题 我会建议先尽可能简单化游戏逻辑以外的部分，专新先prototype游戏逻辑会比较好另外我说真的 几乎所有的PF算法都是based on A*....最多最多就是heuristic function写的好不好而已所以不会存在什么“A*有些瑕疵但是还是暂时得用”这问题
作者:
y3k (激流を制するは静水)
2014-02-23 17:25:001.我建议你们先用2D做... 2.物件可以常驻在场 只差显示不显示
楼主:
gmking (帝王之心)
2014-02-23 23:10:00询问许多人意见后，问题已经解答，谢谢大家
作者:
LayerZ (無法如願)
2014-02-24 22:29:00第一个问题...我没做过手机开发，以下回答有错请指正1.你确定你要在游戏中"即时"运算?地图去掉Z轴后也只是2D，地图固定的话，很多资讯都是可以在设计过程中预先算出来，以纯资料方式加载
楼主:
gmking (帝王之心)
2014-02-25 08:12:00sry没说清楚我们后来的方法导致误会，会先用矩阵存起来
3D的做法通常分两种 一种是打前后左右四个点ray cast出z以后可以算出四方向斜率 二的话则是拿这个mesh的三个点套公式也可以得到斜率（也可以额外参考相邻三角）两种做法其实各有好处 预算也可以，只是你要花点心思去存这些东西，索引时间不见得会比算的划算2d就简单了 直接拿附近八个像素的alpha channel就好
作者:
LayerZ (無法如願)
2014-02-26 15:26:00我没想到索引成本..那真的不一定比较划算@@
因为斜率可以用GPU在shader算 这一定是最快的 XD不过普通CPU来讲的话 大概就是多吃一块内存 快慢难讲这部分有个比较妙的解法 就是在算导航的时候一定会算导航格 再最后一步把路径拼接起来的时候算沿路的斜率这做法有很多意想不到的好处，以前前公司这样做过这样你就可以在每段导航路径顺便加入速度资讯重点是这样计算会快很多
作者:
y3k (激流を制するは静水)
2014-02-27 11:22:00我真的建议你们先用2D概念去做 不会浪费太多时间在这种细节上
推楼上，这句话是重点，也是基础我第一次写游戏时，前辈就是给这句前辈：“你先会走，再来跟我谈其他的”另外，你上面说依照不同地形决定移动速度，又说到高度你是想让角色爬山的变慢，还是走过泥泞地的时候变慢？如果你是鸟瞰视角的话，建议你直接做2D不少游戏程式都是以2D再写，但是看起来3D2D就不用算斜率，只要把“斜坡”本身当成一种地形就好