Detecting a victory condition across multiple Blinks


#1

While playing Fracture, I wondered if it would be possible to detect an “end of game” / victory condition across all connected Blinks.

One possible strategy would be for Blinks to transmit a “not done” status message every second or so, maybe with a hop count attached.

When a Blink has not received a “not done” message for longer than the transmit interval, it can switch to an “end of game” state.

A challenge would be relaying the “not done” message to other non-contiguous Blinks. It might be possible to do this by having every Blink that receives a “not done” retransmit it, on every side except the one that it received it on. Would need to ensure that loops don’t occur. Perhaps by serializing “not done” messages and making sure that a message that has already been relayed is not relayed again by the same Blink?

If each Blink had a unique ID this might be easier. “Not done” messages could be tagged with their sender and maybe a hop/retransmit count.

This seems like a generalizable situation, ensuring that all nodes share the same state.

Any thoughts?


#2

I think this is basically a question of whether showing victory/end-game should be in the API code, versus in each game sketch. Currently I believe it’s up to each individual game to handle both victory conditions as well as the inevitable “restarting” of the game after game over. (The latter is being discussed over here: https://github.com/Move38/Move38-Arduino-Platform/issues/45)

It sounds to me like you are advocating for the API handling showing the end-game state. I can see pluses and minuses to this approach. (I’m currently writing some “end of game” code myself.)

Pluses:

  • Usability would probably really benefit from some conventions. Showing the game is over consistently is one of them.
  • The more code that moves into the API the easier it will be to write for external developers (like myself).
  • Similar to usability conventions benefiting the users, coding conventions will benefit developers.
  • There is already precedent for this kind of “API level” state change, what with 6+ second presses turning the blinks into programming/sharing mode, and longer presses putting the blinks to sleep.

Minuses:

  • Some games might not have a “game is over” state (or will want to show the game is over in a unique way).
  • The more special cases like this exist, the more important the developers understanding what these conventions are, because we will have to program to them. Basically, documentation becomes harder (and more important).

Before writing these down, I was leaning toward sketch/developer-code having this responsibility, but now that I’ve made the list, it does seem like there are significant advantages to the API handling it.