Developer Blog 01 Year 2025

Hey hey Scientists! Helltaker here checking in from the development cave into the research institute! Let's take a peek together at what has happened so far since the start of 2025 and what to expect from the rest of the year.

I want to start this off with a honorable mention to the anonymous donor that helped ANBW with paying its yearly perforce server and software hosting cost (yes its THAT expensive) by buying the TIMMORTALIZED Tier. You can see a very early Work In Progress of their custom T1M in the GIF below <3

Additionally I need to preface this blog-post with this small disclaimer: 

While this is written mostly from my perspective, the work that went into the last 2 months from everyone else in our team was massively larger than anything I personally could ever do myself. My job (as head of production) is to establish a technical or knowledge foundation for others to walk on or help with choosing a direction to get the goal faster. So, I'll try to give as much insight across all departments, but let's just do a deal here: For everything you feel I did well in your eyes, imagine there's another 14+ people next to me that do exactly as much or even more on a daily basis to bring ANBW into its “Final Form” <3

Also for those not wanting to read as much -> Shallteir our Director asked me to make sure we have some visual juice at the very start to lure you in! You can check out a few nice images from upcoming areas, work in progress animation updates and more in the image carousel at the TOP of this post! I probably also asked Yara to lend her beautiful voice for an audio-book version of this development blog so hope you´ll enjoy this (stares at LonnaKinns).

You´ll find the file attached below!

And then there's this to lead you down into the hot stuff (insert cute diversion tactic No2):

Let's recap 2024 a little bit before I expand the view on what's happening in production right now. 2024 was majorly characterized by our attempt to finalize all major gameplay systems. While we did succeed in most parts, some areas, such as combat, still need a little bit of extra time to truly shine. One thing we can finally say though is heading into its near final shape is our so called “OCD” Graph System, which I´ll give more details on below. In essence, 2024 was us mainly figuring out how to speed up our workflows to allow us to scale into “content flush” speed. With the recent improvements for our storytelling system we are finally getting closer to what I'd call the gold standard for speed for our production with target speed of around 2 weeks development time per subchapter.

With this rough summary out of the way, let's dive into the meat of this devblog! Starting with what I feel being the most painful part of the player experience over the past 2 years so far: Optimization! As you know we've always been on the upper range on system requirements and while generally that was to be expected with our move to Unreal Engine 5, our games VRAM requirements definitely kept growing higher and higher over the past years as we added characters and new areas to the world. So, here is what we´re going to do about it:

City Optimization

Starting with a relatively small but very very complex topic: How to render a massive City like Virtual Little Tokyo??? Insert Tech Jargon: Hierarchical Instanced Static Meshes! Texture Atlasing! Decals! HLODs! Reduced Actor Count!

And in words for normal people (not saying you are but ok <3 ^^): Over the past few months I basically reworked (with some help from Niko) our entire placement and texturing pipeline for large city assets like the buildings but also pretty much any other large structure in VLT. As a part of that we use a few textures to group together materials or surface types on small squares all along the texture surface. It's honestly a bit crazy, but we basically use 4 Pixels per surface type and the entire texture atlas is ONLY 128x128 pixels.To achieve the desired result we then lay out our UV, which is basically the “wrapping” of a mesh in 2D, on whatever 4 pixel square and bam -> Surface Type achieved. Previously it was a bunch of individual per surface type 2-4K textures and with the level of detail that nanite enabled meshes allow us to display, we really do not need the extra detail on the surface anymore, giving us a clean scifi look at nearly no texture cost.

Character Optimization

First of all: Our characters ARE meant to be looked at very closely, so we always expected them to have higher then usual texture resolutions compared to non NSFW games out there. That said, as the guy who wrote the character shader / material arouuund 4 years ago, way before we even started the patreon, I can tell you that compared to other systems in our game, our character shader hasn´t received a SINGLE optimization pass yet. It’s mainly out of fear that I might negatively impact our look / style, but that's just a bad excuse in the end and I've already started looking into what can be done to improve our shader pipeline and reduce both computational requirements and VRAM usage.

First win from the initial research pass I did a few days ago: I found out why we sometimes have weird jagged shadows on our characters and I want to stomp my past self on the foot balls for not realizing earlier! When we switched over to Unreal Engines new Shadow Mapping System called “Virtual Shadowmaps” I did overlook a specific mention in the documentation that a specific style of Subsurface Scattering (short SSS) is NOT supported with that newer type of shadow rendering … and that's exactly the type of SSS we´ve been using for the past 3 years, while constantly wondering “why … how … I hope this someday fixes itself”. Well, it did not and, while I found the root cause of the problem, now I´ll have to resolve the resulting issue: The other SSS Style we can use pretty heavily relies on a new texture map that might add more texture … and more VRAM requirements. For now, I'll focus on doing more research on where I can reduce texture requirements or at least scale to allow us to maybe add a thickness map … thick … hehe … to get the desired rendering result from the new SSS shading. Does anyone else also think SSS stands for Super Snake Snussy?!

While I´ve just started on this portion of the character optimization, our lead programmer Chaotic Dreams (Papa Chaos on Discord) came (hehe) to the rescue and inserted a fully new proxy rendering system for our characters, basically culling them from existence when a certain distance away from the player camera. That means that only characters actually relevant for your current story section or sandbox gameplay experience will be loaded, while everyone else gets literally stored and destroyed, so we can load them whenever needed. While I can´t give you EXACT numbers on how much this saves you and it can be quite situational, I can tell you that one character costs about 250MB file storage and at least around 50MB in memory cost (can vary though based on character complexity). Like with anything in life the German saying counts: “Die Menge macht das Gift.” (Go look it up on google translate)

Additionally we have started integrating Low Resolution Representations for the basic Citizens that you sometimes see dropping off edges at the end of platforms. We´re still trying to figure out what the exact visual representation should be, but you will be able to see a concept of it in the next build. The IDEA is that our entire city is actually “virtual” meaning our citizens will render as “data volumes” or “data cubes” when far away from the player and then transform into their high resolution representation when getting closer to the player. I'm honestly looking forward to some feedback on that one because right now I just put in some random cube that looked somewhat acceptable!

 Animation Optimization

Whenever we´ve been debugging on performance optimization, our characters' animation logic always stood out as particularly expensive. We´ve started addressing this over the past months by doing a few things:

Character Merging

Our first simple solution for improving the performance was to merge our usually modular and separated meshes for any of our characters into combined meshes on import. While that added a bit of extra work on the riggers side, it helped us decrease the amount of individual components that run animation logic by a factor of 3-10 depending on the outfit complexity. While that’s a pretty damn neat workflow, a clear downside of this workflow was that it, well, cost a bit more import time which is fricking precious and we want to get rid of it. As USUAL the developers from EPIC GAMES came to the rescue with yet another crazy feature of the engine, just added to the latest release of UE 5.5 and its called “Mutable”.

No, that's not a term for some BDSM thing and yes it's fully consensual. Well at least on our end :D We´ve already started investigating the new system they added which is basically a procedural system to generate outfit variants and either produce them at runtime at a certain cost OR create variants of your outfits in editor time (so during development). Both these features have one additional MASSIVE improvement to offer that will help massively with performance down the line: Internal Triangle Culling. Basically, it could half the amount of rendered / loaded triangles on our characters while they wear clothes!

You have no idea the amount of jizzing in my pants I´ve been doing ever since I found out about this new tool, it’s honestly crazy and amazing to be developing in Unreal Engine 5 and no that's not a advert, that's just … we would NEVER be able to do what we´re doing at the crazy scale we´re doing it at with ANY other engine and I'm very aware of the opportunities given to us and how randomly well some of these system releases are timed to meet up with our games technical production requirements. I definitely think sometimes we rolled at 20 on the luck stat for our production at times <3 <3 <3

Animation Blueprints

While reducing the amount of individual components calculating animations or retargeting animation information is surely a healthy performance improvement, the main perpetrator is our main animation blueprint logic. So far we´ve mainly worked on decreasing the amount of clutter in said BP and have been investigating multiple ways to keep improving its performance. I would say this will stay a ongoing research problem for us until we have fully wrapped up ALL animation relevant pipelines, such as combat and then we´ll slowly transition the cleanup towards fully multithreaded updates -> so offloading the “problem” from main thread, which makes the game slower, to another thread … slightly increasing the chance for visual errors and crashes but certainly helping with general frame rate improvements! ^^

Sandbox Optimizations

While we did a lot of STUFF in the Sandbox to improve performance, I think the most notable change for performance was the removal of ANY hard references to our intimate effort voice audio files. Here’s a quick reminder: we currently have 1,315 Audio Files PER CHARACTER recorded solely for the intimate part of our game. Without going into too much detail you'll probably never ever have the chance to have a as intricate intimate audio system as in our game, because nobody but a insane being like Yara would ever suggest recording around 46 THOUSAND, yes 46,000 individual audio clips for covering every possible aspect of an intimate moment! And probably nobody sane would say yes to that. BUT WE DID!

