战斗的具体参数，其实已经不是程序考虑的了。 程序只需要考虑从数据表A取得数据，存入临时表B。然后当时间到了后（通过定时器实现），再从数据表C取得数据，通过公式计算，最后删除临时表B或者把临时表B存到另外一个地方备份。 数据是哪些？找策划要。有几个表？找策划要。战斗公式？找策划要。（某些所谓策划，连需要几个表都不清楚，还策划。。笑死人了。） 有地图、城市、建筑、士兵、战斗后，道具的出现就有必要了。 为什么呢？ 有了城市能做什么？产生资源，产生钱，产生兵。 有了士兵做什么？可以抢资源，抢钱。 资源和钱做什么？买道具。 买道具做什么？更好的抢资源和抢钱。 （同时，抢资源，抢钱的时候，资源会被消耗） 这是一个很简单的循环。就是绕成了一个圈，虽然这个圈很小。有部分策划想得非常好，就是绕不成圈，那样没任何意义。 首先，需要一个道具的基础表。 自动ID，道具类型，道具属性，说明。 在道具的处理上，可以在玩家表里增加更多字段，道具跟随玩家。 也可以单独建一个道具的详细表。用类似背包的方式实现。 背包的方式有两种，一是用数组存储，二是用横向表存储。都挺麻烦的。不过从道具流通和买卖上考虑。用背包的方式是值得的。 接下来的功能。 商店。拍卖行。基本上跟一般的网站应用很类似。只不过产品变为了游戏里的道具。货币是游戏币。

三、总结 上面的小例子，思路上是基本完善，没问题的。程序代码上只给了一小部分，能真正理解这一小部分。其他部分的程序应该不是问题。 webgame重要的还是数据流的绕成圈，以及可玩性。 上面的功能，真的做出来，是不够玩的。就是没什么可玩性，做出来都没意义。 但是，仅仅是做出来，仍然是一件困难的事情。 游戏里涉及的东西太多。即使是很简单的游戏，即使webgame看上去很简单，甚至实际也很简单；做出来，非常困难。 没有过开发webgame经验的人，来策划webgame或者说开发webgame。会觉得很简单。大功能其实就那么几个。思路上也容易绕成圈。 实际情况是，一个非常简单的功能，当它需要绕圈的时候；当它需要交互的时候。这个功能就不再简单，而是复杂，相当的复杂。 特别是你想制作一款有足够的可玩性，能面向市场的产品，即使是初期思路非常简单，功能也很单纯。但你实际策划的时候，实际编程的时候。大量的数据、数值需要你去处理，大量的交互需要你去处理。这时候，开始的简单，已经变得复杂了。虽然从程序的角度讲，技术含量不高。 优秀的策划是可以把数据表列出来，把数据走向清晰的列出来，放在你面前。这样的策划不多的。 大部分都是有个创意就自称策划了。只能说是把无知当无畏。

专业策划是可以和程序员在程序结构的基础上讨论功能的实现，这样出来的东西就算不够简单，至少也是清晰的，调试、修改都会很方便的。

学习了