编写基于客户端-服务器的游戏的建议

发布于 2024-10-10 17:41:19 字数 572 浏览 2 评论 0原文

我正在考虑编写一个基于服务器的游戏,并且有几个客户端程序连接到它。该游戏(非常)基本上由用户可以“接受”的项目列表组成,这会将其从所有连接的计算机上的列表中删除(这需要非常快地更新)。

我正在考虑为客户端使用 Java 小程序,因为我希望它是可移植的,并且可以从浏览器(主要在 Windows 中)运行,并且更新速度快,并且可以在 Linux 上运行 C++ 或 Java 服务器(目前仅家庭服务器,但也可能使用 VPS)。

这个游戏之前的“化身”是在浏览器中运行的,并使用 PHP+mySQL 作为后端,但是当几个人连接时(大约有 8 个人,这最终需要处理很多数据),这会导致服务器陷入相当大的负担。更多)。
用户可能都位于同一物理位置(具有相同的公共 IP 地址),并且系统每秒会收到多个请求,所有这些请求都需要将列表发送回客户端。

有些计算机可能有防火墙限制,因此您是否建议使用 HTTP 流量、自定义端口,或者通过 SSH 或某些现有协议?

谁能建议一些技巧(线程、一项的多个请求?)、工具、数据库(mySQL?)或 API 来帮助我开始这个项目?我更喜欢用 C++ 作为后端,因为它更快,但使用 Java 可以让我重用代码。

谢谢!

I'm thinking about writing a game which is based around a server, and several client programs connect to it. The game (very) basically consists of a list of items which a user can 'accept', which would remove it from the list on all connected computers (this needs to update very quickly).

I'm thinking about using a Java applet for the client since I would like this to be portable and run from a browser (mostly in Windows), as well as updating fast, and either a C++ or Java server running on Linux (currently just a home server, but possibly to go on a VPS).

A previous 'incarnation' of this game ran in a browser, and used PHP+mySQL for the backend, but this swamped the server quite a bit when several people connected (that was with about 8 people, this would eventually need to handle a lot more).
The users would probably all be in the same physical location (with the same public IP address), and the system would get several requests per second, all of which would require sending the list back to the clients.

Some computers may have firewall restrictions on them, so would you recommend using HTTP traffic, a custom port, or perhaps through SSH or some existing protocol?

Could anyone suggest some tips (threading, multiple requests of one item?), tools, databases (mySQL?), or APIs which would help me get started on this project? I would prefer C++ for the backend as it would be faster, but using Java would allow me to reuse code.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

才能让你更想念 2024-10-17 17:41:19

仅因为速度,我不会使用 C++。性能差异不太可能对您的游戏产生真正的影响。 (您的网络可能会影响任何性能差异,除非客户端和服务器之间有 10 GigE)我会使用 C++ 或 Java,因为您将首先使用该语言使其工作。

I wouldn't use C++ because of speed alone. It is highly unlikely that the difference in performance will make a real difference to your game. (Your network is likely to cloud any performance difference, unless you have 10 GigE between the client and server) I would use C++ or Java because you will get it working first using that language.

街道布景 2024-10-17 17:41:19

对于任何正在寻找良好的 C++ 网络 API 的人,我总是建议 Boost。阿西奥。它的优点是独立于平台,因此您可以为 linux、windows 等编译服务器。但是,如果您不太熟悉 c++ templates/boost,代码可能会有点让人不知所措。看看,尝试一下。

就一般建议而言。根据上面的描述,您似乎需要一个相对简单的服务器。我建议保持非常基本的单线程轮询循环。从连接的客户端读取消息(在多个套接字上等待),并做出适当的响应。这消除了对列表的多次访问和其他同步问题的任何问题。

我也可能建议,在你重写你的最初化身之前。尝试改进它,正如您所说:

系统每秒会收到多个请求,所有这些请求都需要将列表发送回客户端。

鉴于每个请求都会从此列表中删除一个项目,为什么不只是通知您的用户删除了哪个项目,而不是一次又一次通过网络发送整个列表呢?如果这个列表有很大的规模,这个微小的改变将带来很大的改进。

For anyone looking for a good networking API for c++ I always suggest Boost.Asio. It has the advantage of being platform independent, so you can compile a server for linux, windows etc. However, if you are not too familiar with c++ templates/boost the code can be a little overwhelming. Have a look, give it a try.

In terms of general advice. Given the description above, you seem to need a relatively simple server. I would suggest keeping it very basic, single threaded polling loop. Read a message from your connected clients (wait on multiple sockets), and respond appropriately. This eliminates any issue around multiple accesses to your list and other synchronization problems.

I might also suggest, before you re-write your initial incarnation. Try improving it, as you have stated:

and the system would get several requests per second, all of which would require sending the list back to the clients.

Given that each request removes an item from this list, why not just inform your uses which item is removed, rather than sending the entire list over the network time and time again? If this list is of any significant size, this minor change will result in a large improvement.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文