Completing a GDScript sprint to code a GODOT time timer
How absurd can it be to be extremely motivated by a project, but not finding the effortless way to properly engage with it ? That's sometimes how I felt about developing Lampyre, which is kind of normal when you're clawing on such a long-term project by trial and error.
I lately published a bit less coding posts on twitter for a few reasons. None of them being that I don't enjoy GDScript programming anymore, or that I would give up on the game - on the contrary ! I felt frustrated by my own brilliant ways of overthinking the game's mechanics and my progresses slowed on, which I had a hard time perceiving as anything else than a result of my own slacking off.
I took large chunks of time during the holidays to rest, read and reflect on my ways of working (weaponizing both my zettelkasten and my notebooks). I've set up a few new ways to track my habits and my progress (that will be worthy of its own article) and came to a (not so) dramatic conclusion: I decided to take one week off Lampyre coding to complete a GDScript sprint and create a little timer timer application on GODOT.
The Sprint method
"Why the hell would you come up with this, and how any of us both would care ?" is a perfectly valid question you could ask yourself right now. Probably going along with "What in the heck is a time timer anyway ?!".
Sprints are known in the programming world for being a important feature of Agile development. I won't dive too deep the details, but basically, when creating a software or updating one, a whole project is better divided in smaller functional segments. It produces several product versions - iterations you can use to gather client feedback and enhance your very next ongoing sprint (planning, into doing, into reflection - repeated again and again until the final version).
It fosters motivation and drives efficient results through action-oriented goals. The concept has been popularized over twenty years ago and while I'm anything but a professional developer, I would probably bet that it could not be anything else than industry standard - maybe now becoming obsolete or further expanded by new and more elaborated workflows, I don't know.
Anyway, the point is that Sir Carroll in its Bullet Journal Methodology book dedicates this short chapter on adapting the sprint mindset for your own personal projects.
"Sprints are independent, self-contained projects-thus the outcome is, let's hope, a source of satisfaction, information, and motivation to keep going (or [...] a helpful cue to let this particular goal go."
- The Bullet Journal Method, Ryder Carroll
Reading this part again resonated differently this time around, as I lately realized that my lack of clear prototyping and quick iterations was probably the main reason I felt impaired coding Lampyre.
So I thought, it could not hurt trying to complete a tiny project on a week span. While the bullet journal's chapter focuses more on the "safely trying out new things" aspect, I was attracted by the clear goal-setting and frequent iterations brought by sprints.
In a way, my coding segments always have been sprints - but they lasted several weeks, or even months, with sometimes ill-defined prototyping goals. If this one were successful, it could maybe bring me fresh insights about Lampyre development. At worst, it would cost me a few day's worth of coding.
Also, I needed that time timer. The google timer works perfectly fine, but I like the fact that the physical time timers have a visual display of the session's length elapsing. I don't know if the product's design is patented or anything, but there is a surprising lack of online or desktop application mimicking the real clock. Maybe I'll buy one eventually. But in the meantime, I tried out coding it.
So, to summarize things, whether it was sparked by the Bullet Journal Method book or by my own thinking, I began this sprint for the following reasons:
- change of pace
- completing a self-contained product with very clear functionalities defined
- finishing it under a one week period, forcing me to trim unnecessary features and quickly going back to Lampyre
- see if I could adapt the method for the game's development workflow (and also, why not, for novel writing or any other kind of multi-steps project)
- have a lightweight and cool transparent time timer to use daily
How it went
I upgraded GODOT to the 4.5.1 version and got to work (ùpromising myself to download the latest stable version more often, as I reaped large performance and loading benefits on Lampyre with absolutely no further change on my codeù).
The timer itself is extremely simple. As its physical counterpart, it's a round frame with a radial fill depleting as the countdown elapses. You can enter any time value between one second and 999 minutes (the edit field has several content checks to prevent abnormal values or quickly complete partial inputs such as "1:" meaning 1 minute or ":25" meaning 25 seconds).
It has a reset button, three buttons to quickly add minutes chunks without typing them and you can drag it across the screen. It plays a sounds when reaching zero seconds, unless the mute button has been toggled (my current ending audio snippet is the World of Warcraft quest completion sound effect, but I might change it as my brain don't react AT ALL to it if I'm also listening to the game's soundtrack).
I picked up a pair of few open-source shaders from the helpful GODOT Shaders library - namely the procedural Balatro background shader which I found mesmerizing to fill the timer frame with, and I also customized this Frosted Glass Shader to my liking so I could smooth out UI elements and add a little bit of shadows and outlines.
The radial fill colors and spin parameters get randomized for each new timer session. You can see the result on this twitter post. It works nicely. Time elapses. The sound plays. It's functional. The whole thing took an approximate time of twelve hours to create, from project creation to final export.
So, was the idea as haphazardous as it sounded ?
This tiny sprint surprisingly did everything I expected. It gave me a bit of space off Lampyre, which was creepingly looking more and more like a brick wall for my head to bang against everyday as I tried to progress it efficiently again. I decided to shed two superfluous functionalities (window resizing and dynamic time graduations around the countdown frame), which would have taken many hours more to implement for very reduced values. These were good choices. And, well, lastly, I now possess a neat timer application to work with.
The unexpected side effect of this sprint, is that I had terrible motivation starting each coding session. I kept thinking it was a dumb experiment, coding something that would never be useful to anyone else but me, and in a kind of amateurish way. That it prevented me from making worthwhile progress on Lampyre. Each hour spent on it felt a bit pointless and I thought I would stop at any time, ending up using an android application to track time.
But now that the sprint is over, I realize that's a terrific conclusion for the experiment. Not because the timer is anything revolutionary (though I must admit I simply like it for its minimalistic qualities). I see now I persisted because of the sheer simplicity and clarity of what I had to do. Taking it one day at a time and staying mindfully goal-oriented. Motivation was the last factor coming into play for completing this GDScript sprint.
Everyday I kept thinking back to Lampyre and all the cool things I want the player to experiment. So, I could efficiently complete a small sprint that bogged me down - but I had trouble going on with my heart's project ? I knew I had a problem with clarity, and this confirmed it.
Going back to the real thing
We're continuing Lampyre's base crafting development. But this time, we're going to set up weekly development journals and smaller coding sprints - with more self-contained functionalities. It may not sound so different from the previous game development workflow, but it's going to simplify things on my side. Also, I enjoy Bear's ascetic way of displaying smaller articles. It will give you more regular (and hopefully more meaty) updates about the game advancement. Keeping more mindful about useless mechanical fluff and pondering each functionality time cost should also quickens the iterations cycle (I do intend to publish this game at some point, we went great up to this point).
I dearly want to improve my prototyping skills. It's the key to motivation, progress, a playable and fun game - everything. I intend to publish our (Bear) first game development update before the end of next week, and then keep it as a weekly occurence. Other articles should keep showing up on a similar basis too !
Let's dive back into Lampyre's campfire scripts and roast our first vegetables on this d*mned cooking pyre.