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.

G-Day + Ventura Day 10

A double header with this post, as I promised a little look into my Task generation and it happens to be June 1st!

G-Day

On March 11th I announced The Plan which was a period of prototyping and experimenting to find The Game, an ideal project for me to submit to IGF 2016; the deadline of which is in October. Two and a half months has flown by and a lot has happened;

  • Bard Life was cancelled
  • Ludum Dare 32 happened
  • Project BR was started
  • Project Grid Optimizer was started
  • Project P4AX was started
  • Project Ventura was started

With each of these projects I took anywhere from a tip toe to a full on nose dive into development. The goal was to be able to assess each of these projects and then lock one down as The Game by 1st June.

1st June has come and G-Day is here, so what is the project?

Project Ventura

I’ll get into some details about why I picked Ventura over the others at the end of the week, but for the next 6 days I’ll have weekday update ‘Greenlight’ posts about what went right, what went wrong, and why I rejected all the other projects.

So what happens to The Plan now? Well Ventura is locked in, it’s getting made… it’s getting made for the end of October. No excuses, no changing my mind. It’s happening. The extent of how far I will get into the project by IGF submission day is something we’ll discuss over the coming weeks, but my basic goal is to have it fully functioning (perhaps without pretty art) by that point.

Ventura Day 10

Last time we talked about my first steps into the Task generation system. This is the lynchpin of Ventura’s whole design. City States will request things of the players in-game, what those things are is down to the Task Generation system.

Task UI
Task UI
  • It all starts with a Task Type, this is the ‘Raid’, ‘Rescue’, ‘Extort’, and ‘Scout’ in the UI above. This is the general behaviour that the player has to perform to complete the Task. I currently have 12 of these types planned, which should create a ton of variety between all the Tasks.
  • When a City decides to generate a Task, it picks the Task Type. As I develop the game, I want Civilization V-esque personalities for the Cities… which adds a little predictability and flavour to each location. At the moment, there’s a basic dice roll to pick the Task
  • When the Task Type is generated it has to run its own unique script to determine which Objectives are needed to complete it. In my prototype, I have the ‘Rescue’ task implemented. This task is themed as the city having a respected noble kidnapped by bandits.
  • The Rescue Task needs a location on the map that players can visit, a battle that they can fight, and then it has a completion behaviour which determines if the player needs to return to the City to claim their rewards or if the Task is complete as soon as the battle is over.
  • The Location for the task is based on the specific Task Type. Rescue Tasks will specify either an Industrial area (i.e. a Mine, Farm, Workshop) or a Dungeon (i.e. Abandoned castle, spooky forest). When Rescue has been decided as the Task Type, it then adds every possible Location into a list. From that list it picks an object and places the Task Behaviour inside.
  • When a player interacts with a Task Location, it will perform the Task Behaviour.
  • Most Task Types involve a battle for players to fight. In the Rescue Task Type, players must fight a single battle to release the prisoner. Once the Location is set, the system then generates a battle.
  • Battles can have up to 8 enemy units inside. The specific units picked for battle is based on the theme of the Location (a Mine will be based around a Bandit fight, a Dungeon around a Monster fight) and the difficulty of the engagement. This difficulty is based on the original city’s task creation.
  • The Battle Generation looks at the objective location, taking its theme. It then looks at the city, taking its difficulty. It mashes those 2 together and then randomly picks from various hand-crafted configurations of unit types.

This is what I have done so far. The plan is for the unit types to then be placed in the Battle scenario based on various terrain features of the Location. Once that’s done, there’s a whole Combat System I haven’t built yet so this is all groundwork!

WARNING: Crappy code contained in this image
WARNING: Crappy code contained in this image

 

Day 10 GSD

A lot of work has gone into the Task Generation, as you can see from the screen above, and I’ve expanded out the GSD to help track the holistic functionality of the feature;

Day 10 GSD
Day 10 GSD

As you can see, there is a lot of green! Basic game functionality is very much in progress. The next big thing is to start speccing out the Combat System. That will be large… very large.

