In the current Beam app contains mode for the Splash screen (with a local ai-only game playing), for practice (with a local, user-controllable game playing) and ModePlay - which connects to a network then creates or joins a game, and then plays the game.
In practice it turns out that connecting to the network and joining/playing a network game are 2 separate tasks - in the sense that:
They don't share the same scope. It makes perfect sense to, say, connect to the net, join/play/leave a game, then another game, then to disconnect from the net. Under the current model a user after playing a game must disconnect from the net in order to play another game, at which point she probably reconnects to the exact same network before joining a new game. That's dumb.
There are user-level decisions to be made between the 2 modes. On joining a network it is perfectly reasonable to suggest that a user should be able to see what's going on in the net before proceeding. Not the games you were looking for? Terrible performance?
Basically the act of selecting and joining a network should happen separately from selecting and joining a game and it should present different information and choices.
Ok. Too much typing. Here's what should happen:
ModePlay goes away
Add ModeNetConnect - Create the selected network connection and then idles, displaying information about the connection, and waiting from the frontend to tell it to either disconnect and leave or to start a game.
Add ModeNetPlay - the bulk of the current ModePlay goes here. Game creation or selection and joining happens here, as does play. On leaving the player returns to ModeNetConnect
Current question is whether ModeNetConnect should push() to ModeNetPlay, or switch(). Since ModeNetConnect doesn't own any of the network resources, I think using the push/pop stack is probably just unnecessary added structure.
jimkberry
commented
2 years ago
In the current Beam app contains mode for the Splash screen (with a local ai-only game playing), for practice (with a local, user-controllable game playing) and ModePlay - which connects to a network then creates or joins a game, and then plays the game.
In practice it turns out that connecting to the network and joining/playing a network game are 2 separate tasks - in the sense that:
They don't share the same scope. It makes perfect sense to, say, connect to the net, join/play/leave a game, then another game, then to disconnect from the net. Under the current model a user after playing a game must disconnect from the net in order to play another game, at which point she probably reconnects to the exact same network before joining a new game. That's dumb.
There are user-level decisions to be made between the 2 modes. On joining a network it is perfectly reasonable to suggest that a user should be able to see what's going on in the net before proceeding. Not the games you were looking for? Terrible performance?
Basically the act of selecting and joining a network should happen separately from selecting and joining a game and it should present different information and choices.
Ok. Too much typing. Here's what should happen:
Current question is whether ModeNetConnect should
push()to ModeNetPlay, orswitch(). Since ModeNetConnect doesn't own any of the network resources, I think using the push/pop stack is probably just unnecessary added structure.