That would probably fix the biggest feedback we’ve gotten in play testing, that it’s too easy to accidentally do a single click while moving a blink and end up creating a paintbrush by accident. Our first thought was to just move it behind a double click but requiring a reset might feel better overall. Also is it possible to constrain the color choices to only 4 colors, specifically hues 40, 60, 100, 220?
We can definitely constrain the color choices, that’s a quick fix.
As for the reset before paintbrush-ing, I can pretty easily implement that as well. My concern about that is that for the most part, a reset Blink basically never stays blank thanks to the paint-smearing effect from neighboring Blinks. Also, and this is something we can address, we do want the Blink to “react” in some way when pressed, even if it’s not a full transition to Paintbrush. For now, though I’ll make a branch with these changes and let you test them out. I’ll ping you when they’re in!
1 Like
Awesome, thank you! Just played thru it and it looks great. Would still like to move the “change to paintbrush” behind a double tap, but like the idea that a single tap should give some feedback. Perhaps a white flash or a single brighter brush spiral animation?
Here’s our drafted rules sheet: https://drive.google.com/open?id=1KOMJ4VyNvolxJxSS3PHsB7sgF-2nv58u — feel free to give any feedback!
We’ve successfully blind playtested these rules a bit, but haven’t tested extensively enough to call them waterproof. We’re hoping to run some more blind playtests soon!
As a side note, we have two blinks with inconsistent communication/loading issues, so we unfortunately aren’t able to playtest four-player mode with the full set of 12.
1 Like
@forum 
If anyone is up and coding tonight or cares to help validate a bug fix. There was a terribly latent bug, very unlikely to happen, but caught on camera issue where the Paintbrush canvas would reset during gameplay accidentally.
The latest update in the repo seems to squash this bug by effectively putting more protection around the possibility of getting a false positive on reset, but having some extra people try it out and make sure we didn’t introduce anything new in the process would be wonderful.
Thanks for any help in the process These games are literally being programmed and assembled right now 
best,
jb
what were the steps to reproduce the issue? I have a beta version of paintbrush that I could test side by side. I’ve seen this issue before while playing a couple times, but you could always wake them up.
@jbobrow actually, one of the times that I saw this happen, the game fell asleep and the player that woke it back up didn’t know about the different clicks and triple clicked the piece and it reset the game. So not really a bug, just something you have to tell the players not to do…or maybe you can check the wake state on that. looks like you check for wakestate for single clicks, but not for anything else.
1 Like
The issue we were seeing was rather obscure. The value for reset could accidentally be sensed when a Blink approaching or departing is sending a value very close to the reset signal. i.e. the act of angling a piece away slowly could up the probability that an incorrect bit was sensed… most games do not have this drastic of a behavior when an incorrect value is sensed, so we don’t see this issue pop up in other games. I have seen it happen in Puzzle101 as well, but very infrequently
ah, ok. I have an older image of Paint Brush and I’m not able to reproduce what you said, yet. It must be pretty hard to have happen, but would still be annoying if it happened in the middle of a long game.
pieces do fall asleep pretty often in a long game of paint brush, though, so I would recommend checking for a wake state during a multiclick. That is easily reproduceable.
1 Like
Interesting, catching the triple click on wake is a little more involved since it doesn’t happen on the first “frame”
Actually as long as my fix (that was merged to Blinklib) is in place, this works as expected without any special handling needed. For example, this program would do what is expected:
void loop() {
if (hasWoken()) {
if (buttonMultiClicked()) {
setColor(RED);
} else if (buttonDoubleClicked()) {
setColor(GREEN);
} else if (buttonSingleClicked()) {
setColor(BLUE);
}
}
}
If you wake the Blink with a single-click, it will turn blue. Double-click will make it green. Triple-click will make it red.
In any case, for games like PaintBrush and others that basically have no required button clicks during gameplay, it would be interesting to allow setting a different sleep timeout (say, 20 minutes instead of 10). Yes, that will waste battery but for a game that has no other way to reset the sleep timer, it is also a requirement (at least if you want to not annoy players in a long game ).
1 Like
FWIIW, I am adding this to my custom blinklib:
// Resets the sleep timer in a similar fashion as when a button is clicked. Must be called at least
// once every 10 minutes to prevent sleeping. Resets both the warm sleep timer and hardware
// sleep timer.
void resetSleepTimer();
The idea is that it will literally do the same as a button press EXCEPT that it will not notify other Blinks (all Blinks would be doing that in a game anyway). If it is not used, it does not change anything so it is free.
1 Like
This has been the point of debate before and I am happy to share where we currently landed. The warm sleep state is designed to make it very easy to wake a game like Fracture or Paintbrush with a single click, but games like Astro or Flic Flop runs the risk of a lone asteroid falling asleep alone.
We want to ensure that the average player has great battery life with their Blinks, so we are pretty aggressive with the sleep, but I believe within reason. In a 40 minute game of Paintbrush, I do need to wake the board a few times.
While you can of course do this (prevent sleep) with a developer kit and your own Blinks, there is a lot of consideration that goes into what can be published. Of course some of these concerns are only relevant with current hardward constraints, so we can also open up this topic as Blinks evolve 
I should also reference this thread:
All fair points but I guess we can agree that if there is a game like Nothing where there might not be any clicks whatsoever, battery life ends up as a secondary worry.
My idea with what I am implementing is not for callers to use it, say, every loop iteration but, instead, they could do it when non button-press actions are detected (for example, in the case of paintbrush it would be whenever a Blink detects a face was connected). If you think about it, that makes perfect sense as that does count as a game action.
Now that I think about it, I may be able to implement this without exposing a new API. Maybe the right way is to simply consider face connected/disconnected events as actual Blink interactions and reset the sleep timer on this case. It would, of course, not solve the problem of a game that is a single Blink where the point is to not do anything, but that actually narrows the problem a lot.
What do you think?
1 Like
I’m not in the weeds like everyone here, but conceptually this get’s a +1 from me.
This is very much inline with my thinking, I think it is worth trying out and I believe it specifically works well in the model of the custom Blink lib if I am not mistaken
Oh, I am already on it.
1 Like
wouldn’t that have to propagate throughout the mesh, though? Even if a new connection was detected between two blinks, the rest of them would still have sleep timers ticking away that once any of them expired, would cause all of them to sleep, correct? I haven’t looked into the library to see if that’s exactly how it works, but if it is we’d need to broadcast a wake message to all the blinks, not just the two.
In my first proposal, no. In my second one, yes.