Didn’t manage to push out an update for testing this week. Update 3 has been a little hard to work on because it doesn’t have an underlying theme of “this is what I’m trying to fix this week”. Without that guiding element I feel a little bit like I’m just flailing on it. So I’ll probably try to keep some kind of theme in mind for each update from now on.
The big change for Update 3 is allowing status effects to work on the map. This is technically a feature that should have been added ages ago, but was one of the things that got shoved on the side for the sake of other things. While it doesn’t necessarily fix any single flaw in the game, it does provide a powerful tool for several problems: it provides a way to alter how players treat the map a little more because status effects can trigger on each step between nodes, it opens up one avenue of letting players manipulate other player’s movement temporarily with offensive status effects, it allows traps to have longer term consequences, and many other possibilities. What it doesn’t do is improve the way traps trigger to be more thought provoking or any of the other big problems. So it’s really about building a tool for the future more than anything. For the time being I’m just slapping in a few scattered ways to use them across the game in order to test the functionality.
Meanwhile I’m actually working to spruce up the code in this update too, fixing up one of the bigger remaining messes. When I started this thing I tried to have a philosophy of “the next time I have to touch this part of the code to add something, I want to leave it better off than when I started”. It’s not a philosophy I’ve followed as closely as I should have, but I don’t entirely regret it since it manged to get us this far. There’s gonna be a lot of big changes in the future, each one is an opportunity to make things better. For instance, I put no thought into saving the game state. So that’s going to be a really fun update.
On that note I need to gear up to start writing automated tests. When starting work on this thing I deliberately decided not to write tests alongside it because I knew massive design changes were going to end up happening. Probably a controversial choice, but this prediction also ended up being completely true. Yet in reflection I’m not entirely certain the time saved on not having to re-write tests paid off considering the high percentage of debugging that went down which could have easily been prevented with basic automated testing. On the other hand having the opportunity to comb through the entire codebase a second time and improve it as I go with the capacity for hindsight and a view of the whole structure in place might yield some big benefits (Of course TDD advocates will say that if I had just written the test cases to begin with the structure would have been better to begin with. But when you only have one set of eyes available for a project, the mists of time revealing all of your inadequacies is actually a pretty powerful asset).
I guess what I’m trying to say here is that the conventional wisdom is that you want to write a piece of code to be so good that you never have reason to update it again. And it’s true, that’s perhaps the truest ideal for a piece of flexible, clean code- that future unplanned additions should be placed around it rather than within it. But for this project I’ve been trying to get more into the mindset that it’s good to try to improve the health of the codebase as you go. To trim the hedges. That it’s probably impossible to attain that ideal design on your first shot, and it’s better to work towards it instead of leaving a mess on the floor to rot.
A long road is ahead for sure, but for the time being getting the game to be fun is still my highest priority.