Progress Report - May 8, 2023 (Patreon)

Hello, everyone!

I haven't been so excited as to write a Progress Report as I am today in a very long time! I was so eager and chomping at the bit that I legit sat down to write it yesterday, before realizing it was only Sunday.

Let's just get right into it!

So the expression pass on Claire/Jill is taking a lot longer than I anticipated, because I didn't realize that apparently I didn't start adding gesticulation animation until sometime later in the detailing pass.

So rather than just animating the upper face, which is a pretty quick process, I also have to animate both the head and the hands. The head doesn't really take that much more time than the upper face (though it does take more), and while the hands do take a notable more amount of time than either of the other two, I don't need to animate them as much as either. All in all, though, it still adds a lot more needed time to the process.

In total, I'd say that the expression pass turning into a full gesticulation pass approximately triples the amount of time needed. That being said, I still managed to get 4 minutes of runtime fully gesticulated this past week, which isn't too shabby. I was hoping to get more done, but it is what it is.

As of right now, I am still eyeballing May 15 for being when the rendering begins. But do be aware that if I don't hit the point where I started gesticulating as part of the detail pass relatively soon, that date may have to get pushed back. I genuinely don't remember when I started gesticulating as part of the detail pass (I legitimately thought I did it from the beginning, but oops, apparently not).

I'll let you all know if I find myself needing more time. This is why I don't hard-commit to dates - there's always something sneaky waiting around the corner to jump out and jam up the works. And half the time it's my own disorganization and terrible memory.

Regardless, I posted a before-and-after of the first 30 seconds of Claire/Jill on Twitter the other day. For all you lovely people, I am giving an extended 90-second preview. The animation still isn't finished, as the camera, lighting, and model passes have yet to be done. But the gesticulation adds a ton to the overall feel. I am extremely pleased with how it's going so far.

You can download the full 90-second preview as an attachment at the bottom of this post.

As I extensively elaborated on in last week's Progress Report, I am turning my attention toward building a Life is Strange visual novel in my off-time, a few hours before bed. And it has been making stunning amounts of progress.

I cannibalized the Futashep VN's code-base, keeping its renderer and tossing out pretty much everything else. The back-end that's driving the game is built entirely differently, with a focus on rapid prototyping. Move fast and break things.

As a consequence, the engine is much less prescriptive than the Futashep VN, instead focusing much more on a fluid and dynamic approach to handling things. This means I can easily add, remove, and reorder things without it breaking everything, and without needing to wade deep into the data-structures and modify dozens of things all referencing the impacted elements. The entire system is built around the expectation of things changing underneath it.

The biggest driver of, and consequence of, this paradigm shift is the editor system. As I mentioned last week, the Futashep VN had a separate editing program that I used to create the game, entirely separate from the website-based client that you all used to play the game.

The consequence of this is that the Futashep VN basically had two game engines. One was written in Javascript, driving the website-based player. And the other was written in C#, driving the standalone editor. Which meant every time I added or changed a feature, I had to effectively implement it twice, porting features from whichever engine I added it to first over to the other one.

If you've played any PC games in recent years, then I'm sure you're aware of the impact of porting. Many a bad PC port abound these days. That's basically what I was doing with the Futashep VN, and it contributed to the game just getting really unwieldy to extend.

The Epilogue VN, by contrast, does away with that entirely. It is written 100% in Javascript, and importantly the game and the editor are intimately entwined. In fact, they're the same exact thing - there is no distinction. Literally none: the player that you all will eventually interface with to play the game is the editor, just with the editor UI hidden.

There is a single setting, at the very top of the engine code, that turns the editor on or off. All I have to do is set this value to true in order to develop the game - and set it to false to release a build for people to play.

This has made development on the engine exceptionally fast, compared to the Futashep VN. Who would've thought that things go faster when you don't have to implement everything twice and puzzle out how to get the same behavior in two different engines. Galaxy-brain move there, honestly.

The dynamic paradigm I mentioned earlier is also playing a huge role in development time. While the new player/editor paradigm is speeding up engine development, the new descriptive-over-prescriptive paradigm is speeding up game development.

In a nutshell, the major difference is that in the Futashep VN's prescriptive paradigm I discussed earlier, if I wanted to make any changes to the game, I had to load up the game data file in my editor, which was a glorified spreadsheet with a big ugly graph representing the game's data structures in abstraction. This is what the Futashep VN looks like in the editor:

Yeah. It, uhh... it's not exactly the most intuitive interface to work with. And I had to deal with this monstrosity any time I wanted to make any change to the game. I made a typo and spelled Chakwas' name as "Karen" instead of "Karin"? Well, time to boot up this Windows 95-looking fuck and navigate through the graph and several different lists and text-boxes to find and fix the typo, then export the data out, reload the clientside player, and play back up to that scene to make sure the typo is fixed.

Every. Single. Time.

This is the second-biggest reason why I ended up dropping the Futashep VN. It became migraine-inducing just managing it. For Epilogue, I knew I needed a better way. I needed a more intuitive way.

I needed a descriptive way.

The player and the editor being the same exact thing is vital to this better, descriptive way. And the reason why is simple: I want to make the game as I play it.

Suppose I'm playing along with the current build of the game, and I notice that I made a typo and spell "Max" as "Mix". All I do is I click the "Autoplay enabled" at the top of the screen to turn off game logic, click the "Dialogue" at the bottom of screen to bring up and edit the dialogue fixing the typo, click "Back One Step" in the bottom-left to roll back a step, click "Autoplay enabled" to turn it back in, and then keep playing exactly where I left off.

