mmo - 如何制作 MMO(服务器端)？

Question

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

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

成分:

登录服务器:客户端将用户名和密码发送到此服务器，如果成功，则向客户端提供要连接的游戏服务器。

Game Server [1..N]:所有游戏逻辑都在这里，客户端连接到这个。

位置数据库:存储当前登录用户和活跃怪物的数据，他们在哪个游戏服务器中，他们在 map 上的位置和他们采取的行动(移动、攻击等)。

Account Data DB:存储关于用户的所有数据(用户名、密码、字符、元素、任务等)

聊天服务器:由于同一个地方的用户可以在不同的服务器上，所以需要多做一个，让玩家之间可以互相交流。

Monster DB:包含所有怪物的属性、基地位置和AI脚本的数据库。

Monster Server [1..N]:服务器中所有活跃的怪物

日志数据库:存储所有采取的行动和聊天文本。

行动:

登录:

客户端向登录服务器发送用户名和密码。

登录服务器用Account Data DB 验证数据，并检查当前未记录的(Position DB)，如果成功转到3，如果不成功，则返回一个不成功的登录信息。

登录服务器更新位置数据库，将新连接的用户添加到他将连接的服务器(最少人数/最近)

Position DB 通知相应的游戏服务器用户已连接。

登录服务器发送到游戏服务器所连接的客户端。

主循环(客户端):

客户端在位置数据库中检查他当前的位置和 Action 以及他附近的位置和 Action (玩家和怪物)，在收到的数据中还包括玩家的最后更新时间(装备或等级)。

客户端将接收到的玩家的日期与内存中保存的当前玩家进行比较，如果玩家不在内存中或日期不相同，则客户端向帐户数据数据库询问等级、装备等。

客户端渲染玩家

一段时间后转到 1.

聊天:

客户端向聊天服务器发送消息(pm/normal/all)

如果是 pm，Chat Server 将消息发送到目标

如果正常，聊天服务器与位置服务器检查区域内的玩家(与主循环(客户端)相同)，当检查附近的玩家时)并将消息发送给这些玩家。

如果全部，聊天服务器向所有玩家广播

确认发送方和接收方收到消息

行动:

客户端向游戏服务器发送 Action (制作、移动、攻击等)。

游戏服务器处理 Action 并用 Action 的效果更新位置数据库(客户端将知道主循环 Action 发生了什么)。

在制作或掠夺的情况下，游戏服务器将获得的元素返还给客户端。

主循环(游戏服务器):

检查所有从客户端接收到的数据并处理它们。

向客户端发送处理结果(伤害、xp、获得的元素等)并用它的影响(新位置等)更新位置数据库。

一段时间后转到 1.

主循环(怪物服务器):

检查附近是否有玩家存在的事件怪物，如果没有，则将其从怪物服务器和位置数据库中删除。

向位置数据库中的所有玩家检查附近是否有任何怪物(来自怪物数据库)并且未激活并激活它(更新位置服务器和怪物服务器)。

怪物根据存储在怪物数据库中的脚本采取行动(攻击、移动、什么都不做等)。

一段时间后转到 1.

以及我的问题:

这种实现方式行得通吗？ (考虑到有很多怪物和玩家的大 map )

我有一种感觉，如果事情发展起来，位置数据库会非常紧张。如果:

制作多个位置数据库

制作一个链接(玩家/怪物、游戏服务器、位置数据库)的数据库

制作一个链接(位置数据库，区域)的数据库

因此位置数据库基于一个(或多个)区域，当玩家移动到另一个区域时，他的数据将移动到另一个位置数据库；最后一个DB(Position DB，area)是如果一个区域有太多玩家，很少有Position DB可以共享同一个区域(如果区域没有很多人，一个Position DB可以容纳一些区域)

关于使用的技术，我在想以下几点:

登录服务器:scala/django

游戏服务器:C++ 原始编程？

位置 DB:scala/django 用于通信和 DB 与 SQL

帐户数据 DB:用于通信和 DB 的 scala/django 不确定是否使用像 mongoDB 这样的 NoSQL 或保存在文件中的帐户(哪个会更好？)

聊天服务器:在 C++ 中进行原始编程还是应该尝试调整 IRC 服务器？

怪物数据库:SQL

怪物服务器:如游戏服务器

日志数据库:SQL

客户端 - 服务器之间的通信应该是 UDP 以获得更快的通信？和TCP登录？还是应该在客户端和服务器之间始终保持打开的 TCP 套接字？另外，对于聊天，TCP 还是 UDP？

大约每隔多久主循环运行一次才能流畅运行？每 0.5 秒，0.1，接近 60fps？还要让计时器更好地在每个循环中抛出一个线程？ (控制线程的数量，所以如果循环花费的时间比它应该的长)

而且我认为我暂时没有忘记任何要问的问题并为这篇重要帖子感到抱歉......

Answer 1

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

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

还可以考虑让前端服务器始终与客户端保持一个连接，将消息中继到正确的游戏服务器等。通过这种方式，您可以避免客户端必须连接到“正确”的游戏服务器以及所有问题伴随着那种程度的信任。

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