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!

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!











DevPact Podcast #1 – Sunrise and Sunset

Hey all!

Myself and Chris gone and did a podcast. As I am a noob with hosting and iTunes and RSS, and 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!

View and subscribe on iTunes here:

Or grab it directly here:

We’ve never done this before so be kind!




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!

Ventura – Combat Week – Day 3

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

Integrating the Combat Grid and placing Units on it was the progress made on Day 2, now it’s time to get the Units moving on the Grid correctly.

Pathfinding is pretty advanced logic. I remember reading a ‘layman’s guide to A* pathfinding a while back and struggling to keep up. Essentially it revolved around creating an Open List of available tiles and then scanning through every single one to determine which tile is connected to which and whether the unit moving can access it (OpenList) or not (ClosedList).

Everything I just said is perhaps confusing you or completely wrong, but hey that’s the effect that the dreaded word pathfinding has on me!


Combat Week - Day 3
Combat Week – Day 3


Pathfinding is an example of ‘Real Code’. Since I started Game Maker, I’ve been making games using ‘Not Real Code’. Of course, this is completely wrong; all code is real code, but my indie games have been using simple Game Maker functions and terribly inefficient & crude scripts to  generate whatever I want to make.

Game Maker has some great built-in functionality that helped me build my grid, and it also has some satisfactory pathfinding solutions for blocking off tiles and finding the way around them to a target location. In fact, it was these functions that completely busted my balls for about 4 hours!

Here’s a developer lesson for you: Always test stuff with debugging functions activated.

I couldn’t figure out why my first Unit could draw a path around the grid with no problems, but the other units could only draw a path on their 2nd maneuver. It was a complete mind-boggler. I tried everything to try and figure it out. Hours and hours of tweaks and prods, setting up countless variable debuggers to try and find out why it wasn’t working despite all the logic being sound.

Eventually it turned out that the other units were placing themselves on the grid as inaccessible tiles and therefore a path could not be calculated from them. I only found this out after I switched on the Grid overlay (that I had turned off because it was ugly), which displayed red over tiles that were forbidden and green over tiles that were accessible.

What a pain!

After that was fixed, everything else pathfinding was plain sailing for basic functionality. One issue I did have is that the pathfinding solution I’d used in the past (mentioned here) was apparently broken. Game Maker’s built-in functionality does not have any feature to deal with terrain costs. Units in my system have a set number of movement points and I have to use my own solution to determine how far a unit can move in a single maneuver.

Once again I spent an hour or so trying to debug it. I opened up all my old game projects to find a version that worked. 5 projects, 0 working. It’s still not working.

At this point I think I should be building my own solution, from scratch, that I understand completely. But as I want to get the game playable as quickly as possible, 3rd party solutions are still my primary plan.

Next time on Ventura Combat Week, we’ll be looking at Maneuvers… both how they were built and a little bit of design analysis on them.

Ventura – Combat Week – Day 2

Hope you all had a great weekend! Here’s post 2 of my Ventura Combat System progress, which was done a while back. As a side note, it’s so nice writing blog posts retroactively 😉

Some quick context 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 2

Last time I designed and transported my UI from Fireworks into Game Maker, without the actual Combat Grid (where all the action takes place).

The next step was to get that Grid in and put Units on it.

Combat Week - Day 2
Combat Week – Day 2

I’ve got a long and beleaguered history with turn-based combat grids. Previously I was relying on a solution by a developer friend of mine (Mark Parrish; @BestMarkEver), but I thought I’d give Game Maker’s grid system a spin and I’d played around with it a tiny bit for Eternal Struggle.

Easy peasy… I think. Now I reflect, retroactive blogs aren’t that easy. I can’t remember how hard it was or not!

The initial grid setup was definitely really smooth, and putting guys on the grid was also simple. Pathfinding, which is tomorrow’s post, is a major pain in the ass but apart from that Day 2 was quite simple. A nice morning’s work.

You can also see that I got my units on the grid. Initially I was going to just clone their big full-tile faces but there’s a little bit more information I need to convey on the tile itself (i.e. HP), so I went with smaller portraits with some room for maneuver. I’m hoping that I can restrict the amount of iconography in-game, as this is supposed to be an extremely simple (but deep) system.

Tomorrow I’ll be taking on the beast that is Pathfinding. Prepare for a horrendously stupid ‘bug’ and general thoughts about the first complex logic I have had to face as a designer/developer.

In other news, I’ve got a few thoughts I want to share about DevPact, which I announced last week.

One important point I’ve learned over the last year or so of independent development is the constant struggle with exposure. Not that kind of exposure, I’m sure that will come later, but the importance of getting your name (and game) out there.

Myself and Chris are thinking of all the wonderful tools out there to build up a userbase;

  • Let’s Plays – A chance for our glowing personalities to shine through the lense of other peoples’ games + free research!
  • Video Critiques – More planned and thoughtful video content akin to Super Bunny Hop or Errant Signal
  • Game Jams – Ludum Dare, Asylum Jam, Public Domain Jam, A Game By Its Cover… all useful design challenges that expand your network
  • Design Articles – One day I hope to write as well as Dan Cook. Click it and be entertained. That sort of thing.
  • Podcasts – A more adhoc, cheap, and flexible way to discuss current game affairs, other games and issues in the industry. I don’t like the sound of my voice though!

