Posted On: 2022-11-28
Last post I covered how my project is behind where I want to be, and how I think I can improve things going forward. Today is a deeper dive into that topic, including specifics about changes to my process, project structure, and even the frequency and timing of blog posts.
The first major change to how I am approaching my project is that I am going to be more strict about what features I even consider for inclusion. I wrote extensively about the need for this previously, so suffice to say that this is the single most important change for completing the project.
The companion to saying "No" is being willing to give up. Often, when implementing a new feature, there is a gap between what's desired and what's possible. Historically, I've closed the gap using compromise: discuss expectations, adjust implementation, and generally iterate until they converge. This works great with an outside source of requirements: the back-and-forth improves both parties' understanding of the feature, and it can help refocus the work on the parts that definitively bring value.
Unfortunately, that approach has not worked for this current project. Being both invested in the vision for the project and also the implementation itself, I can have a hard time making good compromises: essential parts (ie. autonomous agent movement) have been repeatedly postponed in response to difficulties in implementation, and I've spent too much time iterating on some low value features simply because they were enjoyable to work on. To avoid those problems, I am going to approach these situations as creating a whole new feature: the implementation with a gap will instead be treated as a "can't do that" feature, and any attempt to salvage it will have to pass through the "no by default" approach that any other feature has to go through.
Some people benefit from structured schedules, while others (like myself) benefit from having a lot of flexibility. Personally, I find my productivity often has peaks and valleys: sometimes I'll finish a task massively ahead of schedule, while other times a task will drag out painfully long. Attempting to account for that in a schedule can be quite messy, and it's often the case that an estimate that would be accurate under ordinary scenarios is woefully inaccurate due to some fluke (ie. first attempt works perfectly, or maybe repeated attempts keep failing in unexpected ways.) The simplest way to deal with those problems is to let the work schedule itself: work on one task until it's done, and then move on to the next.
Letting work schedule itself naturally leads to planning when work becomes sparse - but it doesn't lend itself very well to changing the plan mid-development. This can become a problem as it makes it more difficult to intervene when tasks or features are taking an unusually long time. In the Agile methodology Scrum, work is planned and organized around sprints: fixed duration intervals that are bookended with dedicated time for planning and reflection. In an effort to force review and re-planning if a task takes too long, I'll be adopting a similar approach: start each week defining the week's expectations, including an honest assessment of features and tasks that are taking a while. While this isn't a perfect solution (ideally you'd want to catch delays as they emerge, rather than on a weekly interval), it's a significant improvement over my current process, and the time for this planning is already carved out in my schedule: Mondays are the day I normally work on blog posts.
With the time-slot for my blog post being repurposed for planning, I am forced to make changes to my process for writing these posts. Rather than writing them on a fixed schedule, I'll be approaching writing a post the same way I would any other task: scheduling it into the week as a part of my regular planning sessions*.
Additionally, I intend to include regular updates of my progress alongside my (more varied) ordinary posts. As such, I'll be decreasing the frequency of posts down to once per month, and include a brief status report at the same time. For now, I plan to include the status reports simply as a separate (unrelated) section on the end of the post, but I may change that approach if it fails to achieve my intended goals (increased visibility into how much goes into making a thing, as well as an opportunity to personally celebrate my own successes.)
While the previous sections have largely covered process and scheduling changes, I've also got a pretty big change for the actual code of the project: I will develop as much of it as possible outside of Unity. The project is currently weighed down by a lot of dead/unstable code, and as best I can tell, my only maintainable way forward is to isolate the pieces that are desired, and cut out everything else. As a part of that isolation process, I'm writing automated tests to validate the code works (both now and going forward), and I'm doing all of this in a separate, code-only project.
Making the change to primarily develop using a (non-Unity) project has a number of benefits. First, it makes automated unit testing much easier. Second, it accelerates iteration, as my preferred IDE allows for compiling and running tests in the background*. Third, it makes it easier to review changes before committing them (every file is human readable.). Fourth, and perhaps most important of all, it's much better for my morale: Unity's slow startup, constant freezing, and intermittent crashes over the past four years have left me dreading every workday. Making the switch so I only open Unity when it's absolutely required should make my day-to-day work much more enjoyable.
I am optimistic that these changes will both reduce the scope of the project and improve my productivity. I've had the opportunity to put a few of these into practice, and it's already looking promising, but I expect I won't be able to fully implement everything before the start of next year (December contains several unrelated, non-negotiable commitments.) As such, I will take this opportunity to switch over to the new blog schedule: expect a new post on January 2nd, and the first Monday of every month from then on. I hope you'll continue to follow along in this strange journey of making a (rather ambitious) game.