Kenshi 2 will feature a number of tools to help placing objects indoors substantially easier. Let's start with the improvements made to the Kenshi 1 method of placing furniture, now called Free-Placement Mode.
As the name suggests, this mode allows you to place furniture at any valid location at whatever rotation the player sees fit. We've now added collision correction to this mode to allow players to place objects up against walls and other objects much easier. There's also an option to allow you to snap the rotation of your object against whatever you collide against, making alignment to walls and other pieces of furniture much easier.
For some objects, however, this mode is not exactly ideal. Say I want a neat line of hydroponic farms inside the building, we could try and line them up neatly by hand, which could take some time, or we could use the new Grid Snapping Mode for perfect alignment.
But what if you want to align objects at an angle? What if you want some things aligned differently? Well, that's where our final new mode, Furniture Alignment Mode comes in handy. Now players can select any interior object and generate a grid to align to the building.
With these new tools, it'll be easier than ever to create interior layouts for Kenshi 2.
Chris Hunt – Head Developer and CEO
Home Setup
Life Balance
Outside of games I have 2 major interests. The biggest is motorcycle adventures. I have a 1989 Kawasaki KLR which is basically the AK47 of bikes: simple and reliable. I can repair it by the side of the road in the middle of a desert with nothing but a spanner and some cable ties. I once rebuilt the carburetor in the darkness on a beach with a torch in my mouth, without knowing what a carburetor was. I once rode up a ski slope in the Pyrenees and camped at the top, and found the next morning that a gang of wild horses had beaten up and possibly molested my bike which made all the battery water drain out. I rode across half of Spain with no battery, making sure I only parked on the top of slopes so I could bump-start the engine again. I love it, these little things add the adventure and create memories.
I’ve since rebuilt and upgraded the bike from the ground up preparing for a big adventure that I wanted to do in summer 2020 but the virus ruined that, so we’ll see. My dream is to cross Mongolia.
I’m also building a 4x4 camper van to go snowboarding with, but that’s still in early stages. I was originally going to use an old army truck, but that proved way too impractical.
Snowboarding is my other love, but it’s a very season and weather dependent thing so I don’t get to do as much as I’d like, especially as I’m so fussy about snow conditions.
Nicolò Zubbini – Environment ArtistHi, I'm Nicolò, an environment and hard surface artist. I specialise in architecture, but also work on natural and mechanical environment elements, and vehicle models. I have a passion for sci-fi, and any weathered and grungy setting.
I studied architecture, and have initially worked on architectural visualisation, followed by historical documentaries and hi-poly vfx environment. I started using Blender in 2008, and became passionate about its community and open source software. In 2012 I worked for the Blender Institute on the VFX open short movie, "Tears of Steel". More recently, I've been involved in game development, including Kenshi (for 2-3 months working for Sebastien Froncek, from whom I learnt a lot!)
Here are some of the works I've done for Kenshi (Warning! These are from Kenshi, NOT Kenshi 2! My work on Kenshi 2 appers in section above in ‘Interior Object and Furniture Placement Modes in Kenshi 2'). Please also note these are portfolio renders in Marmoset (a render engine for game assets), not in Ogre (Kenshi's actual game engine), so the models look a bit different from how they look in the game.
Having worked often with small indie teams, I have experience in level building, shading and light, using Unreal, Unity and other engines. I also do some scripting to automate my art workflow, using Python.
For Kenshi 2, I'm working on buildings and related props, such as furniture.
Home Setup
I've always worked remotely, and my home-studio setup is made up of a 'normal' mid-high tier gaming PC as a workstation, just with a colour-accurate monitor and a keyboard with custom layout and macro-pad.
Most game development tools are Windows-centric, so my workstation runs Windows, but I also keep a reliable Linux PC on the 2nd monitor with KVM switch, acting as spare/backup and files/media server.
Life Balance
In my free time … well, before 2020, I used to socialise more, like going to my favourite pub with friends and ride or work on my bicycle, but now I have more time to spend on my nerdier side: I guess I'll finish building my 3rd keyboard, start another career in Kerbal and find 10k pages of sci-fi saga to read.
Craig Tinney – ProgrammingHello readers! I'm Craig, the newest addition to the Lo-Fi Games programming team. I've been helping to port Kenshi to Unreal Engine 4 for Kenshi 2 since I started back in April of this year.
Since I joined Lo-Fi during the UK lockdown period, I've yet to actually work in the office with the rest of the team, and I've been communicating with everyone online. Safe to say at this point, I'm itching to meet everyone face to face!
So far I've been involved with the new building placement tools mentioned in this post as well as general porting to unreal and a lot of things we're not quite ready to talk about yet (but they're really cool, honest!).
Life Balance
Outside of work, I make my own games on a much smaller scale than Kenshi. Usually, I make things in Pico 8, which is just about the cutest game engine in the world and everyone should know about. If you fancy checking out my games, they're all available for free at https://ctinney94.itch.io/
Lately I've been trying to find some non-screen focused hobbies due to spending so much more time indoors this year. As a result, I've gotten into building terrain for tabletop games with my housemate. Check out these rocks we made!
I've also started to make tapes of some of my favourite albums since acquiring my Dad's old hifi stack.
Please do not judge me for this, 2020 has all affected us all differently.
“Hello! For the last few months, I've been working on the little pieces of information that subtly unfold the various histories and cultures of Kenshi's world. Writing for a sandbox game can be a little different to other RPGs where the developers normally have more control over what the player hears and sees (and even what the NPCs do!). So, for Kenshi, I need to reflect the necessary information differently while also making sure the world feels alive and immersive.
A few months back, I talked about roughly structuring our first factions' layouts on the world map, but now my job is to zone in on the individual cities and their own mini conflicts. I've been planning out what I like to call the 'Carrots' - the local goals or tempting secrets for the player to explore. I then list out all the possible ways I can convey that information, using in-game item descriptions and different dialogues, or visually with assets. We're strictly against traditional quest systems in Kenshi, so it's important for me to tell the player what they can do indirectly through the environment instead, planting seeds in your minds and making you want to do things for yourselves.
One of those 'dribbles' of information involves writing dialogue Barks. Barks are the short bits of dialogue that NPCs blurt out either in reaction to something, or just completely ambient comments - the ambient comments are the ones that I've been writing and they're perfect for breathing life into a world, reinforcing goals and lore, and simply interacting with the player to really make them feel part of the world. BUT... I have to write a lot of those suckas while actually keeping them interesting and nonintrusive. They can be a bit mind numbing to work on but they're one of my favourite methods to paint a picture of a town via gossiping and general musings from citizens.
If you'd like to read more about my process with writing barks, I've written a much more in-depth article on gamasutra or you can follow me on Twitter”
“UE4 has a system called World Composition - it allows us to divide the world into cells which are then automatically loaded as the camera approaches them. It can do that asynchronously, meaning it doesn't lock up the game; it's loading the data as a background task. We can divide buildings and such over these cells in order to keep them unloaded and have them automatically come in when needed. World Composition is also built to work with Unreal Engine's Landscape system.
Unfortunately, the stock Landscape system isn't explicitly designed for a world as massive as Kenshi 2. While we still intend to use world composition, there’s additional exploration going into third party options for the landscape system to go even further. It’s important for us to get this right as currently Kenshi 2's world is expected to end up even bigger than Kenshi’s ~1000km2.”
“Ideally, but this also relates to pathing. We haven’t finalised exactly how pathing will be handled in Kenshi 2, but our current expectation is that we'll be working with Recast (UE4's stock navmesh which is well-tested and reliable). So tentatively, no more people walking off into the big blue yonder.
UE4 and Recast allow us to generate the navmesh where we need it with a large amount of flexibility, and it should, theoretically, handle our world really well. Either way, I'm confident we'll have a lot less weird pathing going on than we do in the original game.”
“Things like city-spawners are something that we can use, but because of the oddities about Kenshi's world and a bunch of specifics, we also can't rely on a generalised system. If we do want to end up using things like generators, we’ll be developing a tool internally. One other big problem with these sorts of things is that if it’s relied on too much then the world ends up feeling ‘same-y’.
On the other hand, while it’s a lot of work for an artist to go through and manually put all the buildings and pots and pans in the right spot, it means they really are in a spot that does them justice. We do use modular (re-useable) pieces where we can, but we’re being careful with not overdoing them, after all we want Kenshi 2’s world to feel unique and distinct.”
“Natural environments are a lot easier to automate with those kinds of tools – at least for the menial stuff like grass placement. Of course, we could manually position every blade of grass, but that would be a nightmare. What we actually do is procedurally place grass in the right spots determined by our level designer.
There are also other procedural tools we can easily integrate into our workflow for natural assets – for example Unreal has native Speedtree integration. Speedtree is a tool that allows us to make foliage “species” and generate as many unique trees in that species as we want. It makes the foliage-creation a lot less tedious than needing to manually model them.”
“For starters, Kenshi 1 didn't use LODs (dynamic changes in level of detail) which meant operating with a massively constrained tri-budget for near-camera-detail. Kenshi 2 make heavy use of LODs, and we’re massively helped in that area by UE4's semi-automatic LOD generation systems. Essentially, we can have extra detailed meshes up-close, and turn them into simpler low-detail meshes when they’re further away. This all happens without any extra work on the artist's end.”
“It’s a huge shift here, really. When Kenshi development started, multi-threaded CPUs really weren’t that common yet, nor were the cores nearly as fast as they’re becoming now. For context, at the time Intel’s i3/i5/i7 release scheme didn’t even exist. In development, it’s important to work on systems that help as many people as reasonably possible to be able to play - Back then that meant there was no reason to go beyond a single-thread. It’s an incredibly complicated thing to code so it wasn’t worth the development time.
That’s different now, even the average user runs 4 CPU cores. Unreal Engine, by default, runs its render-thread on a separate core. Kenshi 2 runs almost all of its logic on extra threads, of which there are now more, and they’re faster. The gains made by proper multi-threading are massive at this point. Another thing which makes a big difference is that so many rendering-bottlenecks of the past decade have gone from being handled on the CPU to being on the GPU, which is significantly faster for calculations that need to happen hundreds of thousands of times per frame. GPUs have gotten exponentially faster over the past decade, and that’s power we can properly tap into.”
“This sort of thing is for a large part just developing some sort of instinct for what you should and shouldn’t do. If you show me the profiler statistics for a given scene, along with a wireframe, I can generally pretty quickly figure out where any slowdowns are coming from. It’s difficult to explain why in each case, that goes incredibly deep, but you get a feel for the patterns of what works and what consequences certain choices have.
During initial development, you work on rough ideas, generally without hugging tight performance limits for everything. Once something’s working, then it’s time to start looking whether the current cost is reasonable, and where you can easily scrape some frame time off it. The big analytical guns come out when you run into major performance problems. Generally, there’s a certain benchmark you want to hit for acceptable performance at minimum specs. Once you’re unable to hit that benchmark, it’s time to stare at lots-and-lots of numbers – indicators of how costly parts of a scene are – and go through what you can deduce from them. Starting with the worst offenders, you ‘scrape some stuff off’, ever more aggressively. Optimisation’s basically a circle, it repeats as you go. Scenes keep growing and therefore getting more expensive, so you work your ass off to make sure you’re still meeting the benchmark by tearing the existing stuff apart more. The scene grows again and the cycle repeats.
“As a technical artist, I’m incredibly excited to see what Unreal Engine 5 will bring us. If it delivers everything Epic has been marketing so far such as the lighting and geometry changes, it could be a massive game-changer.
That said, we don’t know how the final implementation will turn out so we can’t count on it yet. The promotional material stresses that porting should be easy, and I’m confident it will be, but based on current information swapping from UE4 to UE5 won’t automatically mean much. The major gains with the new tech aren’t user-oriented, they’re things that will make a massive difference for the art creation workflow and we’re already in the middle of that. We also can’t work according to the new idealised workflow either. Obviously, as it wouldn’t be worthwhile to sit here twiddling our thumbs until UE5 comes out and make everything then, the current plan is to just continue developing as before and see what we can do when it arrives.
Speculating on a hypothetical Kenshi 3 though… I imagine our workflow would be fundamentally different using UE5 as compared to our current art-pipelines, and I imagine it’d be significantly more time-efficient. That’s all very speculative though, so don’t get too excited.”
