I’ve been meaning to publish this journal entry weeks ago but I got lost in the flow of getting things done - powered by the return of the agile board.
I think it was only a matter of time for this to happen and can be attributed to the increasing complexity of the project: As I’m adding more and more features, refining existing ones, fixing bugs and addressing feedback from playtests, I need to rely on more than just my memory or handwritten to-do lists. I was dreading the impending re-introduction of the agile board into my workflow, since I now understand very well how it was having a negative impact on the creative vision and design decisions I made in past projects - I was focusing on getting things done, rather than on the things. However, the many Soundgarden-thoughts that accumulated over time were not just filling my to-do lists, they were taking up precious space in the back of my mind, leading to ruminations and an increased worry to simply forget about important - or perhaps even profound - ideas. So the agile board had to come back, but it’s new role should be one of a bridge that would bridge the gap between design decisions and active development.
Rather than using the board as the central point of organizing a project, I now use it as a cache for the concrete tasks that stem from my thoughts and insights. I’m also not using Trello for this anymore, but instead GitHub’s built in project board feature, which puts this form of project organization closer to all other forms of reflection hosted in the repository: this journal, the project documentation, and commit messages. In fact, to further reduce any potential negative impact on the design process, this new board now adds another form of reflection in the form of what I call “micro-journals”. I’m not yet sure how thorough I will be with this, but I aim to add my evolving thoughts about the tasks in the board to their respective descriptions. As of now, this is takes place in the following way:
During my Trello board times, I would occasionally follow some of the steps I described here. However, I now consciously aim for being more through and mindful with this, even with tasks that may seem to be more on the trivial side of things. Thinking about this, I realize how this is perhaps not only a reflection on my work with Soundgarden but really a product of all my design/project management/working on things experience. I appreciate how a more mindful approach can resurface a long history of previously unconsciously known personal work experience. But then again, this is perhaps true for all aspects of life.
[!Note to self] Writing this, I realize that I have not actually documented my previous Trello board-based workflow in this journal before. This is a reminder for myself to upload and link my (already existing) report on that here!
Thursday, February 13, 12:52 AM I am thinking about the growing complexity of this project. Yesterday, I spent what felt like a whole day on implementing the Odd One Out gameplay.
One week later, I’m looking at this momentary thought after having spent another whole day of (unsuccessfully) implementing what seemed to be a simple button. We need to talk about this.
First, I feel the need to clarify that my lower frequency of journaling as of late is not the agile board’s fault. I just had a very clear idea of what I had to do, thanks to a more conscious design approach. In addition to that, as the project progresses, it’s complexity increases. New additions may need to be integrated with the many parts that now exist in this project. Some design decisions may pose enhancements of what’s already there. Enhancements can be things like usability improvements, more responsive and “juicy” interactions, quality of life additions - which may take considerably more time to implement than initial, proof-of-concept, barebones features.
Take a button, for example. It can be simple. The player looks at it, left clicks on their mouse –> the button is instantly pressed, triggering something. Now, what if I want to have some feedback? I could add a sound, instantly played whenever the button is pressed. But perhaps I want to make it more “fun” to press it. An animation could help, showing a quick inward movement - and this is where complexity starts. First, I have to create the actual animation, either by deciding on the specific positions of the button over time, or parameter-based procedural movement that takes place within a defined positional range. Then, I have to make sure the animation does not conflict with the player’s behavior: What if the button is pressed again while it is animating? At this point, we have already added several variables and functions here. Plus, since the state of the game environment is saved in Soundgarden, the state of the button must be saved and also be reconstructed when the game is loaded. Here, we don’t just save some Boolean variable, we have to use the information stored to set the button to it’s correct pressed/unpressed position. The button may also have some other features. Perhaps it can be activated/deactivated in the sense of being usable/not usable, meaning it could be in either pressed/unpressed position but additionally not trigger a state change when interacted with. This would also pose an additional feature to be stored in a savegame. Also, perhaps the button’s state can be influenced by another object, some controller entity that manages a set of buttons as part of some machine or puzzle. And then, of course, the player’s interaction with the button itself must be handled. How do we know if the player wants to interact with this specific button? How do we know if the player is looking at it? Do they have to look at it directly, or is there some tolerance? If there is tolerance, how do we handle multiple buttons next to each other? How do we display a signifier that communicates to the player that they can interact with the button?
I want to be clear that the questions above are not meant to address the design of this interaction. Let’s assume we got that covered already. All these questions are meant to show the technical reasoning that goes into the implementation, and why implementation of such seemingly trivial things might take some extra time, requiring to divert focus away from design and innovation. The new old agile board helps me to stay on track with things, despite the occasional developmental deep-dive. Commenting my progress and on-the-fly insights through micro-journaling in the respective issues helps sorting my thoughts and keep design reflections alive.
This journal entry has ended up being more about the project organization and my general development practice for Soundgarden. For the sake of keeping things in focus and to not overburden an already lengthy piece of writing, I will reserve reflections about the cool new stuff for the next post.
[!Note to self #2] Writing this post, I discovered how to do headings in markdown, making it slightly easier to format the text, and, more importantly, allowing to link back to specific sections. This is a reminder for myself to update my earlier posts with this exciting piece of technology!