大三Unity课设RTS小游戏demo，水平如何？

这个demo回避了太多的细节，实际上根本看不出什么名堂，也就只能骗骗外行罢了。像我们这些经验丰富的人一看就知道，至少在视频里没展现出任何技术难点。以我参与实战RTS项目的经验来说，有以下这些主要的麻烦之处是你都没有在其中体现的。首先是寻路方面的一个大坑。你使用了navmesh插件，所以肯定做不好寻路这块内容，所以你干脆就没做。因为navmesh插件首先不能针对不同的单位计算不同的阻挡情况（当然也不是完全做不到，只是这样做性价比太低了）。在星际争霸里，实际上同一张地图（对于我们地球人来说是同一张），对于tiny（极小）、small（小）、middle（中）、huge（大）这些不同大小的单位而言，就像是不同的地图。但要用navmesh去实现这个概念是非常麻烦的，而且效率也不高。所以你得自己去编写一个寻路相关的东西，但是你要是自己编写还使用navmesh那就是错误的概念。为什么这么说？因为navmesh本身也是astar算法，只是它帮你选定了连接关系。astar是dijkstra算法的一种特殊优化算法，其本质是在一系列有连接关系的事物之间计算出一个最短路径。AStar通常用于基于瓦片（tilebased）的情况，也就是自动根据单元格的坐标定义连接关系，而navmesh则是将相邻的三角面作为下一个节点（nextNode）来进行连接。发现关键之处了吗？实际上RTS游戏的地图逻辑都是二维的，就算像war3这种地图上有高低差的情况，也只是一个获取Z轴坐标（getZ()）的关系（也就是说我从很高的地方向下发射一条线，被阻挡物的Z值就是角色的Z值，也就是在unity里的Y值，这样就可以确定角色视觉上的落点，要注意这只是视觉上的，在逻辑上是二维的）。而阻挡关系，最终可以根据单位的大小计算出四张基于标准瓦片（tilebased）的二维数组——布尔类型的 _map。在RTS游戏中，由于单位通常是圆形的，地形可以转化为AABB（轴对齐包围盒）矩形，然后你需要做的是计算圆形与圆形、圆形与矩形之间的碰撞关系来实现寻路，这个算法都是数学算法，大三的学生肯定都能搞定。但是很明显在你的这个demo里并没有做这个，而是采取了逃避的做法，把建筑物都放在家里，然后中间的战场也是空荡荡的。毕竟使用的是navmesh插件这种第三方的东西，出了什么毛病可能谁都搞不清楚。说到寻路就有一个问题，比如像星际争霸等RTS游戏，在游戏里造房子是可以造在我方角色身上的，然后我方角色被造了房子就会离开这个地方，但是如果你要造房子的地方站着敌人，那就造不上去了。