Oct 17, 2022
My partner Anna and I wanted to make a game, and it was Halloween-themed. We took inspiration from the pie face challenge and decided to make a racing game.
Regarding the format of the game, we wanted the game to have an interface just like an arcade and also for the player to interact with the physical space during the game.
sketch
So we plan to have FOUR buttons available to two players. One player will only have the move-up and left buttons and the other player will only have the move-up and right buttons.
The two buttons would be distributed at opposite ends of a distance, and both players would bounce back and forth to press the button to move their character quickly across the interface to the end within the distance. Each button can only be pressed once at a time, and that’s the rule. So it’s all about the speed of the two players.
The winner who reaches the finish line first will trigger a spider web to fall over the other player’s head as a punishment for the loser.
For this idea, we faced TWO difficulties. The first was the serial communication between the Arduino and the p5js, and the second was about the design of the spider web, as it needed to be light enough and big enough.
For the fabrication, Tom recommended we find inspiration from a pit trap. We discovered the Drop Net Kit System video on the internet thanks to Tom’s suggestion, and we believed we could apply this approach to construct a spider web.
We found a sheet of fabric on the floor, and after several tests, we chose to use magnetic tape to attach the web to the ceiling pipe. Anna used a 3D printer to make a big button. The button base is nice, but the lid is not very satisfactory. We need to make more attempts at it.
For the code: we couldn’t figure out how to build one press for one step at first since the Arduino readout is continuous and the control object on the p5js continues to go along with each reading. Therefore, I adjusted the game’s rules 😂 so that the player not only needs to reach the destination quickly but also avoids obstacles. I established a time threshold for entering an obstacle, and if the player does not avoid it in time, the game ends when the time to touch the obstacle exceeds the threshold. The game might then result in two losers and no winner, or with one winner and one loser. However, although modifying the game’s rules solved the input problem, we still had issues with the output. The first version of the game was suspended.
It was then that, thanks to Yonata’s assistance with our code, he provided me insights on how to construct one press for one step, allowing me to fix the initial problem and return the game rules to their original state. As a result, in the second version, the majority of the logic is coded in Arduino, which is simpler to operate and understand than the previous version, in which the majority of the logic was coded in p5js, and even the output problem was fixed.
However, there are always twists and turns！😮💨 The page lag becomes so severe after completing the serial input and output that the game cannot be played at all. The game progresses smoothly if one player’s output is commented on (I tried here initially by lighting the LED instead of the departure motor) and just one output is retained.
The great news is that after attending Tom’s office hours, both versions’ problems were resolved. Thank you again, Tom, for your assistance! 👏👏
The difficulty with not being able to get the Arduino to receive the p5 instructions in the first version was due to the misinterpretation of the code.
First, controlling the flow of asynchronous serial communication via handshaking does not necessitate control of all communications; rather, it could be managed independently for the specific logic settings. In my code, for example, when the LED must be turned on only under particular conditions, serial.available()>0 can be used to confine only this part of the whole logic. Second, when I manually enter a value as transmission data, I don’t have to convert the byte to ASCII. Giving the value manually is different from inputting the data on the keyboard.
Most of the logic of this version was coded in p5js. (for testing, just one player’s part)
. 
. The problem with the second version is still a coding issue. Tom suggests I add some delay after each if statement, as the extremely laggy response, may be caused by the numerous loops. But it didn’t work. Then Tom gave me another train of thought, reorganizing the code with an array to decrease the number of repeating loops. And it works! The code is much cleaner, too! The page no longer becomes stuck!
Most of the logic of this version was coded in Arduino.
BEFORE 
AFTER
So we have two versions of the game. After discussing with Anna, we decided to use the second version since the game was more straightforward, allowing players to focus on speed. The first version demanded that the player not only be swift but also avoid obstacles, so the game became more difficult.
♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠♠
Oct 25, 2022
After we finished the code part last week, we are focusing on the fabrication this week. Anna spent lots of energy on the 3D printing button since we wanted it to be similar to the arcade button. She also made an excellent base for fixing the two servos and found the best solution for the falling web. The fabrication details can be found on Anna’s Blog.
Anna makes the pretty stand for the servos.
3D printing buttons (base) and lots of soldering work.
And the schematic diagram.
I continue to work on the p5js to give a better visualization for the game, using Illustrator to draw the Halloween theme background. And add some sound to give the game a start and end, making it more organized.
And then we step into the user testing stage. We invited several ITP mates to join the game, and luckily most stuff is going well. But we still have some parts that should be adjusted.
- we need to take care of the long wires and organize it.
- The distance of the racing area should be adjusted since the web should cover the people when it falls.
- The button needs to be fixed because some participants will hit it hard, so the button will be pushed farther, and the distance will be longer, which will be unfair. On the other hand, it’s a tricky spot for a game, and it’s fun if not to fix it. But anyway, we don’t want to complicate the racing game.
- We also find the best way to connect the rope of the web and servo, we need to find the right Angle. It should be able to either pull on the rope when the servo is still or quickly release it when the servo starts rotating.
The testing process is quite interesting and testees said the game makes space to be the ITP’s sports room. 😂
1st Testing Group. Running back and forth 😄, for some technical reason, the first round hasn’t triggered the web to fall.
2ed Testing Group. It’s hard to play the game without screaming！
3rd Testing Group. It’s a sports game, so tried cause it’s the third time for us to test it.
The first and also the last Testing Group, after we set it all up for the class show. Everything goes well, and the web looks much better after we stick the spider! (Oh, I have to hate the spider, it took me 1 hour to bend it and stick it 😭)
The show in class: