At the start of 2023, I made some changes to my process - and in using that new process for the past four months, I've polished the approach, and corrected some of my erroneous assumptions about how it would work.
For today's post, I thought I should document my approach more specifically (taking into account the changes I've made along the way) for those who would like to try a similar
approach for themselves (or those who are simply curious.) At the end, I'll also provide a quick breakdown of what I've accomplished thus far - thereby both documenting
my progress and also assessing whether the new process can improve my long-term retrospectives.
Break Down Each Week
For the past 17 weeks, I've started every Monday by looking ahead and cataloging what I intended to accomplish.
I keep this catalogue in a physical document - a binder that I leave open on my desk at all times - and each day begins by briefly reviewing
what I have left to do that week. Using a physical document, rather than a digital one, affords me three benefits specific to my
situation:
A physical object does not consume any screen space,
so it can seamlessly fit into my existing workflow (which uses most/all of my available screen real estate.)
I can review/edit my plan even when my computer is off/unavailable - meaning the start of my work day is not contingent on the startup time of my machine.
Due to some quirk that I assume is highly personal and unlikely to apply generally, writing on paper helps me remember things.
When planning, I try to break things down to specific tasks, as that helps me think through the specific steps necessary to achieve my larger goals.
Generally, I'll have an idea of what my current goals are (ie. finish the physics rewrite), but in putting pen to paper I change those long-term ambitions into concrete
steps (ie. write automated test to validate converting acceleration into velocity over time.)
I treat this list as a living document, and throughout the week, I will change it as needed - whether that's checking tasks off at completion, or revising/scratching out
tasks that don't achieve my goals.
For each week, I try to keep the list of items short (no more than 5 items), and I try to keep an even balance between writing content and writing code. Having a short list helps me
stay focused, and increases the likelihood that I'll get the majority of the items done by the end of the week. Having a balance of both writing and programming
means that I'm simultaneously advancing two essential parts of my project: the writing that serves as the heart of the project, and the code that turns that into something people
can actually experience. As a bonus, despite the similarity in physical muscle movements, writing content versus writing code use very different mental "muscles" - meaning I can
use one to take a break from the other.
In addition to the week's tasks, I also keep a few "stretch" tasks on the list as well. They generally represent things that I don't expect to be done in the current week, but
that I do want to be accomplished soon. I've found stretch tasks are particularly useful when I have sudden spikes in productivity: if I've been unusually successful (whether
due to luck or being particularly "in the zone"), I can lose that momentum if I have to switch into planning mode. Thus, having these "stretch" tasks handy helps me make the most
of things going well, without implying that I expect to get that outcome every week.
Create A Story Of Success
To mark each week as "done" (regardless of how many tasks I completed), I do a small retrospective of the week. On good weeks, this is my last task on Friday, but often enough
I've ended up pushing these to the last minute, so that Monday starts with a retrospective, and then immediately continues into planning the new week*. Regardless of when it happens,
the goal of these retrospectives is to look at the previous week's performance, and make adjustments where needed. Sometimes this means changes to my plans or processes
(the approach of using "stretch" tasks was the result of retrospective reflection), while other times it means making a conscious choice to continue doing something that works well
(last week's post documents something that went so well that I flagged it as "keep doing this" in the relevant retrospective.)
To complement planning on physical paper, I also write up my retrospectives on paper.
I try to keep both the plan and the retrospective to only a single page each, which allows me to write the plan for the week on one side of the page, and write the retrospective on the back.
This approach brings a few minor benefits:
Since I (generally) keep my binder open to the current plan throughout the week, I also have the previous week's retrospective open at the same time (since it's
on the back of last week's plan).
The record of my intentions for the week and my record of how the week turned out are physically linked: even if a page is separated from my binder, those two
pieces of information will always be together.
When looking back and reading over plans from the past, the physical layout makes things a bit more interesting.
Each week's plan is a small mystery: while I clearly list what I planned to do, and successes or failures are marked directly on each item, there's no
context provided, and unexpected outcomes (ie. cut tasks) have no explanation.
Instead, one must physically turn the page to reveal what happened through the week: the retrospective (briefly) describes noteworthy events and circumstances
from that week, serving as a sort of answer to the mystery implied by the plan.
Concrete Results
Given this new process, what have I accomplished in the past 17 weeks? While the new process only documents this as a series of details - individual tasks accomplished on a weekly basis - for the sake of this post, I'll group them together
into a few larger-scale accomplishments:
Finished the script save and load system Players can exit the game in the middle of a conversation, and the game will pick right back up where they left off when they return. This was the final piece in a feature that
I am quite proud of.
Automated script and attribute aggregation The script systems are portable such that they can be easily imported into new/unrelated projects.
As such, I've set up a project that runs the script using automated choices (and other debug actions), thereby
making it possible to traverse any (and all) written content. That project also aggregates information from the script, (ie. which character uses which expression),
which can help me understand the scope of my project in concrete terms (ie. when making character portraits, which expressions will I need to draw?)
Cut feature: character emotion tracking A rich conversation system needs to track a wide variety of information - from conversation beats to reputation to character moods. I sketched out a design for one such system,
but ultimately decided it's too early to implement it: better to let the script define its own needs and (later) code to match it than impose a complex system that slows down the writing process.
Major writing change: new Point-of-View character In a departure from genre norms, my story features more than one point-of-view character (including player-driven decisions in different PoVs).
This year, I changed one character from "important, but infrequently present" to "PoV" status - which increased the scope of assets needed (ie. new environments, characters, etc.),
but also greatly improved the pacing and ability to convey information to the player. Most of the writing this year has centered on this change - whether that's creating whole new
scenes, or revising existing ones (which have a reduced informational burden, thanks to the new PoV.)
Resolved website difficulties I've covered this in more detail previously, but a noticeable amount of time (and stress) went into sorting out issues with this site.
Engine-agnostic fixed-timestep system The less code lives in the display part of the application (ie. Unity), the better tests I can write and the more stable the whole system becomes. Laying the foundation for that,
I've created a (simplistic) fixed-timestep system that will drive all time-related activities for my project.
"Faux" Physics system (currently in progress) The main driving force behind moving my code into a separate (testable) library, a "faux" physics system is a deliberately unrealistic system for contact and collision resolution.
I am still in the early stages - testing out several different approaches (ie. building it directly on top of a more realistic physics system), but I have a set of tests
to validate both behavior and performance, so that I can have confidence that the fundamentals provably work, no matter how the project changes over time.
Time Off Often underrated as an accomplishment, when I needed to take time off in order to continue being productive, I did so. I am particularly pleased with this, as
the weekly structure has reduced the pressure to "get back to work" - which in turn improves the value of any time off that I do take.
Conclusion
As you can see, my new process is yielding quite a bit of value:
Weekly small successes combine to push major objectives forward
Balancing writing and code maintains momentum on the two most important parts of the project
Having a written record makes retrospectives (like this one) more accurate and (hopefully) more insightful
Coming to reach this process has been an iterative thing: over the past four months, not only did I refine and cut features for the project, I've also refined and cut process changes.
What I have so far seems to be a good fit for me personally - but I imagine there are still more improvements to be made, and I hope my process will continue to surface those.
I hope this has been interesting for you, and, as always, if you have any thoughts or feedback, please let me know.