论任务逻辑宜放在服务器端的缘故

论任务逻辑宜放在服务器端的原因
  原来有一个同事，现在在顽石工作，负责维护《二战风云》。昨天我问他关于网游任务系统的实现时，他说，《二战风云》的任务系统完全是在服务器端实现的。原因没有细说，大概是便于更新之类。当然，二战最开始是个网页游戏，跟手机网游的情况不太一样，不能一概而论。晚上睡不着觉，我又想了想这个问题，得到的结论是：任务静态数据（例如文本描述信息），适合放在客户端；任务逻辑适合放在服务器。 


  昨天开会讨论服务器和客户端做任务系统的优缺点，从大家的发言里我总结了以下几点：
  1.客户端做任务逻辑，运行比较快；网络端做的话，人数多的时候性能压力大。
  2.客户端做的话，涉及的网络通信量比较小，耗流量少，用户体验好。
  3.对于上线后新增、修改任务的情况，网络端做更自由；客户端做，采用更新任务数据包的方式，也可以接受。
  4.网络端安全性比较高，但是这点我们不用太考虑。


  一句话，目标是，在满足日后修改要求的前提下，选一种易实现的方式，尽可能减少流量损耗，加快运行速度，提升用户体验。


  哪种方式流量消耗少？
  客户端做任务逻辑是否网络通信量少。我认为不是，因为，网络端做逻辑判断时也是不需要与客户端通信的，只需要在任务完成后的一个恰当时机，假推送“任务完成了”这个消息给客户端。客户端做的话，还要有新增修改任务逻辑时更新任务数据所耗费的流量。至于任务描述文本、任务奖励这些比较静态的数据，倒是适合放在客户端，确实省流量。可能开会讨论时大家说的省流量，指的是这一点。另外并不是所有的数据在客户端都是有效的，甚至有些数据不存在于客户端里。客户端在判断任务逻辑时，不论任务是否完成，都需要联网取得或验证这些数据。


  哪种方式运行速度快？
  客户端做任务逻辑判断，其实要消耗客户端的机器资源，但是客户只有一个，客户机又很快，逻辑判断的运算量也小，这个可以不考虑。主要的问题是服务器端做任务逻辑，会不会导致服务器端性能压力大，响应不及时。我认为不会。原因是服务器端一般只需要在客户端做出某些操作时（或者心跳时）进行这个判断，并不是时时判断的。同时，大量的网页策略游戏证明，至少服务器端判断带来的性能压力，是有成熟解决方案的。


  哪种方式用户体验好？
  省流量，给用户省钱，不容易被破解，不容易出外挂，很少需要更新数据包，更容易有网页版，速度上还相差无几。综上，我认为静态数据客户端存，逻辑判断服务器做这种方式，用户体验更好。
  
  两种思路：
  1.服务器只用作数据交互
  2.客户端只用作播放器
  这两种思路在实现上都可以说是具有指导意义的高度概括模型。但是我认为，在更新方便和安全性这两点上面，模型1无论怎么努力，也打不到模型2能做到的程度。