游戏服务端设计总结

2014-12-12

  这大半年主要做游戏服务端开发,并没有如我我想做客户端开发。只是,到岗位后才发现,所谓的客户端开发的动作,并不是去研究渲染、动画、物理引擎等基础的东西,这些大多已经由引擎提供了,客户端日常开发工作大部分是游戏界面、服务器通信相关的。我想要做的工作岗位,做那种更加基础的工作,属于算法岗位或者R&D岗位,一般人很难达到要求。
  我做了游戏gateway、登录服务器、好友服务器、数据库中间件,还做了一些游戏服务端和客户端的开发工作。我们3D项目使用Unity 3D,开发语言也选择了C#。我觉得这个选择是在太好了,幸好没有选择JavaScript和那什么Boo。动态语言,即使是强类型,想用于大项目中,也是难以避免增加协作的难度。
  开发验证码业务的时候,意识到OpenResty这样的项目是多么的有意义,根本不需要单独起一个小服务,直接用内置在ningix中的Lua就能够搞定。系统中组件越少,就越能让人感到放心。同时,也深深的理解了“用户是邪恶的”。游戏开发中,一些功能就是为了防止cracker(不是hacker)搞破坏。让人无语 !
  重构好友服务器与登录服务器的过程中,我这才深深的认识到了NoSQL的好处。虽然在毕业前后也用过研究过CouchDB,但是绝没有这段时间认识深刻。意识到一个问题,已有的工具或许能够解决我们面临的很多问题,比如可以用OpenResty代替nginx+应用服务器,用Redis作为消息队列,nodejs作为数据库中间层等。验证码服务也可以利用OpenResty + Redis来完成(Redis的过期时间简直太好用了)。如果让自己编码实现或者基于lib实现,难度和工作量都会增加不少。
  原来没有思考过游戏中一些基础功能的实现原理,现在多少有了一些了解。比如说初高中时玩游戏,组内可以直接对话,但是全服发言就需要收费了,原来是因为真的比较耗费资源。比如好友关系的数据量就远超预想,不能直接用关系数据库来存储。学习了C#语言,的确,它的部分语言特性的确有Java更先进。经过这两年的实际工作,明白了一个事实:对于大部分项目,不同的编程语言的特性对于日常开发工作来讲,并不能带来可观的收益,可有可无的东西。
  我们的游戏数据库中间层是用nodejs实现的。游戏服务器一般都是这样处理的。因为随着游戏开服越来越多,数据量越来越大,需要分表分库,还需读写分离,但是把这些东西丢给游戏服务器来做,肯定是不合适的。所以需要一个中间层来做缓冲。我第一次意识到还可以这样解决问题。但经过两个月的nodejs编程后,我便不看好nodejs技术。和很多其他的技术工具同样,它很好,但并没有那么好,别人没说(不想说)、你没有看到的缺点将来可能会让你在坑里痛苦不堪。对于技术方案的选择,不能菲薄新事物,也不能冒进。需要做的,是对新技术做完整充分的调查。
  公司的3D项目延期好久了,前段时间都让几个美术同事放假休息了。也不知道游戏是否能够真正上线。我真是有点担心啊。这段时间我开始给游戏接SDK。因为我们主要以Web方式(Flash)发布游戏,需要4399、17173、4399这样的平台给我们做广告和导流,想赶紧上线验证一下,看看反响如何。如果反响还可以,就发布效果更好的客户端版本。我离开公司的之前,大家都上线去测试了。用户数还行。离开后,据美术朋友说,又修改了功能,最后再试试。希望游戏能活下去吧。

 

  

如果有任何意见,欢迎留言讨论。


[ 主页 ]
COMMENTS
POST A COMMENT

(optional)



(optional)