So I was also thinking about the accidental click situation. I think a quick solution (for testing, but probably not permanently) is to change the “buttonSingleClicked()” to “buttonDoubleClicked()” so that it happens way less. That way you can test without worrying, then change back later when you’re more confident about the other rules.
Glad to see the technical issues worked out!
Awesome! We’ll test that out, play around with gameplay, and report back. Thanks again!
Just a quick update—we’ve been having a lot of fun as we formalize the rules for this. We’ve tested with both two-player and three-player, and especially with the paint spreading mechanic that Jon added, it’s shaping up to be a really challenging and exciting strategy game. 3-players with 12 tiles worked amazingly well.
I’ll work up a more formal document that outlines the rules more specifically, but if you all want to give it a shot:
We’re planning to spend some time working on a “win state” that shows the winning color on all the tiles, but otherwise we’re really happy with where we are in design. It’s worked out a lot better than we had anticipated, even, and are really grateful for your help and input!
Edit: I want to mention that the chaotic free-for-all gameplay we mentioned before is also quite fun—just trying to paint as many tiles as possible without any real turn structure—but we think that folks might naturally try that gameplay without looking at the rules anyway. So our inclination is to let folks discover that as their own possibility for gameplay. The formalized ruleset feels a lot more purposeful, with a lot of depth of strategy and opportunity for mastery.
Hi Carol!
Great write up, I’m curious to hear how your play testing goes, we’ve had a great time playing some games following these rules and I have a couple of notes from my experience.
Looking forward to playing more soon.
Hey everyone,
I just made some updates in the repo. If you pull the “paintSpreads” branch, you’ll get all these fantastic new features:
You might also notice that the graphics have been slightly adjusted. Blank canvas Blinks have a dim glow instead of no display. Carol and Mary, I know you were going to reconsider the colors, so we’d also like to know what you’d like to use for the blank canvas display.
Have fun!
@danking222 We really like the gentle indigo of the blank canvas display, actually. We’ve been playing with your current build and are really happy with it.
We’re working on finalizing paintbrush colors and game art today! What do y’all think of this direction?
As far as stalemate rules — we’re thinking of implementing a “the game is over if the same piece has been moved four or more times in a row” rule, and the player with the most paintbrushes at that point wins. We hope it’s not too fiddly, but that’s the best way we can think to avoid infinite bickering over the last blink, while still offering a chance to capture it.
We played with the idea of not being able to move a piece that was just moved by the previous player, but in a two-player game, it actually corners players in a not-fun way.
I think this direction is really beautiful. My two small bits of input for the label itself would be:
Really like this style and feel like it would be perfect for a Game Mat as well!
Here’s a revision. I think it works well with those changes, plus a bit more detail/texture to the type.
The paint texture is a public domain stock image, so depending on the scale of the game mat, we could use it for the background of the play space!
Oooh, just realized that a canvas with paint on it should have to be reset to blank canvas before being able to single click to paintbrush
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!
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.
@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.
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.
