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.

OPEN WORLD, OPEN PROBLEMS


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

EVERYONE IS THE SAME INSIDE


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

SOMETIMES IT’S NONE OF YOUR BUSINESS


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

ROBOT FASHION


[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 WE HAD IT

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.

The Signal From Rossignol: Some Thoughts On The Development Of The Signal From Tölva

Jim Rossignol, project lead.

In this post I’m going to talk a bit about how we made The Signal From Tölva. There are few points I want to make along the way, but one of the most crucial is about how this game, like so many indie games, represents the creative instincts and ideas of the people who made it.

In the years since the launch (and remarkable success) of Sir, You Are Being Hunted (2013) I’ve occasionally been asked for lessons, thoughts and opinions on game design and development. I’ve been a little reticent about coming forward those things and that’s been because I don’t really feel like there are (m)any universal lessons to learn from our experience.

We’ve made esoteric first-person games without worrying too much about what other games did (although our inspirations and aspirations are obvious enough) and the bootstrapping steps to success that led us here seem unrepeatable: getting a break with a chance contract from Channel 4, catching a wave with Kickstarter’s novelty and excitement in 2012 – a progressively trickier task as the years have progressed – releasing with the first wave of Early Access games on Steam, arriving with the first wave of survival games (our announcement pre-dated DayZ by just a couple of months). All these things seem to amount to singularity in spacetime: impossible to draw a generalised rules from.

All of that caveating done, I should say that I nevertheless feel compelled to talk about our development experience as it reflects on our latest release, The Signal From Tölva, and so I shall do so.

This is that game.

The Signal From Tölva is an open-world shooter that in some ways resembles landmarks in the genre (it certainly shares genetic material with STALKER games and Far Cry games), but it does so in a way that takes advantage of our peculiar strengths and interests as a development team. It’s an AI-driven experience, in which the systemic activities of the AI deliver the action, with little in the way of scripted encounters. This has both advantages and weaknesses, as I’ll discuss, but I think the most important aspect is that it has a specific feel and a distinct personality. Things that I find essential for any game in 2017.

The personality of Tölva is, as astute people have observed, the personality of the people who constructed it. It is odd. It is remarkably tranquil, even contemplative, particularly for a game that also leans heavily on combat elements. This surprises many, but it is by design. It is a pure expression of the interest I personally have in the escapist terrain that video games can provide. The original working title for Tölva was “Highlands”, and the initial design sketches took ideas from hiking in British and non-British wildernesses, particularly those which featured bleak, treeless canyonscapes. A visit to Iceland fell quite early in the development cycle. Quite obviously, games – like other creative projects – are direct functions of the abilities and interests of the people who made them. But this somehow seems super-true of The Signal From Tolva which feels like an amalgam of what I like, how James thinks, what Olly can art, and how Tom codes. (And also how Dan fixes everything we shonk together.) It is an alloy, with the new properties that such a material exhibits.

To some extent larger projects are able to hire for specific roles and skills in a way that is beyond the limited budget and reach of a small team like ours. In the case of a multi-million dollar development: if there’s a job that needs doing, then someone appropriate is hired to do it, and their work is managed so they hit (or at least approach) a specific target. The results of this are clear in some of the best AAA games: they’re able to repeatedly hit proven templates, even as teams shift and change. A huge aggregate of creative work is made, where some individuals will stand out, but where ultimately the team effort is what is delivered.

Not so with the tiny gang of omni-devs. The reality here is somewhat shiftier, with small teams often trying to hit a moving target that is moving only because of the nature of the process they’re engaged in. The template doesn’t exist. The plan changes as the game comes into being. People spark off each other and the things that get made. That process is one that can be incredibly fertile and outrageously difficult. One of the things I am personally most proud of is what the small Big Robot team has achieved, given its minimal size and its lofty targets. I believe that came about because of who we are, as much as, say, which tools we used, or which middleware we chose to mutilate to our purposes. Importantly, this isn’t the part where I go so macho and talk about 100-hour weeks, because while we’ve worked hard, and done some serious time, we’ve not worked so hard that we caused ourselves grief. We’ve made sure burnout wasn’t a thing. (Which it has been for us in the past. We are old men now, and have learned our limits.) We’ve been extremely ambitious, without allowing those ambitions to crash the project. Some of the principles that we applied to make that happen are discussed in this Gamasutra interview. In short: we made things modular, we made tools that worked, we relied on live systems and emergence over scripting and engineering. We made a game that knew its limits. Tom will talk more about this in other posts.

This brings me to some creative specifics that I think are important to the project, because they were important to individuals. This angle on things helps me understand what we made, and so perhaps it will help you, too.

1- The Complicated Legacy Of The Game Before

The Signal From Tölva is the second album (AVSEQ and Fallen City being rare singles/EP releases, in that metaphor). It is the response to Sir, You Are Being Hunted, and the experiences we had during the making of that game. Where Sir was procedural, this was built by hand. The productivity of a procedural system has been replaced by the control of a man-made one. Sir was super lo-fi, and Tölva has been produced to a far higher standard, with art assets that wow. But also there’s something about the world creation that has stayed similar despite the radically different processes at work.

Tom and I were responsible for the decision to make the world ourselves, and that decision did seem counter to Tom’s wide-ranging interest in generative approaches. Although Olly and myself did most of the world editing, it was Tom’s response to finishing the Sir project that led to us taking this route. You might have expected him to vote for a procedurally-generated approach this time around too, but he felt differently when it came to commencing development. He erred on the side of control, arguing that we should try to make a game that was both prettier and less variable than anything we’d done before. Tom’s interest in game design is dominated by an extraordinary inclination to tackle all things himself, but also by a pragmatism and anxiety about actually getting it made. Not having to do procedural work this time gave him more time to work on literally everything else, and that basic fact made the target of ‘prettier’ seem far more achievable within the time frame.

Tom’s approach to letting me construct a 4km x 4km world was to set things up in a way that could be easily be comprehended. In fact, I was facing much the same task as the algorithm in Sir, You Are Being Hunted, because Tom created real-time tools that echoed the automated structure of that world. Our game level was once again divided up into a cellular grid (perceptible on the map screen, but not so much in the world itself) in which I could assign props to specific cells, so that they might be loaded systemically, and lodded in and out appropriately depending on your range from the location. This of course made the task seem more manageable, too, because I could tackle one cell at a time, making sure they blended into each other organically and naturalistically as I worked.

The tool I had to do this was real-time, too. Unlike normal Unity scenes, where you have to run it to check your edits, we did all our editing live, by having nothing more than a terrain heightmap and skybox in the scene itself, and then saving all the props to an XML file. This meant I could run around the world in one window, while placing and saving the locations of props in another. It also meant that we could use the XML to save and load all kinds of data about the world, without having to save that into the scene itself. Where a scene of this size would become impossibly unwieldy in Unity’s editor, our system made editing both a playable experience, and relatively performant (it does crawl on slower machines now the full world is implemented). This approach, I think, is emblematic of Tom’s background: he is an artist who taught himself to code. He might lack some of the engineer’s sensibilities when it comes to structural work, but it was instinctive for him to treat the level designer like he treated the automatic level designer in Sir. At the same time provide a system that allowed hands-on experience of the world I was creating.

As I know Tom plans to discuss elsewhere, his approach was similarly practical when facing the task of getting the rest of this huge game done. Making things systemic and to some degree “build themselves” was a key aspect of the solutions we came up with, even without an automated generative process building the world itself. The robots know how they are equipped and behave accordingly. It’s a modular system where the AI uses the same equipment as the player. The weapons in their hands are literally the same as the weapon in your hands, because you are one of them. Fiction coheres with technical and man-hour limitations. It works like this because how else do you make a system that creates enough variety to populate a game world when you have so few resources for systems, art, and design? Modularity. Scaleability. Having the world populate and run itself. These are all key shared interests, and approaches that come naturally to the BR team.

Critically, though, it was what was best in Sir that we carried with us to Tölva. We knew that we loved the dynamic nature of AI entities clashing in an open world, and so everything we did was designed to facilitate that in this new game. Tölva’s three factions are spawned in squads which have specific goals in mind: to guard a location, to attack a location, to explore, to survey a wreck or a ruin, or to attack a location held by antagonists. They react to events in the world, investigating sounds and engaging enemies. They encounter each other and the player in a fluid, freeform way, and the experiences the game produces reflect that. This also means that a single playthrough is never enough to see what the game can throw up: a strength and weakness. What if a player could have had a more finely tuned experience? But what if they experience a dynamic and emergent situation which was only true for them? What treasure! Heady, important stuff.

For development, too, this has ramifications. I’ve played this map a thousand times, and thanks to the way it throws stuff into the mix, I am still facing surprises.

2- The Philosophical Value Of A Clear Blue Sky

We got lucky with the unlikely singularities, as I mentioned, but they happened during Tölva development, too. Fortune (and a dash of boldness) meant that we got to work with concepts from a master, former Rockstar art pro Ian McQue. Just as significantly, we hired a 3D guy (this was Olly’s first game!) who actually had the wizardry in him to make the most of those materials and to create a coherent art style for the game world. The results speak for themselves, but here’s a video of Olly speaking about them anyway:

Here too, our personalities dominate the final outcomes. My personal reference point in first-person games might be STALKER, but I never felt like we needed to do the grimdark skies of the genre. Why not create an unsettling and glitchy weirdness under blue skies? Why not create a sense of unease punctuated with ultra-violence in a place that is just nice to be? Why not rely on the eerie and the weird, rather than the grim and bloody? Why not just clear skies, when everyone else’s are filled with clouds?

The blue skies of Tolva are also emblematic of our desire to create a game world that captures a specific feeling and an identifiable look. Olly regularly cites games like Journey and Abzu, with their unmistakable palettes. Our skies are perhaps not entirely faithful to the Ian McQue concepts that we otherwise worked so hard to emulate, either. Instead the look is very much an example of how a visual style coheres around a bunch of elements, both technological and artistic, and exhibits personal responses both to other games, and to the process of developing this one. We went through numerous iterations, featuring everything from psychedelic cloudscapes to a vast, shattered planet in the sky, eventually returning to the clear blue gradient which fades to a starfield as the night progresses – a result of using a dynamic skybox to facilitate a clean night/day cycle.

Ultimately I feel like this single decision – not a cloud in the sky – symbolises the entire Tölva development process: one in which we worked to create something that was both iconic and beautiful, but which is ultimately esoteric within the expectations of the genre. A deliberate iconoclasm is evident in the personality of everyone who works at BR (how the hell else would we get projects like this started?) and I think this symbolises that most vividly.

3- Hacking (Gun) Existing Systems

As development went on, interaction with and utility of the numerous allied NPC bots was the vast robot elephant in the landscape. It had to be mentioned, but we did not speak of it. I had some nebulous ideas about how to achieve the interactions we knew we’d need to make the game work, but I continued to focus on other things. James (Carey, design lead on Sir, You Are Being Hunted), always true to form, tackled the problem headlong, building the command module (a ‘weapon’ that allows you to recruit and command allied bots) in a matter of days. Utilising the existing Ai systems to implement the concept, he constructed a system whereby bots can be removed from their existing units (and therefore existing AI missions and priorities) and forced to follow you or investigate locations that you direct them to. James has a long-standing interest in squad-based tactics and Ai-player co-op interactions (he even worked on the Arma 2 single-player campaign, which is a landmark in such gaming) and so it seems inevitable that his outstanding contribution to the game should be this system. Although devised fairly late in development, it has heavily influenced design since then, while at the same time being an optional tool within the overall game. It is entirely possible to get through the entire experience without ever equipping this entertaining tool, but of course you’d be missing out (or possibly challenging yourself) if you do so. (Again this seems symbolic of our attitude towards the player: most games would have forced the tool into your hand. As with fiction and exposition, we avoided that. It’s your choice, go explore for yourself. The rewards are always greater that way.)

The Command Module implied all kinds of additional details: the unique IDs of the bots allowing you lament their individual loss*, for example. It also gave us a wider range of tactics for the player to engage in without us having to do much more in terms of building new systems. We only had to modify existing AI to make it work. Everything was keyed off the NPCs that we’d already built to bring the world to life, and it relies solely on the abilities of the bots to navigate the world and engage enemies. The Command Module provides another good example of our need to make do with limited resources, and to build within the small garden of systems that we had already planted.

(*Losing those bots, however a small or routine and event, certainly created the response that James was looking for, which was not simply a slightly broader set of interactions, but an emotional reaction to working alongside AI entities, however speechless and fleeting their existence might have been.)

Anyway.

The Conclusion, Such As It Is

The most exciting thing for me about The Signal From Tölva is also the most difficult thing: that it is not necessarily what it seems to be, and that the expectations people bring to it aren’t necessarily matched by the reality. That’s a communications nightmare, of course, and it’s been tricky to really get across what people should expect. Games are so often about clear message and here a clear message was hard to do. This was absolutely a tension within development, too, with different influences and desires pulling the game in a number of directions. Nevertheless I feel like the final game landed a clean blow: it stands tall within the genre of open-world shooters, perhaps because of (rather than despite) being made by a five-man team. We punched above our weight and feel proud of that. And, regardless of its small size, the game offers a bright chunk of escapism that I am still returning to even after hundreds of hours of play. The Signal From Tölva is a strange, quiet game in a landscape of extraordinary multi-million dollar noise. Under the familiar interface of “a map full of icons you can travel to” resides a weirdness that I personally would like to pursue further, and a sense of beginning to explore a frontier that I find enormously alluring.

To take a slightly more philosophical stance: games are often very literal, when they could and perhaps should be more figurative and metaphorical. I’ve found it hugely interesting and exciting to see people discuss the meditated or “prosthetic” nature of the Tölva experience: that you are not the robot you are controlling, but simply an entity remotely linked to it. There is no huge depth or insight in such a trick, but it fixes simple things, like fast travel, and it makes people break step and think for a second about the world they’re engaging with. In this and other things The Signal From Tölva has an ambiguity to it that I think is singular, and which I personally savour each time I play it. I can’t wait to delve further into the fictions we produced for the game and I am pleased that the lorebook is just the start of that.

Next, though, we continue to build. There are things to fix and other formats to look at. And then there’s an expansion on the horizon, too.

Hmm. How ever will we approach that?

Get The Signal From Tölva Pre-Release Test And Help Us Bugfix!

Hello!

It’s time for us to do a little testing of our new game, The Signal From Tölva.

We’re using itch.io’s clever Refinery system to make a limited run of just 500-keys available. If you want to help us out (both financially and feedbackily) then now is the time! The pre-release price is $15 (the final release will be $20) and we will, of course, provide a Steam key to anyone who purchases this version of the game upon release.

This is a pre-release build and THERE WILL BE BUGS. The absolute minimum spec is Windows 7, 8, or 10 (64-bit only), 8gb RAM, 2gb Graphics card of 600-series Nvidia or equivalent. Please note we are not supporting a 32-bit client. A higher spec graphics card – especially 900-series and higher – will definitely pay off here.

You will need to collect your “Test Certificate” reward on itch.io to download the game. We also recommend using the itch client.

Please get yourselves on the forum over here for Tölva talk.

NOTE: Please don’t post videos from this build, except to illustrate feedback issues on the forums. Thanks!

The Signal From Tölva – Announcement Press Release

BIG ROBOT LTD ANNOUNCES THE SIGNAL FROM TÖLVA FOR WINDOWS AND OSX, AVAILABLE 2017

INTERSTELLAR OUTPOST, AUGUST 2016 – UK developers Big Robot Ltd today announce their bold new science fiction action title, The Signal From Tölva. The single-player first-person exploration and combat game will be made available for Windows and OSX in early 2017.

Big Robot’s Jim Rossignol explains: “Tölva is our ode to classic pulp science fiction, with all its weirdness and drama. We’ve long wanted to explore a world of starships floating over hazy valleys, and robots battling amid pulsing ruins. This is that game.”

THE SIGNAL FROM TÖLVA

In the distant future, star-faring robotic factions sift through the ruins of an ancient civilisation. On the highlands of Tölva, beneath the shadow of abandoned war machines, they found something.

Was it the source of the signal you were so interested in? And will the trail lead to enlightenment, or something more sinister? You hijack a drone and you begin the search for yourself.

The Signal From Tölva is a journey into a wild science fiction landscape, filled with danger and beauty: you must survive terrible hazards, navigate through impossible spaces, and fight an ongoing battle to control this haunted, blighted world. You will make use of a range of powerful tools to overcome your enemies and uncover secrets: hack robots to battle alongside you, equip powerful weapons, and detonate savage defence systems.

Fight, explore, and solve the mystery of The Signal From Tölva!

FEATURES

– Explore a single-player shooter set in a sprawling, hand-crafted landscape.
– Delve into science fiction mystery as you explore the haunting highlands.
– Fight a war of territory control against dynamic and ferocious AI.
– Recruit robots to fight alongside you.
– Equip electronic countermeasures, plasma shields, and savage beam weapons for intense skirmishing.

DEVELOPMENT

The Signal From Tölva has been in development for two years and Big Robot have been privileged to work with the legendary Ian McQue (Bully, Manhunt, Grand Theft Auto IV/V) in formulating the game’s visual style. The game’s rich science fiction universe will be further developed in a lore book and prologue novella authored by Cassandra Khaw (Hammers On Bone).

CONTACT

Please contact jim@big-robot.com if you’d like to know more.

www.thesignalfrom.com

How To Set Up A Multiplayer Game Of Sir, You Are Being Hunted

Once Sir Multiplayer launches – it’s a new executable launched from the launcher, or from the folder – you’ll be presented with a menu screen similar to the Singleplayer game but with some exciting new options.

Multiplayer Main Menu

Start Server
Will open a dialogue with some server options. N.B. We recommend an upload speed of 200Kb/sec if you intend to run a server. Slower connections may be viable for fewer than four players.

Ports and trickery

Sir Multiplayer uses various shenanigans behind the scenes to hopefully make your server hosting experience as simple as possible. In most cases you will not need to forward ports or change router settings to make a server work. If you’re hosting a server that appears in the browser list and other players can’t connect, the most likely cause is the firewall on your computer is not set up to allow Sir through.

If you’re sure the firewall is not the culprit then the default port for the server is 44466, which can be forwarded at your router if necessary.

Once you’ve given your server a name, a password (optional) and set the number of players and pieces you’d like click Start to launch a Server hosted on your machine. You’ll see a window briefly open then minimise. This is the Server. You can use this window to admin your Server or alternatively you can use in-game commands from the Client.

Connect
Will open a server browser showing all Servers currently registered with the master server. If you are running a Server it should be listed here. You can also access your Player Settings from here and Direct Connect to an IP if you wish rather than browse.

Go ahead and hit Join next to your server of choice. The list will show the status of the game you are joining. Either:
1) InLobby (waiting to start a game)
2) InGame (the game has already begun, you can still join)
3) WorldGeneration (the world is being created, connecting may be slower)

