WAP游戏是游戏大家庭中丑小鸭:近乎为0美工仅仅由些文号组成游戏界面却可以完成几乎所有大型游戏功能目前比较有名些WAP游戏比如QQ西游新浪江湖还有稀饭学院等当然这些都是些MMORPG为自己网站WebSite做个广告稀饭游戏比较有特色是业内公认从养成MMO甚至竞速这些游戏都是别网站WebSite所没有WAP游戏是没有客服端仅仅是通过网页页面上链接输入框等等进行游戏所以实际上所有逻辑运行都是在服务器端举个简单例子说:比如在地图上移动这动作首先地图所有数据都是保存在服务器上无论是还是DB而要表示当前玩家所在位置在哪也仅仅是把地名本地描述信息图片及NPC等有关信息生成个页面发送给客户端就这么简单而玩家要从本地移动到其它地点也仅仅需要点击个用POST或GET传递地点ID链接便可完成在方面当前能够接收到个合法地点ID时便将本ID更新到玩家记录中去并生成对应本地信息生成页面输出即可挺简单吧
详细我想应该从 3方面介绍些做WAP游戏所需要注意:安全效率延展安全性应该是个游戏产品所最需要注重试想个再有想法再好玩游戏如果不安全导致玩家利益时刻都有可能被盗或是整个游戏平衡性被几个受捣乱玩家通过漏洞弄得乱78糟这样游戏也不会受人欢迎我个人也在这些方面吃过些亏所以把它放在最前面安全性般看来没有黑客就没有这个问题对于用PHP这样服务器端来说安全性问题基本只来源于我们开发本身而黑客其实就是那些有意捣乱用户简单写些我所知道问题和解决办法:

用户输入:这是最基本也是最可能被忽视点‘1+(-10000)’这是什么？这就是‘黑客’最常用种思路方法它多出现在当你需要用户输入个数字时比如玩家可以把自己钱送给其他玩家逻辑很简单看看自己有没有这么多钱(($my_money>$give_money))有话给自己扣钱并给其他玩家加钱完成但你试试下面这段:
[php]
<?php
$a=\"1+(-111111)\";
$b=2;
($b>$a)
{echo\"xx\";}
?>
[/php]
结果如何？你很吃惊嘛？就这样你有BUG了还没完你再试下下面这条SQL:
\"updateuser_moneymoney=money-\".$a.\"WHEREuser_id=155\"
结果又如何你给两个人都加了钱谁都不亏(听说那个收钱是送钱人小号)你游戏和你亏了这样下去你游戏货币越来越不值钱游戏也变得不受欢迎
如何解决？过滤！用适当思路方法过滤让他输入是个真实安全数字是你真正你需要(有关数字过滤思路方法我先卖个关子后面还有和数字有关更危险可能你觉得更不可思议事)
类似问题还有用户在发言时输入了个<结果是你在输入这条发言时就会有相当部分显示不了这个页面你游戏也受到了怀疑

数字:过滤数字你首先想到是什么思路方法或？val？嗯对于“1+(-10000)”这样输入这个没有问题返回值是1这个数字是安全注意！这个数字是安全并不代表就都安全了你再试试下面这个
[php]
<?php
echoval(2200000000);
?>
[/php]
看到了嘛又吓跳吧这都是血教训啊2200000000这个数已经超过了INT取值范围(强行转化)相类似问题还有在MYSQL5中(目前我不知道能不能设置)如果把字段设成UNSIGNED那么0-1＝42XXXXXXXX
这里我提供两种解决办法:
1用abs换掉val经初步测试abs这个是可信它不会对数字造成什么不良影响
2使用高精度及相关如:
bcaddbccompctype_digi/*注意这些参数定得是串型！*/

微观操作:同样用送钱这个例子你过滤了用户输入用bccomp比较了用户要送和他所有成功可以送钱了别忙还有个你可能不太相信但又确实存在问题有句古话:我们不可能两次跨过同条河它说是时间是变化所以事物也是变化你有没有想如如果在你验证过了他是不是有这么多钱可送到你用UPDATE语句为他改钱这瞬间另个人把他钱取走了？不可能吧？可能非常可能至少在我做游戏这段时间这种问题不止次出现过要知道比秒小有毫秒比毫秒小有微秒比微秒小有皮秒....所以切都可能发生所以我个人般在PHP验证的后还会在UPDATE语句的中再做次验证即在WHERE语句中多加句　AND　MONEY＞$a这样个条件基本不会对SQL执行效率产生什么影响还能保证安全性加上是很有意义而语句是否执行成功才是能否给对方加钱真正条件相关还有点要介绍说明在做这样操作时定要把对玩家有损失操作放在前面执行类似给他加钱这样能让他HAPPY操作放在后面在没有引入事务数据库处理机制的前中止也是可能且可怕对于可能出现多人抢同资源问题也应该有很好先后判断这点不细说了但同样重要 [Page]

日志:这个东西很重要要知道如果出了问题找到是哪里出问题问题影响了多少人多少数据如何恢复就全靠它了日志般分两种种是游戏中需要用户比如救济品每人只能领次就是通过它来控制(其实是不应该算是日志范畴只提下)另种就是真正日志比如谁在什么时候给了谁多少钱他输入是什么数字操作前送出方有多少钱操作后又有多少如果有了这样日志记录我想对钱这类重要数据流向就很清晰了在没有正常运行很长时间经过时间考验的前这类日志数据是相当必要

总得来说游戏产品和其他类型产品相比对精确性要求更高所以每步执行都要求是精确且在出错时是可恢复另外记住:用户是绝不能相信！！！



效率
这点我觉得不用多说什么作为个开发人员执行效率是我们本职工作的
个人认为个执行效率很大程度取决于设计(针对某问题提出想法并用最合理、高效、低成本方式解决和实现它这是我对设计理解)所以在进行某系统开发的前定要先把遇到或可能遇到问题分析清楚想明白解决方案并准备好备用或是在出现问题时应急方案(这也是我们头对我们要求:)具体说基本就是对数据结构和逻辑分析可能话写出份策划案或是重点问题清单在实际开发时只要敲键盘就好了这样做也能很好提高开发效率而在执行效率上我不多说了前人有很多很好例子介绍说明我们可以学到我也就不显丑了(没这个自信)举个例子吧我个人最早是看到DZ论坛数据结构上这么用:统计个论坛下面有多少个主题可以在本论坛记录里增加个用于统计字段比如stat_threadnum,每次有人发贴删贴时更新这个字段这样虽然有了定冗余但就不用每次都COUNT去了这是个好办法别就不多说了

延展
其实这个问题就已经不完全是个开发人员工作能力上问题而是所谓‘职业操守’问题了除了不能相信用户还有类人是不能相信:策划(这并没有褒贬的意)为什么？作为个策划他职责就是求变所以他们总会想出新东西来这也就意味着你产品要不断进行修改再修改这是必然所以把写‘活’也是你必须学会(我个人认为面向对象其实就是为了解决这问题)举个例子见过段这样它作用是用玩家几种道具在定条件下换取另种道具实现方式是用SWITCH结果是当每次要添加新兑换思路方法(比如加入用两个梨换个苹果)那就要不断添加新CASE语句使得这功能足足用了好几百行来实现虽然可能换个来写可能(只是可能)效率上不如SWITCH但延展性就要好得多(文件也小)所以能够预测到策划下步可能会如何做也算是个好开发人员能力的(在下次改动的时让自己更轻松些不也是件好事嘛？) [Page]
有关注释和文档游戏逻辑相对要更复杂些所以足够且清楚注释是当其他同事接手你工作时你给它最好礼物:)当然如果你能把写清楚些命名得更准确些本身就是很好注释而文档作为注释扩展更是必要东西我把它们也算作在延展性的中了