This is the second part of a series of posts on simultaneity in 4X games. While you don’t necessarily need to read part I beforehand, it might help you understand some things discussed below 🙂
Our first attempt at building an interesting combat system was a naïve try to emulate the Civilization 5/6 system, also known as the “one unit per tile” system (abbreviated 1UPT), and figure out if we could slap simultaneous turns on top of it. This system is pretty straightforward and its core is contained in its name: there can never be more than one unit of a given type (military, civilian, etc) on a given hexagonal tile (abbreviated “hex” or “tile” in the future). If a player tries to move another unit into that hex, one of two things happen: 1-if the two units belong to factions which are at peace, the movement is illegal and does not happen, or 2-if the two units belong to factions which are at war, the units fight for control of the tile. If combat does happen, the units inflict some damage to each other: if the defender dies, the attacker takes control of the tile; if the attacker dies, nothing else happens; and if both survive, the attacker retreats back to where it came from.
This system is very simple to understand and supports some other features that we wanted the combat system to have in Almanach:
- Differentiable units and unit roles: we want units to have specific identities and strengths (range or melee, slow or fast, magic or flanking or flying, etc). We also want units to be able to improve during the course of a game (or possibly worsen in specific cases)
- A focus on tactical combat: we want to force players to think about how to use the terrain to their advantage. This notably meant to avoid a situation where the optimal strategy is a “stack of doom” that moves around (if you’ve ever played Risk, you know what I mean)
Unfortunately, and as is obvious on the previous gif from movement in Almanach, we very quickly came to the realization that simultaneous turns were incompatible with the 1UPT system: we just couldn’t figure out an elegant and understandable way to prevent a player from giving orders which would result in two or more of his own units being forced on the same tile! So 1UPT had to go. But how do you prevent stacks of doom without it? The answer we found is to impose soft constraints on unit stacking rather than hard ones: rather than “you can’t have more than X units on a tile”, we instead went in the direction of “you can’t efficiently have more than X units on a tile”. We are still figuring out exactly what the consequence will be for having too many units on a tile (it is not exactly a case that happens often in the demo up to now), but we are not lacking ideas:
- Units fight in a disorganized manner, diminishing their stats or life
- Only the first X units contribute to the fight, but all units take collateral damage
- Units have a chance at confusing friend and foe
- A vulnerability to area of effect abilities (a meteor is so quickly summoned nowadays)
Now that we have decided that several units of the same faction can occupy the same tile, we need to figure out what happens when units of different factions try to do the same. Naïve answer: they fight. As it turns out, this is less simple than it might look like. Consider the following simple situation:
A player attempts to move his scout to attack a lion. The lion sees the scout and also decides to attack, moving in the opposite direction towards the scout at the same moment. Does combat happen on the lion’s tile? On the scout’s? On the tile edge between the two? Say we figure that out, what happens next? The two units fight each other, then one is defeated? Does this happen instantly? When defeated, does a unit die, or simply retreats to a neighboring tile if it still has some life? If so, how does the unit choose which tile to retreat to? If defeat does not happen instantly, are the two units now sharing a tile? Or maybe the movement of both units is simply canceled since no one died from the first round of combat?
We tried and experimented with a lot of those ideas, and although some of those can look good on paper, not many of them simultaneously pass the “is it fun?” and “is it understandable?” tests. After quite a bit of playing around, we determined several things:
- Combat should happen on a hex. Hex edge combat was an intriguing idea, but ultimately way too complicated, as units could then in principle be part of 6 fights simultaneously (one at each edge).
- The tile on which combat happens does not really matter, as long as there are clear rules to determine on which one it should be (at the moment, “the stronger army moves forward, the weaker one stays” seems to be working pretty well).
- Units should not die from a single combat round. Its just annoying, and puts too much luck into the mix. Thus, combat should last more than one round. This allows for much more tactical engagements, especially if reinforcements and retreats are allowed. Side note: this seems to also be what Ara (an upcoming competitor of ours, check it out, it looks cool!) will be doing, although they’ve been pretty stingy about any kind of details regarding gameplay. Looks like we aren’t the only ones looking into simultaneity, at the very least!
This gif illustrates what a simple combat between the scout and lion looks like at the moment. Once combat has started, it can last several rounds. Every turn, you can check what happened in that fight since the last turn, which is essentially that the scout and lion are inflicting damage to each other according to some predefined rules. Once the life of the scout reaches zero, it dies, losing visibility of the tiles, and we are left to contend with the aftermath of the decisions that led us there.
So why is this interesting? Because this little interaction, although mostly automated, still leaves quite a lot of wiggle room for the player to interact with it. Most notably, both factions could have brought in reinforcements at any point during the fight, thus tipping the odds to ever be in their favor. Alternatively, both units could also have retreated until almost the very end during the fight, following one of the directional arrows appearing around a hex when it hosts a combat. These arrows indicate that retreats can only be made in specific directions: the active player may only retreat along the green arrows (placed in the direction they came from and around it), and their enemy may only retreat along the red arrows. Blocking retreat avenues effectively prevents a unit from exiting combat, so moving other units around a fight can rapidly become an interesting tactical challenge. Do you want to secure your own retreat if you need it, or cut off a critical direction from an enemy so that they can’t later join up with reinforcements?
It is still early in the testing to really say whether everything will stay as it is presented here, but what we see from these early interaction seems pretty convincing: there definitely is fun to be had moving units around and outwitting your opponents with this simultaneous system. And although some things can still be upgraded in terms of clarity, we do believe that the visuals we added to convey information go a long way into making combat situations readable. Our plans for the combat system also include:
- Stealth (already implemented, will talk about this in a future blog post!)
- Ranged combat (very soon)
- Sorcerous spells (not quite as soon)
With all those elements, we believe that a deep, tactical gameplay will emerge from this experiment in simultaneity.
As usual, if you liked this post, be sure to support us by subscribing to our newsletter (right below, make sure to check your spam after hitting the button!), letting us know what you think in the comments below, or join our community Discord server! Hope you enjoyed, and we’ll see you next time!