If you get into a Lobby you have another chance to tailor you character (in case you want to make sure all players involved in the game look different). There is also a chat window you can use here before the game starts.

Doing Admin
If you are currently the Admin for this server (indicated by [A] before your playername) you have various commands available to you. Simply type these into the chat window:
#new – Starts new map. This will work from the lobby even if players are not readied.
#restart – Restarts current map (when you’re already in-game)
#kick playername – Kicks playername
#makeadmin playername – makes playername the admin.
#lobby – returns to the lobby (when you are already in-game).

If you are Not Admin
If you are NOT currently the admin you can either:
#admin password – Logs in as admin if an admin password is set up on the server (note that admins logged in in this way override voted-in admins).

Or use the prefix #callvote to start a vote on any of the other commands. For example #callvote kick playername to kick someone or #callvote new to start a new map. Other Clients then use #vote yes or #vote no to vote on this request.

Bear in mind that the server operator will have ultimate control of the server via the server window itself, even if you are logged in as a Client Admin.

Gameplay Settings
From the Lobby, server Admins can alter the settings for this particular game of SYABH. You can change Gameplay, World and Robots. Within these sub settings you can substantially alter the feel of any given game.

Gameplay settings lets you adjust things like PvP damage factor, the number of pieces required to activate the teleporter, the number of pieces on the island in total and the timer settings for the Stone Circle.

