|
AI_Tank（不久将会正式改名）是我们正在编写的一个结合人工智能的游戏平台。 该游戏平台以坦克作战为主要内容，希望能构建内容丰富的场景；既支持玩家单人通关的游戏模式，也将支持联机游戏模式；更具特色的一点是，可以编写AI类控制游戏中的坦克，与敌方的坦克周旋，完成一个个有挑战性的任务；同时支持团队作战模式，在这个模式下，玩家或是由玩家编写的AI都将不会是一个人在战斗！ 这个平台还支持外加程序集对游戏规则和新坦克、新场景物体的扩展，只要有好的坦克游戏玩法，都能在平台上实现。 目前在编写AI_Tank的2.0版本。在美工和程序方面均不同程度地缺少创作人员。所以在此宣传一下，希望有看到的朋友能够成为编写组中的一员。 受目前的任务重心的限制，预计在3.0版本中才会采用3D的游戏视图，而当前游戏采用2D顶视图。如果您热衷于游戏中贴图的绘制，并想找一个地方实践自己的美术才华。我们非常欢迎您的加入。 而如果您热衷于游戏的代码实现。您可能会对该游戏的各个部分的实现方法感兴趣，可参见接下来的帖子《对平台中各个已知问题的说明》。如果您认为技术难度符合您的胃口，我们也非常欢迎您的加入。 联系qq：298210841 qq交流群：21597580 诚挚地欢迎您的到来。 [此贴子已经被作者于2007-9-29 11:43:37编辑过]
|
对平台中各个已知问题的说明：
现在将当今能够预见到的在整个平台的编写中需要解决的问题（包括已有解决思路的问题和仍无解决思路的问题）列举如下：
(1) 界面和游戏画面的组织结构问题：
现有的思路是模仿RacingGame的解决办法：界面和游戏画面都继承IScreen接口。然后在主入口中用堆栈来处理不同Screen之间的跳转。
(2) 物理更新和碰撞检测的关系问题：
现有的解决思路的过程如下（每帧）：
按照物理更新方法计算出新状态。
检查全体新状态集中是否有碰撞。
如果没有{生效新状态；返回。}
如果存在碰撞
{
获得所有碰撞物体的列表。 (a)
对每一个列表中的物体调用碰撞处理代码。
<接下来有三种选择>
<其一>
按照物理更新算法计算出列表中所有物体的新状态。
检查这些物体与其他物体是否存在碰撞。
如果没有{生效新状态；返回。}
如果存在碰撞
{
重复(a)(b)之间的迭代过程。
} (b)
<这样做的弱点之一在于当碰撞处理的方法不恰当时，算法存在无限循环的危险。>
<其一结束>
<其二>
检查列表中的物体的原状态是否与列表外物体的新状态是否存在碰撞。 (c)
如果没有{返回}
如果有
{
将列表外发生碰撞的物体添加到列表中。
重复(c)(d）之间的迭代过程。
} (d)
<其二结束>
<结果是此帧中只是调用了已碰撞物体的碰撞处理代码，而并没有更新物体的物理位置。损失了时间。如果碰撞处理不恰当时，会造成两物体的死锁。>
<其三>
<混合以上两种处理方式，对方法一中的过程只进行有限次的迭代。但迭代深度到达一定深度时，不再迭代，改用方法二的处理方式。>
}
返回。
(3) 坦克可见区域的计算方法：
坦克的可见区域与雷达的深度、张角、方向以及场景中的遮挡体有关。
计算出的可见域需要应用于两个方面：
绘制坦克的可见域；
在逻辑上判断一个物体是否在可见域中，将结果传给坦克的AI。
名词定义：
雷达区域：雷达的扇形区域，有雷达的深度、张角和方向确定。
遮挡物：能遮挡坦克视线的物体。
可能的方法：
（1）类似渲染管道线的深度缓冲算法的算法：
第一步：得到所有与雷达区域可能相交的遮挡物（主要为了效率）
第二步：以雷达区域的圆边为t轴，点到雷达区域圆心的距离为n轴，建立坐标系，以t轴建立深度缓冲区（单位间隔为像素级）。
第三步：计算世界坐标系到雷达坐标系的转换。
第四步：遍历每个遮挡物的边界
{
计算其在圆边上的投影坐标。
检查该坐标处的深度值。如果该边界点的深度小于当前坐标处的深度值，则覆盖到缓冲区中。
}
最终的缓冲区数据便能描述可见域的边界。
（2）扫描线算法：
前三步与算法一相同。
第四步：从雷达扇形区域的一边开始作指向圆边的辐向线段，线段逆时针转动，对整个雷达区域进行扫描。
若有物体与该线段相交，则将交点中离圆心最近点存储起来，最终得到可见域的边界。
以上两种方法得到可见域边界之后，判断物体是否在可见域中只需要进行坐标的转换，并比较深度即可。
而绘制上的可能方法：
遍历雷达坐标系中在可见域中的点，将其转换到世界坐标系中。新建一个贴图，将相应位置的颜色值填入贴图中。然后可以在屏幕上绘制该贴图。
这个方法的弱点在于：雷达坐标系中靠近圆心处的点转换到世界坐标系后会产生重叠。
可能的改进方法：将雷达贴图的一部分事先绘制好。得到可见域之后按原方法补充靠近圆周那一面的像素。
(4) 场景物体管理：
场景物体管理类只负责储存场景物体，而不执行任何改变物体状态的方法或绘制方法。
原定计划游戏画面将分为六个层：
背景层(以前称为底层）: 游戏中最下层的背景图。通常是一些纹理图案，在城市场景中是一些道路等的贴图。
这样就需要背景图支持两种绘制方式：随机贴片绘制和整图绘制。
沟壑层：坦克无法越过，但坦克视线和炮弹可以通过的区域。如河流，湖泊，坑洞等。
突出层：一些坦克和炮弹以及坦克视线在逻辑上无法越过的区域，如建筑，树木等。坦克本身可能也在该层中绘制。
特效层：爆炸，烟雾等特效。也可用于云彩，飞鸟等生动性元素。
（以前称为遮掩层）：用于地图未探索区域的覆盖。并不一定所有的游戏规则中都需要它。
文字层：用来显示坦克发出的信息。
可能更好的另一种结构方式：
背景层、特效层、迷雾层以及文字层与游戏逻辑无关，可以分离考虑。
而所有与游戏逻辑有关的物体进行集中储存。定义以下几个物体类型接口（更好的实现方法是使用C#的自定义属性）：
地面阻挡物：阻挡坦克而不阻挡炮弹等飞行物体。比如战场障碍物，矮墙等。
高阻挡物： 阻挡坦克以及炮弹等飞行物体。比如山脉，高楼等。
遮挡物： 遮挡坦克视线的物体。
管理器中的每一个物体都要有LayerDepth属性。以确定绘制层次。
另外：
特效层中的特效物体虽然与游戏逻辑无关，但也需要每帧更新，属于场景物体的范畴。也可在场景管理器中管理。
背景层中没有场景物体的概念，需要与场景物体管理类分离，单独管理。
迷雾层在绘制上需要获得当前坦克的历史信息。机制与场景物体管理并不相干。单独形成一个组件应该更好。
绘制文字的功能在游戏引擎中已经提供了。所以基本上没有必要对文字层进行构建。
(5) 迷雾层的绘制：
游戏画面绘制类在场景物体绘制时，需要依据场景物体是否在迷雾区，来确定是否绘制。
同时游戏画面绘制类也需要根据迷雾类的数据绘制场景迷雾。
是否绘制玩家的场景迷雾对规则类又是可选项。
迷雾数据依附于确定的坦克，同时需要每帧的更新。
考虑到迷雾数据还需要传递给坦克的AI类，所以所有的坦克的迷雾数据都需要计算。
迷雾计算方法的关键在于每帧(或者每几帧)将坦克的可见域应用到迷雾数据中。
为了提高效率，我们一方面可以栅格化场景。
另一方面需要将可见域的计算过程对此进行优化。直接从可见域计算中间过程中获得迷雾更新的输入数据。
(6) 坦克类的构成和控制问题：
有三个类对坦克的实现产生作用：
坦克皮肤类：定义坦克的外表。
坦克状态管理类（可能还需要进一步细分）：定义坦克的各方面参数和更新方法，并提供坦克的控制接口。
坦克控制类：包括AI控制类和玩家输入控制类。通过使用状态管理类提供的控制接口来操作坦克。
由平台外的程序集定义。
而坦克本身，作为一个场景物体。在被场景管理类包含后。逻辑上的任何更新以及事件都应由坦克自身来完成。
设想的处理方式是这样的：
一个坦克类包含一个坦克皮肤类的实例，一个坦克状态管理类的实例，一个坦克控制类的实例。
其中坦克控制类的实例在坦克类的初始化过程中或由外部程序集动态注入或由内部的控制类直接创建。
(7) 坦克状态管理类需要提供的接口：
状态管理类需要提供的接口也就是坦克AI控制类需要获得的控制内容。一般包括以下几个方面：
获取坦克当前状态。
获取坦克已经探索过的区域信息。与迷雾类有一定的相关性。
获取可见域中的敌方信息。
获取队友列表。（团队模式）
通过命令接口来改变坦克的状态。
给队友发送消息。（团队模式）
设想中，平台需要对外部提供对坦克的扩展性。而不同坦克的状态变量和更新方式不同，命令接口也不同。
这就需要一个可行的办法来管理这些差异性了。
(8) 规则类：
主要通过对碰撞通知的处理来决定游戏内容的变化。一个规则的实现往往依赖于特定的坦克类的定义。
所以这些内容都留给平台外的规则组件来完成。
(9) 地图文件的存储：
需要存储的类全部添加SerializableAttribute属性。由地图管理类管理。