Hi all, it’s past time for another instalment of Kenshi development updates. As our second entry while working from home and with several new members of staff joining the team there’s been a significant amount of ‘onboarding’ this month. To start I wanted to go over two ongoing major localisation projects and a recent virtual event for Kenshi. Lastly, we’re sharing updates on Kenshi 2, taking this month to talk a bit more about the narrative and technical sides of building a large sandbox.
Localising Kenshi
In the past we’ve spoken about our passion for providing Kenshi in other languages, but we’ve rarely delved into exactly what that entails. As two major languages are still due to be re-released, along with this month’s progress update it’s a good chance for us to touch on the concept of translation vs localisation.
As any animation or foreign cinema fan would attest to, finding the nearest equivalent word to throw on a subtitle track is a very hit and miss experience. Often when a language is spoken, we use sayings and euphemisms to communicate a certain meaning that resonates with one culture but, even if translated, might be completely meaningless in another. On the simpler side, for anyone in their mid-20’s that grew up with the English dub of Pokémon
here’s a ‘jellydonut’.
Except that’s actually
onigiri or rice balls. As the western audience would have been unlikely to eat rice balls a decision was made to dub them as donuts and call it a day. A much closer cultural equivalence would have been something along the lines of a sandwich, dumpling, or pasty. None of that covers the visual side of what fans see on Ash’s adventure so at best it’s still a very crude way of trying to relate that Brock was nice enough to pack some lunch for their journey. If you understand that and are now thinking what they could have done instead then congratulations, you just took a crash course in localisation.
In Kenshi’s upcoming Japanese localisation, a lot of corrections have been made to dialogue that baffled Japanese players. For example, currently some ironies are translated with opposite meanings which leads to confusion when players need to make dialogue choices. Similarly, Meg has been replacing nonsensical direct translations with their Japanese equivalent phrases, e.g. the current 'eat boots' is now correctly translated as 'kick your ass'. Work is also being done to change proverbs that made no sense in Japanese culture. Players won't see 'out of the frying pan' in the middle of conversation (referring to 'out of frying pan into the fire') and will instead find a Japanese equivalent saying for a worsening situation. All this amounts to a near complete rewrite of our current Japanese text and requires a degree of thoughtful research - it’s a very time-consuming process.
Meanwhile, for the Korean localisation,
we’ve recently released a major update. As we mentioned before we revisited it with a different team, but we also decided to collaborate with fan Jeffrey Jeoung to assist with quality assurance. This helped us by breaking through the language barrier which prevented us from otherwise checking on the quality of translations.
Kenshi x Indie Live Expo
A quiet side effect of the ongoing current pandemic is the effect it’s having on live events across game development, whilst not as pressing of a concern as many other topics it’s easy to forget we’re in the middle of the busy season for live expos.
Lo-Fi is excited to share, following the positive outcome of our last physical event in Shanghai, we worked with PLAYISM again to take part in our first digital event –
Indie Live Expo 2020.
Hosted by the famous
Ryu’sOffice in Japan, live streams were broadcast in English, Japanese and Chinese with aims ‘to promote friendship, fellowship, and enthusiasm through the medium of video games.’ A cause we were more than happy to add weight to.
The event covered a range of different indie titles and initiatives including personal messages from beloved industry figures
ZUN (
Touhou Project),
Toby Fox (
Undertale,
Deltarune)
SWERY (
The GoodLife /
White Owls Inc.) and
KazuyaNino (
TYPE-MOON).
Finally as many of the Kenshi Discord community can attest to, I’m also a huge Evangelion fan so it’s incredibly exciting mention that in advance of
‘Thrice upon a time’there’s an ongoing Evangelion inspired game jam which was announced during the event.
Where to watch:
YouTube (EN)/
YouTube (JP) /
Twitch (EN) /
Bilibili (CN)For more information
check out the Indie Live Expo website.
Just communication.
Similar to the real world, Kenshi 2 is going to be pretty big. Previously when talking to Nat she confirmed that whilst we still don’t have a marketing friendly measured size to rally behind, it’ll be bigger than Kenshi 1. This raises two important questions: how do we make it feel alive and how will it work from a technical standpoint? Below Nat touches on the first point and the magic of the ‘narrative bark’.
“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”
Beautiful World.
As readers already know, Kenshi 2 is in development using Unreal Engine 4 which is a major jump from an aging implementation of OGRE. Following on from the narrative elements of the world,
Victor, our technical artist, has kindly offered to answer some questions about the technical aspects.
Starting with a major pain point then, moving across large areas in Kenshi 1 leads to lots of ‘loading’ pauses. How does Unreal handle huge maps and will that help with this?“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.”
That’s pretty huge, I can’t think of that many other games with similar scale. I appreciate it’s not your field, but will World Composition mean no more units running into the sky?“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.”
You’ve mentioned streaming bits of world in and unloading it on the fly but let’s talk about building larger spaces. In talks from Unreal Fest it seemed like developers can make presets for objects or types of buildings, set the area boundaries then let the engine create an entire city for them to edit. Do we have anything like that helping us with Kenshi 2?“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.”
What about when adding details to natural biomes?“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.”
If everything is going to be nicely dressed up, how do you deal with performance hits for all that extra detail? “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.”
So that covers some basic software optimisations, what about from a hardware perspective - Kenshi runs an older version of OGRE that’s famously single threaded so what’s the difference with Unreal and Kenshi 2?“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.”
A lot of this works on paper but what can you do to know if you’re getting it right as it’s being made?“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.
Finally, Epic just announced Unreal 5, as it’s supposedly seamless to migrate there’s talk of us moving along with it. Are there any features that you saw and immediately thought ‘that would be perfect for Kenshi’?“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.”
---
This month’s blog was a lengthy undertaking so I’m looking forward to hearing thoughts and questions from the community in the comments. As ever you can join us on
Twitter and
Facebook where we have a soon-to-be-confirmed creator competition in the works. If you’d like a none-Steam way to keep up with the studio, blogs are available on our
website and via our
mailing list.
Cheers,