World settings allows an admin to radically alter the make-up of the island you will play on. You can choose from templates which will be familiar to Singleplayer users or create entirely custom biomes. All islands will be procedurally generated from these settings but you can save the seed numbers to replay islands you liked or share them with friends.

Robots settings will let you change what enemies you’ll face, when they’ll turn up and in what numbers. You can even have Robot-free islands if you like!

Ready
Once the server admin is happy with the settings everyone should hit the Ready button in the Lobby and the game will begin.

OK, we’re all in, now what?
Mutiplayer games of Sir take place on a Single Island. Only one person can escape and win the game. You must return the set number of Device Fragments to the Stone Circle as per the Singleplayer game but in Multiplayer the Stones are usually only active for certain periods of time (depending on server settings) In other words you can only return Fragments during this active period. You will get a warning when the Stones are about to become active, they will then remain active for x time (depending on server setting) before deactivating again. This cycle will continue until enough pieces have been returned to let one player escape. The player who drops off the last required piece will win. Remember that you can carry more than one piece at a time (if you find small pieces!)
You can find a running count of the number of Fragments returned and required in your Inventory window.

Useful Multiplayer-Only controls
There are a couple of actions available to players that are unique to the Multiplayer side of SYABH.

Trade
You can open your inventory for Trade with other players by holding down “o” (by default). Other players will see a White Hand icon above your head when you are doing this. While open, other players may begin a Trade with you. During a Trade players can only give items, not take them from the other player. This prevents anyone stealing your rifle when all you wanted to give them was a bandage…

