“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.”
“Hi guys! I'm Victor, or Mr4Goosey (after my last name, Goossens)! I’m happy to say I’m Lo-Fi’s new Technical Artist (I’ll call it TA for short, so that doesn’t stand for Teaching Assistant here). Most of you are probably not really sure what that means, though. In a nutshell, my job as a Technical Artist is to be a bridge between the art department and the programming department. I do artsy things that are too technical for the artists, and I do technical things that are too artsy for the programmers.
I’ve been doing indie-development on all kinds of projects for years now. I got into game development as a programmer, but quickly developed a passion for creating beautiful things – bringing me to the specialized niche that is Technical Art.
Most of the work I do relates somehow to what your graphics card is doing while you’re playing games; I handle lighting, all kinds of color-balancing, and most importantly, I deal with shaders, the ‘code’ that tells your graphics card what every pixel on your screen should look like. Having specialized in Unreal Engine 4, a lot of the shader-work I do is actually material-based (using UE4’s node system). That doesn’t necessarily make the job much simpler (you still need to understand how rendering engines and graphics cards work), but definitely a bit easier to understand at a basic level. I also work with artists to work out any kinks in their work flow, as well as dealing with performance-budgets and optimization.
You might now be wondering what that means for Kenshi in the larger scheme of things. As you guys probably know we’ve decided to move to Unreal Engine 4 for Kenshi 2. Having years of experience in UE4, I’ll be working to smooth out the transition from Ogre, helping the team get used to Unreal’s way of working. Unreal Engine 4 has an incredibly powerful and versatile rendering engine – if you know how to work with it, because that power comes at the cost of complexity. The plan is for Kenshi 2 to be graphically above and beyond anything we could ever do in Ogre, and I’m here to make sure that we can actually pull that off. An easy example for that is what I’m actually working on right now:
Kenshi 2’s new Time-of-Day system, and primarily, its clouds! Kenshi’s fully dynamic lighting and environment is a massive challenge to represent properly, and it means things like clouds just cannot be left static. Kenshi’s new clouds grow, move and morph over time – all without melting your graphics card! Next up is just about every other material in Kenshi...”