Density of Gameplay Mechanics

March 19th, 2010

Alex Wheldon wrote about reducing the sprawl of game mechanics and a focus on core mechanics to improve game designs in his Bene Factum blog post Density, not volume.

I agree that ignoring the minute mechanics underneath a game while focussing on a high concept is dangerous (and tempting). However a lot of AAA games fixate on the given mechanics of a genre be it platform/FPS/RTS and just bulk up the art and story around it – making dense gameplay but really just clones of old design ideas.

Usually I come up with a game mechanic, then fill it out with story, levels, upgrades, scores, bosses, achievements etc. It is this kind of volume that actually adds length and fun to the game – compared to psychologists lab tests of skill or abstract puzzles.

However I agree very much that non-essential vagueries of mechanics are unhelpful – both for the player and for the developer. Unfortunately some genres seem to need a lot of little mechanics to play out – Simulations & RPGs are particularly bad for this, as the ‘High Concept’ clearly precedes the mechanics. Still it is an interesting challenge to minimise the mechanics and still create an engaging simulcrum of the concept.

Exactly the king of challenge I am working out on the Spice Road design. As there are a wide range of activities the player can carry out and lots of stories to engage with – it is important that the basic interactions remain consistent and I should minimise adding new mechanics that will hardly get used. To this end I am focusing on four mechanics that will drive the vast majority of the gameplay – Travel, Combat, Trade & Conversation. The minor mechanics like party management, city policies, inventory management will all share a consistent dialog style interface, while the complexities of politics, diplomacy and  questing will fit into the Conversation system.

So, while not as minimalist as Mario – Spice Road will be a lot simpler and cleaner than a lot of Simulation/Strategy/RPG hybrids.

DIY Gamer interviews Aartform Games

March 13th, 2010
DIY Gamer interviews Simon de Rivaz of Aartform Games

DIY Gamer interviews Simon de Rivaz of Aartform Games

I had an opportunity to share some of the secrets of Spice Road with Arsen Nazaryan and the inquisitive souls at DIY Gamer. Find out how we blend sandbox and missions while carving a new space in the genre wars – read the full Spice Road Interview here!

Tasks and Challenges – Is Easy always Boring in Game Design?

March 13th, 2010

Can Easy be Fun?

With all the varied genres and styles of game it is easy to lose track of the fundamental elements of gameplay they contain. Playing a game usually involves the player performing a sequence of actions to reach a goal. For example a platformer has the actions of run and jump, with the correct sequence guiding the avatar over platforms and around hazards to his target. Taking a broader view, these actions also include navigating the start menu, clicking through tutorial screens, and any story events. All of these actions take time and the total play time for a game has a calcuable mix of time spent on each action. We can add here the non-action of simply waiting to see the game unfold, whether in a cutscene or during play – for example watching where the ball travels after taking a shot at golf.

This is a very reductive view of gameplay, if we add the context of an action to a unit of play we get a more varied list of elements – for example jumping to get up a step, compared to jumping onto a moving platform in time to excape the falling spikes and while timing the jump to avoid spinning blades. For the player the first action is routine and easy, whilst the second is skillful and risky. The simple action I call a Task, the tricky action a Challenge. Tasks are routine, habitual parts of a game – there is no substantial threat compared to the abilities of the player. Challenges need the players attention, they have a reasonable chance of failure that has consequences to the player such as losing health or the delay of having to replay a section.

I can broaden the definition of a Task from a micro-action like pressing the jump key to any duration of gameplay that contains purely tasks. For example – traveling back over conquered screens in a platformer with a key, navigating the shop screens, defeating grunt level enemies in an RPG perhaps while grinding for goods or XP. In some games the Challenges are well spaced – perhaps a boss battle every quarter of an hour, the rest of the time gameplay is safe and routine.

At this point it may seem that I am attacking rote gameplay and tedium in games – but I am not. Neither do I equate Task with Easy and Challenge with Hard. I am not a fan of Hard games, but I love plenty of Challenges. I mentioned the non-action of waiting, to me routine riskless gameplay is closely akin to waiting and so I would like to discuss Tasks in that context. Waiting sounds most tedious – and often even a shiny well crafted cutscene with a genius plotline will leave us hammering our controller looking for a skip button. But sometimes we are happy to wait and watch – indeed in the real world we will wait and watch entire sports events, theatricals, movies – with decreasing opportunities for interactivity. I suggest that some active parts of a game can be less fun than other purely waiting parts. For example – retracing your path over routine platforms with a key is less fun than watching an intricate sequence of bombs explode to solve a puzzle. Perpetual interactivity is not crucial to a game’s enjoyment. Risk free Task oriented sections of a game – while interactive – are not demanding and are only subtly different to waiting and watching.

So long as a Challenge is not too hard or frustrating it can be engaging and fun on its own merits and would stay fairly fun even with primitive graphics, an abstract setting and no context. The skill required to beat it and the risk of failure would be the same in either case and a big part of the fun comes from those aspects. Now on the other hand – imagine a stunning cutscene with amazing graphics and plot… then turn it abstract and you are left waiting in front of a blank screen. Clearly no fun at all to be had from abstract waiting in that case. You might get a little satisfaction watching a puzzle bomb sequence explode as a list of dissapearing circles – but much less than in the original, and mainly as satisfaction for solving the puzzle rather than any visceral enjoyment. The flip side to this is the fact that the simple routine parts of a game, the reassuring smooth sections between the rapids, have the opportunity to either be as boring and painful as the cutscenes we just have to skip, or as interesting and enjoyable as a bright unfurling story.

If it is not clear by now, I am not a fan of 100% Challenge based games. I enjoy having time to get absorbed in a game world without constantly fearing for my life, and sections of story and sightseeing are a welcome break from crazy hard boss fights. As the percentages shift, perhaps as far as 95% Task based I am happy spending the time building my skills in a fairly safe zone preparing those 5% tricky sections – but I am only happy to do so if the wider qualities of the game engage my interest and give me enjoyment. Grinding, retracking, repeating simple tasks for that 95% in a game that is boring is worse than a terrible cutscene – there is no skip button.

So there you have it – I admit that I like games that are mostly unchallenging – but a much greater challenge is to create an exciting and interesting game that stands up through the routine Tasks and manages to entertain throughout.

Difficulty Curves in an AS3 Defence Game

January 30th, 2010
Slice: Fortress Defence

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.

Send in the Cavalry

December 21st, 2009

SpiceRoadCavalry

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

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

November 17th, 2009
HeavenGames: Spice Road Interview

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

Recipes for Gameplay

November 1st, 2009

Example Kingdoms Trading Hex Game

Example Kingdoms Trading Hex Game


Are games Art? I think they might be more like Cooking.

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.

PRESS RELEASE: Aartform announces Spice Road

October 22nd, 2009

Aartform announces Spice Road

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.

Art Prototype

October 15th, 2009

Spice Road Art Prototype
View Full Size

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.

Animation Software

October 10th, 2009

Musket Shooting
Early days in my prototype, but now I have some little soldiers to set the scene.

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.)