So, basically, Setup and Loop form a coding mullet?! / Question on Randomness

[Meeko]

While I finally have an arrival date for my dev kit, on Monday, I’m still trying to get my head around the unique and unforeseen challenges that Blinks pose, that are not immediately obvious.

In a video (The Aw Shux / Doorscape game video on Youtube) Dan King, in the opening minutes explains that “Each Blink is Independent”. I feel like I am starting to grasp that.

One blink knows it’s game, and can teach that “Game” to all other blinks. Rather, one blink knows it’s program, and can teach only those lines of programing to all other blinks, no more, no less.

Almost as if Setup holds the strategy, and Loop holds the tactics.

Setup and Loop form a coding Mullet. Business in the front, party in the back. Beyond this, this arrangement forces the issue on “Top-down programing” to indeed be Top-Down.

But seriously.

Say I put a line of code in Loop that wants a blink to make a random number [This assumes the additional line for “Randomize” to counter using the same seed is in place] The execution of that code will [barring any conditional otherwise] execute once, per blink, … Uniquely.

Each blink that encounters ““Make A Random Number”” in Loop will make it’s own random number and not the Same instance of the same number. It is very likely, and I’d think probable [given what we use those numbers for] that duplication will occur, out of coincidence and not influence.

Pretty much all lines of code, within loop are going to be executed by a blink on their own and coincidence over influence holds here as well.

Everything under the sun that one blink would like to know about, or tell to another blink, has to be sent*, that can only be done, at relative effort, compared to items generated internally, or preordained in setup. The information given or gained here, then can only be used / fed to the instructions that reside in “loop”. Some of these items while “fun to have” are ultimately harder than others. Color information** and or sending information to a blink, that while connected, is not an immediate neighbor***.

Is this pretty much the case?

*Sent as a value of 0-63 which is a finite, and I can only assume these values probably get assigned in multiples, that 63 feels like a lot, but once under the hood, get allocated immediately, for everything.

**At a premium of bits / bytes that ultimately make it prohibitive.

*** I can imagine that, this is it’s own can of worms too. Are some multiple number N of additional bits and bytes required for each N number of blinks that ultimately send, but do not “use” that information directly, themselves? … Basically, does each Blink charge a toll for information that passes through?

[jbobrow]

I love the coding mullet analogy, although I might give it a bit of a hair cut

Everything in your code will be transmitted to all Blinks, so every Blink is running exactly the same setup and loop. Global variables (outside of these loops and often defined at the top) are much like setup, in that they get executed just once.

You are 100% correct that randomize() being called in setup() will gather some entropy from the individual Blink itself, and therefore provide a random seed that is 99.9999999% likely to be unique (honestly, I have a feeling the real percentage is even higher).

At that point, Blinks are off to the races executing the same lines of code in loop over and over again, their clocks are not in sync, so if you ask a Blink to blink every 2 seconds, you can be certain that the cluster of Blinks will be blinking out of sync within ~ 20 seconds or so… unless you use a handy sync clocks algorithm (inspired by fireflies & metronomes), which you can literally copy and paste.

I like to separate my applications into 3 phases:

1. Update
2. Display
3. Communication

Update
In this way, I will create an update loop for each of my different game states and can update any of the variables that affect gameplay here. This might be from internal factors such as button presses or time, or it can be from influence of my direct neighbors, which I have received at the beginning of my loop.

Display
Here I will use the information from the game state to draw to our 6-segment display. I like to clear my buffer each loop setColor(OFF) and then make dynamic animations that often update over time. This allows me to know I am drawing the latest state each frame, rather than simply drawing over what was previously drawn.

For example if I call setColor(BLUE) on one frame and then call setColorOnFace(GREEN,3) in the next frame, the display on my second frame will have 5 Blue segments and one Green segment. Note, I like to think of each loop as a frame from the display’s perspective.

Communication
We should have decided on what we need to communicate to others in our update loop(s) and now we can in a single place, cleanly decide how to share that information, broadcasting it or sending each message in the direction intended.

Of course this is only one way to program Blinks and many examples and games that we have made break these rules. I think that constant broadcasting for communication is a slightly easier model to understand, but sending nicely packaged datagrams is also a great way to pass information from Blink to Blink. Some of my favorite games have only needed a couple of states to communicate to their neighbors such as Fracture, Group Therapy, or Berry.

I think there is more to respond to from your post, but wanted to give a headstart

[Meeko]

Thanks. I got an update from USPS, that my dev kit is actually arriving today, and will probably be waiting for me when I get home.

Not sure if more stoked or eager.

But, in any event, I think I’m definitely at a point to dive in and see if I can do more than tread water.

I have an idea. And as far as theoretical concepts go, all stages and phases are there, its just learning how to code all of it expediently. Thankfully, I know that everything I need to be coded, is actually present in published games. It’s just a matter of finally doing it.