Failure and Progress
I've pushed back on writing this update because it means admitting failure with the demo deadline for the Deckbuilder Fest. The goal was to have a demo ready for that. On the Saturday before the event, I realized I needed to humble myself and postpone the demo. I had been crunching all day-- and most of that week-- but the demo was not where I wanted it to be. The biggest issue was the amount of bugs in the game. These bugs were creeping in because I was neglecting to design and test my code prior to implementation. Instead I was racing to get features "finished" through improvisation.
I was trying to shortcut progress to reach my goal. After I decided to give up on the demo, I updated the store page with the new content I'd made-- primarily visualization of the game Model and a system for telegraphing actions. With that done, I tried to look at why I had failed to reach the deadline, and how I had become so stressed with the work. Part of the issue was laziness-- I wasn't working as much as I could have. But I had also sacrificed the development process when I began rushing to get the demo done. I already went over why that created a bad product, but it also created a bad work environment for myself. There's a lot of catharsis in the design process of: written design, drawn prototype, isolated test, and final implementation. Through each step of the design process, I am engaging myself in critical thought and allowing failures to appear and be solved. There is no frustration during this process (obviously I'm not aware in the moment, but this is all written after reflecting). But during crunch, I am constantly goal focused-- every road bump is a source of frustration because it means the goal is further away.
I needed to take a step back and begin committing to the whole design process again. I planned out the last leg of development (April to June) and outlined all of the features I would need to complete. Through all of this, I am going to be focusing on creating quality systems through a disciplined design process. If that means I miss my goals, then I can readjust the plan.
Progress
Through the month of April, I'll work on refining current systems then implementing AI.
Breaking Apart Large Scripts
Part of the rework is the task of breaking apart large scripts. The offense placement component has a lot of functionality which equated to nearly 1,000 lines of code in a single file. While I used regions to divide each major operation throughout the script, I still had troubles navigating the entire thing. Operations already exist in this project as singular procedures with no local variables. The purpose of a component is to perform some operation while maintaining necessary local variables. Because this particular component did many different operations, I realized I could break away those operations into their own scripts. The below sketch is my plan of how to do that.
Each rectangle defines the purpose of the script. Every method of the original script (the bloated Offense Placement Component) is categorized under one of these rectangles through bullet points.
Remove and Reassign From a List
Part of the reason for the bugs, in the game prior to the demo, was the lack of commands in the View. For the Model, every manipulation of data is done through commands that have explicit methods for execution and undo. However, in the View, I would often rely on jerry-rigged events to execute and undo functionality. Why I initially thought this was a good idea, I don't know. I did it because it seemed impossible to track a command batch through events, but I later realized I could pass a batch ID through the event.
A bulk of my work has been reworking the View to utilize commands whenever data is changed. Here's an example of that:
Below is a sketch I made when considering how I would implement a command to remove entries from a list. The key with this was to ensure I would not mess up the order of the list when undoing the operation. I also wanted to make sure I didn't remove/add entries in the wrong order, as this would cause a misinterpretation of indexes as I iterate through the removal/insertion list.
The solution I came up with was to hold a dictionary of two values: the index from which the element was removed, and the element which was removed. For reinsertion, this dictionary is reordered in reverse order.
Consistency Checks
While I was implementing commands for the View, I realized I could very easily prevent unexpected errors by implementing consistency checks into commands. Commands are made up of readonly data and they execute in a sequence, which means the functionality of an instance of a command never changes through its lifetime. If a command will modify an integer A from 3 to 4, then it will always Execute A = 3+1 and always Undo A = 4-1. With this certainty, I could pre-calculate the results of the command during the construction of the command, and use that to check if the command executed properly. This is more useful during re-execution, where it's more likely for an error to occur. This can also be done in reverse for Undo. If this command executes with the starting state of 2, then we can throw an error because we know the starting state should be 3 prior to execution. I feel like I'm wording this horribly, but hopefully this all makes sense. To put it simply: I implemented safety checks into the execution and undo of commands, making it easier to diagnose future errors.
Where I'm at Now
Like I said at the beginning of this post, I've put off this update. I began writing it before April began, but now it's mid April. I only just now finished the rework. That's behind schedule, but the silverlining is that I've been enjoying the process. I stuck to my word of focusing on the design process rather than focusing on a goal. I feel driven. Each day I stop coding, I have ideas of what I'll tackle the next day and, because I'm designing at the end of my day, I can see it all clearly. I feel more catharsis and motivation for the project than I had through February and March. Although I'm behind schedule, I can get back on track by minimizing the AI system. Rather than implementing a pattern similar to XCOM/Sims, I'll use simple hardcoded priorities based on my understanding of what works best in the game. It won't be as robust as the system I had in mind, but it should still be challenging (it was competent enough for the game jam).
The major tasks to work on next are: AI and the prediction system.