-
1. Re: Off-topic design question
gonorrhea Jun 15, 2009 8:43 PM (in response to earnest.dyke)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
join
the 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
workers
working 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). -
2. Re: Off-topic design question
pgmjsd Jun 15, 2009 9:25 PM (in response to earnest.dyke)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.
-
3. Re: Off-topic design question
earnest.dyke Jun 15, 2009 9:33 PM (in response to earnest.dyke)Excellent solution Joshua! I will look into this.
Earnie!
-
4. Re: Off-topic design question
jguglielmin Jun 15, 2009 9:52 PM (in response to earnest.dyke)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).
-
5. Re: Off-topic design question
pgmjsd Jun 16, 2009 4:37 AM (in response to earnest.dyke)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.
-
6. Re: Off-topic design question
jguglielmin Jun 16, 2009 2:13 PM (in response to earnest.dyke)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.