应用错误收集

我曾试图搜索如何制作MMO并总是找到相同的回复，这是不可能或需要很多钱，但从未提供如何制作的指南。

我想构建一个非常可扩展的东西，我目前关于如何构建MMO的想法如下：

组件：

登录服务器：客户端向此服务器发送用户名和密码，如果成功，则向客户端提供要连接的游戏服务器。
游戏服务器[1..N]：所有游戏逻辑都在这里，客户端连接到这个。
位置数据库：存储当前登录用户和活动怪物的数据，其中包括游戏服务器，他们在地图上的位置以及他们采取的行动（移动，攻击等）。
帐户数据DB：存储有关用户的所有数据（用户名，密码，字符，项目，任务等）
聊天服务器：由于位于同一个地方的用户可以在不同的服务器上，因此需要额外添加一个，以便玩家可以在他们之间进行通信。
Monster DB：一个包含所有怪物的属性，基本位置和AI脚本的数据库。
Monster Server [1..N]：服务器中所有活动的怪物
日志数据库：存储所有采取的操作和聊天文本。

操作：

登录：
1. 客户端将用户名和密码发送到登录服务器。
2. 登录服务器使用帐户数据DB验证数据并检查当前未记录的数据（位置数据库），如果成功则转到3，如果不成功，则发回不成功的登录消息。
3. 登录服务器更新位置数据库，将新连接的用户添加到他将连接的服务器（最低人数/最近）
4. 位置DB通知相应的游戏服务器用户已连接。
5. 登录服务器向客户端发送游戏服务器已连接到。
主循环（客户端）：
1. 客户在位置DB中检查他当前的位置和动作以及他附近的人（玩家和怪物），在收到的数据中还包括玩家的最后更新时间（档位或等级）。
2. 客户将收到的玩家的日期与保存在内存中的当前玩家进行比较，如果玩家不在记忆中或日期不同，则客户要求账户数据DB获取lvl，齿轮等。
3. 客户端呈现玩家
4. 一段时间后转到1。
聊天：
1. 客户端向聊天服务器发送消息（pm / normal / all）
2. 如果是pm，聊天服务器会将消息发送给目标
3. 如果正常，聊天服务器会与位置服务器一起检查该区域内的玩家（与主循环（客户端）相同.1当检查附近的玩家时）并将消息发送给那些人。
4. 如果全部，聊天服务器向所有玩家广播
5. 确认发件人和收件人已收到消息
动作：
1. 客户端向游戏服务器发送动作（制作，移动，攻击等）。
2. 游戏服务器处理操作并使用操作的效果更新位置数据库（客户端将知道主循环操作发生了什么）。
3. 如果是制作或抢劫，游戏服务器会将获得的项目返回给客户。
主循环（游戏服务器）：
1. 检查所有从客户端收到的数据并进行处理。
2. 向客户发送过程结果（损坏，xp，获得的项目等），并更新位置DB及其效果（新位置等）。
3. 一段时间后转到1。
主循环（怪物服务器）：
1. 检查一个活跃的怪物是否有玩家在附近，如果没有将其从怪物服务器和位置数据库中删除。
2. 检查位置数据库中的所有玩家是否有任何怪物（来自怪物数据库）并且未激活并激活它（更新位置服务器和怪物服务器）。
3. Monster根据存储在怪物DB上的脚本采取行动（攻击，移动，不做任何事情等）。
4. 一段时间后转到1。

以及我的问题：

这种实施方式是否有效？（考虑一张有大量怪物和玩家的大地图）
我觉得如果事情成长，职位数据库将会非常紧张。会更好，如果：
- 制作多个位置数据库
- 制作链接（玩家/怪物，游戏服务器，位置数据库）
- 制作链接（位置数据库，区域）
- 因此，位置DB基于一个区域（或多个区域），当玩家移动到另一个区域时，他的数据被移动到另一个位置DB;最后一个DB（位置DB，区域）将是如果一个区域有太多的玩家，很少位置DB可以共享相同的区域（如果区域没有很多人，位置DB可以容纳一些区域）
关于使用的技术，我正在思考以下问题：
- 登录服务器：scala / django
- 游戏服务器：C ++中的原始编程？
- 位置DB：用于通信的scala / django和用SQL的DB
- 帐户数据DB：用于通信的scala / django和DB不确定是使用像mongoDB这样的NoSQL还是保存在文件上的帐户（哪个会更好？）
- 聊天服务器：使用C ++进行原始编程，还是应该尝试调整IRC服务器？
- Monster DB：SQL
- Monster Server：喜欢Game Server
- 日志数据库：SQL
客户端 - 服务器之间的通信应该是UDP，以便更快地进行通信？和TCP登录？或者应该始终在客户端和服务器之间保持一个开放的TCP套接字？还有，聊天，TCP还是UDP？
主循环应该运行多长时间以便游戏流畅？每0.5秒，0.1，接近60fps的东西？还要使计时器最好每次循环抛出一个线程？（控制线程数量，所以如果循环花费的时间比它应该的长）

而且我不认为我现在忘记了任何事情，并且对这个大帖子感到抱歉......

我不认为您的解决方案会扩展。问题是您的位置数据库需要针对每个玩家操作进行更新。您可能使用此方法允许游戏服务器共享数据，这是一个坏主意，因为数据库不是为了启用系统分发。将数据库视为真正的离线存储，仅在激活玩家或对象时加载状态。

您需要摆脱位置数据库并存储在游戏服务器中分配的玩家状态。

还要考虑让前端服务器始终保持与客户端的一个连接，将消息转发给正确的游戏服务器等。这样就可以避免客户端连接到“正确”的游戏服务器和所有这种信任程度带来的问题。

分布式编程非常困难，但编程语言Erlang使您比Python / C ++等更容易。

如何制作MMO（服务器端）？

2 个答案: