New Game: Nothing

Oh wow!

If that’s the case, I don’t really know why the game starts on dead :thinking:

But after that and waiting 10 seconds, it works?

Yeah it works perfectly fine otherwise. It’s a minor bug but I can’t really see why it’s happening :neutral_face:

New version 1.1 implemented with code consolidations and a small implementation change with how blinks search for connections. Thanks @jrcwest and @Confus3d for the awesome ideas and feedback!

1 Like

Not sure what you changed but the “start on death state” seems to be gone now! Unfotunately though the didValueOnFaceChange didn’t quite work the way we expected it to… Tiles that are connected just keep returning going back and forth between the death state and alive state. I’ve got to step away from the computer for a bit but I’ll take a look at this some more later in the day!

Thanks for taking a look Jonathan! I’m guessing it is because the communications sends out the current blink state, so when blinks are changing state it is also changing their faces. Making the blinks communicate out a constant face value should hopefully fix this issue I would imagine! I just pushed out a fix now so that you can test it later!

2 Likes

Thanks @jbobrow for the thorough and detailed response about the blinks sleep functionality! I’m hoping that for the scope of the games outlined in “Nothing”, 10 minutes should be plenty of time to setup and complete the games. Maybe I can add some sort of instruction telling people to either click each blink or combine and click one blink to reset the sleep countdown between games. I don’t know much about the wake up process since I dont have my physical blinks yet, but I also don’t think it will be too burdensome to complete if needed. Will a blink wake up playing the last game it was before going to sleep? I definitely agree 1000% that the priority should be on protecting battery life on the blinks. We’ve all had those moments where we’ve accidentally left the power on on a battery operated device and then having your heart sink the next time you go to turn it on. Thanks again for the info, and if you have a chance to play any of the games let me know what you think!

Hey @TheGoodSire! We got a little free time to try out your games, here’s our feedback for each one. We played with Version 1.0, since we’re still trying to work out the kinks in the face-change method of connection detecting.

  1. Firing squad - This was probably our favorite of the bunch, the only issue I think we had was with the fact we were playing with only 2 (obviously) - we were having some trouble with blinks going off the table without another player to catch them. Could definitely see this being a ton of fun with 3+ players though!

  2. Ninja - Good twist on an old favorite :slight_smile: Had a great time playing this while sitting at the table. No real complaints here!

  3. Minefield - This was another favorite, though we had to impose some of our own rules onto it. We only had 6 blinks, so using the whole table was a bit slow. We ended up using a dinner placemat to confine the space where the mines would sit and had a lot more fun with “close calls”. A full table would probably work way better with 12+ blinks. We also tried a variation where the blind player would continuously make presses, keeping count until they hit a mine, then players would swap roles. Rounds then became “who could make the most shots without dying”.

  4. Dodge Ball - This one was a lot of chaotic fun, though rules were a bit hard to enforce, particularly avoiding crossing a line. We may have had an easier time if we had used some tape or something on the table.

  5. Blink Blitz - This is a great idea, but something we realized is that when the blinks are kept separate you have a greater risk of accidentally bumping one into another, and less risk of actually pressing a button. We also found that, if the newer connection method was established, you could do more shapes than just “y” - shapes that have alternating empty spaces in general work well (our favorite was a zig-zagging line with 6 blinks).

Overall the game concepts behind the simplicity of “Nothing” are pretty awesome. The only thing that I think might be problematic is games that are based on “accidental button presses”. You have to really hit the blink dead-center to get the button to actually trigger. While playing we just kind of used the honor system and acknowledged when we hit the surface of a blink, even if the death state didn’t trigger. Thats not a problem per-say, but it just made me realize that the actual button press detection and animation was getting used as much as I would have anticipated.

1 Like

Thanks for the fantastic feedback @jrcwest! To start, I just uploaded a new version of “Nothing” v1.3 which further consolidates the code and hopefully finally fixes the kinks in the didValueOnFaceChange method. Let me know if this change works!

  1. Firing squad was the first game that came to mind when I was brainstorming games for “Nothing”. I’m glad that the mechanics seem to work well for the most part. I can definitely see how loosing blanks off the edge of the table could be a problem though with smaller numbers of players. I do agree that this becomes less of an issue with the more players that you have since people can catch blinks and stop them from falling off the table. One less elegant solution that I had thought of was to use rolled up towels, blankets or other objects to line the edge of the table to create an arena and stop blinks from going off of the table. This sort of setup could also be used for Dodge Ball.

  2. Ninja was one of my absolute favorite recess games growing up, so I’m glad to hear that a Blinks version has merit.

  3. I think that your variants for Minefield are pretty excellent! Having the blind player continually make presses and keep track of safe moves will definitely smooth out game play. While it’s hard to say without playing it, I think that I’ll probably prefer this version enough to make it the default going forward. Also, adapting the game play area based on the number of blinks playing seems like an absolute necessity. Perhaps I can come up with an adjustable play space scale based on the number of blinks in play starting at the size of a table cloth and moving up towards the full table. Something like 0-9 Blinks tablecloth sized area, 9-15 blinks 2 tablecloth sized area, 16+ blinks whole table.

  4. I can see how the rules on the game would be a little harder to enforce. You idea about utilizing tape or putting something on the table to mark the middle line seems like it could work well.

  5. I think that this game will definitely need to rely on the newer connection method with the didValueOnFaceChange function.This will definitely open up a wide variety of shapes and arrangements that could work well including the Y and Zig-Zag shapes.

The info about button press sensitivity is definitely very useful! I guess it makes sense that the blinks themselves are probably pretty resistant to accidental button presses since the Move38 team probably worked very hard to design them that way to improve standard game play. I’ll be sure to keep this in mind when writing rules for “Nothing” and when adding any new games, or cameos.

Thanks again for all of your help @jrcwest! That kind of detailed feedback really is phenomenal!

Glad to be of help! I’ll give 1.3 a try later today and record it. Hopefully it will help you debug any issues you may be running into :slight_smile:

2 Likes

Hey @TheGoodSire, I haven’t looked at the code yet, but here’s a recording of me play testing version 1.3. It seems a little hit and miss if tiles get triggered based on connection. Have you by any chance looked at the didValueRecievedOnFaceExpire method for this? Might be useful for triggering the death state wherever a blink is disconnected.

https://youtu.be/9BJo04SqL64

EDIT: A potential issue with my suggestion is that already empty faces may return true with the faceExpire method… may need to check if the last value on the face was “ALIVE” AND if it expired.

1 Like

Hey @jrcwest is really nice to see how you’re trying to help people recording this short videos for people like us that doesn’t have Blinks yet!

@TheGoodSire if your intention is trigger dead state if something is connected. You can try making a variable like “number of neighbours”, foreachface, and ++. I think you can do the same that we did for detecting TH.

2 Likes

Thanks @jrcwest for the clear gameplay video! A picture is really worth a thousand words and a video is even better! Does the functionality in v1.3 work as intended in 1 on 1 connections like are needed for the existing “nothing” games?

@Confus3d You are correct that the intention is to have dead state trigger when new blinks are connected to a grouping, but also we would like them to trigger when blinks are removed from a grouping. Granted none of this functionality is needed for any of the base games outlined in “Nothing”, but we thought that these mechanics could allow for some interesting new games to be created going forward. I think that you are definitely on to something with the neighbor counting idea! If you can keep track of current neighbor count it should be easy enough to track if there is a change in neighbor count with the use of a secondary temp variable kind of like how the score counter works in “The Dragon’s Lair”.

@Confus3d Thats one way of doing it. I had suggested that you have the ability to arrange the tiles however you want during “dead states”, and then when they all come back to life, any changes (new connections, disconnections, button presses) would trigger the dead state again. With that in mind, I would think that you could get away with a single FOREACH_FACE that includes a check like:

# Check if new connection or if broken connection    
if (didValueOnFaceChange(f) || (getLastValueReceivedOnFace(f) == ALIVE && isValueReceivedOnFaceExpired(f)))

Though that might not be the right way to go… I can maybe test that out on my own fork maybe later tonight or tomorrow morning.

1 Like

@jrcwest It seems like your implementation idea should work as well! It’s also a bit more concise which is nice! Definitely give it a shot and let us know if it produces the desired results. Thanks again for the play testing help!

No problem! One other thought I had, if you had an entire cluster and implemented a check like the one I mentioned, would you want the entire cluster to go into the dead state? Or maybe just the ones that detect the new/broken connection?

1 Like

