Tom’s Devblog: Tölva’s Technicalities And The Problems Of Big Games

Technical Lead, Tom Betts

It should be pretty obvious by now that The Signal From Tölva was a big game for a small studio to make. It’s an open-world FPS with a huge expanse of painterly terrain to explore, a system of emergent AI territorial war, and a sizeable range of weapons and gadgets to mess with. This would be an ambitious initial scope for any studio, let alone one with only four core developers. We like a challenge, though.

During most of the development the team consisted of the following people: lead design & world design (Jim), additional design and systems (James), 3D art (Olly) and Code (Tom). Dan joined us for around nine months at the end to work on many of the systems we created and to help with critical performance issues and bug-hunting. We did work with a few freelancers on short-term contracts to help with things like sound design and animation, too, but the main burden of development fell on just four people, all working remotely for around two and a half years. That we managed to make Tölva within these restrictions is in part due to the way the studio works with its members skills and interests (rather than adhering to some strict design doc), as Jim has talked a bit about this in his other post. But we also used a some technical tricks and approaches to structural design that enabled us to produce the game within the limitations we faced.

The first set of problems (and solutions) came from it being an open-world design. Popular idea, but not without issues.


[This image is a view from the editor showing clearly how the world is divided into distinct cells]

Big Robot as a studio has always enjoyed the freedom that open world games offer, not simply the scale of the world but also the opportunity to choose your own direction both in terms of where to go and what to do. Looking out in first-person over rolling, sprawling vistas is, for us, one of the most exciting baseline experiences in gaming. However this sort of world design requires a lot of content production, and with only one person assigned to world building it was a tall order. In our previous game “Sir, You Are Being Hunted” the world was procedurally generated, saving us the work-hours of manually laying out the world and its objects. In contrast we wanted Tölva to have a hand designed finish, but we could still use some proc-gen techniques to help with that process.

Early in the development I wrote a system that would generate a terrain for the world, based on a simple mask texture we could paint in photoshop. This mask allowed us to tell the proc-gen process to produce pathable areas, valleys and mountains in specific areas, without us having to edit the terrain directly. The generator also calculated the coverage of grass, small detail rocks and blended terrain textures, based on slope, world location and other masking textures. The whole process meant we could tweak the variables used to generate the world terrain until we had a underlying map that we were happy with. By opening the image in photoshop and editing the RGB channels, Jim could control precisely how the world shaped, from undulation to where and how regions were pathable by AI. This in itself saved us a serious amount of work.

I then wrote a simple in-house tool to allow Jim to decorate the produced map with the actual props that would give the world its real character. This allowed him to run around in a loaded scene and then add props to the world in scene window, while being able to see how they’d look at runtime in the game window. He could even run all over them to test they weren’t going to trap the player controller or get in the way of movement. The data for this was saved to an external .xml and weren’t part of the main scene data at all. This had some advantage as we hit issues in how we wanted to add data to the world, too, because we could edit the XML directly, and the only bit of the environment that was saved to the scene was the terrain itself.

Along with the usual placement functions we also had a few special utilities. Firstly the world is divided into cells which can be assigned to a region (regions can contain a few or many cells and represent a unique area in the world). The contents of these cells are edited individually and the regions they belong to can apply specific coloration, ambient sound and visual effects to the entire area. All of this structural data is stored in the external XML file (rather than Unity’s own scene file), meaning – as mentioned above – that we could parse the world data outside unity, in order to remove instances of objects or to track bugs.

The fact that the editor tool treats the world as a series of connected regions and nodes means that we can use the same data structures to provide the games AI with meaningful information on territory control, mission targets and pathing. If we had taken the approach of laying out the world freehand in a Unity scene view then this meta information would not have been present and we would have had to include this navigational and tactical data in a separate pass (involving more time and tools). With the world partitioned by default it was way easier to identify the location of problems and disable-re-enable areas of the map both for the UI and for development. Ultimately an mildly esoteric approach (which took plenty of cues from the way we generated maps in Sir, You Are Being Hunted) helped us to create a breath and detail of game world that should probably have been out of reach for a small team.


[This image shows a few tiers of the available gun models available to both the player and the rest of the robots]

In addition to the huge world we were designing we also wanted both the player and the other entities in the world to have access to a variety of weapons and tools. Previous experience when developing Sir made me realise that creating individual functionality and models for both the player and each enemy was a huge time sink. So what if – we asked – the player and the other robots could use the same equipment? This led to designing all the usable tools in the game (weapons, shields, AOEs) as owner-agnostic modular items. Any module can be used by any entity that has the appropriate level (and the enemy bots do level up, too).

The player can select the weapons they want for their loadout and the enemy robots (and friendly ones) do the same when they are created by the game. When you see a robot in the game-world carrying the same weapon as you have then IT IS the same weapon, with the same range/damage and charge. We approached the visual design of these elements in a similarly modular way, with each item composed of a core model which is then augmented by a series of bolt-on components (scopes, sights, grips etc). This means that you can also tell visually how powerful a weapon is when you spy it on an enemy bot through the long range binoculars (or indeed, just read about it in the scan function).

