在几个小时的作业后，我觉得bigbook2000提出的以面向对象的方法来策划AI开发是错误的，我走了弯路。
如下图，我做了一张各个对象的示图，就面向对象来说，希望还能混得过去。
在这张图中，绝大部分内容都是在我的策划文档中已有的，只不过区别在于，之前我是用清单而不是面向对象的示意图来表示。比如说，以前我的文档是这样的：
队员属性
名称
AP
生命值
……
或者说这其实就已经是面向对象了，只不过现在的图表把它变成更接近程序的架构而已。可是，这有什么意义呢？这应该是程序员的工作而不是策划的工作，他们做这件事可以做的更有效率而且更好。就移动来说，我用了方法：移动，下含四个子方法：通常，快速等等，以程序来说大概应该是叫方法的overloading，（半吊子的VB程序员，错了见谅），而真正的程序员可能会指出，用一个属性：移动方式，加一个方法：移动会更好。那我现在把它画成这样岂不是浪费自己的时间且误导，我只要用文档来说明一下队员可以有四种移动方式就可以了，我既不必也没有足够的能力去管具体的实现方式。
武器、装备、物品都是一样的。
bigbook2000说，我们并不需要去分析玩家怎么开始，遇到事件流程怎么分支，玩家的玩法怎么进行，并举出了星际和英雄无敌的地图编辑器作为例子，这肯定是正确的。但是，地图编辑器、玩家的行动等有一个最大的特点：它不是AI。地图编辑器根本没有AI，玩家行动只能触发AI。作为地图编辑器，很明显面向对象是完全必要且易用的，大部分时间我们都在“放置”一个个对象。而AI，你不给他一个过程，告诉他要先干什么后走哪一步的话，那是没法用的。
你提出的“战斗本身就不是一个过程，从程序代码的角度来讲，他是由各个事件触发而形成的”根本是错误的。那是在写应用程序，不是在写AI，这一点我看得很清楚，尽管很烂，好歹也写过几个VB应用程序，VB的特点就是“事件触发的”，在各个控件的事件中加入代码就可以形成VB程序的大体结构，和C++不同。玩家的操作对游戏来说，是事件；状态的改变，是事件，但AI的行动是过程。面向对象没办法表述AI的思考。AI思考本身是过程的，顺序的，渐进的。
或许Bigbook2000误解了我的第一张图，
在此图中，是以电脑方的视角来描述的，因此所有的“己方”，从游戏者的角度来看就是“敌人”，而所有的“敌人”，就是指游戏者的队员。你是否把它当成是描述游戏者行为的图表了？——描述游戏者行为完全没有必要，他们不必按照任何流程来行动。从这个意义上来说，用户界面也就是游戏者实际操控的界面其实很接近一个应用程序，用户的行为是不可预知的，必须以事件驱动的方式来写用户界面。地图编辑器是UI-User Interface-用户界面，而我要表达的是AI-Artifical Intelligence-人工智能。
不使用流程图，要怎样才能表现AI？我想只有两种方法。第一，就是编上序号的文档。比如说：
（注意这里还是以AI的视角来写的，参见上文）
0、回合开始
1、找到离敌人最近的队员
2、命令该队员向其攻击
在序号更多、流程更复杂了以后，就不得不用跳转，比如说，如果xxx成立，那么转到第y步。找起错误和漏洞不如流程表容易。有点像早期的basic程序，带行号的那种。跳转就是goto语句，而goto因为最擅长把人弄晕不是快要被VB摒弃了么。
第二种，面向对象，更加程序化的写法，很难想象要怎么清楚表述AI。比如：
如果 队员.队员A.视野矩阵 含有 敌人1，那么
队员A.攻击(目标=敌人1)
倒，我是在写伪代码喔
从策划的角度来说，我宁可写文档来描述。而AI大概是现在的策划案中唯一还需要流程图的。其他的要么用表格，要么干脆已经被策划和程序抛弃。哦，漏了一个，科技树的话也是图更直观好用。
Armstd在楼上提到，“沒有推演模擬過，說實在的我也不知道總共會需要設計多少模組（物件、事件判斷）功能，然後進行分類取用。”我觉得我也深有体会。在设计和模拟中才逐渐知道需要哪些东西，考虑哪些状态和事件。试着画了一下流程表就发现可以直观地添加节点，联系和分支，只要拖来拖去就可以了。