So, while the files itself are honestly somewhat tame in their file size, clocking in at around 120MB per character in storage size and only about 5MB in compressed memory size … we found a way to completely avoid referencing the data and instead built a super super intelligent system to load each sound that we need simply by … big brain … unity style … programming … shame on us -> constructing the file path as a string (text) and generating the “soft object” reference that way. There's obviously a LOT more to this but yeah! It's always a lot of fun to further decouple our systems from each other in order to save us from having everything loaded all the time :3

Below you´ll see another juicy thingy that we did, a portion of the code and logic that is used to determine which type of audio is played when during intimate encounters :3

  Workflow Optimizations

So, while it's fun to work on stuff for YOU guys, it's just as cool to work on stuff that makes OUR life easier (and no sadly we have not yet found out how to properly do alchemy and just create gold cries in artist). So just to name a few:

Building Generator UI

This relatively simple UI element is used to both generate building descriptions from un-optimized buildings in a “prep” scene and then respawn them anywhere in their mighty powerful and optimized format. I have created two variants of this UI so far, one specifically focused on Virtual Little Tokyo´s Building and one for Emerald Vale, the upcoming area for Chapter 2! The benefit of having this UI is to help spawn in buildings more fluidly and have them already fully optimized when working with them!

For anyone reading up to this point: Here is a sneak peek on what kinda funky shit Milad has been working on for Emerald Vales Buildings. As you know we do use a lot of asset packs to populate our world with buildings and props, but we do a LOT to make sure things look distinctive and unique. In this case, by creating destroyed mesh variants and creating these run down versions. Emerald Vale is a new area you will be exploring during Chapter 2 and all I´m gonna spoil is that we were heavily inspired by one of our favorite series Konosuba at the time of writing this section of the game.

Additionally here is a juicy gif to show you some of the work I´ve been doing on the Destructible Objects pipeline for our game. This is something I´ll be using for more interactivity with the game world by allowing you to hit and destroy more stuff so you can look forward to letting out your gentle tendencies for EVIL DESTRUCTION all across our world …

“Muahahaha” 

Another cool thing I wanted to show before moving on to the next workflow Optimization is the City Vista Update. It’s pretty small if you think about all the rest we did, but it was about 2 weeks of work to get there. I had Turtle, who originally did 2D work on our other game “Kagura Survivors”, join our team as a 3D animator and immediately started abusing his 2D skills for environment concepts and paint overs so our new environment artist Niko had something to base the CORE and SYSTEM HQ update on. Additionally, I did help a bit here and there with cleanup and updating the pathways towards Blair’s lab. YES. BLAIR’S LAB IS NO LONGER HALF AN HOUR PATHWAY to get there so you can look forward to a heavily compressed experience of the previous walking simulator when playing the next Story Update release! Yipiii … ngl I'm kinda hyped to hear feedback on how nice it SHOULD feel now to play Chapter 1 in general after our next update hehe :3 :3 :3

Workflow Update OCD GRAPH

So as mentioned previously, OCD is a Storytelling System and it looks kinda like this:

So essentially this is a simple graph system in which we convert the magic Doople and Michaela Laws and our Voice Actors into a playable gaming experience. It's pretty much what you´d see from any other major game productions, but slightly hmmm optimized, since we specifically have to reduce the amount of inputs that a designer has to do in order to create the end result.

So as an example: In previous iterations of the system we had been working a LOT with so called “Level Sequences” which gave us the ability to fine tune facial expressions to a pretty minute degree. While that was AWESOME and fun to work with, it was absolutely insanely bad for our delivery performance, ending up with a month or two of development time for a single pass on a subchapter. 

CLEARLY not what we can afford to do if we want to finish the game within the next 1-2 years. With that in mind we sat down and figured out a system that works more like a block system (trying to avoid saying lego here) in which we can slot in animations during any dialogue to give the spoken portion the needed motion and then on top of that auto generate the facial expression. 

The expression generation is particularly big brained, in the way that we asked our writers: What do you want to be able to express throughout our games? And they told us a list of about 112 individual facial expressions that they'd like to use. So, after writing a section of our game and delivering the final product to Yara, our VA director, the writing team goes through one separate pass giving each dialogue section its “Intents” by adding a IntHappy or IntSad at the end of each recording file name. We can then use these to dynamically generate the required facial expression while the audio file is playing. 

Boom! Saved us about 80% of our workflow time and while YOU haven't seen it yet I can tell you that it did allow us to block out a subchapters pure Dialogue sections in as short of a timeframe as a day of work, compared to the previous 2-4 weeks it would have taken. I honestly don't know if you get the meme, but about 30% of my day recently has been spent mentally jizzing in my pants seeing all the good shit we´ve been building for our creation pipeline!

 Animation Pipeline & Sandbox Story Integration