The logic of making things both modular and usable by any entity extends to things like shields and Area Of Effect weapons too, because even the non-humanoid opponents in the game use the same system of slotting and activating weapons and shields from the shared library. This works because everybody, including the player (and even some inanimate objects such a turrets!) gets treated as an ‘actor-entity’ with a specific faction allegiance and weapon/tools loadout. The interactions between all these entities is built upon this modular, universal approach. This decision was essential in driving the non-scripted behaviour and emergent territorial combat that bring’s Tölva’s war to life.

This approach also provided us with an opportunity to make fiction and function meet, and Jim’s fiction for the world provided logical context for things being this way: you’ve hacked into and are controlling a robot, and the robots you are interacting with have no idea you aren’t one of them.


[This image shows a squad embarking on a scanning mission, from the bunker in the NW to their destination in the SE. It’s quite likely that they will encounter the squad that are guarding the dropship in the centre of the image]

With a tiny team with just two designers and one full-time coder, there was no way we were going to be able to produce the kind of scripted events that you see in many open world FPS games. And in truth, we didn’t want to. Instead we needed the game systems themselves to be able to provide interesting encounters. This is the aspect Tolva shares most with our previous game Sir; the exploration of emergent ai interactions. In Tolva there are three factions, all of which are vying for control of the planet and its resources. The terrain is dotted with bunkers that can be captured and controlled by any of the factions. Once ‘owned’, each bunker will produce squads of robots that head out into the world to pursue their own mission goals. These goals vary from things like ‘guard this location’ and ‘attack this enemy bunker’ to more ambient instructions like ‘head to this resource’ or ‘investigate this artefact’. You can actually read these missions directly from the AI when scanning a robot with the in-game binoculars.

Inevitably the squads will clash with enemies, either during a deliberate assault, or simply out in the world. Fights can break out at any time, and the disturbance will often attract the attention of other nearby squads and entities. Every AI has two distinct levels of behaviour, a squad based brain and an individual level of reasoning. When there is no immediate disturbance (sound, visible enemies, injury etc) the robot will defer to the squad level of behaviour, which focuses mainly on larger tasks such as mission objectives or group activity. But once in combat, the majority of the squad ai is over-ridden by individual combat reasoning. The ai will still relate to group activity (keeping its position in the group where possible, flanking if it’s assigned to that role, even healing fellow bots), but the squad mission behaviour only reasserts itself when the danger is over. And when in a calm state the robots can chat to each other, scan interesting objects and check their systems.

Best of all, these interactions will happen entirely independently of the players actions. You can of course get involved, or even engineer such encounters (especially once you have access to the device that allows you to direct friendly robots), but equally you can just hang back and observe the carnage, then swoop in to mop up the survivors. The sort of emergent encounters that this generates can range from quietly voyeuristic spying, to having your life saved in a firefight by the lucky arrival of a friendly squad. That this system delivers these sorts of moments regularly is one of the things we’re most proud of.


[This image shows some original concept art by Ian McQue, the cladding armor pieces based on that design, and a robot in-game sporting his own unique combination]

Many studios have art and animation teams to develop a range of character models and animations for their games. We had one 3D artist and limited access to a freelance animator. Regardless of these limitations we didn’t want the robots in Tolva to all look the same. To try and deal with this issue we designed a modular ‘cladding’ system, similar to the way that MMORPGs often attach armour pieces to keypoints on a character’s body. The armour parts for each robot are selected procedurally when the robot is spawned and are based on its level, faction and weapon type. Higher level robots can pick from more impressive cladding parts and the total number of pieces that can be combined leads to hundreds of possible combinations and looks. Each faction has a different aesthetic too, the Surveyors sporting an asymmetric look whereas the Zealots end up looking cyclopian and insectlike. Robots also behave differently depending on their weapon choice, snipers hang back and hold position after engaging, whereas assault rifle carriers will tend to move in closer and attempt to flank the enemy, and so on. This range of look and behaviour, imposed on top of the same humanoid skeleton and generalised animation system helped us to inject a sense of individuality into the robots and avoid the curse of the clones.


There were many other, smaller structural and programming tricks we used during development to help face the challenges of producing a content rich game with a small team, but the features listed above illustrate the general approach we took. Few of the solutions we came up with were simply trying to ‘design around’ a problem, instead they also provided new features,systems and content that we wouldn’t have had otherwise. We made sure that we were flexible with the game design all through the project, allowing ourselves to change things if a solution to one element required that something else needed tweaking. For us it has always been optimal to try a different approach and keep moving in development, trying to think around limitations rather than slowing down to meet a content bottleneck. Having generative solutions to things like AI interaction and character modelling also means that the game still surprises us as designers, throughout development and even after release. That helps when you’ve been staring at the same game for a few thousand hours.