I come from a C/C++ self taught programming background, and have used loads of IDEs like Visual Studio, Codeblocks, Eclipse and even stuff like Actionscript IDEs and Processing. Initially I shirked away from interface heavy IDE work, preferring to do everythign in code, but after a few years with unity I have come to appreciate the speed and prductivity benefits of using a more integrated environment, especially when working with a small team of developers, each with their own skills and project area ownership.

Anyway, when I first started with Unity one of my big concerns was, how do i structure all this stuff? I’d done a lot of object orientated design and quite a bit of component based stuff too, but the live editing of values in the inspector and the prepackaged object library use of prefabs was new to me. I asked on the forums, with little real result, as expected, the answer is generally that there are many ways to skin a cat. So Im just going to talk briefly about how I organise unity projects. This isn’t anything really do with specific programming paradigms or how to write better code, it’s more about how I structure things in a unity project to hopefully make things more readable and usable.

Old fashioned guy
I am still a big fan of a decent naming policy for classes, and members. I dont mean Hungarian notation (where you use bMyBool etc to indicate variable type, because its a pain to have to change the type and then all instances of the name). I mean more to indicate ownership. Unity doesnt really support namespaces, so it can be difficult to figure out what classes (and their function) are from the core library or from user made code, people say that you can use the IDE functions on rollover to read the class heirarchy etc, which is true, but I sometimes still open files in textedit (especially since you cant have multple unity instances running) and I also like to be able to see at a glance who has written what. As a result of this I tend to name all my classes with a C_ prefix, C_WorldMap, C_Gun, C_PlayerHealth. This might seem excessive, but its instantly obvious that the class and its fucntions are not part of any core library, or anyones third party work. It also avoids potential naming classes, calling one of your classes somethign like Map, PlayerHealth or Bullet, is unlikely to be a unique name, Ive imported several 3rd party code bases to Unity where Ive then had to rename classes due to a clash of this sort. Of course it shouldnt be C_ for everyone (or we’d all clash), but something that is distinguishable by yourself and others, perhaps linked to the project title. I know that code is ideally meant to be portable and non specific, but I think that games development is one of the areas where things almost always get specific and bespoke, due to rapid prototyping, time constraints ad the unique nature of requirements from game to game.

I also advocate naming in functionality nesting order. I mean by this that if a number of classes refer to the map, then use map as the initial naming element. So C_MapAreas, C_MapWater, C_MapHeat rather than C_AreaMap, C_WaterMap, C_HeatMap. It makes the scripts easier to group visually in the editor and helps you to mentally group them by their shared top level element.

Following this prefix approach I also name all member variables with m_ , m_BulletSpeed, m_BulletDamage, m_BulletType etc. I do this for exactly the same reason I C_ my classes, so I can quickly distinguish between a local scope variable and a class member, either when reading or when using dropdowns to select (all my members are in a nice neat range of the dropdown list rather than mixed in with inherited values and functions). I’ll name them via nested terms too if I can remember (such as the m_BulletBlah examples above). It also lets other people see exactly what Im doing. Unity is nice for people to work together on seperate aspects of a project (one person doing textures , another modelling, sounds etc) but its not great for supporting multiple coders.

I do a similar thing for other assets such as models, where i might prefix my test models with a T_ so I can pick them out quickly in the list/grid array that the unity IDE provides you when making inspector assignments. In our Fallen City project we had so many models that having a decent naming convention really helped speed up the development. (Remember to stress this to your 3D modellers!)

Grouping scripts:
I think when a project is small its more useful to group assets/scripts by type. So a folder for textures, folder for sounds, folder for scripts etc. This means you can easily replace and survey all the graphics for your project, or get a sense of how large the codebase is etc. However, once you find that a project is getting large enough it makes more sense to organise folder structure by functionality, a set of nested folders for Map or AI functions for eg. I also use a prefix convention for folders, to seperate them visually in the IDE (and on disk) from default assets or 3rd party packages. A simple example might have directories called
_Scripts
_Textures
_Models
_Audio
_Scenes
etc and then I might use
_World/_Scripts
_World/_Prefabs,
_World/_Maps
as an example of a folder structure nested primarily by function and then by type. This also helps if you have several people working on a project who can claim ownership of a specific area of functionality. Using underscore at the beginning also puts them at the top of the project list and helps to distiguish them from standard unity folders etc.

