It’s The 1.1 Patch! The One With World Customisation In!

Hello, all!

Today we’re serving up the 1.1 patch for you all, which fixes a bunch of minor issues but also adds a custom biome and a global robot manager.

The robot manager allows you to select global values for how enemies appear in the world, which should allow you to make it harder or easier as you prefer. You can even remove all hostile NPCs from the world (the pheasants and rabbits stay!) and consequently add a “Walking Simulator” mention to our Steam tags…

The custom biome means that you can create some non-standard worlds that go way beyond what the five standard biomes allow. You can switch that on in Game Options. But wait! We know that the first thing you’ll do is make the maddest worlds you can, so it’s important to stress that the permutations this world generator provides are so extreme that they might make teleporter fragments inaccessible to you, which means there’s a chance the crazier levels can’t be completed.

If you don’t want to risk that for a proper playthrough, then stick to the standard templates or spend some time experimenting with a myriad of valid worlds. If you’re happy just to see what you can make, however, that’s what the custom biome is for. Remember that with the robot manager you can also now tour these worlds in safety. There’s even a world code function in Game Options so you can share your creations with others. (Paste these codes in the Custom biome editing screen to get that exact world!)

Here’s a video to explain more:


- NEW: Custom Biome (activated in Game Options.)
- NEW: Global robot spawn manager.
- NEW: Added graphics option to disable God Rays.
- NEW: Colour picker for robot visors (Colour blindness support).
- Robot step height tweaked.
- Fences no longer appear over seriously sloped terrain.


- Audio-based distraction of robots now more reliable.
- Robots can no longer spawn inside pylons.
- Shots Fired stat now accurate.
- Starting gear item count now matches menu list.

It’s The February Update (And he’s here!)

Hello you!

The new build is out now on Steam, and will be available this evening on Humble.

Well, it’s the end of an era. For many months we’ve been releasing a new NPC with each update and now – finally – the cast of Sir is complete: meet The Landowner.

This update is a huge internal milestone for us as it represents the last piece of new behavioural code, the last set of animations, the last character to enter our procedurally generated world. We still have more content to come in the form of the Castle Biome, but the vast bulk of Sir’s assets are now complete.

Why is this important? Because it means we’ve had time to really start tinkering with the variables!

This update has seen some really tight focus on core AI behaviour, most noticeably in the Hunters – our most behaviourally-complex AI. You should see big improvements to Hunter combat behaviour, the way they handle cover and corners, but also to their non-combat states. Several improvements were made to the way AI investigate noise and as such distraction items should be more reliable and more rigorously investigated. Our robots have also had their eyes recalibrated, the ranges they will engage and pursue you from should feel much fairer now. That’s not to say we’ve made things easier. There is – of course – the new threat of the Landowner. But the new AI code changes can actually make the bots tougher in some situations, more tricksy.

There are also some new features to play with! The Toy Train now has a secondary “Moving” function mode (as with all items, “Right Mouse” to activate secondary functions) allowing you to set it trundling off in a particular direction rather than remaining static on a track. This can be a great way to lead robots away from – or into – certain areas. Cue conga-lines of robots chasing tooting trains…

Following the successful response to last-update’s TrackIR support we’ve also added a key for independent head-movement just using a key modifier. If you hold down “Left Alt” (default) you can now look around while continuing to move in a different direction. It’s like TrackIR, without TrackIR!

There are also some under-the-hood things for modder/tweaker types to play with which we’ll talk about more in the BR forums if you’re interested…

All in all this release feels great. The cast is complete. They’re starting to behave properly, and we only have one biome and customisation options to go before we’re content complete and we can start calling this a beta…

As always feedback on the forums is very gratefully received. Enjoy!


We recommend you generate a new world to take advantage of new features. Also: stuff might break on old saves.


- NEW – Landowner NPC.

- NEW – Support for controllers in menus (still not inventories yet, soon!)

- NEW – Free-Look key modifier. Holding “Left Alt” (by default) will allow you move your head independently from the body, simulating TrackIR use for those without that hardware. Only works if TrackIR not running or toggled on.

- Toy Train now has “Moving” mode as well as “Static” (Right Mouse default).