It's that simple.

And this design philosophy bleeds through to every aspect of game development. I'm playing along and I feel like I have too many sentences of dialogue in a step? Turn off autoplay, click "Dialogue" to select and cut out the sentences I want to move to a new step, click "New Step After" to inject a new step between the current one and the next step, click "Dialogue", and paste the sentence in. Then I roll Back One Step, turn Autoplay on, and bam. The change is done.

I find myself working on a later scene in the game, and find myself writing out a sequence where I think it'd make sense to reflect on if Max had a third choice in the scene shown in this gif, instead of just "Nevermind" and "Arcadia Bay"? I jump back to that decision, click "Decisions -> New Decision", give it a jump-target name and a decision text. Then I just add a few new steps, with the first name named that jump-target, fill in the new exchange that comes out of that decision, end the new branch with a jump-target to the same step that the two existing decisions dump out into. Bam, third decision added, right then and there.

All of this is why the engine is built descriptively, rather than prescriptively. If everything was hard-coupled and hard-wired, splitting a step into two steps would've been a nightmare, as it would break all of the linkages to that scene. And adding a third decision? Might as well just rewrite the whole scene at that point.

But the dynamic, descriptive paradigm leverages extreme locality to manage its state machine. Rather than one all-signing eye that is aware of where exactly everything is at all times (and as such needs to be updated whenever anything moves around), each scene is only aware of its own steps, and each step is only aware of the step immediately after it. So adding a new step is just as simple as changing the old step's "next step" pointer, and then having the new step point to what was the previous next step.

This design paradigm has its drawbacks, of course. When you have an omniscient manager that is aware of every possible state the game can be in, you can optimize things and take shortcuts to get everything as bleeding fast as possible. This move-fast-and-break-things approach doesn't have that, and you have to do some wonky things to keep state outside the local zones. For example, the music loops are, uhh... not very graceful. There's a lot of peek-ahead going ahead to see if it should jump backwards or keep going forwards.

But the overall flexibility of the system just makes it so much easier to work with. And in a prototype, where the main focus is just getting the idea written down and testable, then that's all that matters. This isn't a triple-A game with full pathtracing targeting 120fps at 4k. It doesn't need to be at the absolute bleeding age of optimization. Fuck, it isn't even a final game. It's an intermediary design step, a souped-up preproduction storyboard. So it can have some sloppy code and not-as-fast-as-possible calls in it. It's not a big deal.

With all of that being said, you can see the first two minutes of Epilogue by clicking here. Be aware that it does have audio - music is a huge part of the identity of Life is Strange, and is one I emulate. I hope you like Linkin Park.

And because it felt weird having music and then totally silent voices, I elected to implement some basic text-to-speech for the dialogue reading. I have to warn you, it is extremely rough. It's approaching Microsoft Sam levels of bad text-to-speech. But I find it does feel better than just being purely silent.

So, just don't drink anything when watching the video. You're liable to spit your drink out once the voices come in. Consider yourself warned.

I am electing to refrain from offering a playable build for the time being. I want to get the story implemented up to at least the end of the second sex sequence - by that point, all of the major mechanics should be implemented, and it should be in a fairly representative state of both how the game will mechanically play and how it will narratively feel.

And that's going to take me a while yet - I only have about half of the first scene implemented, and there are a total of four scenes written down in my notes before I get to that point. And there may even possibly be a fifth scene, since I am just adapting my notes from when Epilogue was written to be a film project, so things like player choices aren't considered in the notes and I am just feeling them out as I go. The whole "Nevermind" section that's currently implemented, for example, wasn't in my notes. It just went straight into Max lamenting Arcadia Bay and Chloe blowing her concerns off.

But yeah, I am supremely chuffed with how the game is coming along, both technically and creatively. I've put a few hours into it every night this past week, and every night I went to bed positively wired with excitement over how much progress was made and how well it's all going.

I also spent entirely too much time with Cass here, from Fumates, trying to implement something I have wanted for a long time but historically have had a lot of trouble with: clothes bulges.

I absolutely love huge-dick futas whose love-guns are visible through their clothes. It is such an arousing aesthetic to me, especially when other women notice and react to them. And Cass's whole thing is that she's grossly huge even by the standards of the Fumates universe, with women just constantly pawing at her and desperate to have her rearrange their insides. A big part of that in my mind is the women eyeballing Cass' massive bulge through her clothes and just being unable to help themselves.

Unfortunately, clothing bulges are deceptively extremely difficult to actually pull off. The rigging is a nightmare, because the joint where the legs meet the hip is probably the single most complex joint on the human body. Throw in a huge swinging pair of balls just hanging in the air, and it becomes basically impossible to set it up in such a way that it doesn't implode the moment a leg starts moving.

I tried 4 different approaches to get this to work though, because it's pretty much necessary for Cass to function in Fumates. What I finally found to work okay is pushing the balls up so they're not hanging at all. Instead, they're level with her pussy, which already deforms correctly. Which means the balls can then just piggyback off the pussy's rigging, meaning they mostly deform correctly.

As you can see in the preview pictures here, there's still a bit of clipping that I have to fenagle. And the pant-leg variant clips horrifically if the legs bend more than a few degrees forward. But, it should be enough for a casual walking animation, which is all I need it for. Cass doesn't need to be doing full acrobatics in her clothes - she just needs to be able to strut through the supermarket exuding very very visible big-dick energy.

I've been keeping to my refraining from Fumates that I mentioned a few weeks ago. This is all I've really done on that front, because it's something that just really needed to be done.

All right, that's all for now! Until next week, everyone!