Progress Report - July 28, 2023 (Patreon)

Hello everyone!

I apologize for the much-delayed Progress Report. As I noted in the last one, Tuesday was slated for heading back to my folks' place to help with my mum's recovery from her heart surgery.

Part of that was getting up early Tuesday morning, far earlier than I normally get up. Naturally, that required going to bed earlier than usual on Monday. Such that, I found myself not having the time to write the Monday Progress Report.

Basically all day Tuesday was spent traveling (and spending a few hours waiting for a ferry; it was a busy day for ferry travel). Then Wednesday involved getting up *even earlier* to spend all day in Seattle, visiting my mum in hospital. There were talks of her coming home on Wednesday, but she had a few spells of low blood pressure and irregular heart rhythm Tuesday night and Wednesday morning, so the doctors elected to keep her for another 24 hours for observation.

Thursday then saw her coming home, which is a long process in general (anyone whose dealt with American hospitals likely knows this; it took somewhere around 5 hours between "we're letting you go" and actually walking out the door) combined with the long travel time (lengthened further by terrible traffic). Then there was the matter of getting her situated and comfortable, which when you live on a hill isn't particularly great for someone fresh out of heart surgery (to say nothing of her other health problems that make mobility difficult on a good day). So Thursday was pretty well occupied too.

Over the past 72 hours I've had my computer on for maybe a sum total of 5 hours. It's been a hectic week for me. I apologize for keeping you all in the dark there.

Let's Talk Projects.

This is going to predominantly be future-looking because I haven't really been able to get much done this past week, and I won't be able to get much done in the coming few weeks. Put a pin in that, we'll come back to it.

First things first, the Life is Strange Minivid: All of the Chloe audio is, the voice talent did an absolutely fantastic job and I think you all will agree she makes a great Chloe. She was fantastic to work with for this project, first time I've worked with her, and while we came into it with very different ideas and approaches as to how this would work, we were able to click together real fast and we managed to hammer it out in a way that works great for the both of us.

The Max audio is still AWOL. The voice talent for Max originally told me she was hoping to get the audio in by the 28th, which is today. That ship has since sailed, and she is now hoping to have it to me by the Sunday evening. Truthfully, I am not holding my breath on that. I'm not holding anything against her personally - she warned me straight-up that summers are really hectic for her. But the utter lack of communication leaves a sour taste in my mouth, and reminds me of some issues I had with my original Samus voice. If you ever wondered why Samus sounded different in Bounty Booty over every later work where she was voiced by the lovable InsideIncognita... Well, that's why.

IF the Max voice manages a pretty good job, and is able to get the audio in by at least before August 1st, then I will be willing to work with her again on an off-season project. But if she ends up being this unreliable for a future project, or the end result ends up being underwhelming despite the delays already caused, then I'll end up cutting ties with her and look for a new Max voice in any future projects. I hate doing that, I always feel like an asshole, but at the end of the day it's not just me waiting on this audio - it's all of you good people, paying good money and then patiently sitting on your hands. I like to think of myself as patient, but my patience isn't infinite.

I managed to get a little bit of work on Epilogue done last week. Not as much as I would have liked, but I have to temper my expectations when it comes to Epilogue because it is a low-priority side project. The two biggest things I worked on was stubbing and QTEs.

To understand stubbing, you need to first understand a little bit about how the game engine works. I promise this won't be complicated.

All of the game logic is broken down into 3 major elements. At the lowest level, you have Actions. These are simple commands that augment the game in some way, from telling the game to play a specific sound, or display a text tip, or put an item in the player's inventory. They are the machinery that makes the game actually operate.

Above Actions, you have Steps. A Step is a collection of Actions, executed one after the other, bundled up with a background image, a name that other Actions can refer to it by, and some unique information depending on a Step type, such as how long a step should be displayed or what dialogue should be spoken on that Step.

And then above Steps are Scenes. A Scene is a collection of Steps, stored in a big list from left to right. And the Scene is what we need to understand, to understand stubbing.

The game engine is something known as a State Machine. At its simplest level, the game engine starts with Step 1, and then will just march right down the list. So Step 1, then Step 2, then Step 3, and so on and so forth. All of the branching storytelling is done in the context of this straight-line march, using Actions to tell the State Machine to ignore its normal behavior and instead jump to a specific named Step - and then continue its march.

As such, the State Machine has no notion of branches. While you and I like to imagine dialogue trees as... well, trees, with branches and dead-ends and complex paths through the trees; the State Machine just sees everything as one big straight line. And so if you don't explicitly tell it to go somewhere, it will just march right down the line. In a finished product, this isn't a problem, because there are instructions to direct the flow of the State Machine: Jump, Scene-Change, Return to Checkpoint, etc.

But when you're in the middle of writing out a complicated branching section with a lot of interconnections?

You get an issue of branches not being completely finished when testing. And without an explicit instruction telling the State Machine to not blindly march forward, it will just blindly march forward. Meaning that you'll jump right off the end of an unfinished branch, marching into a new branch, and mucking everything up because you're now in a place you were never meant to be.

Compounding this issue is the fact that these Scenes are several hundred Steps long at this point, and so quickly navigating them requires the use of the Graph view I implemented some weeks back. But the Graph view is just a visual representation of the exact path the game engine will take. So, if there is nothing telling the State Machine to stop marching, then the graph represents that.

The result is just a complete mess.

So that's the problem, and the cause behind it. Stubbing is the solution to that issue, and on its surface, it's pretty straightforward. Stubbing is simply adding a new Action, Scene-Stub, that tells the State Machine to stop moving altogether once it reaches a Step that has that action. This resolves the issue of marching off into places it shouldn't go, and it resolves the issue of the graph just becoming a mess.

However, it's not quite as simple as *just* implemented a no-march command. There also has to be special logic in the game's display code, explicitly telling the player they've reached a stub. This is something final players would never see, but for me as a developer it's good to know exactly where the stubs are, so I can either expand past them, or remove them.

And there has to be special logic in the graph view that clearly marks where stubs are, so I know exactly what all I have left unfinished, and can go back and finish them. And this presents its own complications, because the graph view has a grouping mechanism to keep the graph from looking even more insane than it is.

So I had to write some logic in the grouping mechanism, to explicitly push any step that ha sa Scene-Stub Action in it into its own unique group, with a special shape and color, so that it doesn't get absorbed into the group it's a part of, and stands out really easily in the graph view.

Once that is done though, the stubbing works really nicely, and it solves the graph mess issue very cleanly.

As I said, its a pretty simple straight-line march. It just has a lot of edge-cases built around it, to make that straight-line march do more complicated things like branching storytelling.

In retrospect, I probably could have designed it better, but the system works as it is, and the whole point of this prototype is to move fast and break things. Going back and redesigning things is not a focus. I already did it once, with the menu system, and that sucked and really slowed things down. Very much a last-ditch effort.

If I had used a robust, professionally-designed and peer-proven game engine, I wouldn't have these issues. Its the tradeoff between making your own engine and using an existing one: you know exactly how the engine works and exactly how to change it, BUT you have no one to help you when your own shortsightedness comes back to bite you in the ass.

Put a pin in that, too. We'll come back to it.

The other big thing I got done with Epilogue is QTEs. I had previously shown the timer mechanism, which is a really simple mechanism that has a special branch action attached to it if the timer hits zero.

This time around, I implemented the classic hold-a-button QTE, and that took some figuring out from a design perspective. As is classical for me, I ended up overthinking it, tossing out my original plans, and going for a much simpler solution.

The solution I ended up with was to implement a new Step type that disables click-through or end-of-dialogue progression, meaning that only Actions can drive progression. I then combined that with special QTE Actions, and a QTE queue mechanism. The QTE Actions fill the queue up, and then the player's input pops things out of that queue. Once the QTE queue is empty, if no other Action specifically redirected flow, then it progresses exactly the same as it would have if that queue weren't there.

Honestly, it's a sickeningly simple solution that I am ashamed took me as long as it did to figure out.

The most complicated part of the QTE system to implement, then, was the ability to place it anywhere on the screen. And I actually already had the code for that, with the Photography system I implemented and showed off many weeks back. So I basically just adapted that. Now it's a simple matter of adding a QTE Action, filling out whatever it wants of you (for example, the QTE-Hold shown here wants a key to be held down, and how long to hold it down), and then clicking on the screen where you want the prompt to be. Pretty slick, really.

And that's really about it as far as work that was done in the past week to report on. I wasn't able to do much on the Life is Strange Minivid as I wait for my Max voice, and I'll be honest when I say I've just been kinda too preoccupied with the stuff regarding my mum's health to figure out the conclusion of Overbreed Episode 1's storyboard - knowing that I wouldn't be able to actually animate any of it for a few weeks kinda muted any particular interest to get the storyboard done.

So, let's talk about the future a bit now.

Things to Explore While I Am Away

So I want to preface this section by saying that all of this is very much subject to change, based on the state of my mum's health and things that I need to help with around the house. I am not on vacation, I am effectively an unpaid stay-in nurse for these weeks I am here. And remember that first pin? Yeah, remember it again. We're still coming back to it later.

