Slice: Fortress Defence

How hard is a wave of enemies? If the enemies get twice as strong as the player gets twice as strong there is no change in difficulty. The difficulty of a defence game is related to the ratio of power between the enemies and the player. Over time the player buys upgrades and gets stronger, and the strength of the enemies must match that closely to make the game challenging, fun and progressively more difficult.

My original plan for Slice: Fortress Defence was to tie the important variables to math equations like so:

Enemy Power: Linear Growth

Gold per Wave: Linear Growth

Unfortunately the linear gold drops resulted in polynomial player buying power, as each wave added to all previous gold spending (and so power increases).

Player Strength = Gold per Wave + Gold for all previous Waves = Area under Gold per Wave graph, approximately (G^2)/2

Player Strength: Polynomial Growth

Polynomials always grow faster than Linear in the long run – so this would leave the game hard at the beginning but getting easier and easier as the player upgraded. That’s no fun!

So I moved to an exponential model. Exponentials have an interesting property whereby the sum of an exponential is also an exponential – this makes balancing the ratios much easier!

Enemy Power: Exponential Growth

Gold per Wave: Exponential Growth

Player Strength: Sum of Gold for all Waves => Exponential Growth

By making the Enemy Power exponent slightly larger than the Gold Exponent the ratio of Enemy to Player power would also follow an exponential curve – and thus the difficulty would rise slowly then start ramping up fast at the end of the game.

Now all I had to do was ensure my units Purchase and Level Up costs gave a good ratio of Power to Gold. Three factors effect unit power: Damage, Range, Rate of Fire. All three must be combined to give a single Power rating to match to balance against Gold – I just multiplied them together, so a 10% rise in all three would give a unit 33% more powerful, and consequently it should be 33% more expensive.

With a little tweaking this system could now produce defence games of any length by changing the Enemy Power and Gold exponents.

In actual fact – once I had a Power to Gold ratio I could calculate the Players total expected Power from the Sum of all Gold Spent – so I uses this expected power to generate my Enemy wave power. This keeps the enemy and player in close step without getting bogged down in maths.

Adding horses to a game world is not an easy thing to do. The sculpting, animating, and AI behaviours required to model a four legged creature are all more than twice as complex as for a biped. But the steppe simply would not be the same without mounted scouts and fiendish bandits so horses had to be done to make the world of Spice Road suitably fast and dangerous.

Getting the shape of a horse right is hard enough on its own without worrying about the topology of the Lo-Poly mesh so I started by drawing some simple primitives over a reference picture in Curvy 3D.

Building a Lo-Poly Horse using Sketch Based Modelling

Curvy lets you draw curves to define the outline of a primitive – so it is quite easy over a reference photo. It was easy to correct mistakes and tweak the model at this stage because each primitive is separate and controlled by the curves – there are no triangles, patches, sub-d to worry about.

I merged the primitives into a 40,000 tri model, I could have used a higher resolution if I wanted to take it into ZBrush and detail a Hi-Poly version, but this was headed in the other direction to a low poly count so I could render a good number on screen in a battle. I used MeshLab and Quadric Edge Collapse Decimation to produce the Lo-Poly version.

This was a fast route to a Lo-Poly model, but the essential question was could it animate? I added a skeleton rig and tried out a classic Muybridge walk cycle:

Adding a rider and hooking up some gallop, charge and destroy AI produced the first Cavalry battle on the Spice Road. I can’t wait to add some sabre weilding bandits into the mix!

HeavenGames: Spice Road Interview

I had a great time chatting to Scipii of HeavenGames about Spice Road, and he managed to squeeze a lot of details out of me about combat, town management and the trading gameplay. Check out the full interview here: HeavenGames: Spice Road Interview

Example Kingdoms Trading Hex Game

Designing a work of art typically falls into a straight forward workflow – Sketch some ideas, Find some reference images, Draw some detailed sketches, and then paint/sculpt the finished work with as much time spent on detailing and polishing as is available. The workflow is pretty much the same each time, and while a lot depends on the skill and perseverance of the artist a good artist can follow the exact same pattern and create a series of good works.

Designing a game has a very different workflow. If you try and follow the Art flow you would begin with a description of the gameplay and some example screenshots as your ‘Sketch’ – or in game speak a pitch document. Then a good artist would turn to life to find reference material – what would that mean for a game? How much value do history, economics and psychology really have on in a typical game that has to balance fun, ease of use and player expectations of legacy gameplay. More often than not game designers just look at other games for gameplay ideas, and leave the more colourful research to dressing up that gameplay in a genre style.