- Improved AI combat behaviour (especially corners and cover management).

- Improved balance for AI vision and pursuit.

- Several improvements to AI noise investigation States. Should result in more reliable

distraction and sound investigation.

- Changed the way AI glimpse-state works so bots no longer spot players unfairly due to heightened aggro state from recent inter-bot combat.

- Changed destination pathing solution for all AI. Bots will no longer want to visit places they can’t path to…

- Changed the way bots decide to guard doors. Should result in less over-guarded buildings.

- Exposed robot release schedule to xml file. See BR forums for editing advice…

- Faster bunnies.

- Performance: New audio lodding system should boost FPS.

- Increased Wisp numbers slightly. Use them!

- Faster dogs.

- Sundry loot balance tweaks

- Sundry AI variables tweaked.


- Added option to limit FPS to prevent some hardware configurations running too fast.

- Volumes now applied correctly in menu screen.

- UI on/off toggle fro screenies now turns off crosshair too…

- Compass bearing now relative to head camera (so is in-synch with look direction, not aim direction).

- Fixed several scenery items that weren’t blocking path grid properly.

- Fixed some movement issues with Hares.

- Fixed animation issue with sea beast.

- Adjusted perimeter walls for some buildings to fix pathing bottlenecks.

- Fixed some issues with scarecrow teleporting.

- Fixed an issue where quitting immediately after generating a world lost your starting equipment.

The January Update Is Here

Hello you!

Firstly, sorry it’s taken a bit longer that usual to get this update out. (It’s on Steam right now, and Humble builds will appear this evening.) The Christmas break didn’t help, but mostly the delay is due to a massive overhaul of the animation system. The fruits of this are quite subtle, but you will notice it in terms of less jerky transitions between certain animation states, or a subtle slowing-to-stop of the bots. The system is now far more reliable and robust for pathing. It also needed to be done to implement the new NPC, The Rider.

These mounted toff-bots enjoy toasting your unhealth with a blast from their mount’s leg-jets. Crispy!

Less dramatically, we’ve got a new audio levels system, reworked NPC release schedules, tweaks to combat, sticker explosives, braver ravens not to mention independent head-movement with TrackIR support (PLEASE NOTE: 32-bit ONLY). Here’s a video of TrackIR working, with a glimpse of The Rider in-game:

As always feedback on the forums is very gratefully received. Enjoy!

This update will break your saves.


* NEW -Enemy type: The Rider.
* NEW – Support for independent head movement with TrackIR. (PLEASE NOTE: 32-bit ONLY)
* NEW – Group-based volume system. You can now set volumes for various things separately (Turn down robot beep-boops, hush Mr. Walters, your butler etc etc).
* Controller Enable/Disable toggle. Off by default. Should also prevent false inputs causing incorrect movement.
* Complete reworking of the animation systems for all bots. Results in smoother transitions between states and smoother, more reliable movements between pathing nodes.
* NEW – Added ability to clear markers from the map. Mouseover a marker to reveal delete option.
* Leaning distance increased.
* Revised release schedule for NPCs. Different types of NPC will now be released based on number of pieces returned OR time spent in world. Whichever comes first…
* Reduced required number of fragments for escape to 17 (note: this will be configurable in t he final game!).
* Ravens have become acclimatised to Robot footsteps. No more Raven/Robot s pooked/investigate-loop love-ins at village centres…
* Dynamite 100% stickier. Less likely to skid along the ground for ages, easier to hit what you threw it at.
* Dynamite explosion radius increased.
* Moved FOV slider to Game Options. Now works realtime (can see changes without having to exit menu).
* Reduced the chance to bleed.
* Tweaked some combat variables for Hunters because a bugfix (see reloading issue below) resulted in changed behaviour in combat. Feedback on new combat feel with Hunters welcomed.
* Various loot distribution tweaks.

