So much for getting that update done this week eh? Not really from underestimation, something else came up. Progress was made but not enough to wrap it up.

Not a ton to talk about this week, but I will say that it’s notable that skills with turn cooldowns are a bit more interesting than skills that use MP as the cost. Mostly just in the PvP context since it basically lets the other player know “he won’t be using that until so many turns!”. But even in the PvE context it’s a little bit interesting to have to choose the best time to pop it. Odds are that time will be “immediately when applicable” for things that don’t have long map cooldowns but eh. Not much else to say. Hopefully with a few days away from the game I’ll be able to come back with a fresh perspective.

So this update is rapidly degenerating into atoning for sins of the past. Long story short while working on new classes that use status effects, I decided to make one a passive on the map. I then very quickly realized I had never actually gotten around to making map passives work. And then while I was in the guts of the code I realized that most of the ability targeting code was in desperate need of an update. For instance, it hadn’t been updated to use nodes instead of tiles yet. While I was in there I added bunch of other missing features, cleaned it up, etc. It’s about done now, mostly just getting the kinks out and fixing up the interface. So! Hopefully we’ll get to test update 3 this week.

Meanwhile Sew proposed the idea of moving to having one bigger map instead of our current model of having effectively 3 small maps connected together. It has some advantages towards solving our “maps are boring” problem: It allows the layout to be more important since it stays around all game (instead of being disposable like they are now), it allows a greater sense of world, it potentially allows a greater amount of long-term emergent strategies, and it allows re-usable subnodes to be more critical to the flavor of the map.

On the downside it completely tears a hole through battle balance and pacing. How do you make a higher level player be forced to trudge through a low level area anything other than busy work that wastes critical time? A persistent problem has been with a time scale so short it’s hard to make it readable as to what difficulty level a player belongs in at any given time (in a traditional rpg it’s not a major time waste to fight a battle in an area and see how you do. not so much in this game). Right now we’ve duct taped the problem by just not letting people in an area until they’re roughly around it, but opening the map rips that apart. There’s some ideas on the table to make this stuff work. Stuff like having the map get more dangerous as the main quest is progressed. But it requires some drastic changes and doesn’t necessarily solve everything.

Right now it feels a little like a conflict of interest by being programmer and designer: I don’t want to do it because it will add a lot of programming work, and we don’t have that much time left to waste on it. So for now I’m plowing through with my planned changes and seeing if they can improve the game enough. If not, it may be time to see if we can make the open map work. It won’t be a waste of time because all of the changes will be just as relevant (if not more) in an open map anyway. In the meantime I’ll be thinking about how I can make the open map thing work if it comes down to it.

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.