Prefabs and Pointers
I come from C++ as my main programming language, so unlike most people I actually like pointers! Of course C sharp doesn’t really use pointers, but it does use references. I was initially confused as to when a reference is used or not, it appears that most default types aren’t passed as reference, but anything more complex, like a class or list will be passed to functions as a reference, unless you code it otherwise (by creating your own intermediate object or some other form of deep copy). Another aspect of referencing in Unity is the way you can drag and drop elements onto script variable fields in the inspector. Because you often do this with prefabs it can be easy to end up referencing and changing a prefab or material that is actually in your project folder, rather than one you want to be altered for the actual runtime game. I tend to prefix my references with a m_p to help me remember that the object referred to is to be read only (when using prefabs as a basis for instantiation etc), such as public GameObject m_pSceneryTreePrefab. I also do a similar thing with references to scripts m_pC_PlayerHealth (heh, even though I dont do it properly in the example screenshot above), for instance (or for a quick local scope version _pC_PlayerHealth).

Singletons & Global stuff
I tend to use singleton instances for all the major classes in a project. I prefer this to making them static as I can still control when they are created and destroyed and other scripts can test to see if they exist or not (I might not want every singleton class to always be active). It also means that all scripts can access key (global) information and functions without having to maintain their own local script pointers. The drag and drop system to assign refernces to other gameobjects is great in the inspector, but if your scripts are being instantiated as part of a library prefab, then the appropriate references (specifically non local ones) can only be assigned in code on start or awake etc. Singletons help to avoid some overhead from GameObject.Find calls too. I do use static classes, but generally only for utility functions that arent linked to any specific game scenes or object management.

Strong Typing
Strong typing is best, the clue is in the name, its STRONG, whereas other typing schemes are weak. Perhaps another result of my C++ heritage, but I can’t stand seeing a function and having no idea what arguments it is expecting. function myfunction(thing) ‘thing’ could be a bag of chips for all I know, yes, casting is boring, but at least I can see whats happening. Theres nothing wrong with javascript, its got some great features, but you can declare typing in it and I think its better for everyone when you do.

I don’t do all these things really
Of course I don’t really manage to stick to all these rules, generally rapid prototying and quick hacks make write all kinds of unreadable rubbish, but I do try, and when i do kep things more readable I can work for longer on project before i reach that saturation point (you know, where you have really lost track of your own code). Im also not claiming that my approach is either the most efficient, the most elegant or the most intelligent. Im a self taught programmer and to CS graduates I probably code like an idiot, but there aren’t many people talking about how they organise stuff in relation to unity development so I thought I would. So please don’t flame me for not adhering to the Geneva Convention Of Interfacing or the NATO Polymorphism Treaty.. Thanks!

This is not made in the final game engine, it’s just us messing about in Unity. These are game assets, of course, but it’s woefully unoptimised, so older machines might wobble a bit.

The GSC series is one of many influences on what we’re doing. Specifically what we enjoy these kinds of open world games is their intention to have things going on in the world independent of the player. The philosophy of the Stalker games – which created FPS experiences in an open worlds that were available to explore and exploit, rather than being corridors of enemies that needed tidying away, is the sort of experience we aspire to. Just as Stalker’s bandits and monsters patrol their world, so our robot gentlemen are wandering our gloomy pastoral landscape looking for you, and for the vital bits of a machine that you are searching for.

The challenge for a tiny studio like us is how to produce large worlds without a team of artists and level designers to handcraft spooky valleys and ruined villages. Sir’s engine produces procedurally generated islands, which means each playthrough, and each individual player’s playthrough, will be rather different. We’re also not aiming to create a game with the most high end visuals and hi-res textures. Ours is a lo-fi approach that captures some of Stalker’s reliance on a unique atmosphere.

Like Stalker, combat in Sir will be lethal. But I should also mention our reliance on sneaking, stealth, and running away. We certainly feature guns – most notably a shotgun and a hunting rifle – but fighting will usually be a last resort. If you’re in a stand-up firefight, then you’ll probably die. Hiding, staying out of sight, setting traps, and shooting hunters in the back will all be recommended approaches to staying alive. Sir is more an open-world stealth and survival game than it is an open-world shooter.

Finally, the other reason we feel that we are spiritually connected with Stalker is that we are mythologising something close to us. The Kiev-based team took on the nearby real-world Chernobyl zone, mixed it with post-Soviet myth-making and the Tarkovsky/Strugatsky fictions, and created a uniquely-flavoured game which they had personal resonance with. We live in the English country-side, love robots, tea, and class-war, and want to make something funny and sinister from the offbeat materials of British science fiction and fantasy.

Ultimately, though, we want to make a game that has the same kind of significance for people. We know that’s a big challenge, and there’s only four of us. Nevertheless I can promise that you will see more on Sir, You Are Being Hunted quite soon!

Here’s a list of the articles so far:

Jim being interviewed on Rock, Paper, Shotgun.
Kotaku, and again.
ShackNews.
GameSpy, and again.
Indie Games Magazine.
Edge Online.
Strategy Informer.
IndieGames.com.
IncGamers.
VG247.
TruePCGaming.
FPSGuru.
BeefJack.

There are a couple more interviews coming up next week with other outlets, too.

I suppose the pressure is on, now. We’re also keen to stress: we’re just three guys with some art help. A few comments have been imagining we’re a big dev studios with “teams” for stuff. We are just a UK indie, and most of the programming is being done solo by Tom.

Also we don’t have comments on the blog here, so please direct any questions or Big Robot related chatter to the forums.

One of the key features we wanted in Hunted, was the ability for enemy AI to behave as autonomously as possible. Rather than groups of AI being introduced at scripted intervals and exisiting only to provide staged skirmishes for the player, we wanted to see them wandering about the landscape with their own objectives. This adds a significant level of complexity to any AI design.

The enemy NPCs in hunted come in several varieties. The main class are the mobile hunters – the red visored chaps you’ve seen in the first few screenshots – these guys patrol from one location in the world to another, and on arrival will rest, interact with one another and perhaps search the local area for tresspassers or loot. To facilitate this I designed a procedural generation system that places detailed areas of interest (hubs) across the world, connected by trails across the intervening terrain. The hunters move in squads of different factions and travel along these pathways between the hubs. Navigation is done via a nodebased a* network, which is created and stored at the same time as the world is generated. Hubs contain a much higher level of detail in terms of obstacles and waypoints. Hubs generally attract both the player and NPCs as they are generally the location of valuable resources and cover/safety. The wandering hunters have several states of behaviour, governed by a simple Finite State Machine manager. The states are:

Wander: NPCs move between hub locations based on various internal reasoning algorithmns, sometimes they will stop for a while and rest, or even loiter on roads outside of the settlements.

Alert/Search: If an NPC hears a nearby sound, or sees either the player or another NPC from a rival faction, they will switch into this state. In this state the hunter approaches locations close to the last heard sound or last sighting, their viewcone detection increases and they will continue exploring nearby areas until they encounter an enemy or eventually get bored and return to wandering.

Combat: If a hunter sees a target and can approach to within combat range (dependent on the range of their weapon etc), they will do so. In this state NPCs will reload and move to keep in range of their target and when losing sight of the target they will attempt to round appropriate corners to track them down.

Cover: Every time an NPC is injured they have a chance of switching to a cover-seeking state (more likely as they become more heavily wounded). When in this state they abandon all combat and run to the nearest cover location (essentially calculated from a list of locations that are out of sight of the enemy that is pursuing them). Once in cover they will constantly look around themselves to spot any chasing enemy. If found and attacked they will run on to another potential safe spot. If safe for long enough they will regain their courage and return to either a combat or search state.