There’s no turning back now!

Ventura – Day 9

Plenty of work done on Ventura since the weekend, here’s a recap;

Day 9 GSD
Day 9 GSD

 

Last time I had the Tavern navigation and purchasing functionality implemented. The Store was lagging behind but now I’ve got purchasing items fully implemented too. I haven’t shared any screens of the Store so here’s a little sneak peak;

The Store - Where you buy equipment to put on your Mercenaries
The Store – Where you buy equipment to put on your Mercenaries

Unlike Mercenaries, there are more than 4 items in a City at a time, so there’s also a page turning function. However as I mentioned last time, non-Weapon equipment is possibly on the chopping board. Alas, the perils of game development!

Task UI

The Task UI was the last major City UI menu that needed to be completed. In this category you can view and accept the Tasks that a City State will request of the players. Unlike the Mercenaries and Store, Tasks can’t just be ‘purchased’ for resources… Tasks are how a city creates dynamic content for players to engage with. Tasks need to be generated, unlike Mercenaries and Equipment which are randomized but static (a Mithril Hammer will always be a Mithril Hammer).

Task UI
Task UI

I’ll get into the details of Task creation next time, but for now I’ve taken the first major steps towards actually creating gameplay. When simple Tasks are in game, players can visit cities and then compete with each other to complete a Task first and receive the reward.

This is a little bit of a retroactive blog post, so next time I’ll go over what I did today (Day 10) and explain exactly how Ventura will create interesting content for the combatants!

Ventura – Week 1

Why do a day’s update when I can do a complete catch-up post, right?

Right! GSD!

Week 1's GSD Status
Week 1’s GSD Status

Ventura’s GSD got longer, but greener… and that’s a good kind of growth. Many of the tasks that were originally placed inside were too large and high level. During this week I split many of them into smaller parts and then completed those parts.

City UI

The first major feature completion is the lion’s share of the City UI. Ventura has 3 primary places that the player will interact with; the City, the Overworld, and Combat. The City is where players will obtain and accept Tasks, browse and hire Mercenaries, and purchase Equipment. You can see the Merchant is also an option in the main UI, but I’m deciding whether that feature is needed at all.

The Mercenaries Submenu of the City Screen
As seen last time, this is the Mercenaries Submenu of the City Screen

 

This weeks work completed the design and functionality of browsing Tasks, browsing Equipment, and browsing & hiring Mercenaries. Tasks need to be acceptable, and Equipment purchasable, but that utilizes much of the same logic as hiring Mercenaries so they should be quick tasks.

 

Squad UI

The Squad UI is accessible from the Overworld and is the place to see your current recruits and interact with them; be it equipping items, learning their powers, or reading their lore. This is a pretty complex UI, particularly with Ventura‘s controller focus, so it was the longest task for my Sunday’s development time.

Squad Summary in the Overworld view
Squad Summary in the Overworld view

A difficult UI design challenge is the limitation I have with regards to full screen UI. As the game is in real time, and your goal is to spend your limited time wisely, players can’t have their main view blocked by a UI. They can’t be stationary spending precious seconds reading Lore, Ability information, or calculating attributes. The Squad UI has a large amount of information in it, but it must be accessible without preventing the player’s travels on the Overworld.

While I don’t have an ‘auto-run’ feature built yet, this Squad UI is designed with that in mind. It must be informative without preventing progress. Imagine riding from Venice to Milan, with one eye on the overworld map and the other spent analyzing how best to equip your team. This is a better situation than feeling awful for standing still while you tinker with your troops.

Squad UI - Unit Details
Squad UI – Unit Details

Each character in your squad can be opened up to view their detailed information, while also enabling the equipping of items.

One great thing about building this feature is that it involved a ton of database work and planning that will assist with many other parts in the game. Building UI is such a rewarding design task because it solidifies the ideas you have in your head and makes them tangible; from here you can really assess if it’s working or if they need a rethink.

