LogIn
Steve Chapman talked about the production of Industria, and discussed how amazing environments are created for this project.
Steve Chapman talked about the production of ‘Industria’ and discussed how amazing environments are created for this project.
Introduction
Our core team is made up of two developers: there’s me, Steve Chapman from Glasgow, I handle scripting and level creation; and then there’s David Jungnickel from Berlin who creates our 3D assets and textures. Like many indie teams, we work remotely which brings it’s own challenges; particularly when working together on pre-production, writing, concepts and environment plans. Aside from that, we have Lukas Zepf who is our composer and sound designer.
David and I met a few years back, after I graduated from university and he was doing his A-Levels. We worked together on a previous project and we quickly discovered that we shared similar aspirations. During that time, we discussed different ideas and mechanics until November 2016 when we settled on a concept we both loved. When January came round, I left my job and we started working on the idea full-time and by summertime, we had finished a working prototype.
INDUSTRIA
INDUSTRIA is an atmospheric Sci-Fi adventure set in two fictional universes: one a post-Cold War Eastern Germany; and the other an industrialised 20th century Scandinavia. The game starts in Germany where you take control of Nora Solheim, sister to Hugo Solheim. Participating in an international project called U-TEP, Hugo works as an engineer on a groundbreaking machine that will connect these universes. At the height of the project however, Nora questions the morality of her brother’s work and together they plot to collapse the amazing yet terrifying scheme.
The game is a single-player action adventure with puzzle elements. We’re developing it in Unreal Engine 4 and it’s driven entirely by Blueprint script. All of our assets are made in Blender and Photoshop by us, we don’t use any shop-bought assets. We’re also big fans of traditional texturing methods which means that all of our texture channels are created manually. We don’t use any plugins or software such as Substance Painter or DDO, as we feel there is a certain danger that it’s easy to lose individuality with these programs. Given the choice, we simply prefer a rougher more handmade look – perhaps we’re just a little bit old-fashioned.
Environment design
We’re both avid gamers ourselves and we share an interest in seeing other indie games of all shapes and sizes. Sometimes we can feel a little bit let down by some over the top lighting in a scene that could otherwise look fantastic, or perhaps some empty corners of a level which detract from the illusion that the game is creating. With INDUSTRIA, the primary goal is to make the world believable. Every room of every building needs to make sense, and the materials that a wall is made of needs to have a conceivable explanation behind it.
From our experience, the term photorealism is mostly connected with high-res textures, large amounts of polygons and an emphasis on normal and displacement maps. However, our workflow would in theory mean that our game isn’t photo-realistic at all. Most of our assets use 1k textures or less, with many using 256x256p and 512x512p sized maps. Generally we don’t use normal maps for our assets, though we do use them for tiling materials such as landscapes. Also, if you compare it to other games, our poly-count is probably lower than the standard modern game as well.
It’s interesting you mentioned Arch-Vis as I did a lot of research into how those sort of scenes are lit as well as things like how light works in real-life and applying as many of those rules as possible. We focus largely on natural lighting and use that lighting to really push the visual quality of our environments. That combined with minimalistic assets and carefully considered colour choice, means we’ve achieved a visual aesthetic that we really like; and thankfully based on our feedback so far, other people seem to like it too.
We’re attempting storytelling through our environments and we hope the player will look into the hints that we give them in order to learn a bit about the universe you play in. For example, this warehouse wasn’t always this large and originally it stored equipment and consumables for an institute; but since then it’s purpose has changed. Now it houses a machine and so the room was extended using cheaper materials, wood, in contrast to the original brickwork. This creates a nice distinction between the two areas (newer wooden walls and older, dirtier brick) and helps to frame the machine inside the scene. The floor to this room is situated a few feet below street-level, and as such over the years it has become damp and stale-aired – made apparent by the rising damp, leaking walls and wild foliage.
The first thing we do is establish a plan of the environment we’re creating. Normally they’re pretty basic but we use them to understand the shapes and form of the playable space. Generally we have an idea of what the purpose of that environment is going to be, so we just have to create a plan that encompasses that purpose.
Once we’ve got that, we start with a basic blockout of the major forms and pathways. The most important aspect for us is scale and formality as they really help to make the scene feel real. We try to spend as much time as we need on scaling, basically until we’re happy, and then move on to the first detail pass. At this point, it seems most developers will replace BSP with their modular pieces or other static meshes, but generally we don’t.
Originally when I started tinkering in games I began in Hammer; making some probably quite poor environments for Half-Life 2 and Counter-Strike. Hammer has a much larger emphasis on BSP and I always really liked how quick and agile the creation was whilst retaining the ability to create powerful environments. So our workflow uses more BSP than most professionals would probably advise these days, but we still love it!
Lighting
Lighting is something we think about very early on. Once we’ve done the initial blockout, we normally have an idea of where the light sources are and so we can already see how the lighting will roughly look. When we begin doing detail passes and adding materials to the scene, the lighting has to be altered with it. Different surface colours, metallic and nonmetallic objects can all change how the lighting appears and so our lighting goes through a number of stages before we call it done.
Most of our environments rely majorly on natural light sources, which makes large interiors and underground areas a real challenge in our levels because we’re creating abandoned spaces. If we left our scenes purely to skylights, then all our levels would be much too dark to even walk around in. So we have to cheat a little and simulate natural light flooding into a room. For this we use bright point lighting in place of any natural light sources (a window, an opening in a wall) and then we fill the environment using very soft point lighting. With the fill lights, we want to use as few as possible so that it’s not to easy to spot the actual light’s source within the game.
In terms of performance, we haven’t begun optimisation just yet, but already performance is fairly good. We use as much static light as we can to light environments as static always looks better than dynamic. Particularly as we’re going for a soft, Source-Engine-like lighting style, static lighting really helps us control refraction and ambient lighting in a way that you just don’t get with dynamic lighting.
Environment materials
We spent a huge amount of time just experimenting with different aesthetics and styles before we found our niche. Originally we started by learning as much as we could about how PBR works in unreal and how lighting affects the textures that we use. We didn’t like harsh normals and exaggerated surface detail and rather, we preferred softer colours and softer shading. With this in mind, we began creating materials which used only a diffuse and a roughness map, no normals at all. The material setups themselves couldn’t be simpler, it’s literally just plugging those primary textures channels into the right inputs and carrying the rest with lighting.
When it comes to the reflections, we have this very agile process of tweaking roughness maps as we improve lighting. Additionally as a part of the texturing process, Dave is constantly re-importing our meshes into the engine while creating the roughness maps to double-check their appearance. Starting from scratch each time ensures that each roughness map uses it’s own values and no two metals or non-metals act the same under lighting. These slight variations, in our opinion, help to make the scene feel a bit more characterful and less repetitive.
Animations
For technical materials like a monitor with scrolling or blinking text, we use complex shaders. Unreal has some fantastic functionality available and we take advantage of that to create intricate materials as needed. In the case of a monitor, we’ll use separate material ID’s on the polygons that make up the actual pixels of the screen; then we apply our purpose-built high-res shader to that ID. Generally we use these types of shaders to spice up an area that might otherwise be a little bit bland or boring.
The office scene without these shaders felt like it was missing something and although we’re striving for believability, sometimes we have to ignore that just to make the scene a bit more interesting to play in. That is to say, these the premise of this scene is an empty office in the middle of the night. In all honesty, there should be no reason these machines are on in the real world, but we ignored that and implemented them regardless.
Levels
David and I are big fans of Blender and lucky for us we can use it for everything we need. Therefore every single asset you see inside INDUSTRIA will have been created or animated inside Blender.
We plan major forms of the level first and that really helps to keep our design clean. Only once we’re happy with a layout do we then begin making it look detailed and complex. Whilst the end result can look like a nightmare to design, we don’t plan where every single asset or detail will be placed. Depending on the environment, simple or complex, the workflow is slightly different. For example a corridor could be filled quite intuitively, whereas a set piece could require a lot of discussion and a bunch of iterations until we’re happy with it. For example, the very first room in the game changed drastically from our original intention. At first, we wanted an empty room with some simple ambient lighting, but instead we went through about four or five complete rebuilds of that room until we felt it was okay.
The final version benefitted greatly from us relying more on reference images than our original ideas.
When should we expect Industria in stores?
We don’t have a fixed release date yet, but we would assume at this point that we have about two years of production ahead. However that is based on our current part-time input; that could change, for example, with any potential funding opportunities that might arise. Like many indies, we don’t have strict time constraints and therefore INDUSTRIA develops itself as do we with our capabilities.
The next steps for development specifically is the creation of the Hakavik, an important city within the game, followed by vast and varying rural environments. INDUSTRIA also relies on classic shooter mechanics but we also have plans to add some more complex mechanics to the table. For example, the story takes place over numerous different types of environments. We don’t want the game to be several dismembered scenes from an entire story; so we’re trying to give the player the means to travel large distances and experience it all start to finish. That will bring a new set of challenges to us that we can’t wait to tackle!
For anyone interested in our development journey, you can follow our progress on instagram @bleakmillgames or visit bleakmill.com