第一种流程。
点出兵。这时候，兵的参数，出发时间，到达时间，都记录进战斗临时表。
定时器中，处理战斗的部分，判断时间是否到开打的时候。到开打的时间了，则取得被攻击方的兵的参数。然后通过几个公式计算结果。处理结果，比如谁的兵挂了多少，战场掉落了多少钱，城市被谁抢到了。一大堆判断以及updata。（这里的定时器处理和获得资源的定时器处理是很类似的。）
最后把结果分别发给双方。（又涉及到一个短信息系统。）
第二种流程。
点攻击。马上就处理数据。打打npc好做。玩家之间对战，也可以把被攻击的玩家当成npc来处理。
两个人或两人以上即时战斗。需要用到ajax了。目前在技术上和理论上是没问题的，还没实际写代码，所以不好讲。
现在，技术上已经确定可以很好的实现了。
很简单的公式，两种战斗都可以用到：
intval(sqrt($User_B_AP)-sqrt($User_A_DP));
根号下攻击-根号下防御=伤害。
具体写的时候，公式肯定会复杂不少，不过这头痛的事，还是交给策划去做吧。
战斗的具体参数，其实已经不是程序考虑的了。
程序只需要考虑从数据表A取得数据，存入临时表B。然后当时间到了后（通过定时器实现），再从数据表C取得数据，通过公式计算，最后删除临时表B或者把临时表B存到另外一个地方备份。
这里的思路其实就是定时器类。
数据是哪些？找策划要。有几个表？找策划要。战斗公式？找策划要。
有地图、城市、建筑、士兵、战斗后，道具的出现就有必要了。
为什么呢？
有了城市能做什么？产生资源，产生钱，产生兵。
有了士兵做什么？可以抢资源，抢钱。
资源和钱做什么？买道具。
买道具做什么？更好的抢资源和抢钱。
（同时，抢资源，抢钱的时候，资源会被消耗）
这是一个很简单的循环。就是绕成了一个圈，虽然这个圈很小。有部分策划想得非常好，就是绕不成圈，那样没任何意义。
首先，需要一个道具的基础表。自动ID，道具类型，道具属性，说明。在道具的处理上，可以在玩家表里增加更多字段，道具跟随玩家。也可以单独建一个道具的详细表。用类似背包的方式实现。
背包的方式有两种，一是用数组存储，二是用横向表存储。都挺麻烦的。不过从道具流通和买卖上考虑。用背包的方式是值得的。接下来的功能。
商店。拍卖行。基本上跟一般的网站应用很类似。只不过产品变为了游戏里的道具。货币是游戏币。
三、总结
上面的小例子，思路上是基本完善，没问题的。程序代码上只给了一小部分，能真正理解这一小部分。其他部分的程序应该不是问题。
