lordaardvarksfm
patreon
Progress Report - May 15, 2023
🕑 Added 2023-05-16 10:15:37 +0000 UTCHello, everyone!
Let's get straight into it!
Claire/Jill
This past week, I've been hyperfocused on getting the Claire/Jill video done and ready for its final render. I stated last week I was hoping to get the final render started on May 15, which by Job, is today. Did I make it?
Well, sort of. More accurately, "no but with an asterisk."
I managed to get all of the expression & gesticulation pass done (and I gotta admit it looks really snazzy with the characters' heads and faces moving as they talk), as well as the lighting pass. But the lighting pass gave me a little hitch.
Turns out, I apparently just... stopped flickering the firelights partway through the project. Which means I had to go and add flicker to the rest of the scene. In itself, not a problem - I literally wrote a tool to not only flicker lights, but to keep the flickering consistent with shots that already have it.
The problem is that Source Filmmaker can't play back in realtime with final lighting. Meaning, I don't know if the lights flicker too bright or too dim. I can step through the frames one by one and check, giving it about 10 seconds for the lights to finalize on each frame. But that obviously isn't very viable for checking a 22-minute project.
So, I elected to get a mid-quality test render going, so I can check the lighting and make sure there's nothing wonky. That's the asterisk. It's not the final render, but it is a render.
My projections estimated this test render would take about 36 hours. I started it about 24 hours ago, and 12 hours seems like it's about right for getting the last of it done. By this time tomorrow, I should have the test render done and any lighting errors found and fixed.
I've been having the render split between my work machine and my render machine overnight, but during the day I've had my render machine doing all the rendering to free up my work machine.
With the work machine free, I've managed to start and finish the entire camera choreography pass (I wasn't kidding when I said that would go fast!) And I'll never stop being impressed by just how much better a little bit of camera animation can make a video look.
For those keeping score at home, that only leaves two passes: the model pass, and the jigglebake pass. The model pass should go quickly, the only thing I really need to fix is some wonky rigging on Claire's neck and some minor outfit clipping. I also need to add an "unzipped pants" bodygroup to Jill's outfit, for the final scene. That'll take the most effort of the model pass.
The jigglebake pass will be mostly straightforward. The only real complication will be fixing hair clipping into faces. It's not too bad but I have noticed it in a few places, so it'll just take time.
I don't expect either pass to take more than a day each, which means that by all accounts, I should be ready to spin up the final render within 48 hours.
I did some napkin math that projected that the final render would take 8 days of nonstop rendering on my main machine. Adding in the render machine reduces that time, but freeing up my main machine so I can work on stuff slows that down a bit.
I don't think I'll really be working on much during the final render, so I suspect that everything is going to wash back out to 8 solid days of rendering. So, assuming I start the render on May 17, add 8 days... that'd put the final render at being done by May 25?
So, at least right now, let's eyeball Friday, May 26 as a release date. Again and as always, I'm not hard pinning that. Don't quote it as gospel truth. But at the same time, I wouldn't be looking at any day before that for the release.
More generally, let's say expect a release somewhere between May 26 and June 1. At this point, I am fairly confident in that window.
We're almost home free, ladies and gentlemen. It's been 18 months in the making, with the on-stream project starting on October 23 2021, the audio getting recorded and installed almost exactly one year later on October 8 2022, and the project dipping in and out of off-stream production over the 7 months between then and now.
Honestly, all things considered, 18 months for a 22-minute video that was wholly blocked out in once-weekly streams is an insanely fast turnaround. It's nothing like the 6-week-ish production time of Primordium's 7-minute video, but Primordium went suspiciously flawlessly whereas Claire/Jill has been rife with production troubles since more or less its inception.
Never forget Claire/Jill was originally supposed to be a 2-to-3 minute video. Not a 22-minute video.
Life is Strange Epilogue
In addition to the bulk focus on Claire/Jill, I've been spending my evenings hammering away at the Epilogue visual novel, both in terms of development and in writing. And I really can't overstate how pleased I am with its progress.
To start things off, recall how I mentioned in last week's Progress Report that a major problem the Futashep visual novel had was that it was entirely graph-based and was just ugly to navigate?
Well, the very next day after making that post, I went and implemented a graph view for the Epilogue visual novel!
However, it is important to note that it's a bit of a false equivalence. Futashep's problem wasn't that it had a graph - it was that it was built using the graph. Recall how Epilogue is being built explicitly with a "the game is the editor" philosophy.
As such, Epilogue isn't built with the graph. In Futashep, the graph was the game. In Epilogue, the graph represents the game. It's a small but very important difference.
More specifically, the graph itself has no control over the game. It doesn't control what goes where. All of that is done through the game's state machine. The graph only visually shows the elements, and its primary purpose is to give me a way to quickly jump around while editing.
It is worth noting that a fair amount of development time went into the grouping logic of the graph. If I zoom in on a section of this graph, you'll notice that this big blocks are actually multiple steps all condensed together:
These groups can be expanded and collapsed arbitrarily. Here is that same section, with clusters 16, 20, and 22 fully expanded out.
Yeah. I think you can quickly see why I implemented the clustering mechanism. Using the graph view was... rough... between the time it was first implemented and clustering was added.
With the graph mechanism implemented though, working through these scenes has been a breeze, with it allowing me to quickly jump through and fix up any errors or missing branches. It's been a Godsend.
I was able to finish off the opening sequence, and implement scene-shifting. It went about as easy as I hoped it would, since I wrote the system from the ground up with the intent of separating the story into scenes and jumping between them.
Which is great, because the first graph shared is the graph for the opening sequence, of which you all have only seen about half of so far. This is, uhh, the graph for the second scene. Which still isn't finished yet.
Now, the astute among you may have noticed there's a few new colors in this graph. Indeed, I have a very particular color (and shape) convention in this graph. Light-blue is just an ordinary node (or cluster), green is an autoplay cycle, and purple is a small decision.
But this graph adds orange and pink nodes as well. What are those? Well, that gets to what I think is the most exciting part of this past week's progress of all for me!
I have accidentally added gameplay to this visual novel!
Yes, you read that right. I accidentally added gameplay. As in, it was not intended. It just happened spontaneously.
While I was writing out the gas-station scene, again adapting from my notes I wrote down back when Epilogue was intended to be a film, I spontaneously decided that I should implemented a hot-spot system. Life is Strange was notorious for its hot-spot system, which is the mechanism by which you can explore the world and get Max's thoughts on various things. Think her looking at her camera, or the posters on the wall, or at people milling in the background.
And so, I implemented that:
I'm really pleased with how it works functionally, as well as how simple it was to implement mechanically and utilize in the editor.
You may notice that the interactable objects have thick chalky outlines to show them as being interactable. I'm especially proud of that system, and it is exploiting how Javascript's Canvas2D rendering system operates.
To keep things really simple, this is achieved by having the background image as normal, and then a bunch of transparent cut-outs of the interactable objects as separate images, each with the chalky outline behind it.
This transparent images are also what I use to determine when the cursor is over a hot-spot object. Rather than having them be hard-coded zones, which is how most games (including Life is Strange itself!) does it, I instead use the "outlined" images themselves to determine the zone.
When the game is in "hotspot mode", whenever the cursor moves, it will quietly draw all of the hotspot images on a transparent background, and check the pixel data under the cursor. If the pixel is transparent, it means the cursor isn't over that hotspot. If the pixel has any actual color data, then it means it is - and so, that hotspot is the one that's marked as selected, for all the logic processing. All of this drawing is done in such a way that it never actually makes it to screen, so the player is none the wiser.
It's a hilariously crude solution, but it also works disgustingly well. I am extremely proud of that.
The gold steps you see in the above graph are these "hotspot mode" steps. Each hotspot jumps to its own unique branch, as shown in the graph. This allows for the close-up of the object as seen in the GIF, as well as the dialogue. And since it just jumps to unremarkable nodes, it allows for arbitrary complex logic. Such as hotspots leading to other hotspots, or in theory even to entirely different scenes.
You'll notice that, as each hotspot exploration is expended, it returns to the core "hotspot mode" scene. This is all done using a special "return to last hotspot step" action, placed at the end of each branch. This avoids any messy jumps, keeping both the graph and the logic simple, and meaning I don't have to keep track of what hotspot I'm in. It handles all of that for me. Super convenient while creating.
So that's the orange node. But what about that pink node, in the top-right corner of the graph? Oh, well, that one I am especially proud of!
Allow me to introduce you to photograph mode!
Honestly, for a game that rests on photography as a fundamental pillar of both its aesthetic and its literal plot, it kind of baffles me that Life is Strange never had a mechanism where you could actually take your own photos. There were specific interaction zones (or "hot-spots" if you prefer!) where you could play a canned animation and get a preset photograph, but you couldn't actually take the photograph yourself.
It's doubly odd because Life is Strange had all sorts of inane pointless little minigames, but they didn't bother to add one that would have more thematic function than pretty much any of the minigames they did add. Weird missed opportunity.
This one was also entirely unplanned. While I was putting together another set of hotspots, I was looking around for more interaction zones, when my attention rested on Max's camera bag. I know that Max taking photos plays a big part in my plans for the core story of Epilogue, and so I figured I could introduce that early by having her take a repercussion-free photograph of the truck.
And then I decided "why not let the player take the photo"? And so here we are.
As with the hotspot system, this system went together suspiciously easily, and the logic behind it is dirty but effective. There are two systems at play here, the photograph system (moving the reticule around to take a photo, and saving that information for later display), and the polaroid system (actually showing the photograph taken, in another scene).
The photograph system is nothing to write home about. There's a variable storing how big the box should be, mouse-wheel increases and decreases that variable, and it centers around the cursor. When you take a photograph, it stores the position and size of the box, and saves it in a data structure with a step-defined name (in this case, it's "photograph_truck").
The polaroid system though is a bit more clever. At its core, it relies on assuming that the step it's being drawn onto has a transparent hole in it. In this case, the actual polaroid is cut out, showing whatever is behind it.
Polaroids themselves aren't unique steps, like dialogue or hotspot or decision, but instead are special actions that define where in the scene the polaroid is. Adding this action to a step enables a new option in the editor called "Polaroid bounds". Activating that brings up the camera reticule seen here, and you move it to be just slightly bigger than the polaroid cut-out, and click to save those dimensions. You are then prompted for the unique name of the photograph to show (EG "photograph_truck").
When you're actually playing the game is when the magic happens. Once you enter a step with the polaroid action defined, before it draws the main background image, it will first draw the defined photograph, resized and positioned to the polaroid bounds defined in the editor. Then, it draws the background image on top - and since it has a hole cut out, the drawn photograph behind shows through!
It's a dirty, cheap trick, and it doesn't take into account anything fancy like rotation or perspective. But so long as I keep the polaroid close enough to straight-on, it won't be too noticeable. And even if it is, this isn't a final game - it's just a prototype, to get the ideas across for an eventual adaptation into a fully 3D game.
Photographs are stored in player state, meaning each player has their own unique photographs (which makes sense, since you take them yourself), and they save and load with you as you save and load the game across multiple sessions.
One last new system I implemented, which I haven't discussed yet, is the tutorial system. You may have noticed them in the above GIFs, where first you had text along the top saying how to click on items, and then another saying how to take photographs.
These are defined through a "tutorial" action, and they just display arbitrary step-defined text. These are also stored on the player object, so the player only sees the tutorial once.
On a final note, let me just say that the game has quickly ballooned to the point that I can't feasibly show you all every possible path and choice. Even with the river-flow philosophy, there's still a lot of small variations, too many to show. And I haven't even gotten to the planned gameplay mechanisms yet - flow-state, echoes, and contention. Hell, I haven't even added the Big Decisions yet!
From this point forward, I'll only be showing snippets of the game, mostly focusing on the new mechanisms I implement. Hopefully I'll be able to get the first playable demo up sometime in the next few weeks. But there's still a lot of narrative ground to cover, and mechanisms to implement. And that's all just the planned narrative and mechanisms. Again, I'm adapting this from film notes, not game notes, and I am making a lot of things up on the fly, as they feel appropriate to me.
That is, after all, the point of this "the game is the editor" design philosophy. If I am playing the game, and feel like a new story beat or a new mechanism is needed, I can just add it, right then and there. For better or for worse. Mostly for better, though.
I want to end this post with showing off a little minigame that I was able to implement through a clever use of the hotspot system and jumping to create a gameplay cycle. It's nothing novel, but I think it feels rather reminiscent of some of the minigames that Life is Strange proper implemented. Nothing too challenging, and if you pay attention to the dialogue earlier, it's completely trivial. But it was fun to implement regardless:
That's all for now!
Until next week, everyone!
