Druid's Haven: Reactive Design

We had a big design discussion at the beginning, and we all contributed, but implementation wise I was the one to decide how to implement it. There was unfortunately lots of ambiguity as the design discussions were very abstract. That did hamper my ability to plan, so I just gave up and broke down what I could and added what I thought were the simplest gameplay mechanics to start off. Fortunately that did help a lot, as it gave me a starting point. It also led to lots of emergent gameplay, as synergies from plants can add a lot of variety and easy upgrade ideas. The ideas kept coming, and the implementations were fairy easy. I would also iterate quite easily and find what was fun and what wasn't.

Juice it Up

We only had a single sprite artist working, so I had to improvise and instead of animations I could just use the time tested squash and stretch technique. This is an example of the tractor enemy.

Too much to teach

The downside to having so many interconnected mechanics is you have to gradually introduce them, and there just wasn't enough time with the time I had especially having skipped a week. I did try and make the UI/UX as self-explanatory as possible and introducing the replayability, hopefully allows players to discover on their own.

A lot of absence

We did have a lot of instances of even weeks of not having the team be active. I myself did have a week-long vacation coincide with one of the sprints, so I had to push a lot of the work for the final sprint. Unfortunately the rest of the team was absent a lot of time, except for one of the artists.

Rouge lite

It was very late in development that I had the chance to implement upgrades. And it was a great idea. It made the game click into place. Permanent upgrades were even later addition, but they did help a lot with balancing, since they acted as dynamic difficulty, if you failed a lot you get to have a lot of upgrades.

The theme

I wanted to avoid dumping walls of text to the player, or having too much lore as this tends not to do great my experience in game jams. As this particular game target audience doesn't have the patience to sit and read long text. Though sharing that sentiment myself probably biased my decision. I did add lots of synergies to show some of the climate message if plant diversity and how a monoculture or even distribution can affect plant viability. For example having many species of plants (a monoculture) can lead to easy propagation of diseases that target the same genetics. With the help of permaculture techniques the viability of forests can be increased, in areas like water retention, soil erosion, heat dissipation, etc. Concepts we hint at.

Reactive Development

I decided early on that I wanted to go all in on the reactive pattern. I've used R3/UniRx before but this time I went all in. Reacting only on changes did bring some improvements especially if you commit to it. You can decouple your logic pretty easily and make more but just subscribing to changes from many different managers, the only downsides are, you have to worry about unsubscribing, it does introduce more memory usage, and you have to juggle script execution ordering. But R3 makes things easier in the disposing department.

Performance gains are numerous, given you run logic only when dependencies change.