I have a problem on my browser game played by two people on different browsers. The game state is controlled by Session variables which used a Game Class and the buttons players click. At the end of the game, the players have 3 choices, either to rematch same player, to find another player, or to disconnect the game totally. If the player disconnects, the game can cleanly destroy the game object and revert all Session variables.

The problem I am having is to synchronize the other two buttons the player chooses. If both players choose the same button, then the game proceeds to play again. But if one player wants a rematch and the other one wants to play again, then the disagreeing players must both find new players.

I use two Session variables, PlayWithSamePlayer means that they want a rematch with the same player. and I also use ContinueChoicesMade to make sure both players choose then same option. If ContinueChoicesMade is false, then it means the two players disagreed, and is placed back into my game manager to search for another player. I can figure out how to work in my two player synchronizing method to be placed in my Game class so both player's actions can be listened to. At the moment if I run the game, When it gets to my method, it comes out as NullException.

I want so that at the end of the game, one player chooses a button, and the browser waits for the other browser to click a button, then check if what they pressed is the same, and then if it is the same; the game moves on, and if what they clicked is different; the game moves on. What is the best method to synchronize the Session variables after the players have clicked rematch or find new player. Below is my method in the game class that deals with the two players and also the method call out on my aspx.cs pages.

Session data is not shared. Use the same correctly shared - that is, not Session, not ViewState, not static - resource to transfer this state as is done with the rest of the game state. That is, "continuing" a game is no different than making a choice/move while "playing" a game.
–
user166390Oct 6 '12 at 19:15

The method above is in the game class that runs the game. The argument it takes is the browser Session that is sending the information to the game class, were then it separates it the 2 Sessions into player1 and player2. I find it confusing when to make sure my ContinueChoicesMade session variable is checked. It is only false when the two player click different buttons
–
GivenPieOct 6 '12 at 19:22

Sessions data is not shared between Clients. I am confused into how this is supposed to work .. if there is some magical cudgel being used then it should be shown in context.
–
user166390Oct 6 '12 at 19:25

Yes its not shared, but I can test if the Session variables are set. Session variables define which state the game is currently in. Each browser has it's own Session state in which it will carry forth the game when the Session variable is there, otherwise the game will not know what and where to go next.
–
GivenPieOct 6 '12 at 19:37

The Session variables can only be accessed in the request made by the browser with the correct SessionId. Your server-side can only accessed player 1's session in his request, same for player 2. So if you're not going to store those variables else where, how can you bring them into the same comtext to make the comparison? And about the synchronizing thing, if you don't want to work with comet solutions, you can just handle thing in players' next request.
–
hope_is_grimOct 6 '12 at 20:23

2 Answers
2

I don't think using Session here is a good idea. (And I don't think you can/should read the a session's data from another thread. Maybe I'm wrong)
I think you should store those data in the database (SQL/NoSQL) with at least 2 kind of entity:

One with 2 SessionId for the match record

One with players' SessionId and their choices

So you can store their choice and check if they will or won't play the rematch.
Supposed you have some sort of polling or comet solution, a table/game room will be created if the rematch condition succeeded and a message will be displayed if a player refused.

If you want to access data that is shared, you'll need to use either a data storage (like SQL as mentioned in the other answer) or you can store the information in the application Cache. In this case what you would do is create a Game class to manage the entire game, and then add/remove sessions for individual users.

I would argue a "Cache" is not appropriate here. A Cache is good for storing stuff that might be available elsewhere - the keyword is might. There are no guarantees outside of, perhaps, very particularly configured environments. Using SQL (or another guaranteed persistence mechanism) is the way to go.
–
user166390Oct 6 '12 at 20:59

I don't understand what you're saying about the Cache. Why "might" it not be in the Cache?
–
Lawrence JohnsonOct 6 '12 at 22:40

The term cache is generally used to refer to a temporary store where data might not always be available (for various reasons: eviction, propagation, non-durable restarts, scope/locality, race-conditions, etc) and the primary purpose is to speed up access to data - not to store data. I would thus not rely on a "cache" for this purpose. (Different caches - e.g. a very particular configuration - may or may not provider stronger guarantees in a particular environment.)
–
user166390Oct 6 '12 at 22:44

Application Cache: The pattern when using the application cache is to determine whether an item exists in the cache any time you access an item, and if it does [exist], to use it. If the item does not exist, you can re-create the item and then place it back in the cache. This pattern ensures that you always have the latest data in the cache. -- That is, there is no guarantee in general that Application Cache will contain the desired value(s).
–
user166390Oct 6 '12 at 22:51

Yeah, I see as a best practices it's not a wise choice, and even in my suggestion the idea was not to use information you couldn't afford to lose. Thanks for the link
–
Lawrence JohnsonOct 6 '12 at 22:57