Posted On: 2020-01-27
I often recommend remaining flexible while planning, but I don't usually go into details about why that is valuable. For today's post, I thought I should explore the importance of flexible planning by using a recent example to illustrate how it has provided me value.
In my plan for the beginning of this year, I outlined five questions that I need to code answers to:
Once I had implemented both gameplay-to-gameplay scene changes and gameplay-to-cutscene scene changes, the scene change code seemed to be done, but I knew I couldn't be completely confident in it until I validated it using another system. Thus, I left the scene code as "pending acceptance" and started work on the death system - which directly led to the first major change to this year's plan.
Work on the death system began with a minimal test: character dies, cut to a static "you died" message, and then cut back to gameplay, with the character revived. This simplified loop was relatively straight-forward to achieve, and it laid an adequate foundation for traditional death experience (ie. respawning at a checkpoint.)
After that, I began working on a bit more complex of a test: after character death, cut to a bit of narration with a player choice, and then after the choice go back to gameplay. At first, this seemed to be similarly simple: just load a cutscene with the dialogue engine running a simple script, and after the script completed cut back to the actual gameplay. Unfortunately, that is not quite how things turned out.
Before getting into what went wrong, there's a bit of context that may help: the dialogue engine that my project uses is quite unpolished. Originally, I started by using Yarn Spinner, but - over time - I found myself making a few different modifications to better suit the way I was using it. Many of those changes are included in the version I used for the Magic Training Prototype, but, since they were designed for a prototype, they were quite rough around the edges. Even the version of Yarn Spinner that all of this was based on was, itself, a pre-release version.
When I began to use the dialogue engine in the death cutscene, I found myself catching on all the sharp corners left on the unpolished engine. Implementing even trivially simple salience was cumbersome, due to the lack of tools to support it. Additionally, the way the dialogue engine controls its flow is quite rigid: everything must be set up exactly as desired in the editor, with no possible changes at runtime*. Perhaps most importantly, the system I use to change scenes (as well as save/load player progress) relies upon being able to set properties at runtime - and therefore the dialogue engine itself is incompatible with scene changes.
Having limitations in the dialogue engine was not much of a surprise for me: in my original plan, item #3 (about NPC interactions) covers a rather long list of features and tool improvements for the dialogue engine. What I didn't expect was the intersection between scene changes and the engine limitations: with the current dialogue engine, I will be forced to use work-arounds in order to scene change into a dialogue. Unfortunately, if I later make changes to the engine to make it more flexible, I will also have to remove any workarounds I put in place now. Thus, I cannot call the scene change system "complete" until after working on the dialogue engine.
At this point, I need to replan what I am doing. Attempting to move forward without doing so puts me in a place where three major features (scene changes, death, and dialogue) are all locked up as "in-progress" while I try to negotiate the interconnections between them. In any project, too many things in progress will lead to increased rework and reduced quality of prioritization, and given the scope of the dialogue engine's missing features, this would be a staggering amount of in-progress work.
As the focal point of replanning, I need to get past the dialogue engine blocking the scene changes from being considered "acceptable." In light of that, it seems that I don't necessarily need to complete all the work for the dialogue, but, instead, I need to complete certain specifically relevant tasks. Thus, my nice 5-item list will gain a new item, something like:
Although this new item will still leave me with three open features (scene change, death, and dialogue architecture) the scope on it should be smaller than the other dialogue engine changes, and it is readily apparent how this one item impacts the other likewise-open features. Solving this will, unfortunately, not resolve all the pain-points associated with running dialogue after death, but it should at least move it from "impossible" to "possible, but painful".
In light of that, I expect that the death system will not be developed beyond simple tests. While it would be nice to validate the various death behaviors I actually intend to use in the game, doing so without a polished dialogue engine will likely be too painful/time-consuming to be worthwhile.
Hopefully it is clear how a willingness to revise and adjust the plan has helped me to react effectively to an unexpected complication in my work. For myself, I must admit that writing this was actually a bit eye-opening as well: I have always valued being flexible with a plan, but sitting down and writing my way through this particular change has helped me appreciate that dedicating time to replan (rather than adjusting the plan on-the-fly) can help to much more accurately determine the kinds of changes that need to be made.
As I am trying to have increased transparency in my planning this year, you can expect to see more replanning sessions in future blog posts - after all, nothing ever goes quite as planned, and it's looking like slowing down and observing before making changes might be the best way to deal with that.