该游戏是一款低图形(SVG)战略游戏。每个服务器代表一个游戏域及其玩家。所有服务器都应该能够相互交谈,因为玩家可以(在游戏中)从一个域移动到另一个域/发送“外交信使”等。
我们选择了这个想法,因为它使我们能够无休止地扩大世界地图,它使第二方能够将他们的游戏服务器连接到我们,并且让他们更加扩大世界。如果一台服务器(及其备份)出现故障,游戏仍将继续运行(真正的分布式环境)。
我们才刚刚开始。我们应该关注哪些平台,这将有助于我们开发这样一个世界?
该游戏是一款低图形(SVG)战略游戏。每个服务器代表一个游戏域及其玩家。所有服务器都应该能够相互交谈,因为玩家可以(在游戏中)从一个域移动到另一个域/发送“外交信使”等。
我们选择了这个想法,因为它使我们能够无休止地扩大世界地图,它使第二方能够将他们的游戏服务器连接到我们,并且让他们更加扩大世界。如果一台服务器(及其备份)出现故障,游戏仍将继续运行(真正的分布式环境)。
我们才刚刚开始。我们应该关注哪些平台,这将有助于我们开发这样一个世界?
XMPP,以前称为 Jabber,可能是一个不错的起点。
这在很大程度上取决于您希望在服务器之间共享多少数据。您希望每台服务器处理它自己的域,但是帐户数据库、关于谁拥有什么信息的数据、域的拓扑、这些数据将是集中的和/或分布式的,以及如何使它们保持同步。因此,除了游戏的运作之外,还有另一组元数据,服务器需要与之通信。至于游戏数据,您可能会传递事件、数据对象以及有关数据所有权和控制权的信息。除此之外,还必须有一些游戏内时钟元数据来保持域时间同步。
我可能会为元数据、请求和响应消息使用具有不同优先级的异步队列系统。交换消息之上的 XMPP 等协议可以为您带来存在信息、身份验证、加密和其他优势。但一开始,传递协议本身并不像消息的结构和数据的交换那么重要。本质上,交付协议是可互换的。
示例:一名玩家将游戏单元 X 从域 A 发送到域 B。域 A 服务器将带有事件的消息发送到域 B 服务器。在处理事件队列时,B 接收消息并向 A 上的请求队列发送请求,以获取有关单元 X 的数据以及控制/修改单元 X 数据的权限。请求队列具有更高的优先级,将在域 A 上的其他事件之前处理. 域 A 将请求的数据和控制令牌发送到具有最高优先级的域 B 响应队列。同时域 B 服务器已经处理了 3 个其他事件,没有在会话中等待。
重要的是您必须设计数据封装协议,可能是一些 XML 模式。事件处理协议。事件列表、允许的响应、错误消息、恢复。这些都是特定于游戏的。
我会认真考虑 Erlang 和 CouchDB,或者在 Google AppEngine 下实现它。
如果它真的是分布式的,那么我猜没有中央服务器的计划。这意味着您真正需要的是各种服务器之间的通信机制。REST 和 XML-RPC 都是非常简单的机制,使服务器能够相互通信以传达用户需要从一个移动到另一个的通信。
正如丹尼尔所说,你也可以使用像 XMPP 这样的东西,但这意味着你必须将另一组服务器软件与运行游戏本身的任何东西挂钩(我从你的描述中猜测可能是一个网络)某种应用服务器)。
从开发的角度来看,任何强大的开发 Web 应用程序的语言/框架都应该可以工作。Ruby on Rails、Python on Django、众多框架加上 Java,甚至是带有 PHP (ick) 的 Cake 都可以用于开发工作。
我过去曾考虑过类似的事情,但审查各种服务器的问题(即,您如何处理损坏或恶意的服务器,并让玩家同时将同一块移动到两个或三个其他服务器上),处理退出服务器(最后存在的玩家会发生什么)等似乎非常具有挑战性。
我认为首先要回答的问题是游戏是实时的还是事件驱动的,以及客户端是否是浏览器。听起来它是事件驱动的,但请记住,服务器无法有效地将结果推送到纯 HTML 客户端,只能推送到 Java 小程序、嵌入式 Flash 电影等。如果您有自定义客户端,则无需使用 HTTP服务器上的-style系统,意味着服务器->服务器和服务器->客户端通信可以以相同的方式完成。
你应该看看关于 p2p 游戏的“兴趣管理”论文,你会遇到非常有趣的方法。Google Schoolar 将为您呈现非常好的论文。
但请注意,开发分布式应用程序比简单的单服务器方法要复杂得多。