These are all things I think we want to experiment with for DevPact. The key is balance, as all of these tools take up serious development time.

Ventura – Combat Week – Day 1

Damn, over a week since my last post and that was a nothing post! To cap off the week, here’s the first post about what I was doing during the Redlight week.


All work on Ventura so far has been the core out-of-combat functionality. Accepting Tasks, hiring Mercenaries, buying Equipment etc. This stuff is all extremely important, and starting with it gave me some important insights, but the combat is the real meat ‘n potatoes of Ventura. Everything leads back to it. Your gold is invested in combat strength and variety, so it had better be compelling.

Combat Systems are like new games in themselves, but you have to hook them up to existing systems so I find them even harder at times. Thankfully, many of the UI troubles were already solved because of my Squad UI work. Freebie!

For the next week or so, I will take you through the day by day progress of Ventura‘s combat system.

I’ll go into a lot more detail about how the Combat System works and why I made the decisions I did, but in short;

  • 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 1

My first step in designing anything is to mock it up first. Well, the initial thought seeds are in my head but this is the first real step towards production. Below is the initial mockup I made in Fireworks…

Day 1 UI Mockup
Day 1 UI Mockup

It’s currently 100% functional and ugly as sin, however I’m not averse to the general design of the layout.

  • In the top centre is the Phase Info, which will explain to players what the current phase is (Planning, Resolution etc.).
  • In the top right is the Current Maneuver Info. You order your units one by one through both of their Maneuvers. This area is context sensitive and communicates your controls and options based on your unit’s current state (neutral, currently moving, currently attacking)
  • In the Centre is the main event, the Combat Grid. This is where moves are made and units are located.
  • On the bottom is the Current Unit Info. You do not need to select units in Ventura‘s combat system, you give their orders sequentially. This area will let you know more details about who is selected; their HP, damage, and movement points as well as an Ability Browser that lets you cycle through any combat-related traits they may have

With the visual design set, I then start transferring it across to Game Maker. Another reason I absolutely love using an image editor to mockup UI first is because I can cross-reference the grid coordinates directly to use in Game Maker when generating the UI objects;

Combat Week - Day 1
Combat Week – Day 1

Remember that each of these ‘days’ is usually about 1-2 hours, so my first day’s progress was pretty good! The Combat System was mocked up visually and I transferred almost all of it into Game Maker.

On Monday we’ll be on Day 2 where The Grid is implemented. Oooohhhh exciting!

Have a great weekend!


Big things are in the works over here. Myself and Chris McMath (@chrismcmath), a colleague and friend, are starting up a new project called DevPact.

You are all well aware of my plan for IGF 2016 submission, but DevPact is a sort of cooperative, peer-pressured version of it. We’re hoping to update it together with information about our own separate projects (mine being Ventura), while creating some interesting experimental content, giving a closer look into the process of game development.

At this point, we’re not going to be promoting the site much. We need to iron out some creases and get it looking all purty. It’s not even got a URL yet! Early days.

As for this blog? I’ll still be posting here frequently. As of now, most posts on this blog will be replicated on DevPact. For the other ‘interesting content’ we have planned, I’m planning to keep it all on DevPact so Virtu Games is completely about the project and nothing else.

We’ve got lots to do but I wanted to share it with you all.

Redlight: Grid Optimizer

This is Post 4 discussing my project greenlight process. To add a little context, I’ve been working on locking down a perfect project for IGF 2016 submission. These posts will discuss a project and why I’ve red-lighted it. At the end, I’ll make a post about why I’ve greenlit Ventura.

Grid Optimizer

Up until now, most projects I’ve discussed on Redlight have been mainly stalled due to scope. Grid Optimizer is the complete opposite problem; it’s just not exciting to me. I’ve never really introduced the project on my blog, as it’s so simple that I felt it wouldn’t make for stimulating reading. But here’s a screenshot…

Grid Optimizer
Grid Optimizer

Suitably obscure!

In a nutshell, Grid Optimizer is a puzzle game about arranging Factories, Power, and Boosts in a way that maximise your output. Your pieces are randomized, creating endless content. In a way it is the perfect project for me. The scope is tiny, the coding is tiny, the design is easy. If I had to make a game in 6 months to put food on the table, it would be Grid Optimizer.

But I’m not doing that, I’m trying to work on a seductive and exciting passion project. Much like PA4X, I have only one redlight reason…

  • Redlight Reason #1: It’s not exciting enough
    There are a lot of mini-reasons inside this one but ultimately they all come from this. The game is casual, which means free-to-play, which means mobile. Mobile is not good for indie developers. Yes you can cite a Flappy Bird or 2048 (poor Threes), but those are product of their time and place. I don’t truly believe that you can craft a mobile success as an indie, you have to get extremely lucky whilst also hitting a perfect storm of great timing, apt sentiment in the market (i.e. Crossy Road), a solid USP, and THEN you want to make sure you get it perfect first time. Because if you don’t, you will get cloned. You’ll get cloned anyway, but if you did a perfect job first time then it’s harder for the Katchapps of the world to steal your shit.

This was the final day of Redlight, next I will be updating you all on why I picked Ventura as The Game… then explaining some exciting plans for the future.