We thought a general Big Robot update was overdue, so we’re going to give you an insight into what’s going on, and what the robot road map is for the future.
Those of you watching us from across the mists of social media will have doubtless picked up on a couple of low-key announcements. One is that we will again be working with Ian McQue, who provided us with the concept art inspirations for The Signal From Tölva. This project, (or even projects!), is still in its infancy, but I can confirm that Ian will be contributing to a future video game project from BR.
We are, of course, still working on The Signal From Tölva, and have previously announced the free expansion, Ice Variant. No, it isn’t just snowy weather for the existing map, as someone suggested, it’s a completely new campaign, with new designs from Ian and new 3D art from Olly Skillman-Wilson and Jon Polti. In terms of what to expect, this is a prequel dive into events on Tölva, featuring a lost Information Broker. We think you’ll get a kick out of it. And, yes, it’s also going to have some snowy weather, too!
However, it hasn’t exactly been plain sailing for us in recent months. A number of real life events have stalled different members of the team, meaning that we’ve had to take some serious breaks here and there to deal with those issues. We can only apologise for that, but real life and real people, as ever, come first.
We’re picking up some speed again now, however, and the Linux port for TSFT is up on Steam and most of the other portals too. Dan and I will be keeping an eye on feedback for that, so let us know what you will find. More updates will follow, with Ice Variant probably arriving just after Christmas. We’ve finished about 90% of the level building, but that last 10% still has a tonne of work associated with it! We’re enjoying building it, however, and we think that’s going to show in the final update.
Further out we’re beginning to look at future projects. We have a number of prototypes to choose from – at least two of which are already playable to some extent – and we’re going to be looking at more closely when the time comes. Precisely what will come of these, and to what degree they will tie into our plans with Ian, are yet to be fully determined!
But there’s more!
Cambridge lecturer and award-winning author Robert Macfarlane has announced that he’s been talking with us about exploring the “eerier reaches” of the British landscape in a future project. This isn’t much more than a conversation at the moment, but that conversation is extremely interesting indeed, and we anticipate an exciting year or two ahead.
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.
[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.
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.)
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.
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!
What follows is an expanded take on what we touch on in that video. If that sounds good, read on!
Tölva’s world and tone are exciting for a number of reasons – lasers, exploding robots, unfathomable space mystery and the phrase “combat archaeology”, to mention but a few – but here we’re going to talk about how we crafted that rich, screenshot-friendly visual style. We will try and understand the majesty of Mr Ian McQue’s concept art, learn the fundamentals of ‘splattery precision’ and some other made up terminology, as well as comprehending the beauty of a clean normal map bake or efficient UV layout. You know you’re in deep when you can appreciate UVs. We intend to go deep(ish).
So… Defining the look of Tölva was a process of looking at our inspirations and influences and breaking them down into their constituent parts. This way we could take what made a certain look ‘work’, and begin to create a process that we could apply to a variety of assets while maintaining consistency with one another as well as looking appealing in isolation. This meant taking Ian McQue’s sketches and paintings and finding common shapes, colours, types of brush stroke, silhouettes, and starting to form a “McQuevian language”.
Often robots, vehicles, or ships, were chunky with lots of rectangular protrusions breaking up their silhouettes. Layering of details was important, with colour often going from darker to lighter as the layers got closer to the exterior. Angles were often a few degrees off being parallel with each other but still consisting of straight lines, rarely curved. The dumpier a spaceship, the thinner it’s aerials and wires: contrast from form.
We could use these style guidelines to judge how well something would fit in the world, and how close it was to the source. I’d sometimes create reference boards using a tool called Kuadro, a convenient way of laying out image files on the desktop and storing their scale and position in a file. I’d be conferring with Jim at various stages throughout an asset’s creation- he would direct the design, and mine his extensive and tasteful tumblr image library, or doodle thumbnails to illustrate specific requirements. Interpreting sketches from one angle and turning them into 3D geometry has been a particular challenge for me on this project, but following these guidelines, and practicing this approach has enabled me to get better at it through the course of the project.
The first step towards actually making something, once reference was set up, was blocking out a 3D form in Maya using simple primitives and keeping things low detail. Often if this stage went well the geometry could be reused for the final low polygon asset. Then I’d take this base mesh into zBrush and play with the shapes, maybe add things that were more awkward to create in Maya. If I was feeling really fancy, I might do a paintover.
Sculpting, Detailing, Baking
Once something is starting to feel like a strong design I can start to commit to adding details, again referring to the guidelines as I bevel edges, chamfer corners, and smooth any (rare) curved surfaces. Then come surface details that will be baked down into the normal map such as wires, nuts and bolts, screws, handles, cutlines. It’s easy and enjoyable to go overboard at this point and fill every surface with greebly goodness but any artist will tell you that the eye needs space to rest. Not only are you looking for space to rest within this asset, but often you will need to look at the game as a whole and decide whole assets need to act as rest points devoid of any noisy detail, in making up the composition of the world.
At this stage I’m also starting to break up edges with wear and tear and damage where seems appropriate, this is one of the most satisfying parts- chipping away and scratching up clean surfaces requires little moment to moment decision making and I can let this almost therapeutic activity absorb my attention. It’s important to split objects as I go into logical groupings based on their material types, I will use these later to bake a material ID map which is essential to the texturing process.
One of the of the recurring aspects of creating such a mechanical world is designing (relatively) convincing joints, paneling, and other robotic goodness. It was important to spend enough time look at machined parts or engines so that I could start to internalise where a cut line might occur, which panels needed screws, how a curved edge might be carved out of a larger piece. Manufacturing is often about starting with a form and reducing it from there, and the same approach works really well when sculpting.
Then comes a series of steps that are dull but very necessary to getting a clean bake but once that’s done I can move onto texturing. A tight UV layout, good smoothing groups on your low polygon model, and a precise cage mesh all aid in a clean bake.
Generating an Automated McQue Texture process
Or: How to Hand Paint Textures, Without Using Your Hands.
Good modelling is essential and a stunning texture won’t save a bad model, but texturing drives a lot of Tölva’s look and helps distinguish it from other games. It’s also what was most clearly imitable from the concepts. We were fortunate enough to be given access to the list of secret brushes that Mr McQue utilises most frequently and to such effect, and using these able to create an automated process that streamlined the texturing of hundreds of assets. We essentially created a system where I fed in my sculpts and a McQuevian texture was churned out for me to tweak and finesse. This worked by taking the right brushes in Photoshop and creating a tiling pattern with each, attempting to recreate a certain type of stroke or scribble that could be found in any given concept piece. With these ‘master strokes’ I could tile relatively convincing McQuvian patterns across a surface, tinting its colour, and using the pattern to break up the edges of masks in Photoshop. Daub, dash, splatter, speckle, spray, smear, squiggle, strokes, crosshatch, and grainy swirl would become my best friends over the next 2 years. Grainy swirl was great for organic or noisy surfaces like mud or concrete, while crosshatch had a natural galvanized metal flakes look. Each pattern came into its own as I built a library of reusable materials from these tiling patterns.
The tool tying all this together was the Quixel Suite’s dDo, a Photoshop based texturing tool aimed at primarily at creating PBR materials very quickly, which we had employed for our own nefarious aims. Feeding the sculpt data from the bake (tangent and object normals, ambient occlusion, material ID, gradient, sometimes a height map) dDo could tell me where edges were, crevices, what was at the top of the mesh, what was only facing down or upwards. The amount granularity in terms of how you define the masking of a material is very powerful, and once I’ve made decisions about where a material should be confined to I can apply that as a preset to any other asset. “Here’s my paintedMetalC material, it will have chips and scratches on the edges, sunbleach on the top, water damage on the undersides, and some lichen in the crevices.”
Material ID, edge mask, pattern mask.
I found the simplest way to structure a texture was to have a form layer at the top that brightened upward facing surfaces, and conversely darkened downward facing surfaces, with an edge brightening layer to accentuate the objects natural shape. Our ambient light in-engine is a single colour and so baking in some subtle lighting data helped objects have some shape even when in total shadow. Next, a weathering layer that universally affects the asset. Things like dust, stains, and other environmental effects go here. Beneath this all the materials are applied to their corresponding material IDs from the high polygon sculpt bake.
From this point I’ll start to work in overlaid scanned details from the dDo library, these won’t affect the diffuse channel very much (deliberately), but will add some physically based detail and reflectance values. The materials that make up Tölva and it’s inhabitants are 90% diffuse covered and 10% specular, meaning they are largely matte looking surfaces with bits chipped away to reveal the metal beneath. McQue’s style has very little exposed steel, or polished chrome and there is no glossy plastic, so I tried hard to match that. More on the PBR side of things later.
Once materials are assigned to the whole texture there’ll be a lot of tweaking of the tiling pattern’s intensity, colour, size. Material specific details will also go on, like rust that only affects metals. Then in some cases I’ll add bespoke hand painted details like glyphs, diagrams, or bits of weathering that only appear where there’s a pipe or something and that can’t be defined by the automated process. But this is the only part of texturing where I’ll actually paint a specific detail onto a specific part of the texture, everything else is controlled by dDo and my masking.
Bandit, zealot, and scavenger colour schemes
The colours we use are often collections analogous colours making up 60% of an asset, then it might have a darker or more saturated variant covering another 30%, and then remaining 10% has a bright or rich accent colour. Usually the best way to get a decent start with this is to colour pick directly from a concept and go from there, can’t get more accurate than that. As we got further into the project certain palettes would mean different things to me about where they were in the world and who created them, making decisions about colour schemes much easier.
Once all this is done I can save individual materials as presets, or entire documents to be reused on similar assets, this is largely what facilitated us in getting the texturing done as a efficiently as possible.
Implementation: Make Everything Modular
Being able to cannibalise existing assets for reuse is an invaluable tool when you’re trying to squeeze as much variation into the world as possible without burdening your VRAM usage further. The mileage you can get from an asset is often surprising in terms of reimagining it for other purposes. If you model things with discrete watertight intersecting meshes rather than combining everything and deleting interior faces, you can at any point split these out and reassemble them into a new variation of that asset.
This is probably obvious to veteran game artists but was something I was often in two minds about at the start of production, modularity vs bespoke detail. The other thing to bear in mind with this approach is baking with your meshes well exploded so occlusion data doesn’t interfere with neighbouring meshes, preventing you from reusing that one piece in a prominent place because it has a massive shadow across one side of it. Meshes can be merged using boolean operations to merge intersecting meshes and create totally new shapes, which we did to create cliff faces comprising multiple rotated cliffs into one uber cliff.
Creating asset kits is a common technique in games utilised particularly well by the Bethesda teams. Tölva has less of a need for complicated interconnecting architecture but we were still able to get some use out of concrete piece kits that we made to build more industrial areas, and kits of damaged spaceship to decorate the space wreck debris that litters the world. Creating these kits for the environment team (er, Jim) took a sizeable amount of the art dev time. Another example of this kit-based approach are the weapons attachments, all modelled as separate items that could be rearranged and mixed together to create weapon variants.
Working in the sizeable world of Tölva meant pushing a lot of geometry onto the screen at any one time. Occlusion culling and culling regions far from the player helped alleviate some of this but ultimately we were going to have to create level of detail meshes for a lot of polygon heavy, or frequently used assets. This is a fairly simple process and its amazing what you can get away with when an object is at distance.
Expanding the look with Shaders
I have no programming skill or experience to speak of, but I found fairly quickly I was being limited by my ability to create simple shaders to achieve effects commonplace in games and desirable within our sci-fi aesthetic. Unity plugin Shader Forge became my go-to tool for solving these problems, it’s a node based shader writing solution that is approachable but still crammed with maths terminology most artists have never heard of. Using this I was able to assemble and visualise shaders that had pulsing lights, tinted a material based on ID maps, did weird things with transparency, or just layered textures based on normal direction. This saved me using up precious programmer time – Tom was full time on the project, and Dan part-time, so their brain cycles were at a premium! – and gave me control over very specific parts of the look. This kind of autonomy is very precious when you work remotely and there isn’t always someone on hand for you to pester with technical queries. Being a visual scripting system it does have the downside that when it breaks, I often had no idea why, or how to fix it. These issues weren’t insurmountable but did lead to a day of debugging from our resident shader expert, Tom Betts.
I would approach materials very differently if I was starting this project from scratch tomorrow. Coming from a CG background pretty much everything is given a specific texture that uses the full UV tile, and that was pretty much my only option to get the look we wanted at the time. As my understanding of Shader Forge evolved I was able to create a sort of shader version of how my textures were set up inside dDo. I was limited to 4 masks (RGBA channels of the ID texture) plus a base layer, and I could tile and tint some of the McQue patterns within those masks. Each McQue pattern had the diffuse pattern stored in the red channel, specular in the green, and gloss in the blue.This allowed me to get good resolution on textures for assets that were 5, 10, 100 metres long. The ID and normal maps were still limited by resolution but the tiling worked very well. It serves well as a halfway house between a 1:1 mapped texture and tiling materials, but lacks the subtlety and detail of a 1:1 or the variation and fidelity of having a library of materials applied to submeshes.
Our initial approach to terrain textures was to treat them as purely two dimensional, abstract patterns. As the style developed it became clear we were going to need something a bit fancier to fit the aesthetic, especially given the fact that terrain filled the majority of the frame a lot of the time. I began sculpting tiling terrain materials in zBrush, creating quick sculpts that could be exported to Unity quickly to test tiling, detail, and blending between layers. It was important to use detail meshes like small pebbles and shards of rock that already existed to tie the textures to actual 3D props sitting on the terrain. This was the first organic thing I’d had to sculpt that wasn’t a rock or cliff and the soft shapes weren’t fitting the style at all. The solution ended up being to reduce the polygon count of the sculpt using zBrush’s decimation tool to create a more faceted organic surface. Feeding this through dDo and using existing material presets was pretty straight forward. The height map was used by the RTP terrain setup to cleverly blend layers together based on depth, creating a much more pleasing blend that a simple fade.
PBR or physically based rendering has become a buzzword and marketing tool as it’s adoption has spread, symbolising a graphical upgrade over traditional game rendering. Mwoar detail mwoar realism mwoar immersion. Much as I love all those things it’s most important contribution from the artist’s perspective is having a controlled environment within which to work where you can create a material and have it react to light in a predictable manner, not only between scenes and lighting setups in the game engine, but also between software packages.
Having this predictability is even more useful when your game has a full day night cycle and is going to appear in all sorts of lighting conditions. Even if your game isn’t crammed with brushed metal and lacquered pine (highly reflective surfaces being a sure sign of a game trying very hard to get the most of its PBR) it can still massively benefit from a physical approach. Having a nice fresnel falloff on a largely diffuse material makes every object lit at a glancing angle look fantastic, materials are energy conserving so nothing washes out in a way that just appears like a white value being clamped.
McQue’s paintings have naturalistic quality to their lighting, this is ideal for PBR. His colour palettes have a fairly limited range, there are few bright whites or really dark blacks, much like real world albedo colour values. This allows a PBR lighting model to really shine without being overpowered or limited by overly saturated or contrasting texture colour values. PBR is not a style, it’s a tool. You can push your look in a number of directions with colour correction, lighting, and post processing- but you are starting from a well calibrated, stable, neutral position that is easy to control. Using PBR also means you can draw on nearly 200 years of photographic knowledge. Exposure, tone-mapping, HDR, colour correction, bloom, lens flare, chromatic aberration, depth of field, vignette: these are all techniques that have either been part of photography and film for a long time, or are simulating things that a lens does naturally. Also use linear colour space everyone, it has been VFX industry standard for forever, there’s no reason not to.
Having this linear colour space PBR setup means we are generating accurate colour values in the render that, after tonemapping, exceed the screen’s full brightness value. They are brighter than white, this is what makes the render high dynamic range. We use these values on our light emitting (emissive) materials particularly to trigger a bloom effect, but also to illuminate any dirt or scratches on the lens you’re viewing the game through.
Yes, we’ve been quiet for a long, long time. Some people have even asked if Big Robot is even still a thing! Well, it is. And here’s what we’ve been up to.
We feel like we could leave at it that, but we know some of you will want to know more. So let’s explain what this is all about, and a little about how we got to where we are now.
So What Is It?
We’re making an open-world shooter in a science-fiction setting of our own devising. That’s The Signal From Tölva. If you enjoy rich sci-fi atmospherics and free-roaming game worlds then we think you’ll understand what we’re doing here. It’s a dynamic game of exploration, territory control and robo-combat, with an open-ended story running through the whole thing.
The signal of the title is a mysterious emanation from the planet you are exploring – Tölva itself – and uncovering exactly where it has come from, and why, is at the heart of the game. That said, there’s a modern sci-fi twist in our fiction, because you (whatever you may be) aren’t actually there on the surface of the planet. You’ve remotely hijacked a Surveyor, a humanoid drone already on the planet’s surface, and when that chassis inevitably meets a violent end, you’ll simply connect to another. Remote control, via an interplanetary network. That has implications for both how the game plays, and what the story says.
Anyway, science-fictional acrobatics aside, we think you’ll enjoy both the intense firefights and just standing on a hillside watching alien birds glide by. You’ll be investigating anomalous signals from glitchy abandoned bunkers and scavenging materials from mysteriously wrecked spacecraft. We’ve talked in the past about making a game out of those old sci-fi paperback covers or prog rock album covers, and this is that, only with all the open-world autonomy stuff we’ve always been so interested in. We’ll talk more about the development process that got us to this point in a later blog post.
Isn’t procedurally generated this time, nope. We employed a few procedural and generative elements in the creation of the environment, but this time we built the world itself by hand. So many hours of work! But, ultimately, this hand-crafted approach delivers a quite a different feel and end result from the procedural fields of Sir, You Are Being Hunted, /and/ gave us a seamless map four times the size of a Sir island. We’re enormously pleased with the change of pace.
What To Expect
The Signal From Tölva is an open-ended shooter, an action game, and a canvas for exploration. The two big things are: Exploration and Combat. We’ve sunk all our resources into making those two things come alive. The game world is driven by Ai activity that decides where our robots will go, and what they will decide to do. Bots will head out from bunkers to survey crash sites or attack neighbouring bunkers or guard locations. Territory control battles kick off dynamically, with patrolling AI squads skirmishing against each other and taking control of a series of brutalist locations across the planet’s craggy valleys. Battles erupt with or without the player’s intervention, and their consequences can change the course of play by clearing ambushes and capturing or losing vital bunkers that allow for respawning and re-equipping as you play.
This time, though, you’re not hiding in the long grass as those automatons rumble past, and instead will find yourself going in with lasers blazing (even though you will pick and choose your battles, scouting possible encounters from a distance with your binocular-vision). There are hi-tech assault rifles, concussion fields, electronic countermeasures, robot-commanding modules, and defensive plasma shields.. You unlock all these by performing a series of missions for the faction you are hacked into: and these missions, as much as the territory control, drive you across that alien landscape to explore further and fight harder.
What We Can Say About The Story
The Signal From Tölva is set in a future where AI factions have abandoned humankind and set out on obsessive quest to uncover the secrets of a long-dead civilisation. There are starships, there is an interplanetary internet, and there is something very, very wrong with the planet called Tölva.
We’ve been careful to tread lightly and default to minimalism for the story-telling in the game itself. There’s little in the way of direct exposition because we want you to figure out the puzzle for yourselves, if you want to. However, we’ve still poured plenty of of brain into fiction. We’re keenly excited to say that we’re working with the awesome Cassandra Khaw to develop a (free, to you) prologue novella, as well as to help us flesh out some background lore that we’ll be publishing alongside the game. Yeah, we’re sort of going all out on this one, and we’re thrilled about the wider backstory and game universe that we’re building. We’re just not going to swamp you in it during the game. If you want to delve, it’ll be there. And you’ll be able to delve deeply.
And A Quick Bit About That Art Style
We want to go into detail about that journey into pixels at a later date, but it’s important for us to highlight that we’ve been working with two new people to make the game look as good as it does. The first of these is an artist named Ian McQue. Some of you might have heard of the fella. He’s quite good.
Having finished up a long tenure at the mighty Rockstar (since-the-first-GTA sort of long) McQue had been doodling sci-fi stuff. In fact, it turns out that he’s one of the finest sci-fi doodlers we’ve ever encountered. We asked if he’d be interested in a collaboration that would result in some some doodling for us. To our delight and amazement he said yes.
The challenge, of course, was for us to integrate McQue’s vision with our game concept. We had been more than happy with Sir’s low-fi charms and atmospheric consistency back in 2013, but this time things had to be shinier for the sake of the sci-fi, and we couldn’t do that without some formidable full-time arting. It was appropriate and good, therefore, when former-Aardman Animation CGI cleverclogs Olly Skillman-Wilson came aboard to make the 3D stuff. He uses real fancy 3D tools, knows about AO maps and has strong opinions about different modes of anti-aliasing. He uses the word “fresnel” in general conversation. What we’re saying is that he’s basically a sorcerer. And now he’s *our* sorcerer. It’s thanks to Olly’s interpretation of McQue’s work that we developed a beautiful and consistent hand-painted art style for the game.
Science fiction has many allures, and it captures our attention with the thrill of starships and beam weapons, but it really resonates with us as developers because it offers so much freedom to create a distinct and exciting palette of ideas and scenes. Being able to reference McQue’s extraordinary visual imagination and eclectic style has given that process life that we might otherwise have struggled to bring to it. It has been both immensely challenging and deeply fulfilling to engage with top-grade concept artwork, and try and build a look and feel around it. Given the size and experience of our team, I think we’ve made a decent go of that. And Olly has played a blinder. I mean, look:
But yeah. If there’s something to say in conclusion, it’s this: we’re building you a bloody great slab of sci-fi escapism.
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!
– 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.
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).
THE SPOOKY COUNTRYSIDE, OCTOBER 2015 – Ladies & Gentlemen, it’s time to find yourselves hand-in-hand under the shadow of a fearsome robot: resplendent survival masterpiece Sir, You Are Being Hunted has now reached v1.0 multiplayer! You no longer have to die alone.
Over three-hundred thousand Sir, You Are Being Hunted players can now enjoy the company of friends and enemies whilst being hunted to death by robots, thanks to a multiplayer client and the ability to launch dedicated servers. Multiplayer mishap was a feature promised way back in the mists of the 2012 Kickstarter, and marks the end of a splendid journey for the Big Robot team.
Lead designer James Carey explains: “Sir has always felt like a Multiplayer game in-waiting for us so it’s great to have finally made that a reality. It’s an interesting mix of coop and PvP: it might make sense to collaborate at the start of a game, but because only one person can escape at the end those alliances soon break down. It’s been fantastic to see players respond to that ambiguity during the beta test and it’s a real thrill to put those choices in the hands of the wider player base now.”
It’s important to mention that Sir, You Are Being Hunted is one of the few games to feature a networked playable trombone. So that’s cool.
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
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.
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.
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.
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!
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.
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…
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.
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:
Runs the game headless (with no visible interface). This is useful for dedicated servers on machines with no GPU.
Starts a server without going through any menus.
Specifies a specific port for a server to run on. Useful when running multiple servers, or when using port-forwarding through a router.
The number of pieces on the island (by default; this can be overridden by an admin).
The number of pieces required to win (by default; this can be overridden by an admin).
The minimum number of players required for the game to start.
The maximum capacity of the server.
A password for the server. Omitting this means anyone can join. Cannot contain spaces.
A password that allows someone to make themselves an admin (using #admin ABCDE in chat). Omitting this means admins can only be voted.
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.
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!
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.
#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)