With that in mind, my ability to work on lewd things is greatly restricted while I am with my folks, and as such, I will be taking the time to explore other things that I otherwise wouldn't have been able to find the time to. There's three major things I'm eyeballing right now for that. I'll start with the most exciting (to me):

Game Development

You remember that second pin I told you to put down? Well, it's not a secret I've long had interest in game development. If the Futashep VN and Epilogue weren't evidence enough by themselves. And while rolling my own game engine and making prerendered graphics is fun and all, it's never really been my end goal. Proper, fully 3d games has always been the Holy Grail for me.

I don't think it will come as much a surprise to anyone when I say that I am also very much a project-driven person. I need a clear, concrete goal to work as a motivation for me to do things. This is probably most clear in my model work: I can have people banging down the doors for years asking for specific character models, with no interest on my end to ever do them. But the moment I devise a project with those models, then they get slammed into the high-priority queue and get churned out in record time.

A lack of time and a lack of a project have been the two biggest hurdles to my sitting down and learning a proper 3d game engine. A lack of time and a vision of project, similarly, has been what led to what few game-dev efforts I have pursued, such as the aforementioned Futashep VN and Epilogue.

On the last Saturday stream, which was only a few days before I left on Tuesday, we ended up spending a few hours just shooting the shit while the day's efforts rendered out. During that discussion, I brought up how disappointing the Life is Strange remaster is. Particularly, the underwhelming facial animations (which were SUPPOSEDLY redone using True Colors' fantastic mocap technology, but I am unconvinced) and how the remaster completely butchered the original lighting. Observe:

During this discussion, I mused how I would really like to see a proper remaster of the game done. And mused how I would honestly be willing to at least try it myself, given the time and lack of opportunity to do my normal work. Finally, I mused how I would have exactly that time and limited and opportunity for the next few weeks.

From there, I contemplated how it could be an interesting on-stream project, after the Frozen project's principle animation is done and before we move to working the Churn, to blunder around in Unity and experiment with rebuilding a scene from Life is Strange, complete with entirely bespoke animation. Naturally, I asserted on stream, that I would want to implement fully ray-traced lighting, imagining aloud how beautiful the above scene would look with crepiscular rays filtering through the window and being tinted red-pink by the flag, the light bouncing off the hard wood surfaces and bathing the entire room in warm pink light. True Colors gives a hint of what raytraced Life is Strange could look like, and I'd love to see that properly implemented in Life is Strange proper.

And you know what? I stand by that. We've done a few programming streams in the past, and they actually were received far better than I expected. I think people would be interested in expanding the programming streams into full game-dev exploration. I am keeping it in the cards as a potential project - for now.

There is a small caveat, in that I have actually experimented with Unity in the past, to mixed results. I was able to get Elizabeth into Unity, complete with full materials, morphs, and outfit. Was even able to program a little script to make her blink automatically. But I could not, for the life of me, actually get animations to import onto her. I did everything the tutorials and documentation said, but I could not get them to work.

And animations are kind of important for a 3d game, especially one like this.

So, before I commit to any sort of game-dev efforts as an on-stream side-project, I want to take the time to sit down and figure out the fundamentals. Make sure that it's even feasible.

Toward that end, I've already done a little bit of research into Unity and raytracing. I wasn't even sure Unity *could* do raytracing, at least at an indie level. Turns out that, not only can Unity do it, and not only does it actually look pretty good, but it's pretty straightforward to get working in Unity - albeit, it requires a LOT of switches and knobs to be turned to do.

Click to watch video 

And while I was doing that research, I also found myself stumbling into another avenue worth exploration:

Alternate Render Engines

Specifically, I fell into the rabbit-hole of using the Unreal engine for cinematics. Unreal is a very capable engine, and has literally been used for massive Hollywood productions, notably The Mandalorian using it for its CGI. And of course, like Unity, it has very powerful raytracing capabilities.

Click to watch video 

Notably, Unreal also has a built-in animation system, for use in tailoring bespoke cinematic sequences. I don't know how robust it is for animating characters yet, that's something I need to explore. But from the preliminary exploration I have done so far, it seems like Unreal doesn't handle things too differently from Source Filmmaker, in terms of its concepts of shots and what-not.

And with Unreal being an actual game engine, it is much more readily usable for full-scale scene animations - something that programs like Blender, 3dsmax, and Maya are not really built for. Yes, you CAN do scene animations in these programs, but they're not built for it and you have to really cludge your way around to make them work.

Unreal being a game engine means that it's optimized for having many animating objects in the world at once, much like the Source Filmmaker is optimized for that, being built on the Source Engine that powers Half-Life 2, Left 4 Dead, Team Fortress 2, etc, etc.

