Cake Quest launched on itch.io and on the Lexaloffle BBS almost five months ago. At the time, I didn’t feel capable of putting my thoughts and feelings into words. This post serves as my best attempt to do that while reflecting on the process now that I’m no longer involved in its documentation.
If you have been following along with that documentation, then it’s no secret that the game is a culmination of a series of firsts. At its inception, it was my first PICO-8 project. Its initial lines of code were the first I wrote in Lua. It is the first game I’ve finished and released outside of a jam setting, making it the first to which I’ve dedicated more than a few weeks of my time.
In the first post discussing the jam concept that evolved into the PICO-8 game, I mentioned that it floundered partially because I was overwhelmed by how much I potentially needed to do and doubted my ability to actually do it. I’ve felt that way toward game development for the past few years, so Cake Quest was as much a fight against that as it was a learning experience and an opportunity to leave my comfort zone.
Like the jam games I’ve released, it was a solo project, and I was not financially reliant on its performance. This granted me the privilege of having no set deadline, allowing me to focus on each aspect of development for as long as I wanted. To me, a deadline was an expectation. I didn’t need the guilt associated with a failure to meet it.
Quantifying my work has always been difficult, if not impossible. If I were asked how long it would take me to complete a task, I would struggle to give an answer. Over the years, I’ve been told I’m proficient at and with a number of things, but procrastination is something at which I’ve excelled, thanks to near-consistent positive reinforcement in spite of its undeniably negative impact on my health.
Cake Quest‘s development may not have been procrastination-free, but I was determined not to let myself suffer for its sake. I took frequent breaks. On the days I didn’t feel like working on a specific task, I either worked on something else or didn’t work on anything. It was important not to force progress. I told myself that productivity was a switch that I was allowed to turn off and that I wasn’t lazy or unmotivated for doing so.
This approach made each “active” day more enjoyable. Tasks and problems that would otherwise have been obstacles to things I’d have rather been doing were instead puzzles I looked forward to solving. I mentioned before that the project was a learning experience. As those go, it was probably the best one I could have had, since most of these tasks and problems were entirely new to me. I not only gained valuable experience in devising my own solutions, but I also learned how to read and understand others’ solutions whenever I needed a push in the right direction. Considering PICO-8’s limitations, being aware of my specific needs and of what would (or would not) help me meet them was paramount.
There were certain quality-of-life things I avoided doing because they weren’t absolutely necessary, and the game was designed around their absence. I knew this decision would affect the game’s reception, and I justified it by telling myself that I wasn’t making the next Mario or Celeste. Regardless, I could have made more of an effort to get feedback, which I received about two weeks before launch. Someone saw one of my last progress GIFs and pointed out an issue with the camera behavior, specifically with its vertical motion.
I was both thankful and annoyed. I was thankful because the individual was respectful and undemanding. I was annoyed at myself for not prioritizing something like camera behavior from the outset because that made it harder to adjust or fix without adjusting other parts of the game, such as the level design. I wasn’t willing to make those sorts of adjustments. By that point, I was just looking forward to being done.
Even so, I spent the next week researching possible solutions. I was unsuccessful, but after the game launched, I remembered coming across a compilation of math-related Game Developers Conference presentations. From Squirrel Eiserloh’s presentation, “Juicing your Cameras with Math,” I learned about asymptotic averaging, which I was then able to implement with relatively little hassle. I can’t explain it as well as he can, so I’ll just say it improved the camera’s behavior, and I think the game is better for it.
The launch itself more or less went well. People liked how the game looked and complimented its itch.io page, which uses a built-in font and a custom background (I recreated one of the game’s sprites in Asesprite). Like my other games, it is fully playable in the browser. It is, however, my first to have downloadable options because I discovered that PICO-8 can export Mac, Windows, and Linux executables. I didn’t expect to get any downloads, but I thought it’d be useful for future projects.
The lesson I learned from including these is that I should have figured out how to use Butler first, which would have allowed me to update the executables without having to delete and re-upload them (like I did after the aforementioned camera adjustment). Since analytics don’t carry over between files, the number of downloads may have been impacted, but I can’t be sure.
What I am sure of is that I achieved what I had set out to do. When I began, I wasn’t confident. I was apprehensive. Now, I am relieved. Empowered. I’ve been reminded of some capabilities and have become aware of others. I am less discouraged and less intimidated by my limits. Most importantly, I am grateful for the encouragement and support I’ve received over the past year from my friends and fellow developers, without which I probably wouldn’t have gained the confidence to share the game.
Overall, this project was validating and a lot of fun to complete. It still involved a fair amount of work, but I don’t regret a second of it.
Death Row Development 