Now that I think about it you would probably just want dead states on the blinks with new/broken connections. It should still be very easily visible to see that the death state is triggered and it allows for greater flexibility since new connections or removals could still be made from blinks on the other side of the grouping since they won’t be locked in the death state.

Just as a heads up, I had changed the set value on face function to be a static value of 1. I think to implement your change you will have to change it back to be set as the game state.

1 Like

Hello again @jrcwest! Since it sounds like you were going to take a stab at implementing your proposed solution to the new/broken connection issue, I went ahead and implemented a version with the solution proposed by @Confus3d. This new version is listed as Nothing v1.4 in the Github link. I was thinking if you had time, perhaps we could compare and contrast the functionality between the two solutions.

Francisco, was the way I implemented the code in v1.4 similar to what you had envisioned?

In addition to the updated code, I went ahead and created two new games which I think really highlight the new connection identification functionality:

War of Tugs - Start the game by placing all blinks together in one group at the center of the table. All players count down together from 3. Once they get to zero everyone places one finger on the blink pile and pulls to separate as many blinks as they can to add to their pile. Players then take turns setting their own blink piles in the center of the table. Everyone then counts down again from 3 and lunges at the pile to pull away as many blinks as they can with one finger to add to their piles. Lunges must be in one continuous motion and if someone misses they do not get another chance. The player whose stack is in the center starts with their finger on the pile and can try to move it as much as they can to dodge finger lunges at the end of the countdown. A round is over when every player at the table has their turn in the center. Whoever has the most blinks after 3 rounds of play is the winner. If you ever run out of blinks before the end of the game you are eliminated. Rounds always start with the player who has the most current blinks and goes clockwise.

Tractor Pull - The goal of this game is to pull as many blinks as you can across the table without them separating. To start, players can use as many blinks as they want and any configuration that they want to build a “trailer”. After construction, the player grabs a non-trailer blink to use as a tractor. Players grab the tractor with two fingers and connect it to any point on the “trailer” that they want. Players then try to drag the “trailer” from one side of the table to the other. If at any point during the pull any of the blinks separate it is game over. The winner is the player who pulls the “trailer” with the most blinks across the table with none separating. I’m guessing that this game is probably going to require a decent amount of blinks (I’m guessing 15+) to be difficult, but it’s hard to say without being able to get a feel for the strength of the magnetic connection between blinks.

Let me know if anyone gets a chance to test either the new version, or the new games. Thanks again!

@TheGoodSire Yep, just that, pretty clever solution and pretty well executed.

In the way you implemented it, the blink will remember the number of neighbours on the dead state and keep that number for the alive state, watching any changes.

I can’t try it but for me the code looks perfect :wink:

Edit: Sorry, wrong, there is indeed a problem. Before foreachface, you should add numNeighbours = 0 to reset the counter, if you don’t add it, the number will increase every time up to infinite…
Also, line 47 is unnecessary, cause is already on the dead loop, you can delete that.
Also, setValueSentOnAllFaces(1); on line 36, I think is cleaner just to uses setValueSentOnAllFaces(blinkState);
Also, with this implementation, if you load the game on a cluster of blinks, the blinks will load on dead state cause pastNeighbors != numNeighbors will be true, but no big deal with that, cause you have 10 seconds to set up the starting position for the game.

ALSO (is the last also, i promise :upside_down_face:)
I’ve done a fork of the last version, adding the changes mentioned, changed some int to byte AND a cool implement for the first run, so blinks load the first time on ALIVE state on the cluster.
Feel free to compare it with your code and add what you need!

ALSO (I lied!!! :crazy_face:)
For me, Tractor Pull, best idea ever, i LOVE it, cause i love bridge building games, and this is like that, you have to build a strong structure!

1 Like

Hey guys,

I gave the new fixes a try, and unfortunately if the pieces are all connected, they are stuck looping in the dead state from the start. I also gave my suggestion a try and realized it doesn’t work - blinks keep track of the last received face state indefinitely, so at the start it works, but if that face continues to not see the “alive” face, it continues to fail that check and stays dead. I unfortunately dont have as much time this morning as I thought to work with blinks, but I’ll keep trying to think of solutions. If you and @Confus3d want I’ll make another recording later in the day on my lunch break (if I’m able).

Also solid ideas for new games! I’ll give them a try when I get the chance. Though I think war of tugs sounds a bit like how “Fracture” plays? I haven’t been able to play that one yet so I’m not sure.

1 Like