When two opposing squads meet at a hub they react to each other in the same way as they would to the player, a skirmish occurs and one side will usually end up wiped out (though occasionally they may pass safely by each other or a few stragglers may escape to wander onwards). Debugging this sort of AI is a tricky task, as the character models don’t (currently) easily indicate what state they are in. To remedy this I draw a number of helpful indicators in the scene window. Icons above NPCs show their states, their HP and their faction. Viewcones, target lines, shot lines and sound lines are also available. The system is going to require Jim and James to spend a lot of time working on balancing, as we have to deal with situations where other players and NPCs also enter the fray (at the moment hunters that are infighting will only switch to the player if they are significantly closer and not already engaged).

Right now the framework for all this behaviour is in place, and we now need to start making it function as games usually do – with visual feedback that can understood in the context of the game, and the appropriate behaviours for a player to work out what is happening, and successfully interact with the AI. We’re hoping to have a “test village” up soon, and from there we’ll be able to show off some of the behaviour in motion – complete with some more tech bells and whistles that will make the factional battles believable and compelling.

In future we’ll talk in a bit more detail about combat behaviours, and also the way in which we intend to enable to hunters to actually track down the player.

Sir, You Are Being Hunted is focused on dynamic AI combat across an open world. We want encounters to occur naturally rather than being scripted. The heart of the project is therefore based around our robot enemies hunting you, and each other. That means developing some interesting global and local AI behaviour, which Tom will be talking more about later this week.

What you can see in today’s screenshots is our second AI character, called The Poacher. These are stealthy, ambush-based baddies, who lay in wait for you across the landscape. The Hunters, which we’ve posted a few screenshots of previously, are much more active, and pursue you across the landscape, heading to where there has been player activity, to seek you out and take a scalp.

Of course when robots from different factions meet, there’s likely to be a fight. The Poachers happily take down tresspassing Hunters if they encroach on their territory. Poachers tend to carry and use traps, which can render their opponents wounded and immobile – dangerous for an exposed Hunter, or the unwary player. Cunning Hunted players will be able to re-purpose these traps for their own devices. Some Poachers will even carry dynamite – you know, for fishing and stuff.

You might notice that some of the objects in these new scenes have different levels of shader detail. This is because we’re experimenting with some essential tools for world-creation, such as substance textures. You can see that on the wall that the Poacher is shooting over. Rather than creating a final texture, we are able to play with variables and generate vastly different-looking walls by using a single material. This is a technology we’re hoping to apply to a number of procedural features in our sinister countryside, such as hedgerows and walls.

Finally, we’ve had a few comments on the “Steampunk” nature of our world – we’re not entirely happy with that. It is, perhaps, in some ways steampunky, but certainly not Victoriana. There are elements of high modernity – the laser visors on the Hunters, wind turbines, and so on. If such labels must be applied, we’d like to appeal for you to use “TweedPunk”, “ToffPunk”, or “UncannyChapPunk”. Thanks!

More soon.

Yes, Big Robot is going to make a game featuring robots. It’s called Sir, You Are Being Hunted, and it taps into a rich seam of tweed-loving British science fiction to conjure a sinister reality where artificial gentlemen hunt humans for sport.

From a development point of view, Hunted is a stepping stone to what we want to do with our procedural-world generation project, Lodestone. The world-building tech for Lodestone is well developed, but actually we wanted to do so much with it that breaking down some of the tasks into entire spin-off games made sense. Hunted, therefore, is an experiment in the kind of intelligence required for robots to hunt each other – and you – in a dynamic open world.

Hunted is set in a recognisably British landscape. Its inhabitants are a mockery of the aristocratic country gent and his ecosystem. Robots that ape tea-drinking, poachers that lurk in reed-beds, and red-eyed hounds that patrol the moor: these are the things you will be dealing with as you fight for survival. The game gathers up elements of my favourite things: exploration, AI interaction, survival, robots, hot drinks, and blends them into a rich pixelly pulp. (A “British indie S.T.A.L.K.E.R.” might have been something we said in the design meetings…)

So that’s Hunted. You can expect tonnes of detailed information on this – videos, details about the release of it, and so on – in the coming days. We’re also going to update this blog with a load of details about how we’re making this game. Regular development diaries will become a feature, and we hope to give everyone an insight into the process we’re going through to get this lo-fi indie open-world shooter made.

More soon! But while you wait, have a browse of these pieces of concept art by the wonderfully talented Christophe Canon from Frogames.