For example, in the Squad UI I’m forced to use the Left-Stick to navigate through menus. I really didn’t want to have to do this. I wanted to use Face Buttons for everything, which you can see from my City UI screen. Alas that is not possible here, so now I’ve realized I need to go back to the City UI and convert the Face Button design to the Left Stick navigation. Consistency is crucial in UI design.

The other rewarding thing about UI is that it’s all about displaying information from your game. This sounds bloody obvious but here’s the lesson; In order to display the information, you need to access the information.

Creating UI often involves the same logical links and information management that will be needed when the game systems are built. For examples, because my Unit Details UI can display Basilio’s modified Attack value, I can call the same variables and use the same processes to modify his Attack value in the Combat System. Therefore building a comprehensive UI is also building important parts of the Combat System!

 

Cuts!

A game design is often like a block of marble that you need to chip away at until you’ve got the perfect product (if perfection is possible!). When Ventura sprung up in my head, it had a lot of features. While designing and building the game, I’ve realized that some features could probably be cut.

  • Leveling Up Units: What’s the point? Isn’t acquiring Equipment the same thing? There’s no point building a completely new UI and system for leveling up a character when it doesn’t add much to the game
  • The Merchant: Currently this is on the chopping block, but is not removed yet. It’s pending because it’s based on a more complex City system that involves reputation management. If the game is complicated enough without reputation management, then I don’t really need the Merchant. In fact, the Merchant feature (which would involve the trading of precious Goods to earn more money) feels a lot like a post-launch expansion feature.
  • Helm/Armor: As you can see from the UI above, Units can equip a Weapon, Helm, and Armor. But why have 3 categories? If I want players fighting to obtain items, why would I triple the pool of items that are available? This is an economy issue and something that might be needed or might not. If Units can just equip a single item, that may or may not be enough depth to bring the game’s ‘competitive shopping’ to life. This is another feature on the chopping block, and it would save me a lot of time on balance and content creation.

 

Public Domain Jam

The deadline for PDJam occurred yesterday and there was no way Ventura was ready to be gamified. There isn’t even a combat system! Nonetheless, do check out the submissions and support this wonderful Jam idea.

Ventura – Day 1

While I’m actually on Day 5 of Ventura, for some reason I haven’t posted anything… so here’s Day 1!

Let’s start with the GSD…

Day 1 GSD
Day 1 GSD

Ventura is a game about riding around a fictional representation of Renaissance Italy, visiting City-States in order to receive Tasks, recruit Mercenaries, purchase Equipment, and buy Commodities. This week I’ve been focusing on UI, as much of the game is spent navigating menus.

The City Screen is where most of the magic happens. It is here that you receive Tasks which can be completed for Gold. That Gold is then spent on hiring new Mercenaries and equipping them, increasing your strength and allowing you to do more rewarding Tasks and combat other players.

The Mercenaries Submenu of the City Screen
The Mercenaries Submenu of the City Screen

Day 1 was mainly the layout design and very simple navigation from opening the City Screen to entering the Tavern.

If you’re wondering where Basilio’s beautiful art is from; it’s Fire Emblem: Awakening. While I haven’t settled on an art style yet, I do like this modern manga look and a similar style was also seen in Might & Magic: Clash of Heroes 

header

There’s just something I really like about the vibrant colours and diverse manga style combined with the more realistic proportions and less fantastical theme of… you know… real life!

Art is a long way away from being produced, so back to the meat ‘n potatoes…

Draft Overworld UI
Draft Overworld UI

The Overworld is where you’ll spend another significant portion of your time. Here you will receive the latest news (on the top left), can browse the mini-map (on the bottom left), and adjust your combat formation and units (on the bottom right). Combat is the most non-designed portion of the game so far, so I’ll be leaving that for later.

As I’m actually on Day 5, I have a lot more to show you… but I’ll probably give you the week’s update on Monday.

Have a great weekend!

 

Public Domain Jam + Candidate 3

It’s been a while, ladies and gents!

Firstly a quick update on Candidate 2; PA4X.

