在与一位同事一起开发游戏后台的过程中,慢慢了解到他的编程思想,来自于代码大全的防范式编程,简单的一个思路对整个系统的后期的扩建,与重改的意义是重大的。其一来自了,事先能预想到的bug和可能会出现的扩展性问题。
对于一个有经验的人来说,这就是区别,而“会编程”已成为最普通的东西,最重要的是会系统的编程。一样的一个功能模块,低耦合高扩展性的模块是健壮的。就以我最近完成的一个反沉迷系统来说,
具体的一个规则是这样的:
2.防沉迷惩罚规则
累计在线时长 |
信息提示 |
提示频率 |
健康类型 |
惩罚 |
1小时 |
您累计在线时间已满1小时 |
1次 |
健康游戏时间 |
|
2小时 |
您累计在线时间已满2小时 |
1次 |
| |
3小时 |
您累计在线时间已满3小时,请您下线休息,做适当身体活动。 |
1次 |
| |
大于3小时 小于5小时 |
您已进入疲劳游戏时间,收益将降为正常值的50%。为了您的健康,请尽快下线休息,做适当身体活动。 |
1次/30分钟 |
疲劳游戏时间 |
游戏收益减半 |
5小时 |
您已进入不健康游戏时间,游戏收益已降为0。为了您的健康,请您立即下线休息,直到您的累计下线时间满5小时后,才能恢复正常收益。 |
1次/15分钟 |
不健康游戏时间 |
0收益 |
而其中的惩罚行为又细分为各个功能点:
3.防沉迷影响收益的行为类型
游戏行为 |
疲劳游戏时间 |
不健康游戏时间 |
公司巡视 |
商魂收益减半 |
不能进行巡视(0收益) |
员工培训 |
培训经验减半 |
不能进行培训(0经验) |
装备加工 |
|
不能进行加工 |
建筑升级 |
|
不能进行升级 |
战略升级 |
|
不能进行升级 |
关卡订单/商魂 |
收益减半 |
不能进行生产(0收益) |
关卡战斗 |
|
不能进行战斗 |
物品买卖 |
卖出收益减半 |
只能买,不能卖(卖出0收益) |
装备降级 |
降级收益减半 |
不能降级(降级0收益) |
互相公关 |
收益减半 |
不能互相公关(公关0收益) |
原料买卖 |
卖出收益减半/金币购买减半 |
不能进行买卖(卖出0收益) |
商会原料收获 |
收益减半 |
不能收获(0收益) |
异商盟PVP |
声望减半 |
不能PK(0产出) |
同商盟PVP |
|
不能PK |
声望津贴 |
津贴减半 |
不能领取(0收益) |
原料基金占有和收获 |
疲劳时间内的收益计算减半 |
不健康时间内的收益计算为0,不能占有 |
任务奖励 |
收入减半 |
不能完成任务(0收益) |
商魂兑换声望/投资声望 |
减半 |
不能进行兑换和投资 |
员工招聘/激发 |
|
不能进行 |
装备转嫁 |
提升星级减半 |
不能转嫁 |
装备研制 |
|
不能研制 |
子公司提成 |
提成减半 |
0收益 |
对于如此复杂的功能需要来说,一般一个系统是需要进行一个大的修改的。
所幸的是,系统前期的抽象做得很好,在消费这块已经全部抽离到一个总的入口点,结果不到2天就把功能做完了。
接下来是进行一个测试,我们使用了junit 进行了简单的测试。。。