This post will be somewhat of a ramble as I’m going through a pretty tough design decision in Ventura’s combat system that I want to work through on ‘paper’.
If you’ve been reading regularly, you’ll know that Ventura’s combat system is simultaneous turn-based. This means that both teams set their orders at the same time, then those orders playback simultaneously. Unlike a regular turn-based combat system, players are moving and attacking speculatively; the information they have available to them is historic. The enemy is making moves that the player cannot witness until it’s ‘too late’.
Because of this, typical easy-peasy design concepts like “One Unit One Tile” aren’t quite so easy. If I decide to move my barbarian Gregor to tile B6 and my enemy does the same, then both units are in B6. More than one unit per tile is a regular occurrence in Ventura right now, it’s the nature and limitation of the system; a fundamental issue.
I call this Clashing. It can happen in two situations;
Destination Clashing: The player and their opponent both select the same tile with one of their own units’ move actions. These Units therefore arrive in the same tile.
Path Clashing: The player and their opponent both select tiles that cause the movement paths to cross during their units’ move action.
Currently I’m attempting to build a solution that causes a move action (and the next maneuver’s move action) to be blocked by Destination and Path Clashing. This causes the moving Unit to be stopped in the tile they previously moved into if there’s any collision detected between them and another Unit. I’ve been struggling with the tech side for a few mornings, but I’m already wondering whether this is even a solution I want.
With 10 Units in the grid, and 2 maneuvers per Unit, there are going to be clashes all the time. I was imagining that a clash would be a rare occurrence but from testing my solution it’s clear that the speculative nature of simultaneous turn-based combat and the amount of Units I have is going to increase the frequency of clashes.
I don’t think I want a lot of clashes. I want players in Ventura to know where someone will be and where they will attack as much as I possibly can. Clashes are extremely disruptive. If Units are constantly having their moves cancelled then players will have very little idea where their Units will end up once the outcome phase is over, let alone from which tile they will attack.
I need to work on an alternative, but there are a lot of options and I’m finding it hard to choose between them…
Alternative 1: Remove Path Clashing, Keep Destination Clashing
In this solution, a Clash will only occur if Units stop in the same destination. If they cross paths, they’ll just pass through one another. This will reduce the number of clashes. Unfortunately it’s messy because I need to determine where the two clashing parties end up if this happens. I’m struggling to think of a fair solution that also makes sense.
Alternative 2: Grappling
Grappling is an attempt to make clashing an actual mechanic. Like the above solution, path clashing will not occur. However if Destination Clashing occurs, the Units are actually kept on the same tile; locked in hand-to-hand combat. Much like above, there needs to be some logical and fair way to resolve the grapple. I like this solution because it creates more gameplay. It makes intercepting someone’s movement a valid tactic and grappling with a Unit could prevent them performing powerful moves. It’s like a gamified Skip Turn move. For this solution to work, I need a new form of resolution to determine when the Grapple ends, who wins, and where both parties end up.
Alternative 3: Weight
Weight is a mechanic I could add to prevent some of the disruption caused by clashes but not completely ignore them like with Grappling. Currently if two Units clash, both have their movement stopped and their next movement cancelled. Weight would add a priority value to every single Mercenary in the game, with the higher Weight Unit being allowed to continue their path unhindered. This would halve the disruption, and add a unique flavor to certain characters with a low/high weight.
As you can probably tell, this is a big deal! If I cannot solve this in a reasonable way, my whole combat system is compromised. I’m very confident a solution will be found, but to make sure it’s the right one I think I’ll have to branch my project and create 3-4 solutions.
Very time consuming, but it will be ultimately worth it!
I won’t be posting as frequently as on here, but I’ll be posting less “omg MORE Ventura?!” articles and creating some more unspecific content for your amusement. So far we’ve published our first ever DevPact Podcast and I’ve written a couple of articles about Stephen King’s On Writing, a wonderful book that’s made me think about Game Development in a different way
The problem with doing catch-up blogs is that you’ll never bloody catch up! Combat Week started on June 1st and it’s taken me over a month to blog about it 😉
You’ll be pleased to hear that I’ve been slugging on with my combat system since then, despite certain global launches and the constant ball-ache that is ‘life stuff’. So it’s strange to end this daily commentary on a week of work when it’s already advanced a lot since then! Nevertheless, here we go…
Combat Week – Day 7
Previously on Ventura Combat Week, we got all our Units moving in both their maneuvers. It was a grand old time. Now it’s time to stop dancing around the battle field and start brutally punching each other!
Day 7 (and a little at the end of Day 6) was all about Attacking!
In Ventura you do not directly target enemies. Due to the nature of its simultaneous Turn Based play, and a general focus on melee combat, it wouldn’t make much sense to pick out a guy or gal to kill. Targeting a specific enemy, 2 moves in advance, would mostly just end up with a miss… every time. Targeting a certain tile 2 moves in advance has much more flexibility; no-one can get in the way, the tile can’t move, and who knows who will be standing there when the attack eventually activates!
The main goal is to deal some damage to something if you choose to attack, which I believe this system accomplishes. So how does it work?
On an Attack Maneuver, you choose the Unit’s attack direction. In the screen above, this is the pointy red frame. The red tiles are the ones that Lucina will attack when this Maneuver plays out. Any enemy inside one of those tiles when her Attack Maneuver triggers will take damage.
Attack Templates are probably the biggest differentiator between Units in Ventura (although I’m a long way off having my 20+ individual Mercenaries). Some Units can attack an entire row, some can attack very specific tiles (like Lucina above). The obvious balancing factor is the amount of damage dealt by each attack, with specific templates more likely to be dodged than large areas of effect.
Much like fighting games (i.e. Street Fighter), Ventura’s combat system is based on the control and exploitation of space. The wonderful PBS Game Show just did a video about this last week, which I highly recommend watching;
While not completely intentional, I’ve got a funny feeling that Ventura’s design will feel a lot like a battle in Street Fighter. Trying to increase your ‘area of influence’ while restricting your enemy’s is the name of the game in both Ventura and Street Fighter. What will be interesting is to see if this is workable, and fast paced, in a 10 unit 8×5 grid!
Now that Combat Week is over, I can get back to real-time updates! Here is the GSD comparison from before and after this productive period;
Lots of bloody orange! Before I uploaded this image, I forgot how much I’ve done since Combat Week ended (back on June 8th), which is a nice feeling! Since then I’ve got all Maneuvers working, sound implementation, damage implementation and ending turns probably sorted out. A lot of the above orange is now green. There are plenty of bugs but it’s getting there for sure.
I’m hoping that next week I’ll be able to post the long-overdue greenlight post for Ventura, as I still haven’t justified the project on the record.