Red Brick Games

So much work… these squads and modes…

So the main benefit of squads is that they allow soldiers to march around in nifty-looking unit formations, right?

But in Orcs vs. Martians, I’m thinking squads can benefit workers, too.

Counterpoints

But first off - I can’t see squads benefiting most worker actions. Like when workers go to harvest resources - why would you want a squad there? If you tell several workers to harvest a tree, having them march in formation to the tree would just look dumb.

I don’t see squads benefiting the paving of roads, or repairing of buildings, either.

But the one use case is…

But there’s one big exception where worker squads of do look beneficial: building new bases.

In Orcs vs. Martians, building new bases is a fairly high-risk endeavor. Workers are required to carry resources (i.e. building materials) out to the building site. Unlike other RTSs, your stockpile of resources is not magically, omnipresently, available everywhere on the map! You have to carry resources to where you need them, just like in the real world.

So when you send workers out to build a new base, you’re not only risking the lives of your workers, you’re risking the resources that they carry. If those workers die, they drop their resources. To make matters worse, if they die too close to enemy territory, the enemy may retrieve the resources — thus benefiting from your loss.

So it makes sense to protect building parties.

A solution

So squads of workers start to look attractive here.

Why? First, it takes several workers (currently 4) to carry a sufficient quantity of resources to build a new base. You don’t want each worker to walk independently, in a long line out to the building site — that’s harder to manage and protect. Much better for workers to walk together, as a group.

Second, if there’s much risk at all of enemy attack, you’d want soldiers to escort the workers. Formations also then become attractive. Preferably, you’d like the vulnerable workers to travel on the inside of the formation, and the tougher soldiers to travel on the outside. In practice, these formations may not be big enough to have an “inside” and an “outside” strictly speaking, but 4 workers could be protected pretty well by 2 soldiers in front and 2 in the rear.

Squads to the rescue?

Squads provide a nice solution to both those issues.

Here’s the user experience I’m thinking of: the user multi-selects both workers and soldiers. The game detects the mix of different unit types, but shows only the “Worker” command palette. The user issues the command “build new base”. The workers converge on their current base, picking up resources to build with.

Here’s where squads come in. The game internally creates a squad for the workers, and waits until all workers have their requisite building materials. Only when they’re all ready, do they leave for the building site. This ensures they travel as a group.

The soldiers also get added to the squad. The already-existing logic of the squads puts the units in formation as they travel (assuming the user has turned on the formations option). The squad can also be made to detect the mix of unit types, and put the more vulnerable units (workers) on the inside, and the tougher units (soldiers) on the outside.

Problems solved!

Having worker squads will also be a boon to the game’s A.I. players. From playtesting, I can attest that A.I. builder-workers are currently too vulnerable; they’re too easily picked off. A.I. players sometimes lose a lot of resources while trying to set up new bases. (a problem observed in many other RTS games too, not just OVM!) This will help that.

Worker squads could also be used for other building types besides bases. They’re not really unique to bases; it’s just that bases are the most-frequent use case. Probably the criteria for whether to form a worker squad, or not, would be distance to the building site. So e.g. if you wanted to build some distant towers, you’d probably want to use workers squads for that case, too. The game could be made to examine walking distance, or some other criteria, and auto-detect when it’s best to organize workers into a squad.

(”lions, and tigers and bears, oh my” - The Wizard of Oz)

I’m still working on squads, but I’ve also branched out into improving Orcs vs. Martian’s concepts of “modes” for units / squads.

Tecnicals

Previously, each unit in OVM had a single ‘mode’ it could be in. Modes are things like

• going
• attacking
• holding
• exploring
• escorting

etc. If the unit is a worker, the unit can have one of the worker-specific modes:

• harvesting
• building
• paving

etc. etc.

For a while, that was all fine and well. But there was too much code redundancy between the modes. For example, there’s an explicit “Going” mode; but nearly all the other modes also involve “going” in some sense; in “Harvesting”, for example, a worker is constantly going to a tree, back to base, going to the tree again, etc.

Also, I find myself wanting more flexibility than one-mode-at-a-time allows. Namely, I see being able to spawn sub-modes (sub-goals) as being useful.

For example, when a squad goes to attack a base, and it encounters an enemy squad along the way, I’d like the squad to be able to spawn a sub-mode. That is, “engage and defeat this enemy squad”, and THEN continue with the march to the enemy base. So in that case the squad briefly has two goals - the main goal of knocking over the enemy base, and the temporary goal of defeating the enemy squad it encountered.

After mulling these things over (for quite a bit), I’ve decided to try a stack-based approach to modes.

Each unit or squad has a main mode (or main goal), but as it encounters obstacles to accomplishing that goal, it can spawn sub-modes. Those sub-modes can spawn their own sub-modes, etc. All modes get pushed on the stack. As the sub-goals get accomplished (like, “enemy squad defeated”), they get popped off the stack, in the reverse order they got pushed on. The unit / squad then continues with the earlier goals.

The stack-based approach also nicely eliminates redundant code. Whenever the “Harvesting” mode (or some other mode) needs to make a unit “go” somewhere, “Harvesting” can spawn “Going” as a sub-mode. “Harvesting” and “Going” therefore don’t have functional overlap, since one builds on top of the other. Ergo, less redundant code.

I’ve been hesitant to go this stack-based route. I mean, it just seems like one more complication. But, it does seem necessary and useful for what I want OVM to do. So here we go…

- - - - -

These last couple of weeks have been slow, coding-wise. This game is the first project I’ve done that has substantial A.I. in it, so I don’t have much prior experience to draw on. It’s been slow trying to figure how to do some things.

Most of the last two weeks, I’ve been just sitting in a chair with pencil and paper, a question mark over my head, thinking and writing. Which is a little frustrating to me! I much prefer the “doing” phase of programming, where one has a pretty good idea of what needs to be done, and is typing away at the keyboard.