Here is a video of @danking222’s first version on the Master Branch and here is a video of the paintSpreads version. Here is a video of @jbobrow’s paintAnimation. We loved the animations but it was also inconsistent even after resetting all the blinks back to canvas. Going to try switching out all of the batteries and see if that makes a difference.
Changed all the batteries still running into the same issues. The original blink is able to be consistently painted on by any other blink turned into a paintbrush. All other blinks only display yellow on a single face per blink, we’ve inconsistently gotten two adjoining faces to turn yellow, when in canvas mode. Occasionally the yellow faces will light up even when touched by another canvas. This is similar to the problems I ran into with my original prototyping where the original blink would react as predicted but wouldn’t communicate with adjoining blinks.
Thanks for the videos, they are infinitely helpful! To be sure that all Blinks are on the shipping BIOS (since you received pre-release Blinks), can you do the following steps:
- Make sure you are using the latest release of the Blink SDK
- Program each Blink you have to the games from the Examples folder
- Load PaintBrush onto a single Blink and then let it propagate to all Blink
@marymck Oooh, before you reprogram all 12, simply update your Blink SDK to the Gold Master that shipped w/ Blinks or pull the latest on GitHub (this is the best way going forward). @danking222 and I think that the Blink you are programming is being programmed with an older version of the SDK that works differently.
Making sure that all of your Blinks are programmed using the GM SDK should make things silky smooth (or at least the same as what we are seeing on ours
Ah! Ok, that solved it—thanks for bearing with us. We were able to play with all 12 Blinks and it was chaotic and hilarious. We love it! The only issue was accidentally clicking a Blink mid-game and changing the color of the paintbrush, which made us have to backtrack a bunch.
There ~could~ be something interesting there with randomly-changing brush colors if we want to encourage chaos, but we may want to constrain the amount of time players have to set the paintbrush color.
I think it’s also going to be fun deciding whether we want to go with chaotic free-for-all gameplay, or if we want to establish turn-based rules for painting. I think either method could be super fun.
Thanks again for helping us figure this out!
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:
- Clear all tiles to start, and group them into a contiguous shape.
- Each player takes one tile, and clicks it until they have the color paintbrush they want
- The first turn, place your paintbrush anywhere against the shape.
- After the initial paintbrushes have been placed, continue taking turns, moving one tile at a time to anywhere else on the board, trying to create paintbrushes in your color.
- You CANNOT move a tile that would separate the shape—the shape cannot be split up into multiple pieces. (I think we should have a diagram to demonstrate this)
- The game is over when all the tiles have become paintbrushes.
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.
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.
- Game play with moving only one piece can be fantastically long. I thought I really wanted fracture mechanics initially, but I am convinced that being able to think through the move of a single piece reads so much clearer.
- I’m a little concerned that some gameplay becomes never-ending in a 2 player mode, so we started experimenting with different end goals. Haven’t found a great one yet, but thought the goal of having 3 or 4 paintbrushes with 12 starting Blinks is pretty tough when playing competitively.
Looking forward to playing more soon.
I just made some updates in the repo. If you pull the “paintSpreads” branch, you’ll get all these fantastic new features:
- Install is now totally clean, no need to reset each Blink to blank canvas
- Triple-click will wipe the entire field to blank canvas
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.
Figured I’d put this here as well for game art resources Creating Blinks Game Art
@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:
- Try splitting Paintbrush to 2 lines to allow it to be larger
- Flip the color so that the Blinks tag has higher contrast
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.