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 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!

View and subscribe on iTunes here: https://itunes.apple.com/gb/podcast/virtu-podcast/id1015246330

Or grab it directly here:

https://archive.org/download/devpactpodcast/devpact_pilot.mp3

We’ve never done this before so be kind!

igf_pact_white_on_black

 

 

Advertisements

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.

Combat!

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!

DevPact!

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.