Since the last post we’ve mostly been designing and implementing some new lock and key types for the game. That’s gone well and they are nearly done – more on that below. But we’ve also done a bunch of other things.

Balancing Ability Card Charges

The image above shows all the active and passive abilities available in Shadowhand. The active ones require charging by removing playing cards from the tableau before they can be used.

The required charge varies from 40 to 70 which basically means somewhere between one and two hands of cards. I spent a while working out their relative strengths before setting these values. If you boost your willpower chracter stat you can make them charge faster, which can definitely come in handy.

Character Stats

Speaking of character stats (see image above), I also spent some time evaluating the relative effectiveness of our game’s unusual list of character stats and then balancing them. These stats don’t directly affect combat like most RPGs, they affect the cards instead.

I’ll still need to run some tests on the active/passive abilities and the character stats later on to check that my balancing guesstimates are OK.

Gold crate

A recent small addition to the game is to have a gold crate which is hidden under cards. It won’t occur very often but will be a nice treat when it’s found.

New story/goal items

The main bulk of last week’s work was designing story/goal items to uncover under cards, and some new locks and keys to add flavour to the game (more on locks and keys below). The wanted posted above is an example of a story/goal item. The story/goal items occur on specific chapters and are mostly related to the plot except for a special bonus item…

The image above contains placeholder art

New keys and Locks

Some of the new locks and keys are related to the plot and only occur on specific chapters, but others have been designed to be resued on several chapters such as the lantern and dark card, and the torch and gunpowder barrel.

Notice that we’ve also added some large locks to the mix. These will cover lots of cards and so will force the player to complete one half of the tableau first before they can proceed. Also we can hide cool things under them like crates of gold, potions, bombs and story/goal items.

Misc stuff

Here’s all the other stuff we got done:
- Reviewed the story to make sure it all makes sense.
- Added support to game and level editor for new lock/key types.
- Plugged all the new story/goal items into the game and coded goals for them.
- Wrote found item messages for the new story/goal items.
- Set placeholder goals for all the chapters in the game. I’ll balance these later.
- Plugged all the new lock/key types into the game and made them work except for particle effects.
- Added in placeholder sounds for new lock/key types. Probably most of them will be final.
- Coded lantern with overlay glow under mouse pointer when carrying lantern.
- Added particle effect for using lantern on dark card.
- Changed Prosperity stat to a chance to double gold award from under card piles.
- Made sure retrying or quitting a training chapter removes the training.
- Fixed a rare bug with using Charging Stallion on last card in a duel layout. Found by a beta tester!
- Changed the way “new” stars work on inventory tabs. They now clear as soon as the tab is viewed even if you haven’t checked out all the new items on that tab.
- Made new weapon base cards with “damage” label on them to make it clearer.
- Added page up/down to level editor to cycle through levels linearly.

The last couple of weeks I’ve been balancing the first 5 chapters of the game, preparing a beta test with session logging, and analysing the results. More on that below!

(click to enlarge)

Balancing Chapter Goals and Enemy Star Targets

Shadowhand has a built-in AI simulation that can test both puzzle and duel levels 1000s of times and output the results to a file (see example above). I can then use those results to set up chapter goals for things like getting a Combo of X, or collecting Y stars, or earning Z gold. It’s super-useful.

I also use the simulation to first balance a duel with an enemy to check they are possible to beat but are not too easy or too difficult. Then I take a look at range of turns to beat (in graph form) and use that to calculate the silver and gold star goals for each duel.

(click to enlarge)

Gold Economy

Then I log the min/average/max amount of gold earned on each hand/duel in a spreadsheet (see example above), which I can use to work out what prices to set each shop item at. I don’t want the player to be able to afford everything as I want them to have to choose between cool items and to stay motivated to keep playing to earn more gold.

When I got the results back from the beta test I was pleased to see that everyone earned between the average and max amounts I had predicted, and that they bought the items I wanted them to but also had individual variation in choices. This means that my gold economy model works and can be extended to the rest of the game.

(click to enlarge)

Beta Test Logging

The beta version I sent out last week also logs the player’s actions and then emails the log back to me when they exit. This allows me to compare their playthroughs with my balancing efforts. Luckily everything went as expected which means I can roll out my balancing techniques to the remainder of the game.

I also got beta testers to fill out an online survey or to email me with feedback, plus I watched several people play it in person and via Skype. Then I compiled a list of all the action points that I wanted to work on and implemented them in the game.

Luckily there was nothing major, just cool little improvements that help the “onboarding” process go more smoothly. I love this sort of work because you get to make small, yet obvious, improvements/fixes to the game that you know will help players enjoy the game more.

Design