Fixed an issue where poacher could get stuck in Idle.
Fixed an issue where squires could get stuck on the spot.
Fixed incorrect angle of shotgun on Hunters.
Fixed issue where using the Sex Toggle could break your profession button…
Fixed issue where robot blather loops could be turned off permanently (would lead to stealth-bots!)
Fixed several cases where bots guarding the doors on some buildings could get stuck.
Fixed an issue where the dog pinning sequence could flicker wildly.
Fixed issue where the mouse could become frozen on the death screen.
Fixed issue where using an item while dying could freeze the game and also ruin that save.
Fixed an issue where death while menu open could break the fall-to-ground.
Fixed an issue with bot barks between glimpse-state and Attack playing at the incorrect times.
Fixed an issue where the Axe could get stuck at weird angles when swapping equipment.
Fixed a serious issue with bot reloading logic. Robots could sometimes have more (or less) rounds that they should, resulted in either extra shots (surprise!) or no shots at all (in inter-bot combat this could even result in endless posturing without a single shot being fired).

The Sir, You Are Being Hunted Alpha Is Now Open To All

Hello there!

You can buy it on Steam or Humble Store on our front page.

Sir’s alpha build has arrived for all, and Kickstarter (and Paypal) backers can now get their builds of the game over at Humble Store. Steam keys will be available through Humble store just as soon as we can sort that out. (Soon!)

PLEASE NOTE: This is not the final build. We’re aiming for monthly updates from here, until it’s done, but you can jump in and play and let us know what you think.

KS BACKERS: Getting the game is very simple. Go to and enter the email you used to back the game, either for your Kickstarter login, or your Paypal account. Login details will then be emailed to you.

Any problems, you can hit the forum:

Physical rewards have also started to ship this week, so backers of higher tiers can expect some goodies soon.

The grimoire and soundtrack are going to arrive a bit further into this alpha, as we generate more material for the game.

Love you!

Big Robot Is Pleased To Announced Pre-Orders Of Sir, You Are Being Hunted, Via Humble Store! Also: Rezzed Appearances.

Lots to come in the next few weeks, but we’re starting with the pre-order, thanks to those lovely folk at Humble. Pre-order folk will get early access in our second round of testing prior to release, along with the base Kickstarter tiers. This will come about a month after the Kickstarter early access tiers get their access. This will all kick off at some point in the summer. It’s so close we can taste it!

In the meantime, please pass this link on to anyone who missed the Kickstarter and who might want to support the development of Sir in the next couple of months.

We are also enormously excited to announce that Sir will be playable at Rezzed 2013 in Birmingham, UK, on 22nd and 23rd of June. Please come along! Not only will the game be there, but Tom is going to be talking about the game’s development and his procedural generation experiments in Unity.

Sir, Unity, Mecanim And The Trials Of Small Studio In-Game Animation

We thought it might be insightful for you guys to be able to read a bit more about the challenges we’ve faced in completely overhauling our animation system since the success of our Kickstarter. As we mentioned in that pitch, animation is one of the key challenges for the game, and we feel we need high quality character animation to really make the experience work. So that’s what we’ve been doing. However, it was not without complications.

During the time where we were working on the initial prototypes for Sir, we were lucky enough to get Frogames‘ Christophe Canon to produce some great character art and an early model for the main enemy NPC, the Hunter. At this point we didn’t have the resources or time to commission a full animation set for this character so we looked around for alternative quick solutions – something that Unity has in abundance.

IK And Smart Locomotion

Rune Johansen’s dynamic locomotion system for Unity was an obvious choice, because it does so much without us having to code very much into the game.

Runes system

Rune developed it for his Masters thesis and it’s a really smart piece of coding. It’s essentially a procedural animation blending system with foot inverse kinematics, or “IK”. This means that characters to which it is applied will walk realistically, placing their feet sensible on the terrain they traverse. We implemented it with a series of animations from (an autorigging service that applies generic animations to any humanoid model).

Once we had our initial Hunter model and a set of animations we could use Rune’s system to blend them together. Rune explains how this works better than we can:

“The system uses a set of example motions primarily in the form of keyframed or motion-captured walk and run cycles. The system automatically analyzes each motion at design-time and extracts parameters such as impact and lift-off times for each foot as well as overall velocity. At runtime the system first blends the motions according to the current velocity and rotational velocity of the character, it then adjusts the movements of the bones in the legs by means of inverse kinematics to ensure that the feet step correctly on the ground.”