Next in the art flow would come a detailed drawing of the finished product. This would be a first-playable demo for the game. Unfortunately while the drawing is quick to execute and easily changed, a first-playable often takes a massive amount of time and once made there is little scope for changing direction. Given a choice between cancellation and pressing ahead with a faulty design it is very common just to plow ahead, add the extra art assets and levels and try to ship the game. The polishing stage can help add an air of quality to the game at this point but fundamental gameplay issues are locked in by now.

For a game it is essential that there is enough flexibility at the first-playable stage – especially in a new genre/style. It is at this stage that there is enough working in the engine to start playing and fiddling with the mechanics, but not too much overhead that everything slows to a halt.

Back to the analogy – Art can be born of a good idea, and then fairly predictably be taken to a quality final item by an artisan – on the other hand Games might begin with a rough idea, but need to be made before they can be designed. And once they are up and running the design process is not an imitation of life, but a concoction of game mechanics – a mixture of separate elements brought together by a Cook, and carefully balanced by tasting the dish in progress. You can’t judge a game by it’s recipe as you could judge a masterpiece by the original sketch – a massive amount of the utility of a game rests in its preparation and the balancing of its ingrediant gameplay mechanics.

So while I wear my game designer hat I am happier to create lots of experimental dishes (mini-playable-games like the Kingdom Trader pictured) – so I can test them out in the tasting – than I am debating the value of individual gameplay mechanics and numbers on paper.

London – October 3, 2009 – Aartform, the software publisher, today announced a new game for Windows®: Spice Road. Currently in development by Aartform Games, an innovative new London games studio, Spice Road is scheduled for a 2010 release.

“Deep in the mountains and deserts of central Asia, where life is hard and death is sudden, thin trails of gold, silk and spice trace a web between the industrial forges of the West and the exotic climes of the East. You are a colonial governor in the 18th Century, building a town on the Spice Road in a time of war and discovery. More than spice travels your roads – musket armies, philosophies, and power plays that span the globe are at your control.” explains CEO Simon de Rivaz, “From palace to monastry, trade post to brothel – your town is worthless without the nobles, monks, merchants and whores that chose to live in it – and keeping them all happy at the same time is never simple.”

Spice Road will use the StormRaid™ engine to deliver a beautiful fully 3D rendered world on high-end DirectX® graphics cards.

For more information see: http://www.aartformgames.com

About Spice Road:
Spice Road is a trading and city management game. A rich plot drives the single player campaign, and a sandbox mode, easy to mod data tables and lua scripting lets the play continue beyond the campaign.

About Aartform:
Founded in 2003, Aartform has published a number of graphics tools including “Curvy 3D 1.5 – Fast and Easy Sculpting Software”
http://www.curvy3d.com

About Aartform Games:
Aartform Games is the game development arm of Aartform. Based in Kingston upon Thames, Aartform Games creates thoughtful games for the discerning player.

I’m making some test art assets to fill out the game world and give some basic components to hang gameplay on. So far this consists of a few buildings, some GUI components and an animated character. Stage 2 will be getting the gameplay tied in to the art so the core gameplay works.

I know other people like to start with bare bones no-art prototypes, but for me the art is as much a part of the game world as the backstory, combat logic and the upgrade paths – ie: Fundamental.

It has been a hard couple of days remembering how to animate, looking for reference material and struggling with keyframes. On my indie budget I can afford approximately zero software, so I have written my own keyframe animation studio, to go with my own modelling and 3D painting tools. While these have some upfront time costs it is much easier to pull off clever tricks to improve my productivity. For example I only have to animate one half of the walk cycle and the other half is automatic.

I am a bit rusty with keyframing – but I suspect I will be getting lots of practice soon!

Edit: Thanks to a hint on TigSource, I updated the walk with the arms swinging in the right phase to the legs – I must have been too close to spot the mistake (Working in mainly the front and side views it is easy to mistake the left and right arms.)

Today I’ve been prototyping a character model that will be one of the main soldiers in the battles you fight.

I used Curvy 3D 2.0 to paint this Lo-poly model. In the game I hope to fit 1000’s of these guys on screen so they will appear quite tiny.

Pondering the best methods for game design.

I manage all this with a pile of A3 Notebooks full of calculations and ideas, and piles of A4 with Lists (lots), Mindmaps (Rarely) and Flow diagrams. Then I scrunch all of this into a big bunch of Spreadsheets. If there is a better way I would love to know!

Complexity effects the player too: once a feature has been detailed – I have to decide if it will be fun or a chore when the player does it the 100th time.

I think the two tier approach of micro-management and auto-management is useful here. Let the player learn the basics of micro management, but then give them a choice of using auto when their power base expands and the micro would be overwhelming. Similarly micro-fighting and auto-resolution of battles lets a lot of the complexity buildup relax, leaving more time for having fun with the more interesting bits. Happily some chore-like activities are actually crazy addictive, and will stay in the final mix as a pleasurable time sink.