多人游戏的服务器架构？
我计划构建一个小型多人游戏，可以在网络浏览器中作为 java applet 或 flash 文件运行。 我以前没有做过任何服务器编程，所以我想知道我应该拥有什么样的服务器架构。
对我来说，在服务器上创建 perl/php 文件很容易，java/flash 代码会联系这些文件来更新玩家位置/动作等。但我正在考虑是否应该获得一个专用的网络主机，哪个操作系统使用哪个数据库等。此外，使用的带宽量和可扩展性也是一个考虑因素。
另一种选择可能是使用云托管系统（而不是专用服务器），因此他们会随着游戏的发展而添加额外的机器。 只要每台服务器运行核心 perl/php 文件来更新数据库，它就应该可以正常工作。
另一种选择是使用谷歌应用程序引擎。
任何有关服务器架构、操作系统/数据库选择以及我使用 perl/php/python 脚本进行服务器端编程的方法是否良好的想法，将不胜感激！
I'm planning to build a small multiplayer game which could be run as a java applet or a flash file in the web browser. I haven't done any server programming before, so I'm wondering what sort of server architecture i should have.
It'll be easy for me to create perl/php files on the server, which the java/flash code contacts to update the player position/actions, etc. But I'm considering whether i should get a dedicated web host, which OS to use, which database, etc. Also, the amount of bandwidth used and scalability is a consideration.
Another option could be using a cloud hosting system (as opposed to a dedicated server), so they would take care of adding additional machines as the game grows. As long as each server ran the core perl/php files for updating the database, it should work fine.
Yet another option could be using Google app engine.
Any thoughts regarding the server architecture, OS/database choice, and whether my method of using perl/php/python scripts for server-side programing is a good one, will be appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你需要更多地理清游戏，更多地思考架构而不是具体的实现细节。
主要问题是您的游戏是实时的、回合制的还是基于长延迟的（例如，电子邮件国际象棋）。 另一个问题是您是否要冻结状态以供后续重新加载。
我强烈建议您提前确定同一游戏中的所有玩家是否都将托管在同一服务器上（例如，1000 场 4 名玩家比赛与 4 场每场 1000 名玩家比赛）。 如果可能的话，选择第一个，并将同一游戏中的每个人都粘在同一服务器下。 您将很难将多个客户端同步到一台服务器，而不是让多个服务器同步玩家。 否则，一致性的定义就有问题。
如果可能，让每个客户端与服务器通信，然后服务器将更新分发给客户端。 这样你就有了一个“官方状态”，并且可以进行各种冲突解决、幻像等。点对点在更快的游戏（例如，FPS）中提供更好的性能，但会带来大量问题。
我无论如何都看不出有任何令人信服的理由来这样做以及 Perl 或 PHP。 你的游戏不是基于网络的，为什么要用面向网络的语言编写它？ 使用老式的 J2EE 作为服务器，并通过 XML 和 AJAX 与客户端交换数据。 如果可能，请在客户端而不是 servlet 上运行真正的 Java 应用程序。 然后，您可以从使用 JMS 中受益，JMS 将为您抽象大量通信细节，从而减轻您的巨大负担。
You need to clarify more about the game, and think more about architecture rather than specific implementation details.
The main question is whether your game is going to be in real time, turn based, or long-delay based (e.g., email chess). Another question is whether or not you are going to be freezing the state for subsequent reloads.
I would highly recommend figuring out in advance whether or not all players in the same game are going to be hosted on the same server (e.g., 1000 of 4 player matches compared to 4 matches of 1000 players each). If possible, go with the first and stick everyone who is in the same game under the same server. You will have a hard enough time synchronizing multiple clients to one server, rather than having multiple servers against which players are synchronized. Otherwise, the definition of consistency is problematic.
If possible, have each client communicate with the server and then the server distributing updates to the clients. This way you have one "official state", and can do a variety of conflict resolutions, phantoms, etc. Peer to peer gives better performance in faster games (e.g., FPSs) but introduces tons of problems.
I cannot for the life of me see any convincing reason to do this and perl or PHP. Your game is not web based, why write it in a web oriented language? Use good old J2EE for the server, and exchange data with your clients via XML and AJAX. If possible, run a real Java application on clients rather than servlets. You can then benefit from using JMS which will take a huge load off your back by abstracting a lot of the communication details for you.
对于您的服务器架构，您可以查看Three Rings 的代码。 他们用 Java 编写了许多可扩展的游戏（客户端和服务器端）。
For your server architecture, you might have a look at Three Rings' code. They have written a number of very scalable games in Java (both client- and server-side).
我也不鼓励使用 PHP，而且 HTTP 也不是最好的主意，因为它是无状态且多说话的。 我在公司工作了一段时间，目前正在开发大型多人游戏。 后端是普通的 JVM（多个客户端通过 tomcat 连接，每个客户端一个移动设备）。 所以我知道您传输的数据越少，服务器上所需的缓冲区就越小 -> 一台机器上有更多客户端，响应速度也更快。 还要考虑安全性，https 相当昂贵，特别是如果您需要传输图形和声音。 您自己的非浏览器客户端容器的二进制协议会做得最好（好的选择是开发调试时间的可切换协议）。 也许听起来很复杂，但事实并非如此。
@Sarah 很好的提示，也谢谢；）
I would also discourage from using PHP, also HTTP isnt the best idea as it is stateless and talkative. I was working for some time in company currently developing really massive multiplayer game. The back-end is plain JVM (being connected thru tomcat by multiple clients and from mobiles one per client). So I know the less data you transfer the smaller buffers you need on server -> more clients on one machine and also a bit faster responses. Also consider security, https is quite expensive, especially if you need to transfer graphics and sounds. Binnary protocol of your own with non-browser client container would do the best (good choice is switchable protocol for the development-debugging time). Maybe sounds complicated but it isn't.
@Sarah nice hint, thanks too ;)