zoukankan      html  css  js  c++  java
  • Erlang游戏服设计总结

    这主要是一年多来,个人从事Erlang游戏服开发中对一些事情的思考。

    想到哪说到哪,没有条理可言。

    欢迎讨论。

    通常Erlang游戏服务的设计涉及到的东东包括如下:

    • 任务系统
    • 活动系统
    • 公会系统
    • 玩法系统
    • 好友系统
    • 聊天系统
    • 商城
    • 转盘
    • 以及其他

    我经历过的项目不多,只有2个。在这2个项目中我看到系统建模都采用如下一锅端的方式:

    • 即玩家进程加载了所有玩家数据,处理所有可能的系统;
    • 整个游戏服通常只有玩家进程、公会进程、玩法进程以及一些公共进程。
    • 整个游戏服里你看到的都是进程,看不到应用。
    • 通常玩法进程很少,很多逻辑上有区别的玩法都简单粗暴塞进一个玩法进程

    我很好奇,Erlang游戏服都这么做吗?在我看来,这一切都是乱糟糟的,不是说Erlang/OTP系统是以应用作为构建块的吗?

    为什么我看不到任务应用,活动应用,公会应用、玩法应用、好友应用等等?以应用去划分系统不是更加清晰?也许还能按需加载

    数据,而不是加载整个玩家数据呢?以应用建模,兴许能够更加容易复用代码呢?

    再者所有东西糅杂在一起,系统的测试基本变得不可能;没有测试也就意味着bug.

    尤其常见的是玩法进程夹杂了多种玩法逻辑,通过case if pattern match 去调用不同的代码。

    通常搞好了一种玩法,也不经意导致其他玩法出现bug。(我在2个项目中都碰到了这个问题)。

    我希望的游戏服设计应该是这样的:

    • 系统以应用做为构建块,你会有任务应用、好友应用、商城应用、公会应用等等
    • 以应用划分,玩家进程无需加载所有数据,需要的数据在相关的应用解决,甚至于对非热点数据,相关应用可能加载处理完就释放内存了。
    • 以应用做划分,系统升级可以以应用为单位,热更更方便。虽然通常数据结构升级都是重启解决的,但如果能在线热更就更好了。
    • 应用可单独测试,无需依赖其他东东。
    • 不同的玩法以不同的进程构建,一种玩法搞好了,你无需再去理它。

    也许以应用去建模,为任务构建进程显得过于大材小用。甚至于说在玩家进程里处理数据更加方便,避免不必要的进程间通信消耗。

    那么我想建模成库应用也是有好处的吧。

  • 相关阅读:
    0309. Best Time to Buy and Sell Stock with Cooldown (M)
    0621. Task Scheduler (M)
    0106. Construct Binary Tree from Inorder and Postorder Traversal (M)
    0258. Add Digits (E)
    0154. Find Minimum in Rotated Sorted Array II (H)
    0797. All Paths From Source to Target (M)
    0260. Single Number III (M)
    0072. Edit Distance (H)
    0103. Binary Tree Zigzag Level Order Traversal (M)
    0312. Burst Balloons (H)
  • 原文地址:https://www.cnblogs.com/rubyist/p/5530575.html
Copyright © 2011-2022 走看看