I’m quite pleased with how accessible the coding is for a 4X game. As I’m not delving into AI, it’s all a lot of UI systems and its turn based nature makes bug fixing and general logic so much easier! Therefore it’s very buildable.

However the problem is with design, iteration, and a massively convoluted assessment status. Remember why I cancelled Uffizi and Bard Life? Those games took too long to find the fun. PA4X has the same problem. It will take me weeks and months of design before it’s at a stage where players can say they enjoy the game. On top of that, it’s also a lot trickier to balance and design systems for a competitive 4X than a city-builder or idle game, so it just doesn’t make much sense to continue with it at this stage of The Plan.

No greenlight for this game, I’m afraid!

 

So where am I now?

I’m 11 days before my deadline for The Plan. The Plan was created to help me find a candidate for IGF’s 2015 submission in October. June 1st is when I need to begin working on ‘The Game’. Here are the prototypes I have built during The Plan;

  • Project BR: A multiplayer survival deathmatch game where you’re given a procedurally generated character and must complete dramatic quests while attempting to survive. Status: Needs an iteration loop.
  • Grid Optimizer: A simple puzzle game based on optimizing grids. Status: Ready for initial playtests
  • Ludum Dare 32 Followup: I didn’t discuss this at all on the blog, but Ludum Dare 32 did give me a good candidate game that’s worth investigating. Status: Needs an iteration loop.
  • PA4X: See above. Status: Red Light
  • Candidate 3: See below!

As you can see, Project BR, Grid Optimizer and Ludum Dare 32 are all technically in the running.

I have very mixed personal opinions about all of them, which I’ll get into on June 1st. Nonetheless, I still want another candidate game as I’m not satisfied with this selection.

 

Public Domain Jam / Candidate 3

My final shot at a completely blue sky idea before The Plan ends is Public Domain Jam.

Candidate 3 is a game which I want to get barely playable for the Public Domain Jam deadline, but it is also much more than just a fire-and-forget Game Jam project. I’m aiming for two birds with one stone. A solid Game Jam entry as well as an IGF Candidate. Funnily enough, Public Domain Jam has brought me full circle. I’m back on Machiavelli for this one!

Remember this guy?
Remember this guy?

 

Ventura is the codename for this project, and it’s back to the Renaissance with me. Linking to Public Domain Jam’s goal of being inspired by publicly available written works, I’m using Machiavelli’s writings on the use of mercenaries in Renaissance Italy as the inspiration for this new game project.

Ventura is extremely exciting to me as it brings together so many things I find intensely interesting in the field of Game Design.

  • It is a medium-term session multiplayer contest, akin to a Dota or League of Legends. I want the game to last around 30-40 minutes.
  • It involves competing with others, but not just through combat. Economy and strategic development decisions play a massive part.
  • In Ventura you are one of 4 mercenary captains who is tasked with protecting the City-States of Italy from external threats. You compete with others to fulfil quests and contracts, in the same world.
  • It’s similar to an MMO RPG quest region, but the core game is built around the idea of making it competitive. You compete for fortune, you compete to find the greatest recruits, you compete to acquire the most powerful loot. Everything that spawns in the game is limited.
  • When PvE is done, towards the end of the match, PvP begins and you take all that preparation and strategy into a fight to prove who is the strongest Capitano di Ventura.

Like Dota, where you experience an entire RPG in a single session, Ventura gives you a similar experience; but as a distilled MMORPG.

Reading it back now, it sounds crazily ambitious, but I believe I have a lot of very simple-to-build systems that become interesting based on the context of competitive play and a shared world. I’ve also got a combat system in my head that will be very entertaining. Then again, most of it is still in my head at this point… and that’s always too early of a stage to judge viability.

From now until June 1st I will be working on Ventura. Unlike with PA4X, I want to bring back the GSD and share the dev diary style posts I was doing previously.

Then, for better or for worse, I’m picking a game project that’s getting submitted to IGF 2015. Scary times, but unbelievably exciting too!