Somewhen in 2024 I started my first research pass on improving our intimate / sandbox production pipeline. The original vision was to utilize static poses and procedurally animate mainly the hip motion to get to something that looks somewhat sexy and believable. After I discovered Taco on LINKEDIN (which is still a surprising place to find other adult devs), he joined us with the main priority of updating whatever shit I had produced into something actually fun. You may have seen version 1 in the previous build iterations, but I can promise you that version can´t hold a single candle to what's heading your way in the next update:

Creator Mode! Yeah originally we wanted to use a similar pipeline as the one I originally had created, but that was really not giving us the visual results we were looking for, so Taco simply built a full … runtime ready … creation mode for animation poses and loops. Ngl I´m sometimes a bit stunned by what this guy is able to pull out of his sleeves in just about a few weeks of work. Taco is a true magician. Obviously this is mainly meant for us devs to create the fun times between the player and other characters … but we´ll make the tool available for anyone in the Sandbox Mode and have already worked out a nice way to handle file sharing between you and other players. 

Next to the first version of creator mode, you´ll be able to give us feedback on the created results both within Subchapter 10s next intimate scene with Projekt Melody as well as about 25 Selectable Poses / Animations in the next Sandbox Update. Sneak Peeks Below!

 General Optimization

While I worked away with the team on a lot of the very visible issues, Chaotic Dreams our lead programmer hacked away on code bloat in order to get us ahead on the decoupling of our systems and further removal of unnecessary hard references but also old code in the project. A good portion of the past 2 months was invested into making everything run better, react faster, be more lightweight, and be much more fun to develop with. For anyone not understanding what a hard reference is: It basically means you load a section of code and as a result something else also HAS to be loaded. Hard references can have a cascading effect, effectively tying together large chunks of a filesbase and forcing everything to always be loaded at once and at all times which obviously sucks both in editor but also at runtime.

The solution to a LOT of this stuff is to completely remove both hard AND soft references from your workflows and simply use strings, strings … and more strings, to construct file paths and variable data.

I think at this point Papa Chaos is dreaming of strings xD

With this I'm wrapping up the major portion of the DevBlog and we can go into the “Looking ahead” portion:

What's to come and when can we expect things?

As usual it's hard to make specific promises, as we are still SOMEWHAT hard capped in our average development speed by the available budget (Which lets be fair is plenty but compared to what other games pull in relatively tame). With that said, as you may have noticed, we invested heavily into improving our development pipeline to alleviate some of that weight from our shoulders and speed things up for you. We are aiming to wrap up a large chunk of this game's production over the next year, so there's this stated goal specifically.

We already have a large chunk of the next update for the ending of Chapter 1 produced and have mostly been working on pipeline updates to improve the overall gameplay AND game creation fun. For the next month I am still planning two individual updates, one focusing on the SANDBOX UPDATE specifically and one mainly focusing on the next Story Chapter.

We´ve been talking with our writing team about what we can expect in terms of delivery dates for the full story and dating timelines of our game. We expect a large portion of the game’s story and dating timelines to be finalized in writing towards mid of 2025, While this seems pretty close, it doesn't mean we are finished obviously. There will be plenty of work for the writers to add side missions and other optional content to the game so we will have a lot more to explore in the game than “just” a story and dating timeline.

Put Into Numbers

Storyline contains 9 Chapters with a number of at least 5 Subchapters of various lengths, but usually a few more. Every chapter after Chapter 1 has the function of adding one or two new datable waifus. Based on the current experience with Prologue and Chapter 1 we expect a duration for a single playthrough per major Storyline Chapter of about 1-3 hours, but that can easily expand to 3-5 hours depending on various factors such as intimate scenes, boss fights … simply exploring new regions.

On top of all of that we have a Dating Timeline planned for every dateable character of which we will have 10 with each of these additional timelines having anywhere between 5-10 playable date subchapters. You can expect each of these subchapters to span about 30 minutes - 3 hours each.

And all that is without even considering the side missions we have planned that involve a certain Takashi, Bar Owner. Or the optional one shot experiences with some of our optional romanceable side characters :3 :3

So yeah .. TLDR: Doople won't leave my cellar for a while now and Michaela is a workaholic anyway. Cheer them on :D (And give Doople some Wall water, he needs it)

While all of this is happening, obviously we have continued creating more and more characters, character concepts … UI Concepts and whatnot. For now, I´ll leave it at a few images of this and for UI I think I´ll just show it when I know we have a “Final Final” Concept done. In a few weeks most likely 🙂

Thanks so much for reading up to this point and I hope you had a good time and your brain is only partially melted. As Blair would say: Take care, my dear anomaly.