Reveal Location
You can show other players where you are by pressing the “y” key (by default). This will place a [P] marker on everyone else’s compass showing them your direction. It will also display your name above your character’s head if players are close enough. Both the [P] icon and your name will fade after a few seconds.

In Game Voting
All of the #commands are still available during play. For example you could use #callvote kick playername to begin a vote to kick a troublesome player or #callvote makeadmin playername to make someone else admin.

Chat
Press “t” (by default) to chat to other players in-game. PageUp/PageDown (by default) allow you to scroll back through chat history.

Command Line Servers

If you want to run a server without launching the game through the menus, you can run the multiplayer executable directly from the command-line, with the following arguments:

-batchmode
Runs the game headless (with no visible interface). This is useful for dedicated servers on machines with no GPU.

-server
Starts a server without going through any menus.

-port NN
Specifies a specific port for a server to run on. Useful when running multiple servers, or when using port-forwarding through a router.

-numpieces NN
The number of pieces on the island (by default; this can be overridden by an admin).

-piecestowin NN
The number of pieces required to win (by default; this can be overridden by an admin).

-minplayers NN
The minimum number of players required for the game to start.

-maxplayers NN
The maximum capacity of the server.

-password ABCDE
A password for the server. Omitting this means anyone can join. Cannot contain spaces.

