I've never given thought to this interesting question until now, but essentially instead of one client per session you need to model/accomodate n clients per session.
Almost like a workflow or BPM solution? not quite sure if you can use the same jsessionid and/or cookie from different browsers to
jointhe same game session.
And I'm not sure how/if conversational modeling in Seam is applicable to a multi-player game. Not sure if workflow applies b/c you have multiple
workersworking simultaneously on the same task which is not how BPM works AFAIK (usually it's resource A finishes task 1 --> resource B finishes task 2 --> etc. in BPM modeling).
I solved that problem using a POJO JMS listener that delegates messages to a bunch of SFSBs. Each SFSB represents the state of a 'game', and each 'player' interacts with the SFSB for their game via JMS. The POJO JMS listener picks up the messages and looks up a SFSB in a map (think of each SFSB as a 'game'), and invokes a method on the SFSB. The SFSB returns information about the next state, which is then broadcast on a topic. A conversation-scoped bean is used to subscribe to that topic and relay the changes back to the browser via Seam remoting.
In my case, the 'players' are traders, and the 'games' are option contracts.
Excellent solution Joshua! I will look into this.
If you don't want to have to configure JMS and have the time, check out ICEfaces. It has the ability to server-push (ajax-push or COMET). You could simply have an application-scoped GameManager that would push the updated game info to each user that is registered in the game group. The new SessionRenderer API is quite easy to implement. For each SFSB, you would add the user to the (gameID) group (one line of code). Any method in this bean that changes the state of the game could then trigger an event that the GameManager would observe and push the updated state to the rest of the game group. It wouldn't be too difficult to have more than one game group either. For a user to exit the group, you just remove them from the group (again, just one line of code).
Yes, but that's basically rolling your own pub-sub (not that it's that hard). Also, it would be difficult to make that work in a cluster.
The neat thing about using JMS for communicating to and from the 'game state' is that you can have anything trigger changes to the game. EJB3 timers might be good in a real time strategy game, for example.
Actually, ICEfaces has a version of server-push for clustering, the BroadcastRenderer. It just does the configuring of JMS for you. (you can look at the code to see). You can still use ejb3 timers or trigger pushes from a database as well.