Snake Classic

Summary

A big part of why I decided to do this project is because I legitimately wanted to play something like this. The idea of the project itself is also very extendable, allowing myself to add more and more features down the line. But the biggest reason was I wanted to push my front-end development by making something that posed a challenge for myself.

Developer Diaries

Seemingly Simple

Looking from the outside, this project is relatively simple. And that's what I had thought as well when I first delved into doing this project. But as I worked through the feature list that I had planned, I became more and more challenged, considering my comparatively limited skill at the time. It also certainly doesn't help that the infamous feature creep occurred during development. For example, pausing, gradually accelerating snake, and usable control on mobile was not initially planned. Now, feature creep is not necessarily a bad thing in this case because this project is meant for me to learn new things and get outside of my comfort zone, as will be elaborated later. But it does mean that my initial prediction on the burden of development for this project is way off.

Comparatively Heavy Client-Side Logic

Every one of my other project before this required relatively simple front-end scripting. Compared to all that, this was complex, although it certainly pales to the projects I'll be working on afterwards. The complexity came from the fact that this is a full-fledged game. The core gameplay loop was not that simple to code, at least to me at the time. I remember needing to spend a day just to "render" the game's "canvas" (both words in quotation mark because I didn't use any canvas library, it was plain CSS grid, perhaps partially why it wasn't trivial). Because I had used a CSS grid, I needed to code the behavior of the snake from scratch: how it would wrap around the canvas, how its length would be calculated, how turning would work (and with respect to the literal edge cases at the edge of the canvas), etc..

State : Its Management and Abstraction

This is one of the main thing that I had learned from this project. This project had used Svelte 3, which uses Svelte stores for its state management (notably different from the Rune API used in Svelte 5). At the start of development, how the state (high scores, game states, etc.) was managed was messy. I remember how satisfying it was for me to grasp how to tidy them up and refactor them using the more advanced store abstraction that Svelte 3 provided. It seems simple and obvious to me now but I'm still proud of what me at the time have managed to do considering my skill level back then.

Failed Venture to the Back-End

Some days into this project's development, I had thought of having user account where high scores and your current game would be saved. I was legitimately blind about writing a back-end at the time, let alone dealing with databases. I ended up trying to have a simple written in Express, heavily taking inspiration from the back-end from ARC Cafe that my friend had written. The database I used was Google Sheets, yes you read that correctly. I followed this tutorial from Fireship about how to use GSheets as a database (which also listed plenty of reasons of not doing so for a half-serious application). It didn't work out because it took longer for me to really grasp how the back-end works than the deadline I had set out for myself for this project.

Conclusion

To this day I still think that this project possess the quintessential quality of a hobby project:

1. It's something that I was passionate about because I was certainly eager to play the end product. For this project, every extra lines of code written brought about visible changes to the project's functionality that kept me motivated.

2. It's very extensible as seen by the feature creep I experienced. You could add plenty of new functionality on top of the base project:

   1. User accounts.

   2. User settings that are tied to user accounts for controls binding, themes, and many other things.

   3. Multiple difficulty.

   4. Friends and leaderboards!

   5. Side-by-side snake duel?

   6. And many other things that I haven't thought of.

3. Last but certainly the most important, it was well outside of my comfort zone due to its relative complexity.

I think it's very possible that I may remade this project in the future from scratch (because Svelte 3 have been outdated for quite a bit and SvelteKit is really how it should be done nowadays) with all the bells and whistles that I initially thought of. Would love to do it once I have more time to myself.