Some of WolfQuest’s game code is over ten years old now — that’s older than most of the wolves living in Yellowstone today, and older than some of our players! Over the years, that codebase has grown enormously, and while we’ve revised, refactored, and rewritten large chunks of it, it’s certainly feeling its age.
That’s why we’re starting over with Episode 3. Every line of gameplay code in Tower Fall will be fresh and new. Tommi, our lead Unity developer, has been working on this new codebase for over six months now, merging his knowledge of WolfQuest gameplay with some fresh perspectives on code design.
What do we gain from this effort?
- We can design the entire episode as a coherent body of code, rather than incrementally, adding features one by one, as we did with the original game. That’ll give us a clean, modern codebase for ongoing development and expansion.
- We can implement a new type for AI. Instead of behavior trees (essentially branching if/then logic), we’re using Utility AI, which creates more naturalistic behaviors based on the animal’s current priorities and available options to satisfy their needs and wants.
- We have a blank slate to redesign some features — like a new, more naturalistic spawning and scent system for prey animals.
- We can make core elements more robust and modular — for example, setting up new animals is very cumbersome now but will be much easier in the new codebase. We’re also making it easy to let players switch from one animal to another at will. (Not saying this will be included in Tower Fall’s initial release, but you never know…)
- We can build a new wolf and camera controller, with better camera controls (including a mouse-driven camera orbit), vastly improved Jump function, and other improvements.
- We can make the game fully compatible with Xbox and Steam controllers.
- We’re writing code in a special way that will allow automated testing, which should help us identify and fix bugs far more quickly and efficiently than in the past.
Of course, because we’re starting from scratch, it may take longer to produce Episode 3 than if we’d stuck with the old codebase (though given the state of that codebase, we had expected quite long development and bugfixing periods for it too). And it will create some inconsistencies with the old episodes — though we do want to rebuild those episodes eventually with the new codebase, as long as sales continue at a decent level. But we think those are tolerable tradeoffs given all the benefits of a new codebase — and the robust platform it will give us for future development. (Episode 4, anyone?)