project
https://editor.p5js.org/dkitp/full/Y5UDdEgib
We made a game! A game that is (spoiler!!) almost certainly unwinnable, but very delightful to struggle through all the same. :)
One of the biggest joys this week was some informal playtests from just hanging out on the floor and chatting about what everyone was working on this week — watching people’s reactions as they figured it out (and watching their expectations shift in real time!) was really delightful!
Team: B Wu, Devan Wardrop-Saxton
process
pair coding
Our original spark was thinking about a button that was unpressable — a button that ran away from the mouse, or had to align in specific ways at specific times to trigger a win condition, or had instructions that were visible/invisible at different times. There’s something that’s just so irresistible about a big red button, and it felt like a really fun jumping off point to explore.
The central idea still felt juicy though, and there was something fun and Frogger-y about having to wade into computer processes already at work. (Another helpful touchstone was the adorable and convoluted puzzle game BABA IS YOU). And if we can get one version of it to work, why not two? Why not three?
- We started with the rectangles exercise from class/the worksheet! Once we’d talked through where we were headed, B coded out our first “button,” the circle, and I took coding out the rest!
- Coding the triangle once we had the behavior down for the other two shapes was much trickier — circles and squares are inherently equilateral, and swapping their arguments out for variables when we needed to implement changes over time was pretty straightforward. The triangle much less so, since we had to update each coordinate of each point individually to get the interactions we wanted (and update each one in different ways to keep it equilateral). We talked about potentially altering the shape, but it was so cool to have three different shapes with the three max RGB values, and I’m glad we stuck with our initial idea.
- Because of how the mini browser window interprets mouseX, we’re pretty sure you can’t actually get all three win conditions (mousing off the canvas “below” 0 or “above” 400 doesn’t stop the movement on the left and right object courts — so your only option to stop those objects would be to mouse back onto the center court, thus starting the circle’s motion again).
- One of the most useful things this week was just so much practice on how to debug well! Definitely starting to internalize where and how to look when only some of what I intended to make happen is visibly happening.
- At one point I had gotten the triangle “landing pad” coordinates set up to change, but they weren’t drawing any differently. In console.log it was clear that the code was working, there was just a disconnect somewhere along the line. We rearranged some parts of the code and ta da!
- Figuring out how to get an equilateral triangle to change size while still being in proportion was also tricky, since the Xs and Ys of the triangle needed to change at different rates — we broke out the trigonometry, only to then realize that the ratio was just a clean 2:1 (which we could have grabbed from the numbers no problem without any algebra). But it was really useful to exercise that muscle and understand how to calculate cos for future triangles that aren’t as regular as this one.
The closest I’ve gotten to winning so far! Probably the closest anyone will get to winning!
worksheet
Really starting to understand the math & relationships at work is so satisfying! #2 on the worksheet (mouse over + the rectangle appears, mouse back + it disappears) this week had me stumped though!
- Even after reviewing my classmates’ code for the problem, I still couldn’t make the logic make sense if I wanted the rest of the sketch to stay functional.
- I searched for other sketch examples online for inspiration, and found this conditional switch project useful for confirming my understanding of the logic was on track: https://editor.p5js.org/re7l/sketches/28wsGI24p. But in that sketch the on/off trigger is totally separate from any other function, which wasn’t ultimately that helpful for our interdependent little rectangle ecosystem.
- The furthest I got was a kind of Schrödinger’s rectangle that flickers endlessly back and forth as long as mouseX is ≤ 200. It kind of does what the question is asking for: when you mouse away, whatever state it’s in at that moment will be preserved until you mouse back. But as long as mouseX ≤ 200, it’ll just run the logic over and over again since right now the code is saying, be unstable as long as mouseX is there!🤣