Video showcasing the game, with me doing a bad job voicing over my gameplay:

I hit most of the points of what my project is in the video, but I’ll explain it here as well. My project is called “As Easy As Pie”; in it, you make a pie. The game is split into four minigames, which I will refer to as phases: mixing, flattening, preheating, and baking.

In the mixing phase, players must rotate the left joystick in order to mix the dough. At the same time, they must add water by holding the A button. Both gauges must be filled within 60 seconds of starting.  There are three failstates associated with this phase: not mixing enough, not adding enough water, and adding too much water. The first two are determined when the timer runs out, while the last one happens immediately when an internal variable passes a threshold. Going behind the scenes, holding the A button increments this variable by one every 100 milliseconds. The mix has enough water when this value reaches 200; however, 250 is too much water. The game also does not check if the joystick is actually being rotated; it only checks that the position is not the same as the previous check. The game records the magnitude of this difference and uses it for a similar variable for mixing. When the mixing gauge and water gauge are full, the player can then move on to the flattening phase.

In the flattening phase, players must mash the left and right triggers to use the rolling pin. The triggers use the same Max variable when put through the controller patch, so I only needed to record one number between 128 (LT pressed), 65408 (RT pressed), and 32767 (neither or both pressed). Like the mixing phase, the patch checks for changes from the last check. The threshold value is 20000000. If this value isn’t reached by the end of the 60 second timer, then the game enters a failstate. Otherwise, the player can move on to the preheating phase.

In the preheating phase, players must use the right joystick to set the temperature of the over. The ideal temperature for baking the pie is 425, but I allowed for five degrees of buffer on both sides, giving a workable range of 420 and 430. The player must press A to confirm the temperature; this was a workaround so that I wouldn’t have to deal with the patch immediately moving on to the next phase if I so much as touch an acceptable value while still scrolling. There are two failstates: setting the temperature too low or setting the temperature too high; this is checked at the end of the 30 second timer (30 seconds because giving less time was the only way to make this harder without asking for extra precision in how close the player ought to be to the proper temperature) and when the player presses A. If the temperature is acceptable, the player moves on to the baking phase.

In the baking phase, the player does nothing. They must wait for an internal timer to count down for 60 seconds. When the timer rings, the player has 5 seconds to pull the pie out of the oven. There are two possible failstates in this phase: pulling the pie out early or late. Otherwise, the game is completed and the player is shown a success ending screen. At any time, the player can press select to return to the start screen.

Here is the patch:

As explained in the video, its a hot mess of spaghetti. But, as its creator, I can (somewhat) decipher what is going on under the hood. The top right section of the patch is the primary control system, with a loadbang sending a message to the state controller and all the jit.playlists. A section slightly to the right of that handles toggles for metros in each phase, making sure than no timers are running when they aren’t supposed to when the player restarts the game in the middle of a phase. After that, each phase is sectioned off (relatively). They are all controlled externally by the controller patch, but a conditional makes sure that control is only allowed for the relevant phase as determined by the state controller. Internal logic and timers for each phase are stored here. Failstates and successes send messages to the state controller and the jit.playlists so that everything is showing the right things and the system is allowing for the proper interactions. The timers count up, but I used the output of the timers and subtracted it from 60 (or 30) in order to show a countdown when the internal logic is actually counting up. As mentioned in the video, each phase has a value associated with it in the state controller, with a number between 0 and 6 inclusive. 0 = start screen, 1 = mixing phase, 2 = flattening phase, 3 = preheating phase, 4 = baking phase, 5 = success, and 6 = failure. Depending on the conditions met for failure, the patch will show a different failure screen to give a snarky remark based on what went wrong.

The gauges were arguably the hardest thing to implement. You can see an example of what I did to the left of the audio playlist; effectively, it is a series of conditionals that show a different gauge with increasingly more of it filled based on the value of the corresponding variable.

To those having trouble with videoplanes giving an improper aspect ratio, I simply worked around it and didn’t actually fix anything. I scaled the videoplane to have a more accurate aspect ratio, but it still left my instructions cut off at the top. Instead, I created an extra layer for instructions and moved it slightly down. This was thanks to me keeping the .psd versions of the images, allowing me to make a different version by hiding other layers.

The art for the game was made almost entirely in Photoshop and was drawn using an XP-Pen Deco-01 USB tablet, since I cannot find the pens for the lab computers and refuse to draw with a mouse anymore. However, I had to make an exception for any animations that I needed to do, as I do not have any animation software on my computer. However, most of the art that the animations use was already done, so I could import static elements of the animations into Adobe Animate and work around that. The only issue that I had involved the exported video not retaining the transparency of the water. Ultimately, it was minor and did not require fixing.

And for those asking, the pie is whatever you want it to be as I never made the ‘fill the pie’ phase (which would have been between preheat and bake).

The logic behind the game was made almost entirely within the two hours of in-class work allocated for the penultimate day; only small edits were made to the logic afterwards. Making the art aspects and connecting them to the logic I think took longer to do.

 

Some things that I could have added after the fact: more sound effects for audio feedback (as well as to give the player the expectation that the game has audio that’s worth paying attention to), and some randomness to the threshold value for the timer in the baking phase to truly justify the lack of an on-screen timer. Other than that, I am happy with how this project turned out.