I’ve probably said it before, but Shadowhand has taken a lot of design work. Solitaire games have been made before, and so have turn-based RPG games, but they have never been combined before like this. That’s meant a ton of design spreadhseets and documents have been generated. The design folder alone is 65Mb and nearly 160 files, and that doesn’t include visual or sound design, or test results, which were also epic untertakings.

At least now the design is all done and it’s clear how I need to balance the rest of the game. There will still be tweaks as I receive more beta tester feedback and maybe also after launch as well, but nothing major as we must ship what we have soon!

It’s been a busy week. Helen and I have been finalising more design decisions and editing more text, and I’ve been coding a bunch of small loose ends in between our meetings. I’ve also been balancing the chapter goals and game economy but more on that in another blog post.

Training Level Dialogs

The image above is from a pre-duel dialog from Chapter 5 in which you get to do a spot of fencing with an expert. Some enemies also have a post-duel dialog if they need to say something important when you defeat them. We spent a while writing the text for dialogs and making them all trigger at the correct point in the game.

(Click image to enlarge)

Story Editing

We also went over the story for Chapters 1-6 to make sure that the conversations flowed naturally and the plot was clear. This was a surprising amount of work but the end result is much better.

(Click image to enlarge)

Item Drops

I also added in item drops for chapters 6,7,8. There are several types of item drops:
- Story item drops that occur as a result of talking to another main character. The image above is a story item drop from a robbery!
- Enemy item drops that occur after you beat an enemy.
- Shop item drops that occur after you complete a chapter. These are items you can purchase if you have enough gold.
- You can also pick up items from bomb/potion crates on some levels.

Loose Ends

I’ve been ploughing through lots of loose end tasks and have reached the end for now which means I can get back to main features in the coming weeks. These aren’t polish items, just small things that I made a note of before to finish later, or things that cropped up as a result of testing and design meetings.

- Some code refactoring (always fun! I’m not being sarcastic, honest.)
- Finalised some design decisions about the game economy and earning gold.
- More design questions answered.
- Showed 2 star goal on level end screen if you don’t reach it, and showed 3 star goal if you manage to get 2 stars.
- Players can no longer keep earned gold if the fail to meet a chapter’s goals in Normal mode.
- Fixed simultaneuous defeat issue with killing training dummy on final turn.
- Level end screen: Enemy loot now shows as 0 if you don’t win the fight.
- Made sure gold shown on loot cards is same as enemy’s gold.
- Gold card image is now dynamically set based on enemy’s gold value.
- Fixed automated AI test run gold output ready for balancing the game economy.
- Made Chapter 6 card with coachman image.
- Made sure enemies with no throw anim don’t try to use bombs.
- The “new item” icon won’t be shown for each additional consumable if the player has already seen it before. I had to save this information in in the player profile to make sure it persists between game sessions.
- Fixed possible exploit with undoing a card that has instantly charged/poisoned a weapon.
- If you have two counter attacking weapons now either can counter attack instead of just the first one found by the code.
- Added a restart hand button to the in-game menu after doing a Twitter poll and discussing it with devs. 75% wanted a restart button!

I’ll make another blog post soon about the balancing I’ve been doing and the metrics system I use for beta testing.

Since the last post I’ve made a bunch of small changes and have worked with Helen to add new text to the game and edit existing text.

Puns

I’m a dad so naturally I like dad jokes and puns, and I like to get a few puns into my games. Also Helen is great at wordplay due to being a writer and editor for 20 years, and she came up with some classics for Shadowhand.

Above you can see the Gravedigger in the game, now named “Doug Hole”. We also have a drunkard called “Earnest Swigger”, which makes me chuckle in an easily-amused manner.

Haste Icon

We needed a decent icon for when the player is hasted and I had a list of standard ideas such as 2x, fast forward chevrons, clocks/hourglasses, lightning bolts etc. but then Helen suggested we use a Triskelion/Triskele, which is kind of cool, and so we used that instead.

Brutes Brew

Several potions in Shadowhand are alcoholic and although they give you an initial boost they also have a detrimental effect after a few turns by slowing down your weapon charging.

The image above is of Brutes’ Brew which boosts your chance to stun (with an appropriate weapon) to 100% for 3 turns. It was 50% for 5 turns but after some testing we changed it to 100% because it gives the player a guarantee of getting a stun, providing they can hit the enemy.

Combat Stars

For puzzle levels players earn stars based on how many cards are left on the tableau at the end of the hand – the same as in Regency Solitaire.

However, for duel levels player earn stars based on how quickly they defeat an enemy. Hovering over the enemy will show a pop up with the star goals. The image above is a tutorial explaining this early on in the game.

Optimising Automated AI testing

Having recently done a ton of duel testing in order to balance the bombs and potions in the game I was getting annoyed at how long 500 automated tests took to run – sometimes they took 5 minutes depending on the complexity

