Databases
StackOverflow2013
Postsdbo
POUsing fibers for evented iteration?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POUsing fibers for evented iteration?
    primarykey
    data
    text
    <p>As part of my CS education, I am in the process of building a multiplayer Android yatzy game with clients linked together by a TCP server based on Ruby/EventMachine with JSON messages representing game events passed back and forth.</p> <p>However, I'm feeling uncertain about how to optimally handle game turn management.</p> <p>A typical yatzy game consists of 15 rounds. My implementation will handle up to 4 players. Events like dice rolls, dice holds and score choices are sent to the Ruby server and broadcast to the other players.</p> <p>Currently, my server is handling game turns. Each time it receives a new score choice from a client, it broadcasts the score to the other clients. Subsequently it broadcasts a message with the user id of the next player to roll the dice.</p> <p>I would like my system to be able to handle players dropping out without ending the game for the remaining players as a grim side effect. I've come up with a solution, but I'm not confident that it's ideal.</p> <pre><code>@turnfiber = Fiber.new do 15.times do @players.each do |key, value| Fiber.yield value end end end </code></pre> <p><code>@turnfiber</code> is an instance variable belonging to a game object which represents the running game. <code>@players</code> is a hash which uses the players' unique id's as keys and the corresponding player object as value.</p> <p><code>@turnfiber.resume</code> is called each time a turn has ended (through a score choice submission) to retrieve the next player to roll the dice and broadcast his permission to roll. The idea is that if a player leaves the game in say turn 4, his client will send a quit message that will remove the leaving player from the <code>@players</code> hash, broadcast his departure, and because the player no longer resides in the <code>@players</code> hash, prevent succeeding iterations from handing dice control to the "dead" player thereby avoiding a deadlock. So far my Android client is incomplete, so I have not yet tested if this theory actually works in practice.</p> <p>My choice of the Fiber class is based on a desire to be able to iterate 15 times over the <code>@players</code> and have them roll the dice one at a time. Fibers makes this possible since they pause the loop each time <code>yield</code> is called and returns the player.</p> <p>I would like your thoughts about this approach, particularly what weaknesses it has and what alternatives you think I should consider to solve this problem of turn management.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USNiels B.
    1. USNiels B.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POUsing fibers for evented iteration?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POUsing fibers for evented iteration?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POUsing fibers for evented iteration?
      1. USPhilip
      1. VTFavorite
    1. COIt looks like the fiber is not retaining any state between resumes - in fact, it looks like you are deliberately mutating it over the fiber's lifetime (the @players variable). Given that the only real advantage of a fiber over a simple in-line iterator is the persistence of the stack context, why use a fiber at all here? You'll still need to block (or hand off to EventMachine's reactor) in the code using the fiber's yielded value, anyway. I'm sure this approach will work fine and all, but I can't see it resulting in simpler code for this application. Or maybe I'm missing something?
      singulars
      1. POUsing fibers for evented iteration?
      1. USCatnapper
    2. COThinking about it, what I want is to do a nested iteration (15 rounds, 2-4 players) with the possibility of mutating the players variable and most importantly: Not do the iteration all at once, but one at a time. I thought about using a round counter for the outer loop, but I will still need a way to iterate the players hash one at a time. In Java, which I have worked with previously, one can retrieve an iterator object on collections and do calls to `next()` to retrieve the next object. Is there something similar for Ruby?
      singulars
      1. POUsing fibers for evented iteration?
      1. USNiels B.
    3. COI posted an answer to address your comment and original post. I like this question, coroutines are a fascinating topic for discussion and are often misunderstood.
      singulars
      1. POUsing fibers for evented iteration?
      1. USCatnapper
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload