我对于游戏开发，其实是有过实践经验的。13-14年间，在12m的时候，我就是12m的游戏开发主程（虽然当时后台只有2个人，而且我还是处于完全没有游戏开发经验没人指导的愣逼状态 囧），当时服务器的代码，是基于一个非常简陋的netty框架搭起来的，从登录到所有游戏逻辑，几乎都是从0开始自己写。之前也没有写游戏服务器的经验，项目中可参考的内容也基本没有，当时对于架构认识也有限，历经半年多，磕磕碰碰，也总算是把后台逻辑写得差不多了，成功上线。从登录到游戏到比赛到活动，一个简单页游所需要的东西基本也都有了。游戏当时也没有做成功，推广不得力再加之股东纠纷。当时所遇到的一个比较严重的问题是服务器承载的问题，因为游戏模式是模拟足球比赛，一场比赛持续5分钟会涉及到7200帧的计算，再加上数据库读写，资源损耗较多。模糊记得，当时努力做各种优化过后，手写机器人简单测试中，8G的服务器，三四百人同时开始打比赛就会有严重卡顿。当时也竭尽全力想各种办法，提高比赛帧的计算效率，优化数据库表设计、连接以及读写，可最终效果都有限。
从6月1号到新公司这边来，一直在研读手头的游戏代码，也做完了3个新需求。弄清楚手头的棋牌游戏逻辑后，不经感叹以前设计游戏时的经验浅薄。在通读了现在游戏代码后，回想以前设计的足球游戏代码，发现在如下几点上存在严重缺陷。
1.当时设计的游戏逻辑和数据库读写没有分离，导致的结果是数据库在机器性能吃紧造成读写延迟高时会把延迟反馈到游戏中，导致严重的游戏卡顿。如果要做优化，应该让游戏逻辑仅依赖于内存数据，需要写入数据库的内容由独立线程单独处理。这个设计缺陷应该是当时代码中最大的问题，因为这个缺陷存在，会同时影响到游戏帧计算速度，游戏帧计算速度过慢又会连锁带来线程释放慢而导致需要的线程过多的问题。
2.对于异步数据以及资源共享访问的设计考虑不完善。现在还记得，当时多用户抢桌子时因为资源竞争带来的诸多奇奇怪怪的bug，当时也尝试各种办法甚至于添加各种补救逻辑，但是最终对于资源抢夺的逻辑解决的也不是很好。反观公司的代码，一个ConcurrentHashMap和synchronized就解决了所有问题。当然，以前代码的那块需求比公司现在的更为复杂，但是究其最终没有很好解决的原因，还是对于synchronized理解不到位的。
3.没有扩服设计。即便服务器性能差，如果有扩服设计，也是可以通过增值硬件采用空间换资源策略来解决的。但是以前压根儿没想过这一点。通读代码下来，其实做简单的扩服设计也是很容易的，而且现在回想当时拿到的的netty封装代码，其实已经有对扩服的支持。扩服时，需要考虑的一个问题就是数据同步的问题。当前棋牌的设计，是以桌子为单位分配服务器，所以避开了数据共享的问题。如果真要面对数据共享的问题，有几个可以考虑的方案是，数据库、memcached或redis。其中redis应该是主流，memcached应该是简易版。
4.部署容器的选择。这一点没有验证，但是感觉应该也是以前的一大失误。应该用jetty而非tomcat的。jetty对于大量请求以及时间比较长的连接支持有优化，对于契合情景下的性能能有一定程度提升。
主要就是上面4点设计缺陷吧。如果还要说有什么其他问题，可能就是我动手前没有完全吃透需求，没有把逻辑内容进行很好抽象后再动手的毛病。这个毛病会因为总有遗漏而老导致代码变动从而导致代码质量下降。
上面这一些都是问题。其实通读下来，游戏开发和所谓的优秀的设计并没有想象中那么难。你所需要做的，就是更扎实的基础理解以及更多的耐心。
网友评论