作为我计算机科学教育的一部分,我正在构建一个多人Android Yatzy游戏,通过基于Ruby / EventMachine的TCP服务器将客户端连接在一起,并传递JSON消息来表示游戏事件。
然而,我对如何最优地处理游戏回合管理感到不确定。
一个典型的Yatzy游戏包括15个回合。我的实现将处理最多4个玩家。像掷骰子、保持骰子和选择得分这样的事件被发送到Ruby服务器并广播给其他玩家。
目前,我的服务器正在处理游戏回合。每次它从客户端接收到新的得分选择时,它会将得分广播给其他客户端。随后,它会广播下一个掷骰子的用户ID的消息。
我希望我的系统能够处理玩家退出而不会对其余玩家产生灰暗的副作用。我想出了一个解决方案,但我不确定是否理想。
每次轮换结束(通过得分选择提交)时都会调用
我选择使用Fiber类的原因是希望能够对
我想了解您对这种方法的想法,特别是它的弱点以及您认为应该考虑哪些替代方案来解决这个轮换管理问题。
然而,我对如何最优地处理游戏回合管理感到不确定。
一个典型的Yatzy游戏包括15个回合。我的实现将处理最多4个玩家。像掷骰子、保持骰子和选择得分这样的事件被发送到Ruby服务器并广播给其他玩家。
目前,我的服务器正在处理游戏回合。每次它从客户端接收到新的得分选择时,它会将得分广播给其他客户端。随后,它会广播下一个掷骰子的用户ID的消息。
我希望我的系统能够处理玩家退出而不会对其余玩家产生灰暗的副作用。我想出了一个解决方案,但我不确定是否理想。
@turnfiber = Fiber.new do
15.times do
@players.each do |key, value|
Fiber.yield value
end
end
end
@turnfiber
是属于游戏对象的实例变量,用于表示正在进行的游戏。 @players
是散列,以玩家的唯一ID作为键,对应的玩家对象作为值。每次轮换结束(通过得分选择提交)时都会调用
@turnfiber.resume
,以获取下一个掷骰子的玩家并广播他的掷骰子权限。思想是如果玩家在第4轮离开游戏,他的客户端将发送退出消息,该消息将从@players
散列中删除正在离开的玩家,并广播他的离开,因为玩家不再驻留在@players
散列中,所以防止后续迭代将骰子控制权交给“死”玩家,从而避免死锁。到目前为止,我的Android客户端还不完整,因此我尚未测试这个理论在实践中是否有效。我选择使用Fiber类的原因是希望能够对
@players
进行15次迭代,并依次让它们掷骰子。由于Fiber在每次调用yield
时暂停循环并返回玩家,因此这是可能的。我想了解您对这种方法的想法,特别是它的弱点以及您认为应该考虑哪些替代方案来解决这个轮换管理问题。
next()
来检索下一个对象。Ruby中是否有类似的东西? - Niels B.