ServerGameState lifecycle

[ghost]

The servergamestate life cycle is as follows.

It sits in an intermission phase for a specified amount of seconds. During this time it periodically pulls users from a waiting list into the game.

Then the game progresses,

Then it repeats.

Concluding notes: Upon constructions, a ServerGameState needs to be "started". This will start the intermission timer. that can be done by calling gameState.startTimer(). Instead of adding player via GameEvents, a player can be added to the "waitinglist" by calling gameState.addPlayerToWaitingList(). This is how the server should add players.

Summary: Call startTimer() upon construction Call addPlayerToWaitingList() upon client connection.

[GitPS]

This timer is running in another thread? Has any of this been implemented yet? The addPlayerToWaitinList() doesn't exist as far as I can see. What information will that method take when?

[ghost]

It has been implemented. I'm not sure why you can't see it. I'll look into it when I get home. The timer is just your basic java.swing.Timer. I assume it runs on its own thread. It generates events every second. After X events, I advance out of the INITIALIZATION phase.

[GitPS]

I see why. We only have a GameState that is returned when we call pi.getGameState(). We need a ServerGameState to be returned from the main class or we wont have access to that method.

[ghost]

I thought we had that problem with something else and we solved it by casting the GameState to a ServerGameState. Did we do that? If so, could we do it again?

[GitPS]

We can cast it, yes... I'm just not a fan of casting a ton of things. We can come back to it if we find a better way.

[ghost]

We could make a new GameEventType that is to be invoked on a GameState that adds a player to the waiting list. It would be handled during any phase. It would have to be different than { ADD_PLAYER, String }. Perhaps { ADD_PLAYRR_TO_WAITINGLIST, String }. Thoughts? And an event for start timer. That would mean everything would happen through the invoke method.

[GitPS]

That would also work. I just made a cast right now. If it is only getting called once on a player connect it might not be too much of a concern.

[GitPS]

@ajjensen13, do you agree with the casting method or do you think we should do something "cleaner"? I am starting to like your idea above more and more. We should really stay away from casting things if we can work around it.

[ghost]

I think invoking is the best way to do it. Also, we could .setNetworkHandler the same way.

GameEvent { type: GameEventType.SET_NETWORK_HANDLER, value: NetworkHandler{ … } }

More generally, any time we had a problem with the interface not having adequate methods, we could use a GameEvent/Invoke.

I think I might have a bad case of Analysis Paralysis. Just tell me what events you want me to handle, and I can do it.

Aaron Jensen

[GitPS]

Hopefully I manipulated those GameEvents correctly.

[GitPS]

@ajjensen13, is it safe to assume that this can be removed: https://github.com/GitPS/PiCasino/blob/Sprint-1/src/com/piindustries/picasino/blackjack/server/ServerGameState.java#L86

I believe I am handling it properly here: https://github.com/GitPS/PiCasino/blob/Sprint-1/src/com/piindustries/picasino/PiCasino.java#L74

Should the ClientGameState also work this way?

[ghost]

In theory, yes.