在一个机会下，玩了个Capcom的动作游戏，「MAXIMO vs Army of ZIN」，玩过后，从中体会了一个，制作动作游戏的窍门，虽然是自己想出来的，但理解上应该差别不大的了。曾经说过我会写篇文章和大家分享一下的，就现在写出来吧。
动作游戏有一个很关键的要素，就是「速度」。游戏进行时的速度及反应等都要很快，才会是个好的动作游戏，但是在电脑游戏上，速度是很难控制得好的，因为这个牵涉很多场景分割技术，例如：BSP Tree、Quadtree、Octree......等等。
以上几种技术的教学文章，在网上已随处可见，所以我也不会在这里说了，况且我对这也不太熟识。但我想说另一个简单点的，就是「Portal引擎」。Portal引擎有篇很好的教学讲解，所以亦不在此详谈。我想说说的，是如何配合Portal引擎来设计出动作游戏的场景，加快制作上的效率。
上图是个简单的场景，当中共有8个不同大小的分割区(A~H)，经Portal引擎计算后，图像引擎只会画出E、D、F、C及H，其他的都不会画出，这个Portal引擎才算是成功。好了，那么我想说的是甚么呢？因为如MAXIMO这类场景颇大的动作游戏，一次过做计算及画出大多数Polygons是有点太慢了，所以MAXIMO中的场景地图多数会是下面模式设计：
地图中的「Stage1-A」、「Stage1-B」及「Stage1-C」是大型分区，大家可以用BSPTree、Quadtree等的场景分割作计算，「(I)」和「(II)」小区可以简单地处理便可，而当中灰色的线就是代表Portal的位置。就这样，一个Stage的场景便规划好了，但要怎样去处理呢？很简单的，只要用ViewFrustum计算便可以了。
假设Camera的位置在Stage1-A，理论上怎样转动，也看不到在(I)中连接Stage1-B的Portal，若果Camera的位置在Stage1-B，也不会看到在(II)中连接Stage1-C的Portal，那么便好办了。我跟据以上的论点，那我的方法就是，当Camera位置在Stage1-A时，我跟本不用理会Stage1-B及Stage1-C，除非Camera位置在(I)或(II)中。在Stage1-A中，当然要画出Stage1-A了(而当中作了分割计算)，另外只要检查有否看到Stage1-A连接(I)的Portal，如果有便画出(I)便可。
另外，若Camera位置在(I)或(II)内，只要ViewFrustum计算看到了那一边的Portal，便代表了看到那个Stage1的分区，这样的设定可说是非常简单。而这个方法有一个要诀，就是像(I)及(II)这两个分区，必需是室内场景(或只看到天空的场景)，而且在设计上亦应尽量迁就，Camera是不会同时看到两个Portal面((I)及(II))。而在Stage1-A~1-C的设计上，便可以用尽3D显示卡的能力，例如场景可以大一点，或用上多点Polygon数量等等，但始终亦要顾及GamePlay时的速度啊。
其后，我在玩其他动作游戏时，亦发现很多游戏也用上这个方案的，例如SEGA的Shinobi系列、兽王记、Konami的Zone of the Enders系列......等等。看来日本游戏厂商，亦颇为喜欢用这个简单方法制作动作游戏，似乎证明了这方法是很简单及速度高，很适合动作游戏使用。
这方法若加入BSP Tree、Quadtree、Octree等的场景分割及剔除计算，便成为一个可以处理大型场景的方案，而且亦可以再加入更强增速功能，如LOD(Level of Detail)等，令这个方案更为强大。
上面所用的例子，图中的各个分区以方型作表示，只是易于绘画，在设计上是可以用不同形状的，这个只是视乎需要决定而已。