Actor 是在简单的多人游戏之间实现消息传递的正确工具吗？
我正在考虑使用 Actor 来制作一个用 Scala 和 Java2D 编写的简单的类似 Asteroid 的游戏，该游戏可以由两个玩家以合作模式玩。
两名玩家都可以在共享的游戏场上控制自己的飞船，小行星在太空中漂浮。
我想知道演员是否是实现两个玩家之间网络元素的正确工具，例如位置更新或小行星的破坏。
实施它需要什么？困难的部分是什么？我担心我会在保持它们同步方面遇到问题......
有更好的解决方案吗？
编辑：
我不打算做任何有关防火墙或 NAT 的花哨的事情...我想到有一个小型“服务器”，两个客户端都连接到它。 （实际上，一个客户端将启动服务器并在同一台电脑上运行它。）
两个客户端都将连接到它，最好都使用远程参与者，这样我就不必对远程/本地情况进行特殊处理。
如果 P2P 路线更容易的话，我对走 P2P 路线没有任何问题。需求是固定的，我永远不必为“我们需要 64 名玩家的游戏!!!”的情况进行计划。
I'm thinking about using actors for a simple Asteroid-like game written in Scala and Java2D, which can be played by two players in a cooperative mode.
Both players can control their own ship on a shared playing field, where asteroids float through the space.
I wonder if actors are the right tool to implement the network elements between both players, like position updates or the destruction of an asteroid.
What would be necessary to implement it? What would be the hard parts? I fear that I will have problems with keeping them both in sync...
Is there a better solution available?
EDIT:
I don't plan on doing any fancy stuff regarding firewalls or NAT... I thought of having a small "server" to which both clients connect. (In reality one client will just start up the server and run it on the same pc.)
Both clients will connect to it, preferably both with a remote actor, so that I don't have to special case the remote/local case.
I have no problems with going the P2P route, if it is easier. The demands are fixed and I never have to plan for the case of "we need a 64 player game!!!".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我最近参与了一款游戏的开发，该游戏或多或少地使用了相同的消息传递方法。即，有一个远程服务器在某个端口上侦听，然后有多个客户端连接到它并来回传递消息。
不过，它是用 Python 完成的，并且由于我们不想依赖任何外部库，因此我们编写了自己的 actor 以及在它们之上的远程消息系统。
事实证明，存在一些速度问题，但我认为它们主要与 Python 执行线程的方式有关（以及我们对其缺乏理解）。 Scala Actors 或 Akka 的基准总是给出比我们在 Python 中能够做的更好的数字。
同步对我们来说并不是一个大问题，至少在游戏本身中不是。但那时我们没有那么多数据可以交换，而且这是一个回合制的游戏。因此，每个客户端都会被依次查询，如果超时，则会查询下一个客户端。在我们的问题中，客户端仅对服务器向他们提供的内容做出反应。然而，这可能不是实时游戏中的最佳解决方案。
对于实时事物，您可能在服务器上有一个传入队列（Actor）来接收所有客户端移动，并且可能有一个单独的游戏状态通道以避免阻塞。这确实需要更多的同步工作。因此，这在一定程度上取决于您需要更新的速度。
I’ve recently been involved in the development of a game which more or less used the same kind of messaging approach. I.e. having a remote server listening on a port somewhere and then several clients connecting to it and passing messages back and forth.
It was done in Python, though, and as we did not want to rely on any external libraries, we did write our own kind of actors and a remote messaging system on top of them.
As it turned out, there were a few speed issues but I think they were mostly related to Python’s way of doing threading (and our lack of understanding of it). Benchmarks for Scala Actors or Akka always gave better numbers than what we were able to do in Python.
Synchronisation was not a big issue for us, at least not in the game itself. But then we did not have that many data to exchange and it was a round based game. So, each of the clients was queried one after another and if there was a timeout then the next client would be queried. In our problem, the clients were only reacting on what the server presented them. This might, however, not be the best solution in a more real-time game.
For a real-time thing you might have an incoming queue (Actor) on the server to receive all the client moves and probably have a separate channel for the game state to avoid blocking. This would indeed be a bit more involved to synchronise. So it depends a bit on how fast you need updates.
不管它的价值如何，Akka 的一些早期采用者都是多人游戏，尽管我无法提供参考。
此外，《使命召唤》的多人游戏核心是用 Erlang 编写的 。该链接指向做这件事的人的演示，这是非常有趣的东西。
For whatever it is worth, some of the early adopters of Akka were multiplayer games, though I cannot provide a reference for it.
Also, Call of Duty's multiplayer core is written in Erlang. That link's to a presentation by the guys who did it, and it is very interesting stuff.
如果存在大量异步消息传递（即在没有任何先前状态的情况下发送的消息），Actors 绝对是一种方法，
我将按如下方式实现它：每个玩家都将是一个从另一个玩家接收消息的
Actor玩家。发送给参与者的消息不会丢失，因此一旦所有消息都已传递，您最终将达到同步状态。当然，您必须编写自己的同步算法。可以使用
RemoteActorAPI 直接访问远程参与者，或者使用中间通信介质（例如套接字）来传输消息。我假设没有中央服务器来协调玩家。
Actors is definitely one way to go if there is a lot of asynchronous messaging (i.e., messages sent without any prior state)
I would implement it as follows: each player will be a
Actorreceiving messages from the other player. Messages sent to actors will not be lost, so you will eventually reach a synced state once all messages have been delivered. You will have to write your own syncing algorithm, of course.It is possible to use the
RemoteActorAPI to directly access the remote actors, or to use an intermediate communication medium (e.g., Sockets) to transport the messages.I am assuming that there is no central server for coordinating the players.