I saw the question come up a few times asking something along the lines of “how can I have the blinks count how many there are” or some other task that requires all the connected blinks to work together. I do the same in Raid when it crunches the players scores and I wanted to share a condensed example. This demo counts the number of connected blinks. It should be pretty re-usable in this form and maybe could serve as a starting point for someone else.
I threw a bit of a sequence diagram on the readme to show how I visualize it, it gets pretty complicated pretty quick so I kept it to a fairly simple use case with 4 blinks.
that’s super; it really does help. Each time I tried to design this, a blink was sending the same message to each face; but this picture shows very well how the handshake method gets it done. Thank you !
This is really interesting. I’ve been puzzling over how to detect a victory condition across all blinks, and this is part of it, I think.
I was using a message system very similar to yours, to broadcast state when connected, or when state changed.
Then I maintain an array in each Blink holding the known state of all connected Blinks, indexed by their unique serial number. Then each Blink looks at their local array to verify that a victory condition is satisfied. If it is, send a message requesting confirmation from all Blinks, and update the state array to reflect “confirm victory” as a state. Then display the victory animation.
I don’t see a way around maintaining the local copy of the state of all Blinks. Do you?
that sounds really similar to how I maintain what moves are legal in our game. If the player makes a move on one blink, it broadcasts that move to all the blinks and each blink maintains a state of player index to move. With that state locally, they can know what moves are legal if one is made directly on them later. I’m also broadcasting state changes when players tap a blink so that all of the blinks are in the same game state
I’m not sure how you implemented broadcasting but I had to have a unique key to the message (in my case usually the last byte of the time) so that blinks could avoid re-broadcasting the same message or needing to maintain a more complex state (like here with the task). The main issue I hit then was that I needed to be sure two different messages would never be broadcast at once since that could cause things to go a bit nuts.
I mention that because I think it was the main reason I couldn’t solve my score problem with my simple broadcast solution and used this task solution instead. Since, at times, all blinks in my game update their score at simultaneously, it would have been very slow or expensive for me to sync up the shared player score in real time via broadcast.
Side note: you mentioned your using the blink serial to identify each unique blink. I started down that route at one point early on but had to backtrack since the full serial is a whopping 8 bytes. Ended up chewing up a ton of space everywhere I was indexing things specific to a blink. It ended up being the reason I initially wrote the first form of this task solution. Each blink could enumerate its self and self assign a unique index so they only had to broadcast a single byte to identify themselves / store info about one another.
@gapMindful, this is a very cool way of doing it. This looks a lot like the way the blinks download algorithm works. Made me think hard a few times!
You inspired me to have a crack at this interesting problem. I wanted to see if it was possible to do a full tree search that was robust to loops and spontaneous topology changes without needing to use serial numbers (and thus avoiding memory limitations and needing datagrams).
Check out what I came up with…
…and LMK if I missed anything. And thanks again for all the thoughtful work in this area!