So I spent a bit of time optimising the test runs and managed to speed them up by at least four times! This means that the AI can now do about 20 fights per second which will greatly speed up my future weapon/outfit tests for balancing.

The main optimisiation was simply not drawing anything during the tests. This meant the game could skip Vsyncs which were holding up the simlulation by up to 17 milliseconds every time the player or enemy performed an attack.

Other optimisations included further reducing the length of some animations to the bare minimum time where they still correctly trigger vital code when they finish. Also I preloaded in some dynamic images for items that keep getting destroyed and recreated. The preloading won’t happen in the release version as I need to be careful with VRAM use.

Other thangs

We did a bunch of other bits ‘n’ bobs too:
- Edited character stat panel text to make it clearer what it means (hopefully).
- Edited some card text for clarity.
- Tweaked AI so it uses attack potions more intelligently then retested all relevant potions.
- Tested using Undo after a card drop offs the tableau due to the player’s “Lucky” stat, and made sure that lucky cards don’t mess up the tutorial.
- Made new post-duel dialogs for several enemies (image + text)
- Renamed some story characters for political reasons! The world has changed since we originally named them.
- Added support for enemies to have the same graphics but different names and stats.
- Charged Tartan Kerchief to give percent-based boost to health potions instead of a fixed number.

We’ve have a busy few days sorting a bunch of loose ends and also answering some design questions that had piled up. Basically I’m trying to clean off a bunch of quick tasks that are cluttering up my todo list. Here are a few examples:

Buff and Debuff tooltips

The game already had tooltips for separate stun, bleed, poison and haste icons, but there were no tooltips for general buffs or debuffs, just a green or red arrow icon.

So I finally coded proper tooltips that list all the current buffs or debuffs (see image above). There are up to 6 possible debuffs and 9 possible buffs, though it’s highly unlikely you’d get them all at once. However, I did need to code a tooltip that can change size depending on how many lines it needs to display.

Firebomb Blunderbuss

This weapon is based on a real naval weapon that Helen researched. In the game we finally decided to make it 100% unblockable fire damage instead of part normal damage and part fire damage as that was overly complex. It’s a late game item and is pretty cool.

Smoke Bomb

Originally we had a cool idea about using the smoke bomb to cover up some of the enemy’s cards in smoke. However, this was going to take too long to code and because it should only last one turn so that the cards aren’t covered up on the player’s turn, it meant that it wasn’t going to be much of a hindrance.

So we repurposed the item to increase the number of cards the enemy requires to get a combo. This was pretty easy to code as we already have a potion called Clarity which reduces the number of cards required to get a combo. Also I made sure Clarity cancels out the effect of Smoke Bomb and vice versa.

Bits and bobs

I also did a few other things such as:
- Made floating text that says “Resist Alcohol” for when an alcoholic potion takes effect but your character manages to resist due to having the Sailor’s Trousers outfit item.
- Tweaked the enemy AI to use attack buff potions when their weapon is charged or nearly charged and not to waste them when they have uncharged weapons.
- Made soap always disarm the other weapon if the first one is already disarmed.
- Improved inventory management so that when you drop an item on the inventory it doesn’t pointlessly scroll if the item is auto-sorted onto an on-screen slot.

Polish List

I also moved a bunch of tasks to the “Polish” list, which I may do after release. These aren’t bugs, just things that, as a perfectionist, I’d rather see improved.

I do this because I found out years ago that the only way to maintain sanity when coming up with cool little polish ideas during development is to put them on a separate list that is not part of the main To Do list. This way they don’t distract me from actually finishing the main game.

Wow I can’t believe it’s been 2 weeks since the last post. Basically I went down a giant rabbit hole of balancing…

It all started because I wanted to give a smuggler early on in the game some Slasher’s Cider, which is a potion that increases the chance to cause bleeding. However, when I ran my automated AI test system the potion didn’t seem to be make much of difference to the outcome of the fight.

So I embarked upon a large scale test of all the bombs and potions in the game to check that none were overpowered or underpowered. This involved setting up special test scenarios for each item and logging the results.

How many tests to be accurate?

Typically I run the automated AI test system 500 times and then again and compare the results. I’ve found that running a fight just 100 times isn’t accurate enough.

In fact I was reading about the margin of error for repeated tests and for 10 tests it’s about 30%, and for 100 tests it’s about 10%. That means I could run a test and get say a result of 40% and then run it again and get a result of 60%, or anywhere between those values (if the true value is 50%). That’s not acceptable for fine tuning the effectiveness of bombs and potions, or anything really!

Running 500 tests reduces the margin of error to 4.5%, which isn’t great but is better. Plus if I run it again and average the two values, it becomes even more accurate.

What did I discover?

