The Big Ideas

Inspiration

I was chatting with a vore-flavored group of friends during the middle of 2021. The topic of healthbars came up (who doesn’t love ’em?).

I thought it’d be funny to tease someone by whipping up a little Unity project that showed the bars sloshing around in a monster’s gut (and going down, obviously).

So that’s how this began! I literally started with the health bars, and went from there.

Design

Early on, I decided on a fundamental principle: both sides should be equally playable. That is, the player should be able to effectively control a single monster or an entire village. This called for very generic, very extensible design.

I don’t have my older records – I switched from Collaborate to Plastic SCM and didn’t save the commit logs – but I’ve definitely spent most of my time implementing “boring” stuff.

Abilities

When you think of an “ability”, you probably think of what I’d call a special ability: a hero unit’s spells, for example.

In RTS, everything a unit can do (other than moving, I guess) is an ability. Villagers have a Gather Resource ability. The monster has a Stomp ability. Town Centers have a Build Unit ability.

Even what you might call an “autoattack” is going to just be an ability!

Abilities are defined by what they can target, parameters like range, features like area-of-effect and channeling; and, of course, the actual code to execute them.

There is no concrete system for how abilities work, but they’re generally state machines. They send instructions to the unit’s animator and wait for messages as the animation reaches certain points.

Abilities can sometimes be cancelled voluntarily…and they can always be interrupted by a third party (:

But, to make any use of these, we have to be able to give units commands! Thus…

Orders

Anything that you can select can be given orders. An order instructs an entity – a unit, building, etc. – to do something. Entities store a queue of orders, and whatever’s at the front of the queue gets handled.

Importantly, orders can generate more orders. For example, if you tell the monster to stomp on a villager, the following sequence happens:

1. The Ability order immediately goes off and tries to cast Stomp.
2. Stomp fails, reporting that it is out of range.
3. The Ability order issues a MoveInRange order, then makes a copy of itself and puts it right behind the move order.
4. MoveInRange tells the unit to get within a certain distance of its target – in this case, the villager unit.
5. MoveInRange resolves. The Ability order is handled.
6. It fails! The bat isn’t facing the villager. It queues up a Face order (and another copy of itself).
7. Face resolves. The Ability order is handled.
8. This time, the ability successfully executes.
9. Once it’s done, the Ability order finishes.

This allows for very complex behavior with very simple building blocks. This order-spawning process is also recorded for the sake of…

AI

What’s a single-player game without a decent AI?

At first, I only had unit-level AI – each unit decided what to do individually. This was limited to eating people and/or wandering around.

Much of my recent work has been focused on force-level AI. A force is a team: villagers, monsters, or Gaia (for neutral entities). The force AI makes decisions for every single unit the force owns.

A force AI is made up of several modules. For example, here’s the current stack for the villagers:

• Build villagers
• Place depots
• Place town centers
• Place houses
• Assign villagers

The AI decides where to do things based on influences. Here’s an example for the placement of depoits:

It wants to put depots near resource piles but far from existing dropoff points.

This is done via hill climbing: it tries to move up “hills” towards the highest point. There’s also some randomness, so that it doesn’t just get stuck in a bad spot forever.

I use this alongside more traditional logic (e.g. don’t try to build a new town center until you have enough villagers). There’s still lots to do in this department (including fixing a bug that makes it hill-climb to the wrong place…)

The AI also keeps track of all the jobs it has assigned: right now, buildings being constructed and resources being mined.

If the AI sees that a unit’s order is done, it checks if the order made a copy of itself, or if it’s truly finished. It will then update its records or throw that task out entirely, respectively.

So, if a villager is assigned to build a house, but winds up getting swallowed whole, things don’t get stuck (:

Other details

I’ve worked on plenty of other smaller things too, of course:

• Selection groups
• Fuzzy targeting (making it easier to click on small units)
• Lots of camera modes, plus cinematic and macro-POV action cameras
• Camera shake and other special effects based on monster movement
• Content filters for individual objects, sound effects, etc.

I want this game to feel nice!

Looking forward

Once I’m reasonably happy with the AI, I’ll be releaseing alpha 9. I’m thinking I’ll swich to working on the kinky stuff again: sound effects for stomps, particle effects for burps…that kind of thing. That’s what we’re here for, after all (: