2016 Update

Hello one and all!

It’s been a long time since the last post and I felt it would be a great opportunity to update you all on myself, DevPact, and Virtu’s current project.

Recently I moved to Berlin and I have been working at YAGER since January. It’s my first ever AAA gig, and it’s been wonderful. The different styles of almost everything based on the size of the project is really surprising.


Our major project at the moment is Dreadnought, a class-based space arena shooter. My responsibilities revolve around everything ‘Live Design’. Balancing, feedback collection and response, tweaking, analyzing, and designing existing and new features for a game that’s going to be running 24/7 for many, many years.


Much of my previous experience at Substantial Games and EA Playfish revolved around this style of game, and I’m looking forward to being involved with our community and encouraging a more ‘open dev’ approach to AAA F2P PC services. Exciting stuff!

An interesting side-note is that every game company I’ve worked at has been completely different… Facebook games, Casual Mobile games, Hardcore Mobile games, and Hardcore PC games. I’m looking forward to entering this extremely different sector and deciding which type of company I prefer and which type of games I want to design.


Myself and Chris left China at a similar time and while we are still in touch, there’s definitely a lot less peer-pressure to keep up with DevPact’s original posting and content frequency. As of now I’m assuming it will linger around untouched til the end of time. All content I would be producing there I will now just be doing on here, my original site!



Having such an extended break between pausing Ventura, starting a new project, leaving Berlin, then starting another new project has changed things drastically for Virtu and my own personal independent development.

Ventura is near and dear to my heart, but multiplayer is something I’ll have a very hard time sorting out and the game itself becomes extremely complicated from a coding standpoint when you take into account that every Hero has 4 unique abilities. Before it went on hiatus, I was somewhat building an engine to enable me to bust out loads of possible Ventura heroes… but as I came back to look at the project a couple of months later, it dawned on me that the work needed to make Ventura a mildly exciting game was humongous. Like most multiplayer strategy games, it’s designed holistically and building a vertical slice of content in order to get feedback would take a very, very long time.

Welcome back to Haft

Since arriving in Berlin I’ve started a new project with a new mentality and new set of goals. Before I was setting up Development Pacts with my friends to force me to work hard. I was hoping to enter IGF 2016 and ensure that every second of my part-time indie dev was working towards a greater goal. I hated it. I was beginning to detest the whole idea of indie game development so I’ve taken a step back and calmed down.

My latest project is being built very casually. I’m not super stressed about whether the scope is too large or not. I don’t care if it’s commercially viable. I’m not aiming to blow peoples’ minds with an intense multiplayer combat experience.

I’ve got a simple question that I want to answer… how would a Turn-Based RPG work in a Civilization style 4X feature set?

It may not work at all. It may be amazingly innovative… all I care about right now is answering that question. I’m not going to get stressed about it, I’m not going to beat myself up, I’m not going to hype up the idea that I’m fighting for awards or all that crap that’s way too far out of my reach at this point.

It’s liberating!

This project is being called ‘Fellowship’ at this point. When I feel like sitting down and explaining what the hell it is, I’ll make another post on here and set up the Fellowship category.

The only hint I’m giving about Project Fellowship

For now I’m just enjoying life, enjoying work, and enjoying tinkering around in Game Maker.

Since last posting, I also entered Ludum Dare 34 with the best game I’ve ever built myself; Slum Runner. In a way it saved my indie-dev life.


I’m insanely proud of it so please give it a spin if you see this and let me know what you think.

Ventura Mechanics: Attacking

In this series of articles, I’ll be spotlighting individual mechanics in Ventura; explaining why and how I’ve made them. I’m hoping this will not only give you guys insight into the design process, but also help me clarify and distill my own mechanics!

Part I: The Best Offense is a Good Defense

From my experience, most TBT games have completely open attacking. As long as your target is within attack range, you can attack them. It does not matter if there are 5 units between your current unit and his/her target, you can magically hit them.

I don’t like this, and a lot of it comes down to my love of Tanking and what the implications of open attacking are for defensive plays. When I’m thinking of the sort of experience I want to provide in Ventura, I am always pushing the interaction between units and the importance of positioning.

World of Warcraft
World of Warcraft

Tanking was first introduced to me in World of Warcraft. As my first MMORPG it was incredibly refreshing to play a character whose sole role was to protect allies by putting themself in danger. World of Warcraft uses the classic Aggro system of tanking; using a semi-transparent resource that the Tank can build up against enemies. These enemies then attack whoever has the most Aggro on their list. Allies using Heals will generate a lot of Aggro, so the Tank needs to have the ability to build up plenty of counter-aggro to make sure they stay on top of the Aggro List for each enemy.

Naturally this only works in PvE situations. Human opponents do not have an Aggro List that can be manipulated by another player. Skilled human opponents know the natural threat level of each enemy and choose who to put on their personal aggro list. No amount of bluster will make a human attack a super defensive target… it’s madness to do so!

Axe from Dota 2 - Calling enemies to fight
Axe from Dota 2 – Calling enemies to fight

Dota-likes (or MOBAs) also attempted to create tanks that work in PvP situations. As a tank cannot force humans to attack him, they must incentivize humans to attack them. This is done in a few ways…

  • Crowd Control: Being stunned and silenced is usually a major pain in the ass. PvP Tanks tend to have abilities that mess up enemy formations and combos. This makes them a high priority target in many situations, as they shut down your team’s strategy.

  • Sustained Damage: This is the classic “Deal with me now or you’re going to regret it!” technique. Tanks are horrible to attack because every 100 damage you do to a tank is reduced heavily compared to a squishy mage. You need a reason to attack the tank before the mage, so what if the tank eventually does more damage than a mage? Sustained Damage or ramping up damage is a really nice way to create interesting decisions for dealing with a Tank. Do you ignore them and deal with more high priority threats? Or do you take them down before they become a problem?

  • Taunts: Lazy design, but literally forcing enemies to attack a Tank does technically work. In most cases this is just a thematic skin of Crowd Control. Hearthstone utilizes Taunt in a much more interesting way, but with multiple throwaway units it’s hard for me to draw much inspiration from it.

These techniques have varying degrees of success. League of Legends is a game that heavily promotes tanking and bruiser-type characters. Dota, on the other hand, has some fat dudes but typically the game is not balanced around having many of them.

Part II: Attacking in Ventura

In Ventura, I will be using Crowd Control and Sustained Damage for that PvP ‘threat’ to incentivize attacking a tank. These are smart and strategically interesting ways to create a dynamic battlefield.

As Ventura is on a grid though, I can use another way to tank. Standing in front of an ally.


In this example, Axe (the big red dude) wants to attack Lina (the ginger) but there’s another of Lina’s allies standing in front of her. In Ventura, Axe therefore cannot attack Lina from this position.

The way the game currently works is that any unit will block line of sight to the target, meaning that allies will block your current hero from attacking. I will probably remove ally blocking, but for now let’s see some more examples.


Zeus can attack Axe in this example, using diagonal positioning to get clear line of sight. Diagonals are always a real pain in Turn Based Tactical games, but I feel that having diagonals allow line of sight gives them an interesting tactical usage and doesn’t feel too weird.

I was worried that this would be too hard to understand, but as the grid is made of squares and the line is drawn from the center… there shouldn’t be many cases where weird angles allow attacks that shouldn’t be possible. A direct Bishop-like angle should provide a means of attack.


This angle, clearly shouldn’t allow attacking. Remember, at the moment allies block each other. This is likely to change.

What I absolutely love about unit blocking is that positioning becomes extremely important. Each tile not only acts as a position from where to launch attacks, but it also acts as a defensive position from which a unit can block attacks and defend allies. This makes positioning abilities a very useful tool for tanking and therefore gives me another technique for creating high priority tank targets.

Ventura Mechanics: The ATB

In this series of articles, I’ll be spotlighting individual mechanics in Ventura; explaining why and how I’ve made them. I’m hoping this will not only give you guys insight into the design process, but also help me clarify and distill my own mechanics!

Part I: Turn-Based Tactics Systems

The Active Time Bar is a natural starting point for me because it’s one of the primary reasons I started Haft (the precursor to Ventura). I want to like TBT games, but I never do.

These are the following reasons I dislike them…

  • Turns take too long

  • One mistake is extremely punishing

  • There’s too large of a possibility space

These 3 poignant detractors are all symptoms of the traditional Turn Based Tactics turn-system; Team A, then Team B.


Team Turns

With Team Turns, you move all your units in one turn. XCOM, Heroes of Might & Magic, and Hearthstone (to some extent) are all examples of this system.

You can focus fire enemies before they can react, but you can also get focus fired before you can react. When making moves and choosing targets, you need to judge exactly what the enemy can do within their turn with all their units before you can be ascertain whether a unit is safe or not.

What this results in is possibility paralysis. I have to play so carefully that every decision I make takes 10x as long. Combine that with having to move 4-5 units at once? Turns are going to take forever! No human opponent is going to sit around waiting for me to make my moves.

XCOM - Enemy Unknown
XCOM – Enemy Unknown

Hero Academy uses this format, but it’s designed around ‘play-by-mail’ so there isn’t so much of a problem with it. Ventura is a ‘real-time’ PvP game, where you and your opponent are both in the room (be it virtual or real) at the same time.

The benefit of this system is that it’s obviously really easy to understand, and that you can create combos very easily. As you cannot be interrupted while you make multiple moves, you can combine the powers of units and abilities together to do really cool stuff. These combos are the strategy of the game.



Alternating Turns

Another approach to Turn-Based Tactics games is the Chess approach. Each player moves one unit, then it’s the next player’s turn.

I dislike this approach more than Team Turns, because it’s almost impossible to perform those strategic combos. I find that these games severely lack in strategic depth and excitement because it’s so hard for you to really do anything interesting. Your units rarely interact. Isn’t the point of having multiple units the interaction between them?

The Banner Saga
The Banner Saga

It also really sucks when there is a disparity in the number of units on each team; The Banner Saga being the major culprit here. If I’m fighting 3v1… my opponent can move his single guy 3 times while my 2-man advantage is basically nullified. Not only does it not make sense logically, it feels very arbitrary.


Active Time Bars or Initiative

Initiative is my favourite approach to turns. Each unit has an initiative value that determines who has the next turn. When they take their turn, actions add initiative and push them down the turn queue.

Final Fantasy X: Skip to 1.51 for the actual battle

It is the best of both worlds as it allows fast turns by moving singular units at once, but it also allows combos as you can have periods where you can move uninterrupted by the enemy.

Initiative becomes a non-transparent statistic that you can manipulate to get what you want. Let’s say you have two Heroes who synergize extremely well together; Claude and Mathilda.

  • Claude has an ability that does two attacks in one turn.

  • Mathilda has an ability that increases attack damage of an ally.

  • You obviously want Mathilda to use her ability on Claude; increasing the power of his double attack.

In a Team Turn system, this is easy peasy. You’ll do this every single time. It’s a great combo! In an Alternating Turn system, you can rarely do this combo. Too much can interrupt the interaction between Claude and Mathilda. What if Claude moves before Mathilda? What if Mathilda buffs Claude and then the enemy moves the only viable Claude target out of his range? If Claude is in range, then obviously you’ll silence Mathilda every time.

Initiative systems allow you to create circumstances where you can perform combos, much more reliably than Alternating Turns. It becomes a strategic option in and of itself. Above is a pretty bad example, but watch the bar with all the faces on the right and you’ll see what I mean about initiative.

Part II: Ventura’s ATB

Initiative felt like the best solution overall. For a game that wants to “Recreate a Dota Battle in a Turn Based Format”, it’s all about combos and synergy between units but it also means interrupting combos and outwitting someone is crucial.

Welcome back to Haft
In Ventura the white number is the Hero’s Initiative value


Team turns are too easy for combos, and would rely on excessive mana management or cooldowns to prevent combos being unleashed every single turn. Alternating turns are too hard, removing much of the strategy that I want to capture in Ventura.

Ventura’s turn system is pretty much the most basic form of initiative;

  • Heroes have an initiative score from 0-1000, no Hero has the same score.

  • When players have picked their Heroes, each of the 10 units is sorted in order from the lowest to the highest initiative score

  • The game picks the Hero with the lowest initiative score to have their turn

  • Once the current turn’s hero has taken their move, 1000 initiative is added to their score and -100 initiative is removed from the score of the 9 other Heroes.

Many abilities can affect a Hero’s initiative value, pushing them down the queue or pulling them up. However, there is no initiative value for casting moves or performing actions. If someone doesn’t want to move, that’s their perogative but they won’t gain initiative boosts for it.

Manipulating the Initative bar is a type of strategy in itself, and giving everyone the ability to do it (through inaction) would take away a lot of the flavour of the heroes.

For example, I have Hero designs based around initiative manipulation while other heroes are designed around being naturally slow or vulnerable to initiative changes. Furthermore, remember that paralysis by possibilities? If the initiative bar wasn’t remotely predictable, it wouldn’t solve one of the 3 major issues I have.

The Final Fantasy X example above has initiative values for actions… meaning that every single action has some degree of time to perform; represented on the initiative bar. I don’t want to do this, although it is easy for me to implement if I feel my current system is lacking.

Quick Update

I’ve been working hard on Ventura this week and last, implementing plenty of features. I thought I should give y’all a little GSD update to let you know what I’m working on. Full regular Ventura updates will be posted every Monday on DevPact.com, so check it out.


Lots of green, as you can see. Ventura‘s systems are very integrated and very simple, so it’s been a joy to work on so far. As mentioned in my latest Monday Update, I’ve been thinking a lot more about ‘Good Code’ and the way I’m programming features. It is a little messy as I add more and more on top of existing systems, but it’s good to keep my eye out for any godawful sinful code practices. I’ve been a slave to copy-pasting code, which would make any seasoned programmer cry!

Most work on Ventura is now based on the Ability System. Not just the coding of it, but also the content. I’m hoping to finish a robust and powerful backend so that the content just creates itself, although I’m sure a lot of the more adventurous abilities will require some custom solutions.

Once the backend is done, I have to create 10 Heroes worth of content before the game is playable. Then it’s technically ready for public eyes, at least in a capacity where I can witness the combat in action and then learn where to take the game before October arrives.

Reducing the scope of Ventura

Hey all,

As you may know already, I’ve been working on a game called Ventura which is a competitive online multiplayer strategy + tactics hybrid. Players start as lone wolf mercenary captains and have to perform tasks for the various city-states around the map to build up their strength, reputation, and gold reserves. Having a powerful mercenary gang give you strength in combat, which is a unique simultaneous turn-based tactical system inspired by the likes of XCOM and Frozen Synapse.

That’s a lot of stuff. In fact it’s probably taken me about 2-3 months to even figure out the best way to explain what Ventura is, since so much is going on. During this time I’ve been working on the prototype, on and off. I built the overworld map, I built dungeon generation, I built the city-screens and the purchasing and equipping of unique mercenaries and gear for them. I built the start of the combat system.

But only the start.

The fact is, I’m struggling right now with it. As it became more advanced and the pieces started to fall into place, a lot of red flags have cropped up. Some are design based, which I feel confident enough to solve, but most are related to programming. I’m not that confident when it comes to code. Progress has stunted drastically and my motivation has dropped along with it. Spending over 60% of the entire dev time just trying to get two characters to not walk into the same tile will have that effect on you!

With 9 weeks to go until the IGF submission closes, I need to pull my finger out and get something playable and awesome as quickly as possible. Which is why…

  • I’ve cut online multiplayer. Network code was always a red flag but the main reason is that I want a same-screen game I can get people to playtest easily for instant feedback
  • I’ve cut all the overworld map and out-of-combat systems. There were plenty of design red flags, but I am still confident it would work. Alas, it required network code and therefore this is a result of the online multiplayer snip.
  • Combat is no longer simultaneous turn-based. While I was very excited about the innovation I was seeking, the coding for it was unbelievably tough and for me to iterate and try out different systems it would take months and not days. It needs to be days at this point.

With these cuts, it’s hard to really say Ventura is the same game… but I’m sticking with the name and going back to an old prototype I gave up on a long time ago, back when even using an array in Game Maker would cause me to wince!

Welcome back to Haft
Welcome back to Haft

Haft was a concept I was building about 2 years ago. My goal was to create a combat system that could provide the thrills and spills of a battle in Dota 2 or League of Legends, but with turn-based and strategic mechanics. Much of the enjoyment I find from Dota is theorycrafting; imagining devastating team compositions, and then pulling off incredible inter-hero combos to crush my foes. You can’t actually do that in Dota unless you’re a cyber-athlete!

Haft was simple.

  • XCOM-style grid-based combat, with less randomness and faster turns
  • Final Fantasy-style ‘Active Time Bar’ initiative system so that turns alternate regularly and are quick and exciting. No sitting around and waiting, please!
  • Dota-style Heroes that are drafted by each player. They have unique abilities and strategies available to them and because they’re drafted there are no clones.

Back then though, I wasn’t capable of building it. Frankly I just sucked! Furthermore, Duelyst was announced and I was petrified that Haft had basically been crushed before it began.

Nowadays I don’t suck as much, and Duelyst went in a completely different direction than what I was expecting. I should never have stopped. There’s a game industry lesson for ya, stick with it… it will be unique just because you’re not the same as them.

So we’re back to Haft. Ventura is becoming Haft. What this means is that I definitely have the capability to finish the game by end-of October, at least from a systems perspective. It should be fun, it should have all content inside, and therefore it’s the best thing I can show the judges before taking the next step and actually hiring people.

It’s sad to lose so much of what made Ventura innovative. I love the medium-term session based gameplay of Dota, and want to see more multiplayer games take that approach. Ventura was my multiplayer-focused Heroes of Might and Magic, and I still really want to play that game!

Nonetheless, there’s still a lot I can do with the ‘New’ Ventura. The initiative system has so many amazing strategic possibilities that I’m relishing the idea of playing games with it. Designing Heroes was pretty much the first thing I ever did that was Game Design related, so this game is just me designing heroes for a living. Fun, fun, fun! On top of that, it’s local multiplayer and therefore it’s technically already playable. Once I have 10 Heroes integrated, I can put it in front of people and assess.

The most important thing to me about this New Ventura though is the fresh lease of life it gives me. It was very difficult banging my head against a wall for 3-4 weeks. I’ve personally not been in a brilliant mental state as well, dealing with a mild depression, so you can imagine how relieved I am to cut out so much of the impossible work and focus on the thing that truly matters… Game Design. This is as pure a game design project as there has ever been, what a great first game to test myself on.

Clashing in Ventura

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.


Clashing is used in Frozen Cortex, a game I'll need to research for this problem
Clashing is used in Frozen Cortex, a game I’ll need to research for this problem


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.

Get outta my spot!
Get outta my spot!

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.


If you can’t tell what’s happening in this mangle of muscle, it’s Zangief grappling with Blanka!


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.


Heavier characters would enter juggernaut mode

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!

Ventura – Where we at now?

Over the last couple of weeks I’ve been catching you all up with my progress on the Ventura combat system. Since it was technically over a month ago, you guys are a month behind!

I felt I’d catch you all up with a video of the combat system in action, as it’s totally the best way to show you what I’ve been working on. But first, a recap…



Let’s start with a before-and-after comparison of GSDs since Combat Week ended;

After Combat Week
After Combat Week
GSD - All caught up!
GSD – All caught up!

YOU SEE THAT GREEN? It’s everywhere, right? Let’s go over what it all is…


Sound Integration
Ok so I can’t exactly showcase this, but since Combat Week ended I’ve implemented various clangs, swishes, grunts, and repetitive “Confirmed!” stings. Yippee!

Combat Damage
On the last Combat Week day, I got Attacks working. Now they actually deal damage, correctly.

Turn Resolution
This was a biggy, you can now play input orders to all Units on both Teams, watch them resolve correctly, and begin the next turn.

I forgot to green this one in, but now Units can die and it doesn’t completely break the turns and resolution systems. Sweetness.

Now that’s all done, let’s see this baby in action.


  • Player 1 perform a Move Maneuver and an Attack Maneuver with Lucina (Unit 1).
  • Units 2-4 Idle for both of their turns
  • Unit 5 performs two Move Maneuvers.
  • Player 2 Idles with Unit 1
  • Cordelia (Unit 2) performs an Attack with Maneuver 1 and then Idles for Maneuver 2
  • Units 3 & 4 Idle for both of their turns
  • Unit 5 performs 2 Move Maneuvers.

From the outcome you can see Lucina move into position and hit her two targets. Cordelia doesn’t hit anyone with her Maneuver 1 Attack, as Lucina is not in position yet… if only she’d Idled first!

Screenshot - All caught up
Screenshot – All caught up

The combat system has come a long way but there are still some pretty important features I need to implement, that will probably take more than my morning hour to finish.

  1. Clashing – What happens if two Units want to enter the same tile? How is that resolved?
  2. Movement Cost – Units should only be able to Move 1-3 tiles per Maneuver.

My super regular updates will probably dry up a little as I work on these major features. Once they’re done, however, the combat system is pretty much ready for Content and then the dreaded PLAYTEST.

Scary stuff!

A little DevPact update

DevPact is now live on http://www.devpact.com!

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

Check it out!

Ventura – Combat Week – The Final Day!

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!

Choosing your Attack Direction
Choosing your Attack Direction

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.


Day 7 - More attacking
Gaius chooses to Attack to his right for his 2nd Maneuver, hopefully hitting Tharja and Flavia (as long as they don’t move!)


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;

Day 10 GSD
Before Combat Week
After Combat Week
After Combat Week

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.

Have a fun-packed weekend, chums!











Ventura – Combat Week – Days 5 & 6

