Goals

• Bugfixing
• UI improvements
• Performance improvements
• QOL improvements
• Developer tools
• Documentation

Risks and Mitigation

1. While I think it's valuable to spend some time cleaning up the codebase, stamping out bugs, and improving the usability of the system, there's a decent chance that improving the general quality of my current implementation won't provide specific enough tasks. That could make it very hard to focus and be productive.
   • I can resolve this issue with the following cycle. First, I can spend some time tinkering around with my codebase looking for problems. That'll generate a bunch of specific issues to fix specific problems. Once I've collected a fairly large collection of these issues, I can switch to resolving those issues that I've discovered. When that collection of issues empties out, I can return to bug searching. That cycle should help with the mental focus side of the issue, at least.
2. I don't have a clear idea of what might be wrong with my current implementation. While I can do ad-hoc bug-hunting to find some problems, it's not clear whether that process will be very fruitful.
   • If my suspicions are correct, there'll be more than enough issues for me to find. I can already think of half a dozen problems with the current implementation that I could start addressing almost immediately. One of reasons I'm doing this sprint is to stabilize what I think is a fairly buggy codebase. If it turns out there aren't enough bugs for me to quash, that's great news.
3. While there are definitely classes (like promotions and policies) that could benefit substantially from some intelligent editor scripts, it's not clear to me how valuable that work will be. I personally won't make much use of them, which means that attending to those tasks could be a waste of time.
   • This goes back to the reason I'm doing any of this: to present a well-constructed product to prospective employers to convince them I can do the work. Good tools for the developer are a big part of that. I need to show not just that I've created the game, but that I've made it easy to continue to build the game. Even if I don't use the tools, it's important that they are there.
4. It's not clear how I'm supposed to document this codebase, or how useful that documentation will be at this point.
   • Part of the documentation is handled by unit tests. It might be useful to describe some of the basic structures I use in the codebase (the distinction between Logic, Canon, and Responder classes, for instance) and to provide a brief description of all the substantial classes. I might also describe how the UI is supposed to work, describing the procedures for setting up a new state or a new panel. I can also do some research on how this is supposed to go. But at this stage in development documentation isn't a big priority. I'll attend to it only if I run out of substantial bugs or need a bit of a break from that grind, but will otherwise leave it on the backburner.

Review

I spent pretty much the entire time either improving the UI, adding some QOL improvements to map editing, or fixing bugs. I managed to do two of the above-mentioned cycles and ended up resolving 36 separate issues, most of them relatively small bugs.

I did not build the current implementation, and not for any particular reason. It simply didn't cross my mind. Therefore I don't have a good sense of how well the final product functions. It could be that there are tons of issues I haven't figured out yet.

My will to work petered out early Wednesday of the second week as I was almost done with the second hunt-fix cycle. It turns out my plan wasn't sufficient to maintain my focus, especially in the face of Christmas break.

Retrospective

What went well?

1. I managed to address a ton of small issues in a fairly timely and efficient manner.
2. The UI in both the map editor and play mode is now much better. It updates more intelligently and has fewer bugs and bad affordances.
3. I managed to add city editing to the map editor by repurposing my existing city display in a way that avoided redundant UI elements and ended up working fairly smoothly.

What could be improved?

1. Normally I end my 27-minute units of work early if I finish a task before the timer is up. I excuse it as a sort of reward to myself for working efficiently. Typically this isn't a big issue, since tasks usually take many pomodoros to complete. But during this sprint there were a lot of issues that took a very short amount of time to resolve. I was frequently ending pomodoros with half of their duration or more left on the clock, which was causing me to end my workday a lot earlier. That small organizational quirk cost me at least an hour a day during this sprint. I think I need to stop ending pomodoros prematurely, particularly when I anticipate a bunch of small tasks. Instead I should pause the timer, wrap up the task, and immediately find and start on a new issue.
2. While my ad-hoc bug searching did reveal a bunch of problems, it's not at all clear that it revealed the right problems. Moreover, the process became untenable towards the end of the sprint because I didn't have specific goals in front of me. I need to find or develop a new technique for finding bugs. My current hypothesis is to develop user stories to describe what a player should be able to do with the program without encountering any problems. I might also add specific standards of quality that my codebase must meet to focus pursuit of things like performance.
3. I have not been building my project, which means I have no idea how closely my experiences in the editor relate to the final product. I need to commit myself to weekly builds so I actually know what the hell the final product is shaping up.
4. I would be very surprised if there was no memory leak in the current program. I need to find some tools to detect memory leak in Unity applications and add that to the list of problems to be solved.