So for an attacking stance you might have the following animations (walk forwards, run forwards, strafe left, strafe right, walk backwards etc.) Rune’s code examines each of these animations and then can pace and crossfade the animations dynamically to match the characters movement. The system is also capable of aligning the characters feet to the surface between them and then cascading the bone changes up the transform chain (IK).

All of these features require some setting up and tweaking but can result in a genuinely dynamic and adaptable animation system. The net result is a character whose feet and legs remain solidly and realistically rooted the ground, bending and blending procedurally to create really believable connection to the floor, regardless of changes in movement vector. Of course the underlying movement is not Root-motion based (where the distance travelled in each animation loop is dictated by the animation loop itself), but constantly variable. The only disadvantage to this system is that it is (understandably) very complex and can be a significant performance hit if you intend to run multiple characters – which for Sir was a big problem…


When Unity4 introduced their Mecanim animation solution we were excited to try out the new system, hoping it would provide us with a similar system to what we had enjoyed with Rune’s work, but with less overhead. However it took quite a while to readjust our models, animations, and code to get a satisfying result.

Mecanim provides a “blend tree” system where animations can be crossfaded in realtime based on script-sent input values. For instance this could involve defining a series of blend states to mix between a walk and a run animation based on an passed speed value. This area of functionality is similar to the original blending functionality of the locomotion system we used before – in fact it offers far greater control of the process – but it involves more manual setup via the Mecanim ‘Animator’ tool. The Animator essentially allows you to minutely build and fine tune blend trees for your character’s animation. Where before Rune’s loco system did this on the fly, it was now down to us to rebuild the rules governing what anims to play with what blends at what time. No small task!

To Root or not to Root

Most Mecanim demonstrations use root motion based movement because blending animations generally works best when the animations are mixed at specific loop points (i.e. moving from a walk to a run works best when the ending of the first animation has the character’s feet in the same position as the start of the run). Root motion approaches often imply that once a character has begun a specific animation they can’t react until it has reached a convenient loop point (an example is in many games where an enemy will continue reloading even if staying in that pose exposes them to a rain of bullets). Our NPCs operate in a procedurally generated world and function much better if they can stop and alter their motion and behaviour mid cycle where necessary. So instead of converting all our code to work with root motion we decided to try and implement a mix of Rune’s procedural system and the new Mecanim blend trees.

As a result, each character in Sir has a script that tracks the velocity, turn speed, strafe speed, heading and other motion values. These values are then sent to whatever current Mecanim layer we have activated on the NPC (we have a layer for each behaviour; attacking, fleeing, hunting, searching, roaming etc.). The blend trees in that layer then resolve the final animation mix that is appropriate for the characters current behaviour. This can result in a few rare hiccups where an animation crossfade happens at a non-ideal cycle point, but with careful setup of the blend trees and clever animation design such instances can be minimised.

This approach also gets tricky when a character has the potential to execute a wide range of movements. It’s convenient to branch animation blend trees first by velocity, then by turn speed for example, however if a character can strafe, turn and walk/reverse the tree can quickly get complex (Of course this would also be true for a root motion based animator too). Finally, we can also control the overall animation speed of any layer (attack, flee etc) from the AI state itself, so we can easily speed up a particular behaviour and adjust the animation speed in the same script.


The loss of the original IK system is a compromise we had to make. It felt like a big loss, but the advantages of another system were clear. The Mecanim solution is a lot more efficient and allows us to have more active NPCs in view at once, which is clearly more important to the game than exceptional foot placement. The majority of AAA games do without foot IK on models and however nice the original IK looked our NPC hunters are often knee deep in grass or peering over walls to shoot you, making believable leg movement pointless. You generally don’t have time to admire the enemy footwork while running for your life through the bracken, either.

Ultimately we think our experience with these two different approaches to implementing animation show the complexity of the choices faced by developers working in the kind of environments we are using to build Sir. It’s rare that one piece of tech or middleware will do exactly what you want, and that’s the reason why so many larger teams choose to write bespoke engines and code for their games. When you are a small team like us, it’s wiser to appraise the solutions available and then weigh the advantages: the system that is most efficient, and easiest for the designers to tweak, is almost always the winner.