Posted On: 2019-04-22
Today's post will be a bit less focused than usual. I have several topics worth sharing that are too small for individual posts, so I'll be writing a bit about each one, in the hopes that together they will make for an interesting read.
Testing is still ongoing on the current prototype, and I am immensely grateful for all the feedback I have received about the game so far. Interestingly, even though each of the playtesters so far have had different perspectives on the prototype, there have been a set of specific issues that have been raised by everyone who has played it. Seeing that pattern has helped me to know where to focus my efforts, and I am hopeful that the changes I have made will make the prototype (and the eventual larger game) more enjoyable for everyone.
Looking forwards, I have started thinking a bit about the next prototype that I want to work on. There are several specific non-combat interactions that I want to test, to verify that players will use them the way I expect them to (making A Notebook Prototype has taught me the importance of testing such assumptions.) In the process of documenting these ideas, I have realized that the next prototype will likely be ambitious in scope, especially if I try to test all the different kinds of interactions together. Considering that in light of my reflections from my Six-Month Retrospective (specifically, that I am already behind on where I wanted to be on the final project) it seems clear that I need to get the final project scaffolded and started before I begin any more prototypes.
While I typically use an informal, ad hoc planning style for most of my work, software architecture is one place where I try to be a bit more structured in how I plan and prepare. As a quick summary, software architecture is the discipline of organizing the parts of the software (code, data, content/assets, etc) in a way that will make it more efficient to both create and maintain. It's something of an unsung hero in the software world, especially as iterative design (an unstructured approach to refining a design over time) and Agile software development are marketed and hyped as the future of software. Even in the most dynamic, agile world, software architecture still has a place: it's hard to quickly change if you can't find the place that needs to be changed.
As I prepare to start work on my larger project, I know that creating an architecture that facilitates extensive content growth and unforeseen changes will be essential for being able to complete the project in a reasonable length of time. One very important aspect of this is being able to divide up the constituent parts, so that parts that are slow to change can be automatically tested, while parts that are constantly changing can have smaller, more focused testing. I've experimented with this a bit in my current prototype, and I am pleased to say that the "Salience Engine" benefits greatly from automated testing, while the prototype itself benefits from the "Salience Engine" being highly stable. I am hopeful that this same approach can be used in more places in the larger project, as the scope of testing functionality always balloons over time, and automated tests are essential for keeping that scope in check.
Hopefully this has been an interesting read. If you have any thoughts or feedback, please let me know. Likewise, if you'd like to be an early tester for the current prototype, please let me know about that as well.