Sorry for the silence, have been on holidays. Had a wonderful wedding to attend in Poland before a delicious and boozy stay in Prague. Mmm-mmm!
Something you might actually care about is that I’ve just built a new PC. It’s powerful… very very powerful. My plan is to start working on some Game Design focused Let’s Plays, although I’m sure I’ll be pretty bad at the start. Let’s Plays, Design Articles, as well as solid work on Ventura… this is my plan until the end of the year.
It’s a very exciting time and hopefully it will help build my ‘brand’ and spread my network, while improving my own skills and design abilities!
I’ll probably be starting properly next week, with a couple of days this week to reacquaint myself with Ventura and let you all know if I’ve finally fixed the damned clashing!
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.
Myself and Chris gone and did a podcast. As I am a noob with hosting and iTunes and RSS, and Wix.com doesn’t allow it, I am going to stick them all on Virtu so I can get the feedburner working. It’s lame but hey, at least any random dudes looking at this god-forsaken blog can get some audio content!
I was in Qingdao the home of Tsingtao beer for a short break, so apologies for the lack of posting.
Here’s post 5 of my Ventura Combat System progress.
Some quick context for new readers as to what the combat system is trying to achieve…
1v1 combat with teams of 5 Mercenaries
Simultaneous Turns, with a Planning phase (making moves) and a Resolution phase (witnessing the outcomes)
Two Maneuvers per Turn
In your Maneuver you can Move, Attack, or Idle
There are no targeted attacks, you select a direction and your character’s attack ‘template’ will affect tiles and enemies below it
There are plenty of more details, but not for version 1!
Combat Week – Day 5-6
Last week we were introduced to Maneuvers; the two orders you can give your Units in a turn. On Day 4 we got a single unit moving; Lucina, who could select two tiles and move along a path towards each destination sequentially.
Day 5 & 6 involved inputting Maneuvers for all other members of the player’s team. This was much harder than I imagined, as there is a lot of logic I didn’t really think through when the initial thought seed begun.
Maneuvers are planned, they do not begin as soon as they are inputted. The moves are made and then, when each unit has locked in their 2 Maneuvers, all the movement has occurs at the same time; first Maneuver 1, then Maneuver 2.
What’s tricky about this is that the Units need to sync up at the end of each Maneuver. If Lucina is moving 1 tile to the right, but Basilio is moving 5 tiles up and 3 tiles across… Lucina has to wait at her Maneuver 1 destination before beginning Maneuver 2.
Remember the order of the outcome phase?
Maneuver 1: Idle
Maneuver 1: Attack
Maneuver 1: Move
Maneuver 2: Idle
Maneuver 2: Attack
Maneuver 2: Move
If Units are not waiting at the end of their Maneuver 1 for the other Units to sync up, they might move out of the way of a Maneuver 1 enemy who is still attacking. There are also plenty of opportunities for tiles to contain 2 Units in them (which needs to be forbidden), so to keep the game fair I have to make sure that when Units ‘clash’ they’re clashing at the correct point. We’ll talk about clashing in the future.
My ideal situation is that eventually I will be able to increase/decrease the speed of each Unit so that they all arrive at the same time regardless of distance traveled. For now that’s not necessary though, so I spent most of Days 5 and 6 implementing the ‘waiting’ logic.
As a side note; I’ve discovered that as a Designer who was forced into Programming, the perspective you get from coding is truly valuable. I used to naysay the idea that designers should know how to code. I still don’t think an extreme level of knowledge is needed, but it definitely helps to have my crappy level of ability. It helps so much with logic and ensuring that your design doesn’t have gaping loopholes and conflicts.
Programming the waiting logic was tricky, especially when I have to perform both players’ actions (a logic that isn’t used in the finished product). When the 5th Unit completes their 2nd Maneuver, the team needs to switch to Player 2’s first Unit. Then, when the 5th Unit of the 2nd Team completes their 2nd Maneuver… the Outcome phase begins.
Here’s how I coded it;
The Combat Controller (an object that watches and maintains states) is constantly looking at the Maneuvers that are taken.
Each time a Unit completes a Maneuver order, it adds +1 to the controller’s tracker variable.
There are 5 Units and 2 Maneuvers per Unit, plus 2 Teams.
So, when the tracker variable reaches 10, Team 1’s Maneuvers are all ready.
When the tracker variable reaches 20, both teams have completed their orders.
At this point, the Phase changes from Planning to Outcome.
This phase change triggers Maneuver 1’s path for every Unit, at the same time, on both teams.
Units start moving.
At this point, we start tracking another variable.
At the end of every movement path, the Unit will add +1 to the new tracker.
As before, the Tracker is searching for a value of 10 before it can say that Maneuver 1 has been concluded (5 units, 2 teams, 1 Maneuver)
Once 10 is reached, all the Units that have already complete their path will then begin their Maneuver 2. This syncs up all units on both teams.
Once 20 is reached, the Outcome phase is over and the Combat Controller switches back to Planning mode for player 1.
So a couple of mornings worth of work and I can now move every Unit twice and turns will complete themselves. It’s quite cool to see it in motion, although a little confusing to display with my alpha art and lack of VFX
Design Decisions RE: Maneuvers Pt.II
Last time we talked about Frozen Synapse and how its Simultaneous Turn Based system was a big influence on my concept for Ventura’s combat. The second influence, related to Maneuvers, is XCOM: Enemy Unknown.
Ventura’s combat system is a like a hybrid of XCOM‘s two-manuever system and Frozen Synapse‘s Plan/Outcome system. Like Ventura, in XCOM you can also perform 2 moves per turn.
You can move twice
Or you can attack twice
Or you can move once and attack once.
You can also use an ability or an item in place of a movement or attack. I haven’t played it in a while, so I have to confirm, but I believe that you can’t attack and THEN move unless you have a certain perk on your Unit.
This system creates a nice strategic resource to plan around. Positioning is extremely important in XCOM, as cover creates an imbalanced situation for Units standing in it (they’re very powerful compared to being completely screwed in the open). Using 2 moves to quickly grab hold of a piece of terrain is a valid strategy, but to do that you give up both that Unit’s offensive and defensive capabilities for a turn. If you choose to attack twice, you have a large sphere of area denial, but can be out-maneuvered by more mobile foes… especially as cover is destructible.
I plan to have terrain on my Combat Grid, which will simulate similar effects as in XCOM, but the real takeaway is the question; “Do I stay mobile or do I try to punish the foe?”.
To stand still in Ventura is very risky, as Units are attacking tiles and not targets. A moving Unit in Ventura needs to be pre-empted with an Attack Maneuver. They could move to any tile within their movement range, so it’s a guessing game for the enemy. A static Unit is easier to predict. You know that if a Unit decides to Attack, they will be standing on that tile for that Maneuver.
I’m hoping Ventura will be an intense and strategic battle of minds, as you try to predict how each of the enemy’s 5 units will use their Maneuvers. Predicting where the enemy units will be moving, and when they’ll be attacking (therefore standing still), is half the battle… the other half is trying to surprise your opponent by acting unpredictably while still trying to intercept and damage their units.
Perhaps standing still and attacking twice in a terrible battlefield position is so unpredictable that you come out unscathed and cause vicious damage to an enemy!
This is what I’m trying to achieve with my combat system. The speed and mind-games nature of Frozen Synapse, with the simplicity and readability of XCOM. One fear I have is that while going for very short turns, I still have too many variables and possibilities that hinder the speed of action. 5 Units perhaps is too many, so we’ll have to see in playtesting whether it truly works or not.