Hey all! I haven’t posted before, but I’m a Move38 collaborator working on some Blinks game designs along with design partner Mary McKenzie ( @marymck ). Thought I’d share our design motivations and progress here for all to see.
Our core design goal is to develop simple gameplay that requires very little instruction. We’re aiming to identify the ways that people might naturally try to interact with Blinks, and create an interesting/beautiful game experience that requires minimal instruction, and could even easily be discovered through experimentation. Below are outlines of the two game concepts we’ve come up with to try to address some of these goals!
Paintbrush
6+ blinks
The blinks start out all blank, except for two fully-colored “paintbrush” blinks. (The number of players can expand well beyond two, but we figured we’d start small for prototyping!)
When the sides of those “paintbrush” blinks touch a blank or partially-colored blink, it paints that edge the color of the “paintbrush” blink
Once a blink is fully painted one single color, it becomes a “paintbrush” and can now be used to paint partially-painted or blank blinks.
Winning: Once all the blinks have been converted to paintbrushes, the game is over and whichever color has the most blinks takes over all the colors, indicating the winning color. If it’s a tie, the blinks all show up half & half colors.
Rainbow Ring
6+ blinks (must be configured into a ring shape; all blinks must be touching ONLY two blinks, or else the game resets)
The blinks display a meditative cyclical animation, starting on red. We envision this as each blink shining bright and fading to dim in a cycle. This animation plays for a random length of time, between 5-20 seconds.
At some point between 5-20 seconds, two non-touching blinks change to the next color in the rainbow spectrum (for example, during the first level—red—the pair would display orange), and they must be moved to touch each other within the ring within 3 seconds (set to change pending playtests!). If done in time, the entire ring begins an orange cycle animation. If not, the ring remains red and the cycle restarts.
This goes through 6 colors of the rainbow spectrum (Red, Orange, Yellow, Green, Blue, Violet).
If a blink is detached early (before the matching pair appears), the cycle resets to red / the game restarts.
Winning: Once the game progresses through to violet (or perhaps from violet back to red), the blinks flash rainbow colors to signify win state.
While it’s a lot less likely that folks will be able to just figure out the gameplay of Rainbow Ring based on experimentation, we still think it can be successful, simple gameplay. The experiential goal of Rainbow Ring is to inspire a meditative flow state punctuated by quick reactions, similar to how “Super Hexagon” gets you into something of a trance/reactive state during gameplay. We can increase the difficulty and reaction speed by increasing the cycle animation speed and decreasing the time allowed to match pairs as you progress through levels.
Curious to hear your feedback! We’re really excited to start prototyping playable versions of these design concepts.
So I whipped up a working but unsophisticated version of the game. You can check it out here:
I would say read the code if you want to know how to interact with it, but actually, I think it’s a better experience if you just install it blindly and then mess around with it.
I branched and added a mechanic that I believe makes the game a little less intuitive, but feels more strategic, I’ll describe the quick modification here:
Paint brushes paint over painted sides or blank canvas sides
Painted sides smear paint only onto blank canvas sides
With this small addition, the paint spread much more quickly, since you can spread your paint from pieces you have only partially painted. The game feels a lot like checkers in that there are painted sides that can advance, and that there are “kings” or paintbrushes that are more powerful pieces.
There are lots of ways to make the painting process more legible, but once again, this branch is a quick pass at the mechanic. Note: the game loads in a weird way and requires manually resetting each piece to canvas. Paint Spread Mechanic
Additionally, i took a quick pass at adding a little brush animation (not transition for painting, but just something to call out the special pieces in a painterly way) Brush Animation
The act of fracturing in this game becomes really important when painted sides spread, and it is fascinating to see how the paintbrushes secure certain areas. I think having a delay in the process of painting will help the act of painting read well, but not so important for understanding the best mechanics.
Awesome, we’re excited to check this out! Thank you!
We got a chance to play a bit with Dan’s last commit yesterday, but were running into an inconsistency where the only Blink that was able to be painted onto (even in canvas mode) was the original tile with the software on it. We tried troubleshooting a bit but were struggling to figure out why this was happening. We’ll check out your updated commits soon—it’s super exciting to see this come together so quickly!
That’s… odd. I haven’t been experiencing that. What exactly is your setup? 12 commercial Blinks and one dev Blink? Also, is there any way you could shoot a little video of it happening?
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:
@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.
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.
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.
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.
@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.