Greetings and salutations,

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.

Day 5-6 Movement
Day 5-6 Movement and Multiple Units

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?

  1. Maneuver 1: Idle
  2. Maneuver 1: Attack
  3. Maneuver 1: Move
  4. Maneuver 2: Idle
  5. Maneuver 2: Attack
  6. 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.

Move to a safe position? Attack twice but leave yourself open?
Move to a safe high-ground position, Attack twice but leave yourself open, or Move then Attack but risk retaliation?

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.

This Unit has plenty of cover and the enemy is ripe for the picking
This Unit has plenty of cover and the enemy is ripe for the taking

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.

Ventura – Combat Week – Day 4

Here’s post 4 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 4

Pathfinding was the order of the day yesterday, and we learnt how important it is to debug all the time! Briefly touched upon was Maneuvers, which are an integral part of my system. Today we’ll go over the first steps towards implementing them…

Combat Week - Day 4
Combat Week – Day 4

It’s hard to see from the picture above, but Lucina (long overdue shoutout to Fire Emblem by the way) is currently in the middle of her Turn Outcome. During this turn she had two Movement Maneuvers; the first being at M1 (coordinates 2×4) and the second at M2 (6×1). In the screenshot above, Lucina is moving towards M1. Once she reaches it, she will then move towards M2.

The first step in building Maneuvers, probably the most important and time-consuming feature of this combat system, is to get a single person moving for both orders. On Day 4 I built the system to allow players to choose a Unit’s Tile Destination. Once that destination is chosen (by selecting it), a path is calculated from the Unit’s original position to that new destination. When confirmed, that Tile Destination is stored as M1 and completes the Unit’s first Maneuver. Maneuver 2 then involves selecting another tile to move to, but this time it’s from the M1 location.

This was surprisingly hard to implement, and involved the storage of 3 locations based on the game’s state.

  • Lucina’s original location needs to be stored for path calculation towards M1
  • Then her M1 location needs to be stored for path calculation towards M2.
  • When the Turn Outcome happens, which ‘plays’ the two Maneuvers, Lucina’s Unit, starting from its actual position, has to move down those two paths sequentially.
  • Finally her original location needs to be updated to M2 so the whole process can start again.

I’m confused just reading this back… video would be a much better way to explain this damned diary! It’s coming soon, I swear.

Design Decisions RE: Maneuvers

Simultaneous Turn Based Tactics provides some unique challenges that I haven’t seen dealt with in exactly the way I’m prototyping for Ventura.

  • Challenge 1: You can’t target specific enemies because they may or may not be in range when the movements begin
  • Challenge 2: The system is all about prediction and threat assessment, based on a unit area denial capabilities and the 3-way choice of Attack, Move, or Idle.

Frozen Synapse is the game that originally inspired this idea, as I didn’t even know simultaneous turns was a thing until that wonderful game.

In Frozen Synapse, you and your opponent have a Time Window to set moves for. During this time, you can perform actions by delivering orders to your units. You can command them to move to waypoints, guard a certain direction, and choose whether they engage enemies or ignore them. It’s an extremely complex system with a lot of little mechanics. Much like in Ventura, you do not need to target specific enemies in Frozen Synapse. Units will attack on sight, and generally kill anything they see in one hit.


Frozen Synapse by Mode7 Games
Frozen Synapse by Mode7 Games


In Frozen Synapse you have the Time Window to exploit during your turn. In Ventura, I’m giving the player two discrete ‘Maneuvers’ to exploit during their turn. During Frozen Synapse‘s Time Window you can give as many orders as you want to your units; you are only limited by the time it takes to perform each order. In Ventura you can choose to Attack, Move, or Idle for each unit, twice per turn.

When the outcome begins, there is a particular order in which actions take place.

  1. Maneuver 1: Idle
  2. Maneuver 1: Attack
  3. Maneuver 1: Move
  4. Maneuver 2: Idle
  5. Maneuver 2: Attack
  6. Maneuver 2: Move

Each of these steps is completed in full before moving to the next one.

For example, if a Unit has set their first Maneuver to ‘Move’ but is already in range of an enemy ‘Attack’, they will be hit first before moving out of the way. Changing the order of these Maneuvers has a massive impact on the game, so I expect to make a few builds to experiment with what works best.

Tomorrow we’ll be continuing Maneuvers; both the development (moving all your units) and design analysis (continuing the inspirations for the Combat System with XCOM: Enemy Unknown).

See you then!