Early on the the design of the game I gave the various bombs and potions placeholder values and ordered them in what I thought was a reasonable order of effectiveness. However, my tests soon revealed that quite a lot of them were underpowered (nothing was super-overpowered but there are a couple of powerful items on purpose).

So I embarked upon various tweaks and retesting until I got all the items to influence the outcome of fights in an acceptable manner.

It’s possible players might have used an underpowered item but not really noticed it was underpowered just because it did something visually cool and changed a stat, but I didn’t want to take that chance.

250,000 tests!

In the end I ran about 250 test scenarios and many of those were run twice to collect more data. Each of those scenarios consisted of 500 automated AI tests. So in total that’s about 250,000 tests.

Imagine if I’d tried to do that manually? Or just said “those figures are probably good enough”. The game could be broken.

Some may call me perfectionist (and they may have a point) but I learned a lot about how the potions influence the outcome of fights and if they are best used with fast or slow weapons, one or two weapons, at the start of end of a fight etc. I could probably write a Shadowhand strategy guide now

Anyway, I’m back on track with the main development now, so more blog posts coming soon!

First I added the ability to show a modifier e.g. +2 as part of the weapon card name (see screenshot above). This means that there can be more powerful versions of weapons found earlier in the game. I also added the same ability to Grog Bombs because they deal a fixed amount of fire damage and later in the game the player will need more powerful ones.

This turned out to be quite a big task because I had baked the card names onto the card graphics (I was going to change to dynamically drawing them if we ever localise the game). However, now that I needed to display +X next to the name I basically had to re-export all the weapon and gear cards in both small and large format which was 136 exports!

I also needed to create a special new small font to draw the card name. It’s no good scaling down a larger font as it just looks bad, it’s always better to export a font at the exact size it’s planned to be used in-game for clarity.

Inventory Stacking

I coded gear stacking so that the player’s various bombs and potions can be stacked in the inventory instead of taking up zillions of inventory slots. The quantity the player has “in stock” is shown on the bottom right of the card on both the small and large versions.

Coding the stacking was a bit complex as it had to handle taking one off the top of the stack and allowing it to be equipped in one of the player’s 3 gear slots and vice versa.

Furthermore I decided to auto-sort the inventory as well so that the weapons/outfit/gear/ability tabs are always sorted in a sensible order. However, new items will still appear in the top left of the inventory tab (and be marked with a new icon) so that players can check them out. This is basically what Dark Souls and the latest Zelda does, so it should be OK

Each one of those sounds (and music tracks) has been specified, created, plugged into the game, tested/edited, and finally mixed. That’s a lot of work for Power Up Audio and me as the guy integrating them into the game.

Attack Sequence

When an enemy attacks the player in the game several sounds are triggered in sequence with carefully timed delays and balanced volumes so that you can hear them all. For example:
- Enemy yell (triggered immediately)
- Weapon attack sound (like a swoosh of a sword which is triggered immediately but peaks at 250ms)
- Weapon impact sound (e.g. a crunch or squish. This occurs after 300ms)
- Player hurt sound (played at same time as weapon impact sound)

Furthermore those attack sounds have to be heard over the battle music which plays at a volume that doesn’t blot out the general cardplay sounds.

Anyway, for the last couple of days I’ve been listening to the final mix in-game and adjusting some volumes here and there. I listen with headphones on, then through my speakers which are quite large, just for a different perspective.

Right, this is it, the final push to get Shadowhand done! July was a scrappy month as I had a lot of Aikido going on plus we went to the Develop conference in Brighton, but now we have a wonderful clear calendar for August and that feels great.

Shadowhand has been in development since June 2015 and it’s the biggest most complex game we’ve ever made. It was supposed to be finished over a year ago but it turns out that making a turn-based RPG combined with a solitaire-style mechanic is a lot of work. Who’d have guessed it?

TODO List

Here’s a summary of what’s left to do. There are of course many sub-tasks within these tasks and lots of smaller tasks are not listed. The tasks won’t necessarily be completed in this order but it’ll probably be somewhat close to this.

There will of course be post-launch fixes/improvements and also localisation if the game performs well enough to justify it.

Crunch or what?

Phew, that sounds like a lot of work, but none of them are giant tasks as the bulk of the game and the systems are done. It’s just finishing things off and making sure it plays well from start to end!

My main todo list (in Excel) has time estimates on it and it claims that the remaining work will take 217 hours. Some of the work may go well and take less time but the reality is some of it will take more time and there will be unexpected new tasks cropping up. Currently I’m aiming to have it done by the end of August, which is about 46 hours a week, so not a crazy crunch, but it’s going to be pretty intense.

Anyway, the plan is to keep regularly posting dev diary updates now (and the occasional video) until the game is done.