-adminpassword ABCDE
A password that allows someone to make themselves an admin (using #admin ABCDE in chat). Omitting this means admins can only be voted.

-allownoadmin
By default, the server will always ensure that one player is admin (by promoting the first player to join, or a random player when the admin leaves). Adding this flag disables this behaviour.

-servername ABC DEF GHI
Sets the name of the server in the server browser. Note that this has to be the last argument in the list, and will treat the remainder of the commandline as the server name.

Love you!

An Update To The Sir, You Are Being Hunted Multiplayer Test

IMPORTANT NOTE: Instructions to get started in the test are here.

We’re here with the first of a (hopefully) weekly series of updates to the Sir Multiplayer Test. The new version is v0.1.45. If you’ve opted into the Multiplayer Branch on Steam you should get the new update automatically.

The first week of testing went smoother than we could have hoped for with our official servers more or less constantly populated and only one short outage all week. It’s all been remarkably stable and we’re very pleased. It’s also been fantastic to see so many of you hosting your own servers for friends and the general public, and to that end we’ve spent a good deal of this week adding some more controls for server operators. The full release notes are below but the long and short of it is there’s now a proper voting system for electing and replacing admins, kicking grumpy ne’er-do-wells, voting to start maps if someone is idle in the lobby and won’t ready up…

There are of course a number of bugs found and squashed – thanks to your feedback – so keep those reports coming in. We’ve been listening to feature feedback too and have added a new system for locating and identifying other players. You can now ‘ping’ your location onto the compass with a keypress (default “Y”) so friends can find each other or mark areas of interest like good loot. This marker will last for 10 seconds and for the duration the player’s name will also appear above their head if you are within a certain distance. It’s essentially the visual equivalent of shouting “Oi! I’m over here!”

Thanks from the whole team for your enthusiastic uptake of Multiplayer Sir, it’s been fantastic to watch your streams and videos, and even better to play alongside you

More to come!

Patch Notes:

Server Controls.

1. Server operators can now optionally add an Admin Password during set up.

Use #admin password to log in as admin with this password.

2. Admins can make other players the admin with #makeadmin playername

3. You can now vote to use admin commands even if there is no admin.

Use #callvote command to start the vote (e.g #callvote kick playername to kick someone or #callvote new to start a new map. Clients then use #vote yes or #vote no to vote on this request.

Command list:

#new – starts new map

#restart – restarts current map

#kick playername – kicks playername

#admin password – logs in as admin if an admin password is set up on the server (note that admins logged in in this way override voted admins).

#makeadmin playername – makes playername the admin.

#lobby – returns players to the lobby

Fixes & Additions

– Improvements to server browser (including auto-refresh, summary, and an alphabetised list)

– No more smashing/exploding sounds when joining lobbys

– Reveal your name & position to other players by pressing a key (“Y” by default)

– Miscellaneous small bugfixes (rider volume, UI tweaks, similar sundries)

Coming This July: The Sir, You Are Being Hunted Multiplayer Test

Hello there. Long time! How’ve you been?

This is a quick update to say that the Sir, You Are Being Hunted multiplayer test will start on July 1st. It’s been a long and difficult road to get to this point, but thanks to the hard work of Dan and James we’re now able to open up a test client to everyone who owns the game at the start of next month. We’ll collecting feedback bug reports as usual for this work-in-progress aspect of the game.

We’ll provide information on how to get hold of the client – as well as some other details about what we’re up to – on the day.

Hope to see some of you online in July.

-BR

An Update On Sir’s Multiplayer

Hello! It’s been a bit quiet on here since 1.1, but we thought we should update regarding multiplayer now that we know a bit more. In short: it’s been delayed pretty significantly. We’re now planning to get it done for some time in early 2015.

While initially we’d made great progress, things ground to a halt as we disappeared down a rabbit-hole of networking issues and we ultimately didn’t get to where we’d hoped to be in the weeks and then months after launch. Consequently we’re going to bring in another developer to help get it across the finish line, and that’s going to take some additional time and resources to do.

Obviously this is deeply frustrating, and it’s particularly vexing in light of the speedy progress of the rest of the project. We apologise sincerely to everyone who has been waiting for this aspect of the game, We can only say that we share your frustration. We’ll keep going, though, and we should be able to update again soon with some images of our player characters in action.

Thanks for your support and patience.

– BR

One More Update Before The Big Day

Hello!

We’re pushing out an update with a bunch of small fixes and tweaks today, but really big news is that Sir’s single player mode will hit v1.0 on May 1st. This, therefore, is the final patch of our Early Access period. Oh yes, it’s the end of a long road.

There will still be a few things to come after v1.0, as well as ongoing fixes and support, including multiplayer (no, no date on that yet, we’ve still got a way to go!) and also a customisation patch that will allow you mess with the game generation in-menu, rather than just in the back-end XML files. But we’ll get to those later!

For now, the big message of this latest update is: help us bug hunt!

We need as many people as possible to pile in, find problems, share logfiles, and help us get this game into the best shape it can be. There’s a bunch of changes up today, including major performance improvements. Go and try it out!

Changes

– NEW – End sequence and credits. The closing voice-over and credit page now play before you get to your stats.

– NEW – Tooltips on all items, plus roll-over instructions for inventory slots.

– NEW – Fragment counter in inventory revamped to show fragment count per island, plus current location.

– NEW – State indicators for bleeding, trapped, and starving.

– Changed some textures and vegetation detail on Rural biome.

– Major optimisation pass, up to 30% performance increase on some machines.

Fixes

– Walters’ voice clips now no longer wait for each other to finish (so you don’t miss any!)

– Toy train can no longer fly into the sky on cliffs/slopes.

– Opening inventory or map with control no longer conflicts with mouse and keyboard controls.

– Landowner gets stuck less frequently.

– Background music levels fixed.

– Ruins stonework lightened.

– Bog creature sounds don’t last too long.

– Flashlight no longer appears to be made of stone.