Another Hyperion update was submitted last night -- it features an in-game tutorial and tips system. Great for both new and experienced players. Watch for that hitting the App Store -- we're dropping the price at the same time. And by dropping the price, we mean making it free.

As usual we're involved in a couple of long-term and couple of shorter-term consultancy and service projects. This year we're being somewhat more discriminating about what we accept though -- if you need help give us a shout at help@36peas.com. We generally always have capacity for iOS games projects and normally (depending on other commitments) some back-end multiplayer and infrastructure stuff as well.

Note: SlideShare seems to have had some kind of fit with the title slides. I really don't repeat myself that much ;)

A lot of the salient parts were made by me vocally. As far as I'm aware there wasn't a recording -- and I don't have notes, but you should get the general idea from the slides above.

There's also a great write-up by Keith Andrew over at PG.BIZ.

In this post I've outlined a couple of ways this kind of data storage can be used alongside component-based stores for global state and shared data.

Background and context to date

To date we'd been sharing global data using one of the following methods:

1. The GameWorld's local store (a dictionary)
2. Properties on the GameWorld object itself
3. In-component referencing / lookups

These have all got problems -- the first requires proper management of lookups, is slow for common lookups (each lookup is a key search) and is clunky for access outside of the game world (i.e. by controller interfaces; the second requires modification of the GameWorld class -- this feels very wrong and makes the GameWorld code completely unportable, and; the third leads down the road of interdependency and presents similar problems to traditional OO hierarchies (inflexibility, obfuscation and bottlenecks).

No perfect solution

A component-oriented design really should be as component centric as possible, but there are cases where there is no clear "component" solutions, for example:

• GameWorld <> Application <> OS communication
• Controller interfaces and attachment
• Game state
• Caching

The blackboard architecture helps with all of the above cases.

It also helps with more debatable components -- things like map managers -- where there's a strong case for externalising the functionality of a component but also a desire to have belong in the game world (especially for the purposes of messaging, updates etc). Other components can acccess said map managers directly as if they were singletons or external systems, but they can also participate in the gameworld's messaging system or update loops as required.

How to implement a component-friendly blackboard data store

We're simply creating a blackboard class and hosting an instance of it on the GameWorld object itself. This means that:

• Specific data stores are exposed through properties
• As a result data access is type safe
• The blackboard can house it's own LoadData function to populate from persistant storage if required
• The blackboard class itself is project-specific but it's hosting in the GameWorld is generic (keeping your game world, objects and components generic utilities)
• Access is direct for all components (e.g. component -> object -> world -> blackboard)

Smarter game components and behaviours

Abstracting away shared storage has a couple of other benefits at the component level as well.

A great example of this is, in the iOS/Cocos2d space, sharing sprite batches between instances of the same component. Our simple BCharSprite is instanced in a number a different types of game objects and hence is difficult to build factory and shared methods for -- it's a true component in it's isolated behaviour. However, we want to be able to re-use sprite batches when the sprite sheets themselves have already been loaded by another component. This is accomplished very easily using a blackboard using a single NSMutableDictionary accessed as follows:

Should I use a blackboard for storing data in my game's component architecture?

As with anything component-oriented (and really any software design) this does require some forethought and consideration -- you need to understand why you are implementing this kind of storage, how your comopnents are independent and (as they inevitably will be in some way) interdependent.

There is no perfect solution, but there are lots of great ones. This seems to be working for us so far.

More information:

• object composition and lightweight game component architectures
• our original game component architecture design
• blackboard data storage

We use a pretty lightweight component architecture for our iOS projects. It looks exactly like the structure above.

• Game World -- container for game objects; entry point for broadcast messaging, update loops, cleanup messaging and object removal
• Game Object -- container for components (or behaviours as we actually call them in code); parse for loading objects from templates; proxy for messages, loops and cleanup
• Component -- a specific piece of encapsulated game logic or functionality

The component is the critical thing -- this is where you put your stuff. Game objects are a composition of components. I'm not going to try and explain that here -- I suggest you check out the links below, or wait until John gets the session recording up from 360idev in which I talk about this quite a bit.

• Original outline post written here: 36peas component architecture
• Refactoring Game Entities with Components
• Property and evented style components
• Theory and Practice of Game Object Component Architecture (PPT)
• A Data-Driven Game Object System (PDF)
• Game Programming Gems 5 (2008) -- Bjarne Rene -- Component Based Object Management
• Not quite component-architecture specific, but this post re static blackboards on AIGameDev is useful if you choose to implement data storage in that way.

It's critical not to get hung up on trying to implement or decide upon a perfect architecture. There isn't one.

Remember:

• Object-orientation isn't bad -- but composition is very different, so they end up competing
• Though most composite systems utilise OO structure and design in their implementation
• Messaging and data storage/access need to have solid design (there are several options -- see links above) before you start coding

In implementation that we use, a component (behaviour): 

• Gets used more-or-less generically
• Receives messages and acts on them
• Sends messages to it’s game object or the game world
• Reads and writes data from the game object’s store
• Handles messages on the update loop (and draw loop potentially)

Additionally:

• The components contained in an object represent the only formal definition of that object -- don't add or remove components to an object after its initialization
• You need to be watching performance -- certain tasks (like key lookups on a shared store) can be expensive if done frequently (design around these or embed other systems within your component architecture)

360idev Game Jam example and code

The Game Jam's theme was "opposite" and the entry I put together was titled "Fungal Adventure." Summary of the game is pretty much:

• 2-player local iPad game (vs -- with players on opposite sides of the device)
• Move your dude left and right
• Objective is to get to top of screen to win, or to force other player to die
• Eating a mushroom makes you go faster for a little while
• All mushrooms have some effect on you -- which must be countered by that mushroom's counterpart (edible<>toxic; psycho<>medicinal).
• If you don't eat the right counterpart you die (and lose)
• Eating any mushroom also swaps all other mushrooms of that pair (i.e. all edible become toxic etc)

It looks like this:

Aside from the obvious game wrapper stuff (menus, scores, tallies etc) I'll be following this up with some additional features and changes before releasing it, including:

• Swap out one set of mushrooms for something else to make it a bit clearer how the pairs work
• Add an AI for single player use
• Add some other obstacles and game-state-changing elements

If you'd like to take a look at the code itself (which I know at least a few of you do judging by the numerous requests and feedback I got after the session), you can download it below.

However, please read the following disclaimer:

• It was written in a 12-hour game jam on zero sleep

Which means that:

• It's incredibly sloppy
• There's very little memory management
• There are huge performance problems if you replay the game a few times
• Sometimes you can't win
• Occasionally mushrooms spawn on top of a player and end the game immediately for no apparent cause 

However, on the upside:

• It's an excellent demonstration of what you can do with components in a short space of time
• The component architecture itself (the DW* classes) are not sloppy -- I've re-used them
• The game code itself is so incredibly shoddy you can see that it's not important how to build a component system, just that you do so in the first place 

Download it here -- Fungal Adventure (36peas 360idev 2011 Game Jam project).

Notes on use: 

• Do what you like with the code
• Name and all artwork are copyright 36peas
• I've had to remove the background music as I'd borrowed it from another project

Enjoy -- give me a shout if you've any questions on the above, would like to see the same material at a different conference or just want to chat. You can get me on twitter @36peas or by email gareth@36peas.com.

--

Updated 21/09/11: Not quite component-architecture specific, but this post re static blackboardson AIGameDev is useful if you choose to implement data storage in that way.

Last week we set about putting some parameters around the remaining design work for the core feature set of Dead West. We’re not trying to pre-emt derived and iterated gameplay stuff -- just get a basic framework to aim for.

One of the biggest remaining decisions is whether we're targeting aracde-style replay or campaign-like progression through the various maps and levels. We've a lot of flexibility in how we spawn, introduce and balence enemies -- so we can take a basic "x enemies == y time" sense of anything.

In order to produce for ourselves both a chicken and an egg, we decided to firewall some assumptions against the level designs we currently have. After a good amount of pondering on how we do that, we:

1. Took a straight line (quickest) path through each level*
2. Calculated a walking traversal distance for that path (based on what looks right in our current codebase)
3. Inserted a number of enemy encounters that we felt looked right based on the aesthetics and feel of each map
4. Timed those encounters (based on a completely different game)

* this sometimes meant picking arbritary start and end markers

The point of doing this was to answer the question "if we just give the player a simple A-B experience in each level, how long would it take them to complete the set of designs we have"... hopefully leading us towards a design on arcade or campaign/completion play.

Some detail on the techniques we used:

• Stopwatch was invaluable for working out a pixels-per-second walking speed for our standard heroes.
• "Mean time between interesting shit" was calculated/measured in Fable 3's gameworld
• Reasonable encouter sizes and hits-to-kill enemies was estimated based on Battleheart
• Relative encouter sizes and likely time differences were based on Warhammer Fantasy unit balance calculations

We got to a level completion time of between 25 and 40 minutes... and an answer on what kind of map progression and session play style we're targetting. We'll go into more detail on that in the future -- but suffice to say it's nice having the flexibility.

By far the most difficult bit was simplifying the problem set -- we spent a long time stopping ourselves from talking about enemy encounters and the complexities therein. We ultimately boiled them down to "Small", "Medium" and "Large" encounters, safe in the knowlege that if GW can genericse everything to a points value we will be able to as well.

Other pleasant side effects of the whole thing included a prototype for how we can offer variable play based on player preference and player experience -- and a good number of ideas for where we go next in regard to spawning and triggering of enemies (all of which seem simpler than we'd anticipated).

In it we cover wrangling perspective and the use of 3D-like environments for our upcoming 2d, action-strategy iPad game, Dead West. See below for a further breakdown of contents.

We also start to talk about some of the level design itself -- and how that impacts on the art and art design.

All the artwork featured was produced in PhotoShop, and the video's full of hint-shaped nuggets for producing exactly this kind of art in PhotoShop.

The video also features early previews of some of the original score from Dead West.

Game Dev in Motion?

What do you think of the format? Let us know in the comments -- we're thinking about doing more.

We’d written a little about Brotherhood in a post last week, but on getting into the detail discovered that there’s something very interesting going on in the multi-player experience. The game carves out a multiplayer mode based not on the conventions and received wisdom of its contemporaries (those being other AAA titles) but based on a gameplay experience that has been evolved and perfected over the series*.

As a result of this, the gameplay experience delivered by Brotherhood’s multiplayer mode is nerve-wracking, tense and thrilling. And it’s all of those things because of the clever way other human players are introduced into the game world established by the single-player Assassin’s Creed experience.

If you’ve not played it, the best introduction is probably seeing it in action:

Some from-the-horse’s-mouth (well, actually a Goose in this case) observations:

Ignoring the ridiculous wait times (I timed 19 minutes on one occasion) to get into the game, the level of tension generated in the Brotherhood multiplayer experience is second to none. To be successful in a match you must act swiftly to score as you are competing to finish top of the leader board. This works contrary to you having to behave in a calm manner so as to avoid detection by the player you are hunting. This juxtaposition is heightened by the fact you are sometimes being stalked by many opponents - and other players may also be tracking your target, increasing the necessity to locate and dispatch your prey quickly and quietly. On a number of occasions I’ve witnessed a player break cover and assassinate his target only to be brutally stabbed in the face a split second later.

The chaos that ensues when a player acts inappropriately can at times be both frightening and hilarious: you may find yourself calmly walking amongst a crowd approaching your prey - lining yourself up for the perfect kill - and then, for no apparent reason, the calm is shattered as someone nearby starts to run. At this point it becomes a true test of nerves. There are many reasons the character may be running: they could be under chase; they may be after your kill; they may be coming to kill you, or; it may just be the AI fucking with you and there’s nothing wrong. Either way, at this point, nine times out of ten the majority of players in the area panic and scatter, some will die, others will escape but your perfectly lined up kill has gone and you must steady your nerve and begin again. The level of concentration this demands is so much more than in most multi-player experiences and the depth of emotional involvement it demands is truly mind bending. Never before have I played a multi-player game that has the player so engaged that the emotive drive actually parallels the events occurring on screen. Whilst from a tactical point of view it may help to have a soldier-like mind set while playing the latest Call of Duty, at no point do you actually feel like you are a soldier or part of a unit. The level of distrust and suspicion of everything in your environment goes a long way to making you feel like an assassin in Brotherhood.

As mentioned before the overall mood of the game is generated by its conflicting pace, this however does open it up to criticism as at times the second greatest frustration raises it’s head, on a number of occasions I have found myself with no target for various reasons and at points the time it takes for the player to be assigned a new target can be quite lengthy. When playing a game when the suspension of disbelief is anchored around its pacing this problem is quite a large one if for no other reason that you can’t ecru points and maintain your position on the leader board if you have no targets to kill... especially if other players are racking up kills during this down time.

There are a number of  issues in the game play’s architecture and design though – primarily that the issuing of targets isn’t consistent (i.e. it can take you a lot longer to be allocated a new target than your competition). At these points the attitude towards the game can be adversely affected. In some instances the focus can easily switch from the cloak-and-dagger approach intended and generally desirable to a “shit... I really need to get a quick few kills to regain my place on the leader-board”-type attitude. This negative change in attitude often sends a ripple through the other players’ behavior. If for whatever reason players start dashing around to grab quick kills, the atmosphere of stalking-while-being-stalked quickly dissipates and the mood becomes more brawl than a battle of wits and holding of nerve.  On the whole though these situations are rare and the game really draws the player into a unique and innovative style of game play that – no insignificant feat considering the vast array of design variables involved multi-player game play.

What next?

Playing a Call of Duty or Halo game in a multiplayer mode does provide a challenging and changing experience because of the nature (and varied skill sets) of human player opponents – and how they behave differently from AI opponents. Brotherhood relies on this differentiated behavior (of human-played characters over AI characters) in order to drive it’s game play. It’s like a sequence of inverted Turing tests – convince the human that you’re a computer.

The recent popularity of bot modes in AAA titles (e.g. Firefight in Halo: Reach) already highlights that players are interested in multi-player experiences that do rely on there not being human players as opponents (it wouldn’t be possible to organize and coral so many human players into a horde-like attack of the opposing team). But, whilst interesting – and a lot of fun, it’s no co-incidence that the heavily-human-player-behavior reliant experience of Brotherhood is also an emotive one. What else can we do to drive such emotive responses?

* I’ve not played it myself yet, but according to all accounts a lot of what’s good about the behavior-based tensions and skill in Brotherhood is also born out in Chris Hecker’s upcoming SpyParty.

I’m sick of hearing iOS devs complain about Apple, about Apple’s policies and about Apple’s terrible treatment of developers.

It’s their platform. They created a market. If you don’t like it, fuck off.

I wrote started to write a full post about this earlier, and planned to bring together my thoughts coherently. I had references on market laterals from the HBR and everything. But I can’t be bothered. I am very much looking forward to getting this off of my chest as quickly as possible and getting back to what’s important: testing earth-tone base colors for the delivery of Citadel goodies I’m expecting tomorrow.

In virtually un-edited form, here are some of the notes I started to make earlier: 

• Apple created a market. Duh.
• It is, was and probably always will be their platform
• Apple are known for lock-in to their stuff
• Apple are known for not sharing things until the last minute
• Re devs not having access until launch, some people seem to have managed just fine in getting stuff ready.
• Just because you’re developing for the App Store, doesn’t mean that you represent the average, typical or most likely example. “Camera+ from Tap Tap Tap sold 78,000 copies on Christmas day, but no one else I know sees numbers like that” << of what relevance is that?
• People like to moan… so most of what you read on the web (yes, including this) is people moaning. Those who are doing well have got better things to do.
• Apple most probably think about what they do and how it affects developers – they know what they’re doing.  Maybe their considered opinion is that it works best this way.
• Apple tend to stand by the information they do publish – they told us the Mac App Store would be 90 days, and it was 90 days.
• “Apple's secrecy cripples their ability to have a positive relationship with developers.” So what? Their App Store continues to lead the space.
• iTunes (the music store) is notoriously lacking in features for both users and creators / publishers… yet it is still head-and-shoulders above the competition (it also created a market). 

One particular game is relevant to this post: Reckless Racing.

A couple of times in 2010 we spent some development time on a top-down, drift physics racer. Originally titled Retro Racer, then later some part of our Unga Bunga project and most recently Dwarf Dash.

The time we spent on each form of the project was useful – in its first instance it was a case of getting a prototype working, with physics written from scratch. It took about 3 days and was fun and effective-for-a-prototype playable.

In its second form, we did little (no) work on the game code itself, but a lot on the design and concept – this ended up forming the grounding of a completely unrelated god/sim game: Unga Bunga.

In its third, most recent and final form (as final as it’ll get) it was titled Dwarf Dash (which we started as part of the Ludum Dare Challenge). This involved a re-think of the concept, related art and general game design issues, as well as a re-implementation of the original prototype in our new component architecture. What we learnt here from a technical point of view was invaluable and fed directly into how we used that architecture in the two titles we now have in active development.

Where does EA come in?

As it turns out (and we could’ve figured this out in advance, but didn’t) there’s not a huge amount of original design, iterative design change or innovative implementation involved in something that is quite squarely another crack at a well established genre and game type.

We were doing this because I very much enjoy top-down drift physics racers. And this is where there’s an important (and not often explored) message:

Creating games that you (the indie dev) want to play isn’t enough.

As indie developers with no external constraints, we should be be mindful of the required development and design implementation: we should be working on things that are interesting and exciting to develop as well as play. This is how we bring real value.

Producing video games is a vast and varied undertaking. I’m insisting that we select titles based on their innovative design value, as well as their desirability as a game player. Let’s leave the implementation of well-trodden game types to EA (and those like them) and enjoy the fruits of their constraints. Reckless Racing, aside from minor criticisms of the AI and a few other bits, is a pretty damn good implementation of a top-down drift physics racer for iOS.

To conclude

Thank you EA for sating my need to drift rigid bodies around finely-tuned curves. And thank you EA for getting me to this point and letting me get on with innovating and creating.

The day’s events prompted a number a thoughts for game development ideas, most of which are quite well suited to iOS. Instead of staying up several hours longer than I’d like and writing up one of the general game design posts we’ve been working on, or finishing the 2010 gaming retrospective we’ll likely post next week, I thought I’d spend a smaller amount of time expanding on the ideas below.

Balance: removing the normal visual cues

Park a truck on slope sideways, with an exit on to a level path. Then get inside said truck and bend to pick something up – all of a sudden you realize that a lot of what you rely for balance and stability has gone and it’s actually quite disconcerting.

Taking this idea, it’s pretty easy to extend it to an accelerometer-based game that involved some abstracted form of “balance” in the game world. Progress the game by making the player dependent upon visual cues and then – bit by bit – removing them.

Logistics: right resource, right place

Take 4 people, 4 vehicles, 2 primary locations and several secondary locations and then try getting things in the right place at the right time. When the respective skills and properties of those people, vehicles and locations are varied (and in some cases absolute) things get mighty tricky.

This is an idea needing a context / world design – but anyone who’s ever considered game design has plenty of those. Apply one to the other for puzzling or real-time management fun.

Environment cycle: the massive effects of night and day

Doing things in the dark has its problems, doing them in the dark when the temperature drops another ten degrees below zero between day and night is another thing entirely. The knock-on consequences of several cycles are interesting too – a snowy hill is drivable one day, but unusable the next because it that snow was compacted and is now sheet ice.

Degrading performance: hampering expected ability causes frequent re-planning

Locomotive movement, respiratory function and agility are generally predictable for any human being. But when the environment they’re operating in affects those things significantly they’re forced to frequently re-assess their ability and re-plan their actions.

The obvious game mechanic here is in gradually degrading the abilities of the player, forcing them to perform faultlessly or otherwise find alternative methods.

Displacement and misplacement: confusion and exploration

When you’re familiar with how your objects are connected to your environment (physically and functionally) it becomes very difficult to answer normally-trivial internal queries (where is this, what do I need to do that).

This is likely best applied as a specific element of a wider game – one in which the player becomes familiar with their tools and their abstracted connection to the game world. Changing that environment around them (i.e. not giving them a new environment, but one that provides the same function in a one-home-for-another like way) presents them with challenges they wouldn’t have expected and likely aren’t well prepared for.

Space is premium: confinement drives perfection

The main criteria for selecting our new home were all about space – specifically the size and space within each room. Already (and we’ve not fully lived here yet) we can see the massive (beneficial) change there is in doing very simple things – like moving in and out of rooms.

Have a player perfect something, then make them do it again with less “space” – two examples spring to mind here: PacMan and the usefulness of many entry/exit tunnels and what happens if you take them away, and; Osmos and the affects of a more confined (or densely packed) play area.

I've resisted doing this for other games, but now fully into the swing of things with #idevblogaday I've decided to ignore all previous concerns and just get on with... critique and anaylsis of other people's games.

Any experienced game developer will tell you that the best form of testing ideas is by looking at the work of others. With a bit of patience and a lot of 20-achievement-point plays, it gets pretty easy to learn from a game in an hour what the development team spent years on. Okay, they probably learnt at little more - but in terms of testing design ideas you're actually better placed seeing it with fresh eyes (just like the fresh eyes of your audience: the player).

So, without further adue, here are some thoughts on very recently released Infinity Blade from Chair Entertainment.

I'm not going to bother explaining how the game works - it's pretty simple. If you've not read them already check out Shawn McGrath's notes on reward and fun and demaning better design. Actually... if you've not played it yet do that first and then then read them. I don't want to give anything away. Oh, hang on - best not read part 3 of this either. Or part 2.

Giving my own game away, you've probably guessed that this is in parts - they go something like this:

1. My thoughts from late in the evening after reading one of the early review (before having played it)
2. The initial thoughts/reaction of our resident art Goose (an eager sword swinger)
3. Some analysis and specific design thoughts I wrote as I was playing through the game

Part 1: Late-night ramblings before playing

...I love the fact that they appear to have thought about how to bring a levelling experience to devices that are _not_ console/PC. The whole 30-minute rinse repeat (with levelling) thing, regardless of whether it's been implemented well, is absolutely on the right track...

...I'm intrigued about how it plays out on both iPhone and iPad given the swipe-sensitive nature of the game -- something that's quite different on each form factor...

...Also: cut scenes with interactivity. Winner. Don't care if it works, it's just showing that they actually -- you know -- fucking thought about it. "It" being watching another bloody cut scene on a i_____ screams "I know how to make CONSOLE games"...

...All of this done with the Unreal engine... the Unreal engine that powers so many "me too" titles elsewhere. There's the flip side of that too: it makes things look good when you actually try...

...I suspect/hope that this, though, will be remembered not for its aesthetics (which will be surpassed soon enough) but for the fact that they brought a graphical iteration as well as device-specific thinking and inspired game design...

Part 2: Initial thoughts / reaction

From Goose:

At first was bowled over at the way it looked but then figured, "you know what? It's not actually that impressive, kind of reminds me of the PS2's Devil May Cry." I'd have probably still been impressed as I haven't yet seen much that looks anywhere like that good on the iPad -- before, that was, I checked out Rage HD recently. Playing Rage changed my view on what is doable.

At first the gameplay made me grin. However, after having to do it again for the umpteenth time i started to get a bit bored -- and massively dissapointed. I thought there would be a large amount of exploration involved but, nothing. Would have been really blown away if there was an ability to explore the awesome looking castles.

The whole thing feels like a demo for an upcoming - and less than great - title. If its going to be a show-case piece then it nees to be more polished. Which reminds me, this would work better with actual buttons to press - or at least touch controls that responded a bit more like buttons. I quickly got fucked off at how many times i took a swing and nothing happened or the dodge button didn't work and i ended up getting twatted as i stood there like a fucking goon. 

On difficulty... what the fuck? No real learning curve, if anything it's fucking backwards! One minute everyone is a push over and as slow as a retarded sloth, the next they all have mad ninja skills and fuck you up in a heart beat.

The overall feel (aside from it feeling like a demo) is standard beat em' up,  only replacing the ill-placed narrative with, er, some walking. All it's missing is a over-egged vs screen with slide-in introductions surrounded by flames.

Over all it's a shame: I really like the look of all the environment and the equipment and the fighting can be fun at times. Unfortunately though, the only thing that makes me want to play again is my desire to knock that smarmy bastard off his throne and hopefully open up something new in the game.

Part 3: Analysis / design thoughts

So after us both having played it all the way through (well, in so much as you can do that - to the point of actually killing the God King anyhow) we noted some thoughts on the game's design and implementation.

Useful or just a curiosity, this is the kind of stuff we use to evaulate our own game design decisions.

• The eagerly-anticipated "interactive" cut scenes feel more like a severly crippled adventure/looting experience -- not enhanced cut scenes.
• The fast-forward feature during cut-scenes and in-battle interludes is brilliant: it get's around the "i don't to press skip because I might miss somehintg" issue, as well as providing the player with a functional and consistent way of skipping through the juicy bits.
• The button/touch responses are infuriating - so much so that I went for a sheild-heavy build so I didn't have to press the dodge buttons too much.
• There's no clear indication of what you should be doing and when -- the earliest battles with the God King are so repetitive that you wonder whether you should just let him finish you quickly and wait for a "different" experience to make an actual attempt. It turns out that this is the wrong way about doing it - at some point (generally at the end of Bloodline 5 or 6) you should able to actually beat him. In fact, it turns out you shouldn't expect anything other than an exact repetition of what came before: whether he kills you, you accept default at his prompt or you kill him, it'll be just the same the next time around.
• It's pretty obvious and not particularly worthy of specific comment, but this game is entirely based around artificially rewarding the player. Nothing you receive in reward (xp, cash, loot, levels) changes anything about the game - there's no new content (arguably the additional weapons and armour provide a small reward in the form of new textures) and nothing changes the game mechnic and features (established early on in the first Bloodline).
• The in-menu music is very clever -- dum, dim, dem, diim -- it compells you on, constantly driving your forward for the sake of, well, driving you forwards.

• The affect of enemy levels is just a mess. As there is no "levelling in this game is unlike every other" message or even suggestion of such, you expect something akin to the genre-defined normals unless told otherwise. To illustrate, some specific notes taken as playing through:
  • Should i really be able to take on a lvl24 assasin (at level 10) and win?
  • I took out the God King at level 17. He was level 50.
  • Really what do the levels do... On bloodline 5 I'm encountering a lvl25 Hedge Knight who can't land a hit on me (I was lvl14 at the time) - i can just shield block, block, block break and then take a swing. This was repeated later for level 30-40 enemies (I only ever got to level 22), and the level 50 Death Knight (who provdies no defence whatsoever to the God King himself).

• The pacing and visibility of the battles themselves is too quick and unclear - it's far easier to rely on what it tells you than shows you - i.e. the "block break" thing is the cue to start swinging one's sword.

• Unclear on what options are when you loose a battle -- save and return to start of castle? Does this mean you save your status and go back to castle start or that you save a game or what?
• Seemingly no facility to have more than one campaign -- in a game that does, theoretically, at least, support multiple effective character builds this is just plain irritating. No one else can play it on my iPad, and i can't play it how I'd like. I can live with not being able to share it with others - but I'd really like to do a shield and magic build alongside my shield/attack build.
• Seems on bloodlines 3 and up it's always possible to get the God King down to approximately 60% health without really taking too much damage yourself -- at this point though he'll inevitably break your shield and knock your sword aside. Until you can do some real damage (at Bloodline 5 and up) it doesn't feel like you're getting any more able to defeat him. And then when you do it all happens in one go.

• There's nothing stand out about the graphics (although a good demo for the platform). The visual design is impressive - and a relatively small amount of world space is used to good effect in both battles and battle-to-battle movements (camera angles being the key to this). Unfortunately there are some very specific issues that make things look very poor - best example being the sight of a sword piercing armour in a finishing move -- i say the sight of a sword piercing armour because I'm sure that was what was actually meant -- unfortunately it looks more like a geometry mismatch with the sword texture cleaning intersecting the armour texture. I realise Apple may have kicked back on blood effects but there are lots of other ways to get around this.
• Some battles forgo the pre-battle info screen - I.e. you get a route circle/button, but tapping it moves you to a position and then starts the battle immediately. This wouldn't be so much of an issue (I never needed to re-spec equipment before an encounter based on opponent info) if it weren't for the fact that you expect that pre-battle pause and as such aren't primed and ready with your sheild finger or dodge.
• The dodge buttons just don't work properly. As a result of this, you inevitably end up with a shield technique that gets dull fast.
• Opponents get easier as they increase in level - a lvl 31 assassin (encountered at lvl15) was a lot easier to deal with than a lvl23 assassin on a level previous -- specifically in that it became quicker, but far more predictable and less risky. When doing block, block, block break instead of having to estimate when it starts swinging again, it now blocks your attacks after it recovers from the initial stun of the block break -- so the pattern becomes block, block, block break, attack, attack, get blocked, ready shield to repeat. Previously you were left exposed as you're attacking as it'd just swing straight at you while you were attacking -- because the pace of the mechanics of the thing are so quick, it's not possible to dodge or shield these attacks (unless you only land a couple of blows and then deliberatley stop attacking).
• Very rarely do you have break from this pattern - some enemies attack with their sheild and you have to dodge it and some land very heavy blows and deplete your sheild quickly (depending on your spec, possibly before the end of the battle).

The endless repetition is actually a good idea - I don't mind it at all. It's all the other stuff that gets in the way. The rinse, repeat structure of the game is novel and provdes greater valuable mileage out of limit assets / development time. It could do with being just a bit more interesting though. Groundhog Day gets is a somewhat more refined version of formula, and that doesn't even have swords in it.

This sounds like a lot of criticism, but it obviously got something right - as I've been compelled to write about it.

We've explored this by example - mainly because it's more fun to read that way, but also because it's useful for those not familiar with the genres used or for those who haven't tried the different difficulty settings available.

I'm sure most have you have played MW2 (note that other Call of Duty titles aren't necessarily appicable - we'll perhaps write about the apparent lack of considered difficulty settings in Black Ops at another point). The other example, Strategery, is available as a universal app for iPhone/iPod and iPad. For the purpose of the example, it makes no difference which device you're looking at.

The key thing to note here is that on the easier settings, the opponent AI in both games plays without tactics - they are equipped with basic responses and impulses, but no real tactical knowledge. On harder settings the opponent player/AI is equipped with tactical knowledge which it employs it to reach its objectives.

Through the provision of different difficulty settings these games manage to provide two distinctly different experiences: a visceral experience that provides no challenge, and; an intellectual challenge that requires the player to apply and develop skills (with the visceral elements rewarding and encouraging them along the way).

Case Study: Strategery

(above: key points in a vs AI game on "Easy" difficulty setting - human player is blue)

Strategery is a domination-style game in which several players (in this case one human player and the others all AI players) take turns to make advances across the board, with the winning objective being to conquer all of the available regions. There are some subtle nuances to how play progresses - namely that with the standard rule set new playing pieces are first divided between your border regions and then your other (less vulnerable) regions. Each player is rewarded with new pieces at the end of their turn equivalent to the number of regions in the largest contiguous area they occupy.

On the Easy difficulty setting, the AI players:

• focus on expansion;
• attack "soft" targets (those with fewer pieces);
• end up hugging the edges of the playing area as it looks to expand in every direction, and, most importantly;
• are oblivious to other players' movements.

Note: there also seems to be an element of "cheating" in the random (dice roll) element of play on Easy - whilst rolls in even scenarios on Brutal seemed to be 50/50, on the Easy setting they seemed to average 70/30 in favour of the player.

(above: key points in a vs AI game on "Brutal" difficulty setting - human player is blue)

On the Brutal difficulty setting, the AI players:

• concentrate on constricting other players;
• will attempt to "cut through" large areas occupied by their opponents, and;
• try to minimise the number of "border" regions they have in play (in order to concentrate newly awarded playing pieces to those borders).

It doesn't take long playing the game to realise that the Brutal AI plays very much like a mindful human player who is adopting Blitzkrieg-like tactics.

Case Study: Call of Duty: Modern Warfare 2

On the Recruit (easy) setting, Modern Warfare 2 is straight forward to play - it's pretty difficult to get yourself killed. The experience is very much like watching a gripping action film in the same genre, the player is taken along for, and "shown", the ride. 

The Regular diffculty setting only changes the experience by adding a few more opponent forces and by making them a little more able to aim accurately. If it were not for the back drop you'd be forgiven for feeling like Master Chief wading through hordes of the Covenant.

In these two easiest modes the player is pretty much denied the opportunity to think tactically and it's difficult to become immersed in the full mise en scène of the respective levels' design.

When first jumping in to the harder difficulty settings (Hardened and Veteran) it can, at first, seem a little frustrating: there is a noticeable change in how hard it is to accomplish objectives. The game doesn't get harder simply because the opponent's bullets do more damage or because their aim is so much better, it gets harder because the enemy forces are actually employing a tactical method in trying to kill you. Amongst other things, they'll plan ways to get around your "wall of fire" and they'll keep their heads down to avoid getting shot wherever possible.

This is where things get interesting: you quickly abandon your run-and-gun approach and end up having to completely immerse yourself in the environment in order to develop your own tactics. Instead of following a linear path from one check point to the next, the player has to evaluate each immediate objective. By thinking laterally and adopting a more military (realistic) mindset each stage is completed with relative ease. By flitting from cover to cover and only taking shots that are available survival is prolonged. The changes in enemy behaviour and consequential planned tactics employed by the player enhance the sense of danger and realism. 

The diagrams above illustrate the analysis below for the extremes of difficulty in the Market Square section of the "Hornet's Nest" level - set in the favellas of Rio de Janeiro.

If you've not seen it before, check out YouTube-hosted walkthroughs of Hornet's Nest on Recruit (easiest) difficulty and Hornet's Nest on Veteran (hardest) difficulty.

On the Recruit (easiest) setting: 

• The player has essentially free reign on the route they want to take.
• The player can head straight for the raised area around the central building and:
  • see all the enemy forces
  • wait for the enemy to enter the map from the main spawn point (green arrow in diagram) or the building tops
  • wait for the enemy to filter through towards areas A, B & C
  • pick off enemy targets as they expose themselves between those areas
  • watch (and pick off) a steady pattern of enemies moving from roof #1 to building #3 and on to #6 and #7
  • ignore building #7 once it has been cleared (it generally isn't re-occupied by the enemy)
  • do likewise for enemies moving into buildings #5 and #8
• The enemy player's basic tactic of holding positions and occasionally taking shots when available makes overpowering them very easy: the player can get a good view of where enemies are and can deal with them one by one by standing behind cover and surveying the map as the other non-player-controlled members of the team keep the enemy suppressed in cover.

On the Veteran (hardest) setting:

• Enemy soldiers still spawn in the same areas, however it's rare that they move across open ground.
• Instead of simply reaching A, B, or C, the enemy soldiers will, if possible, push on to reach area D and ultimately will attempt to take control of the central raised area.
• The enemy soldiers that spawn on the roof of building #1 still filter through #3, #6 and #7 but if and when the occupants of building #7 are eliminated, remaining soldiers will move around in order to occupy the more advantageous #7 building.
• Similarly, the troops around area C and those spawning from #2 will continuously try to occupy buildings #5 and #8.
• Combined with the continuous suppression of the player's team members, the above enemy tactics force the player into making their own tactical choices.
• The obvious route - to the central area - gets the player killed quickly. If the player heads up towards the raised part of the central building they are quickly overwhelmed: they are flanked from two sides and the enemy will actively move in on the player. As the enemy soldiers have a better aim (than on easier settings), both the player and their team mates are regularly forced into cover, allowing the enemy free (and largely invisible to the player) movement of the battlefield.
• The player will need to choose a flank on which they wish to counter attack and attempt to clear a path up one side of the map with the aim of getting around the rear of the enemy forces (note that doing this also rewards the player with "hidden intel" - an artificial reward/achievement).
• Once occupying a position to the rear of the enemy, the enemy soldiers fall back allowing the player's team mates to advance - pushing the enemy back yet further.