这是我们的MMORPG手机游戏的正确架构吗?

时间:2011-10-05 06:53:08

标签: mobile architecture client-server

这些天我正试图为我的公司设计一个新的MMORPG手机游戏的架构。此游戏类似于Mafia Wars,iMobsters或RISK。基本的想法是准备一支军队来对抗你的对手(在线用户)。

虽然我以前曾在多个移动应用程序上工作,但这对我来说是新鲜事。经过大量的努力,我想出了一个在高级流程图的帮助下进行说明的架构:

High-level flow

我们决定使用客户端 - 服务器模型。服务器上将有一个集中的数据库。每个客户端都有自己的本地数据库,它将与服务器保持同步。该数据库充当用于存储不经常改变的事物的高速缓存,例如,地图,产品,库存等。

有了这个模型,我不知道如何解决以下问题:

  • 同步服务器和客户端数据库的最佳方法是什么?
  • 在将事件更新到服务器之前,事件是否应保存到本地数据库?如果应用程序在将更改保存到集中式数据库之前由于某种原因而终止该怎么办?
  • 简单的HTTP请求是否可以用于同步?
  • 如何知道当前登录的用户? (一种方法是让客户端在每隔x分钟后继续向服务器发送请求,以通知它处于活动状态。否则,请考虑客户端处于非活动状态。)
  • 客户端验证是否足够?如果没有,如果服务器没有验证某些内容,如何还原操作?

我不确定这是否是一种有效的解决方案以及它将如何扩展。如果已经在这些应用程序上工作的人可以分享他们的经验,这可能会帮助我找到更好的东西,我将非常感激。提前谢谢。

其他信息:

客户端在名为marmalade的C ++游戏引擎中实现。这是一个跨平台游戏引擎,这意味着您可以在所有主流移动操作系统上运行您的应用程序。我们当然可以实现线程化,这也在我的流程图中说明。我计划将MySQL用于服务器,将SQLite用于客户端。

这不是一个回合制游戏,因此与其他玩家的互动不多。服务器将提供在线玩家列表,您可以通过单击战斗按钮与他们战斗,并在一些动画后,结果将被宣布。

对于数据库同步,我有两个解决方案:

  1. 存储每条记录的时间戳。还要跟踪本地数据库的时间 最后更新。同步时,只选择那些行 有更大的时间戳并发送到本地DB。保留一个isDeleted标志 对于已删除的行,每次删除都只是作为更新。但 我对每个同步请求的性能都有严重怀疑 必须扫描完整的数据库并查找更新的行。

  2. 另一种技术可能是记录每次插入或更新 这是针对用户的。当客户端应用程序要求同步时, 转到此表,找出哪个表的行 更新或插入。这些行成功转移到 客户端删除此日志。但后来我想到了如果用户会发生什么 使用其他设备。根据日志表所有更新已经 为该用户转移但实际上是在另一个用户上完成的 设备。所以我们可能还要跟踪设备。实施 这种技术耗费时间更长,但不确定是否存在 执行第一个。

4 个答案:

答案 0 :(得分:2)

我实际上已经处理了你提到的一些标题。 我不建议使用mysql,即使你进行了分片,它也无法正确扩展。如果您这样做,您将失去使用关系数据库时可能带来的任何好处。 你可能最好使用no-sql数据库。它的开发速度更快,易于扩展,并且可以轻松更改游戏中的文档结构。 如果您的游戏数据很简单,您可能想尝试使用couchDB,如果您需要高级查询,那么使用MongoDB可能会更好。 一开始就要注意安全。他们肯定会试图破解游戏,如果你发布了许多客户端,很难让安全性变化向后兼容。 SSL不会做太多,因为最终用户不是窃听者而是问题。对您的数据进行签名或加密将使用户更难以向其帐户添加商品和黄金。 您还应该定义您的体系结构以支持多个客户端,而无需使用ifs和case语句。阅读客户端版本并将该客户端分派到适当的代码库。 有一个带升级,维护等标志的维护模式。如果你需要重新分析数据库或任何其他可能需要停机的更改,它会减少一些麻烦。 客户端验证是不够的,特别是如果在应用程序购买中使用。我同意上述帖子。服务器应该控制游戏逻辑。 至于DB同步,它最好是memcache只读数据。典型的例子是可购买的项目,地图,新闻等。用户数据更难,因为您可能无法承受丢失任何修改的数据。最简单的设置是将用户数据缓存几个小时,并且每次都直接写入数据库。如果您使用no-sql,它可能会承受高负载而无需使用持久性队列。

答案 1 :(得分:1)

看起来不错。但是客户端是由什么组成的?网络?你能用线程来同步两个DB吗?我应该以这种方式制作游戏,使其立即与本地数据库交互,并让一些后台机制进行同步(类似于快照)。这让我想到了mysql复制。我认为值得尝试,但我从未这样做过。它还为您提供其他问题的答案。但收费怎么样(有多少客户连接在一起)?

http://dev.mysql.com/doc/refman/5.0/en/replication.html

答案 2 :(得分:1)

我看到两个潜在的问题隐藏在您将所有状态存储在客户端上,然后使用后台线程更新服务器上的状态。

  • 服务器如何验证发布的数据?如果有人攻击你的应用程序,他们可以修改代码,这样每当他们挥动剑(或者他们在你的游戏中做的任何事情)时,它总是很受欢迎。在单人游戏中做到这一点并不是什么大不了的事,但在MMORPG中这样做会破坏其他人的体验。因此,服务器应该验证每次数据更新 - 甚至更好,服务器应该负责每个业务规则。因此,当你向对手挥动剑时,应该是服务器调用,服务器返回它是否是命中,以及对手丢失了多少生命值。

  • 与其他玩家互动怎么样(因为你说它是MMORP,会与其他玩家互动)?由于您说您更新服务器并在后台线程中获取更新,因此交互将会缓慢。当您与另一个角色进行通信时,您首先等待后台线程同步数据,但您还必须等待其他玩家的后台线程同步数据。

答案 3 :(得分:0)

让您的客户端向服务器发出命令(“命中玩家”),并将服务器发送(相关)事件发送给客户端(“玩家被杀”)。我不建议进行数据同步。服务器应该负责所有重要的游戏决策。