So, much like I need to do more research on Unity as a viable on-stream project, I also need to do more research on Unreal as a viable upgrade path from animating in Source Filmmaker. All things being equal, I'd much rather use a game engine like Unreal for animating in over Blender, because frankly I find Blender's interface (and not just its user interface, but also the way it works under the hood) to be obscene and unnecessarily obtuse. And with a game engine, I can use my original source files from 3dsmax directly, which is a much more familiar pipeline for me.

I would honestly consider animating in 3dsmax directly, but it just isn't really a viable animation tool, and especially not a viable scene animation tool. And its renderer, while impressive, I honestly find wanting in a lot of ways. Unreal, though... There could be something there.

There is also the possibility of combining these two pursuits: rather than learning Unity for game development and Unreal for cinematic animating, it'd make a lot more sense to use the same engine for both - especially since game development would require a lot of animating anyways, so why not do the game animating in the same tool as the cinematic animating?

This could go either way: while I prefer Unity for programming because it uses C#, which is the language I am most familiar with, I can't deny that the first look at Unreal for cinematic animation is tempting. But maybe Unity has a powerful animation engine, too - I didn't even know Unity could do raytracing after all, until I looked into it. So I could use Unity for both, or Unreal for both. I need to explore both paths more in-depth.

And finally, for something completely different:

Procedural Asset Generation

Specifically, I have been considering a procedural house generation system. I wrote a Tweet thread about it, but the long and short of it is that I don't have many good prefab house models, for building a neighborhood exterior scene with. And I figured that, hey, I could programmatically generate house exteriors - and I could generate the interiors, too!

Having the full house being generated has a lot of applications, such as a way to quickly generate some consistent scene prefabs for use by myself and others in creating indoor environments, as well as the aforementioned ability to generate neighborhoods for narrative purposes.

And I'd like to extend beyond just generating houses, too. Exteriors in general are a proper bitch to build in SFM. They've always been one of my greatest weaknesses. I'd like to explore the ability to procedurally build full exterior scenes, and then import them into SFM for quick, bespoke exterior environments.

So yeah, those are three spaces I think I will be spending a bit of time exploring. Maybe I'll end up finding more to explore as the weeks pass by.

Speaking of those weeks passing by, you remember that first pin I brought up, then brought up again, and am now bringing up a third time? It's finally time to discuss that calendar in the room.

I might be out longer than I expected.

So when I was prepping for heading out to be with my folks, I was planning on two or maybe three weeks. Possibly four, but that was a stretch. It turns out, that may have been an underestimation. A gross one at that.

As I've brought up several times now, my mum had heart surgery. Specifically, a triple bypass. And for those that don't know, a triple bypass requires the sternum being cracked open. That's the vertical bone going down the middle of your chest that your ribcage attaches to. Heart surgery literally requires splitting your ribcage open.

And as you can imagine, that isn't something that you recover from quickly. I didn't know the specifics of this until I visited my mum in hospital on Wednesday. Her ribcage is being held together with wires and bolts, and so far as I know, those will be in her chest for the rest of her life. She has a special pillow that she needs to squeeze tight against her chest whenever she is straining her ribcage, such as lifting herself into or out of bed or a chair, while coughing, or even while just inhaling deeply. This is because all of these activities naturally cause the ribcage to expand - and could possibly cause her ribcage to break apart, or at the very least interrupt the natural process of the split sternum healing and fusing back together into a single bone.

The literature that the hospital provided has the healing process separated into two phases, with the first phase being very adamant about the fact that she is to not put any stress at all on her sternum during its time, to allow it to heal. It also asserts that this phase can last anywhere from six to eight weeks - between twice to three times how long I was expecting to be out.

I won't lie when I say I don't know how long the second phase is reported to last. I didn't read too far ahead into the literature.

I don't know how long my folks expect me to stick around. I don't know if they want me to stay for the entirety of phase 1, or for the full healing procedure, or for even longer. I love my folks, but I'll be honest when I say that I'm not comfortable being away from my work for that long. And I just really can't work while I am with them.

I think it largely depends on how these first few weeks go. If she manages to do well and her recovery goes smoothly, to the point my dad is comfortable with leaving my mum alone while he's at work, then I might be able to get away with the original 2-to-3 week plan. But I might not. And I don't think I will know until that time comes.

So, yeah. I might be out 2 weeks. I might be out 12 weeks. And I won't know until those weeks come to pass.

I will keep you all updated as I learn more.

For now, I will sign off saying that there will not be a Progress Report this Monday. I'll aim for next Monday.

Hopefully the Life is Strange video will be released in the first week of August at least. As with everything else right now, we're playing that by ear.

Until next time, take care everyone.