Hello everyone, Duhop here.

This month, I have an update on the release timeline for Alex’s Journey to the Grave in addition to the usual development anecdote.

The the new timeline, though, is essentially just this; it’ll be finished when it’s finished, and it’ll be finished in 2026.

It’s true that following the passing of our team member, motivation to finish the game has never been higher. However, that same intense emotion doesn’t only affect motivation—it’s also a constant reminder that we have to make incredibly sure to do things right.

For me personally, as the game’s sole writer and director, that means an itching need to take things slow, and overthink everything. And the worst part is, it’s not even irrational. Because how could anyone let themselves half-ass something dedicated to their friend in the afterlife?

As it seems to be with most creators, I’ve never truly been 100% confident in the quality of my work. “Is this really any good?” has been a question constantly ringing in the back of my mind since I began this endeavor, and now, it’s impossible to ignore. It feels like all I can do going forward is make sure we take the time to do our best.

All that is to say; after the delay and rethinking this tragedy caused, it’s no longer an option for us to rush the game to completion before the end of 2025. Our new simple hard goal is a release in 2026, which should give us far more time than we need.

The scope isn’t changing, the story isn’t being rewritten. And of course, an internal timeline with goals and deadlines still exists, because no project like this gets completed otherwise. But it’s flexible, as I’ve learned time and again it needs to be, and each piece of the game will receive all the time in the oven it needs.

I’m also excited to continue keeping you all updated with these devlogs. I think in addition to showing our progress on the game, this has already become a great way for me to share some of the thought process and emotions behind it.

Now, moving on to your regularly scheduled devlog content.

Learn Big by Doing Small

In game dev, it’s never quite possible to do everything right the first time around. No matter how much you think you know about a task beforehand, actually doing it will force you to learn so many more details than you ever even considered. Even if you start on a much smaller scale.

This month, I want to talk about one such process that changed dramatically after our first game, and how bringing forth an old character sprite gave us a stark reminder of that fact. It’s just another reason that I’m so, so grateful we took on and completed at least one small project before beginning our more ambitious work, and I want to share that lesson with everyone I can.

For our first game, Alex’s Hope & Alex’s Solitude, we used a much simpler system for sprites and their expressions than what we use now. Every single possible expression and pose combination for each sprite was an entirely separate, full body sprite image:

This is the easiest and simplest way to set up sprites in Ren’Py, but as you can probably imagine, it’s also by far the most inefficient. Both on filesize, as well as time spent exporting images.

Did I know about layeredimages—the far more efficient way to do this—at the time? Yeah, actually. I just chose not to use them because I hadn’t learned how yet, and the efficiency wasn’t really a problem for the smaller game. Of course, I know now that it probably would have taken me like 15 minutes to learn, and the smaller filesize would have actually been nice, but thankfully it did make me realize that I needed to learn and implement them into AJG from the start.

But was that the only thing we did wrong? Of course not!

I usually sing Paintedtrash’s praises in these devlogs, and rightfully so, because her art is absolutely amazing. However, it was both of our first times working on a visual novel back then, so…

Every single sprite image was exported at the wrong resolution, and extremely off-center.

That meant that even after all the time she spent exporting them, I had to manually resize and painstakingly reposition every single one to the exact right position on the canvas before exporting them a second time.

Here’s the kicker; if I so much as dared to close Photoshop between export sessions, the new exports would magically end up a very noticeable 1-2 pixels off from the old ones, even at the exact same size and coordinates. To complicate things further, sometimes it was actually Paintedtrash’s original exports that were a few pixels off and not mine, so false positives and negatives on the cause of each case were flying around all over the place.

In the end, we had to re-export every single sprite image for each character multiple times. Like, 4-5 times total. It was a mess.

The main lesson I learned from that debacle was to be incredibly precise and specific when providing technical instructions for exporting images, lest you create a whole lot more work for everyone. Putting that into practice, my re-exporting duties since then have been reduced to nothing but simple resizing when multiple resolutions are needed.

But of course, that still isn’t all we do differently with our sprites these days.

Jenna is the one and only character from AH&AS making a return in AJG with some of the same sprite art, and bringing her old sprite forward into the new game has been a massive headache for Paintedtrash. A headache that clearly demonstrates just how much her process has evolved since she first drew it, and therefore is perfect to share with you all here :)

In the original project files for our first game, the layers and organization looked about like this:

Putting aside the obvious lack of proper nomenclature here, a layer count above the high thirties might actually seem like more than enough at first glance. However, many of those layers contained multiple elements that needed to be separated to allow for changes to expressions, poses, and clothing, and they were all sat unorganized in just a couple of folders that made the export process hell.

Of course, Paintedtrash now knows exactly how the layers and folders for a sprite need to be separated and organized ahead of time. Doing so from the start saves her massively on busywork, and makes any future revisions or additions so much easier to work on and export.

But because Jenna’s old sprite was made before she had such wisdom, bringing it up to date meant having to sift through and address every single layer in the project file. In the process, she painstakingly cut and pasted every mis-combined element of the lineart and color into new layers, renamed everything, and reorganized it all into dozens of beautiful folders like this:

In short, the experience of working on AH&AS taught her how to plan ahead and organize project files for our sprites to an incredible degree of efficiency—and, critically—before we ended up bogged down by it while working on AJG. My own shift to using layeredimages compounded that efficiency, with our current file system for sprites refined down to a science:

Wielding the combined power of layers, organization, and easy implementation, it’s now far less time consuming for us to re-export individual pieces if we need to make changes, far easier for us to make new additions, and we now have exponentially more options for combining different layers to create unique expressions without adding filesize. And on the topic of filesize, this is down to just 4MB total from 14MB for all the expressions and poses of a similar sprite in AH&AS, which is especially good considering the sprites in AJG have nearly twice the resolution.

Systems like this need experience and iteration to get right, and without our experience creating AH&AS, that would have all had to happen within the confines of our work on AJG. Either we would’ve ended up with something inferior, or we would’ve had to burn a whole lot of rubber spinning our tires and redoing our work to end up with what we have now—a process that on a project this size, repeated through all we ended up learning from it, probably would have taken a whole lot longer than it did for us to finish AH&AS in the first place.

In summary, always start small with game dev. Learn big by completing every part of the process on the small scale, and only then let the work itself go bigger. In addition to potentially massive increases in efficiency like our examples here, many tasks you might consider trivial at first—like publishing your game on Steam, which is a universal learning experience regardless of scale—can reveal themselves as far more important than you might think to learn properly ahead of a larger project. I can’t possibly stress enough how important it is to see at least one small project all the way to the end before you go bigger.

Personally, if I could go back and do it all again, I would’ve worked smaller for even longer. We went straight from small to big with Alex’s Journey to the Grave, and that meant skipping over medium. I would’ve liked to have the experience with longer-term skills from medium!

On that note, thank you so much for reading to the end, and thank you so, so much for continuing to support Violet Horizons.

Until next month,

-Duhop