Happy New Year! 

New years invite reflection. Today, I’ll reflect on dev logs themselves.

More specifically, why do we write them? What are they for? And why do I have writer’s block?

(Note: Chinese Translation of this devlog[www.xiaoheihe.cn] is available! Courtesy of Baojie)

I started my first blog post about 12 years ago. At the time, game dev was still foreign to me, so I lurked on game dev forums quite a bit. I saw mentions of starting a Tigsource dev log, so I started a tigsource. Then I saw mentions for Tumblr, so I started a Tumblr. It wasn’t that I particularly wanted to write a dev blog. It just seemed like the “thing” game developers did. If game developers were jumping off cliffs, I probably would’ve done that too.

Over time, I saw mentions of other platforms: Facebook, Blogger, WordPress. The “meta” of where you should post was always shifting. Long-form posts fell out of favor. Short, frequent updates on Twitter or Instagram came into favor. These days, the long-form dev log meta seems relegated to be Kickstarter – or failing that, Substack or YouTube dev videos.

At the time, after having just moved from Tigsource to Tumblr, I was already tired. Can’t go chasing the latest platform all the time! So, I stuck with tumblr. Not because it was the best platform but because I was already there.

(The first dev log post and fanart. Content-wise, blogs were only a few paragraphs. Much smaller than today’s blogs)

If you browse dev logs, the kinds of content they contain run the full gamut. I’ve identified these as the most common types:

“We’ve finished the 5th dungeon, fixed a bug where the player could clip through walls, and enemy 73 has also been completed 🙌”

This is the quintessential form of a dev blog update – it reports progress.

Perhaps they’re a bit dry. And I question the effectiveness of this type of content. After release, it’s a different story. But before release, and lacking additional context, what useful information is really imparted to the reader? Are there 100 enemies? Does finishing enemy 73 mean that the game is 73% complete? (if only)

(We recently discovered glowing particles… That about covers it for the developmental update part of this blog post)

Technical documentation of varying levels of accessibility. I posit the common motivation behind these posts is that the developer achieved a hard-earned victory – especially over something that seemed easy beforehand. Writing about it is how they process that experience.

For example, when I wrote about the frog boss long ago and its collision setup, I was genuinely surprised to discover I needed twelve separate colliders to support everything I wanted the frog to do. That clash with my own expectations made it feel worth talking about.

(Twelve colliders. Five to deliver pain. Four to receive it. Three for platforming. And one frog to bind them all)

As I gain more experience, I find there are fewer of these surprising game dev moments to write about. The things that stump me now tend to be far less interesting (like managing memory or draw calls). They’re not worth discussing in a dev log.

So, perhaps the new meta for technical dev logging is a “how it’s made” video short. They’re positioned like trivia : quick, fun to watch, and appreciable by anyone.

(obligatory game trivia pic – the bushes are clouds in Mario Bros!)

The apology update is for when something bad occurs. Say the game is delayed – or worse, outright cancelled. Or say the dev has gone silent for too long. On Kickstarter, where money has changed hands and the obligation is greatest, these updates are mandatory.

I’d hate to have to make this kind of update. 

I’ve given much thought to launching a kickstarter in the past – not for lack of funds, but rather because it was the best dev logging platform for written posts. But I didn’t trust myself to be able to update regularly.

Interestingly, I feel that’s part of the reason why I DO update regularly now – it’s the canary in the coal mine that reminds me my ambition still lives.

(Blythe doing a Balasana Yoga pose. Not to be confused with a Dogeza motion)

Traveling sneaks its way into game dev logs too.

Often because the travel is gaming related – for example, attending a gaming convention to show off the game. Other times, travel is simply a vacation. With how much time and energy traveling takes up, it’s only natural it ends up in the dev log.

Lastly, some devs travel to collect references (“the game is set in Spain, so we went to Spain“, etc). This is the kind of travel I’d like to do. Unfortunately, technology has not advanced enough for me to visit a space whale.

Marketing updates inform about the game and build excitement.

“In Zelda, you’ll slay the Gleeok Dragon and build flying machines! The power is yours!”

Interestingly, I’ve been trying to avoid this kind of update. To hype the game too early feels counterproductive. It’s like wafting the smell of a delicious steak in front of someone… and then telling them they can’t eat it. It makes more sense to hype when that excitement can be acted upon – nearer to release.

The other reason I find marketing and building hype tricky is because I want to avoid spoilers. You know how in Zelda: Tears of the Kingdom, Nintendo hid the entire *********** from all the promo materials? That was awesome!

There’s a delicate balance to hit – you want to reveal just enough so that the player is intrigued – but not so much so that the player is robbed from the joy of discovery. And you have to time it all just right – when hype and action can intersect… It’s tough!

Therein lies my conundrum.

The topics to cover in a dev log are surprisingly few. Development updates are dry and unuseful without context. I haven’t traveled anywhere recently nor plan to. And hyping readers is unproductive when the game still has a ways to go. Plus, we want to avoid spoilers.

So… what can I write about?

I think I’ve come to a realization. The true purpose of a dev log is to communicate that the game is healthily continuing along. This communication can be direct or indirect.

We know what it generally means when a kickstarter stops updating. But so long as there is continuing communication, the game lives.

Maintaining communication itself achieves this. So, maybe the content contained therein could be more wide-reaching & not focused exclusively on Star Iliad?

Viewed through this lens, I’d have a wealth of things to talk about. Who wants to hear my thoughts on other video games? Maybe my new year resolutions for 2026? Food?

(I got this ramen from Costco and it was pretty good! Also, Star Iliad is healthily chugging along)

I’m curious what dev log topics tend to resonate with readers. Suggestions are welcome.

Next dev log is in 2 months – at the end of March. Til then!

Spot the difference in this picture of two enemies at the moment of their demise. On the left, an enemy in Phoenotopia. On the right, an enemy in Star Iliad.

Notice anything? The one on the right sports a “hit glow” FX.

Note: Chinese Translation of this dev log[www.xiaoheihe.cn] is available! (Courtesy of Baojie)

Phoenotopia surprisingly never had hit glow – something that is pretty much standard for most enemy hit FX in other games. Other tricks Phoenotopia would employ were to shake an enemy on impact (ok, that one is pretty standard), and to shrink an enemy before disappearing it in a puff of smoke.

The common factor behind using those hit effects was that those techniques were free and easy – they didn’t require installing any additional assets or programming any extra shaders. And they looked “good enough.”

During Phoenotopia’s development, technology was kept frozen. Once a solution was found and deemed “good enough“, we left it alone. We were more focused on the sheer size of the content. Keeping a feeler out for new technology felt more like distraction.

And to our credit – we made a game. AND we dodged this Unity BUG[unity.com] that targeted the more modern Unity versions. (Keeping your technology frozen rocks!!)

Still, I did feel a little insecure that our bag of tricks was feeling pretty dated. With Star Iliad, we would once again raise our sails for “New Technology”. For today’s blog post, I’ll chronicle a few of our technological expeditions and their results.

I wanted a heat distortion effect to convey that a place is HOT. Nintendo had heat waves in Super Metroid’s Norfair 30 years ago on the SNES!

I wanted a similar effect so I’ve researched a variety of solutions. There’s never a straight path with these things – you’ll find there are dozens of tutorials online – some better than others – a discerning eye is needed to find the hidden pros and cons to truly know which one best fits your project.

In the end, we did achieve heat distortions, but with the caveat that you must target the screen entirely or in large swaths. For example, we can target the lower-half of the screen, which looks great when it aligns with a lava pool. However, as soon as you start climbing, the effect breaks.

Looking at the Super Metroid effect again, I see that their heat distortions target the background parallax only 🤔

So, maybe we won’t use heat distortions for the Lava area afterall ¯_(ツ)_/¯

Luckily, with a bit of tweaking, heat distortions look like watery distortions. And we do plan to have fully submerged aquatic areas that would benefit from watery distortions.

Expedition Result: Half-Success ✅❌

I wanted these Distortion Waves for more satisfying explosions and shockwaves. This has been used in a lot of games, but the trailer for “Momodora: Moonlit Farewell” was the one that galvanized me to finally try for it – a result of the time being right and perhaps because the game sports a somewhat similar art style. Once the game launched, I recorded some gameplay footage for study.

(Yeah, I pretty much do this for every game I play)

Their distortion waves imbue each swing with power!! Notice how only one circular distortion wave at a time seems to be supported? If you ring the bell multiple times quickly, the new wave causes the old wave to disappear.

I believe that kind of behavior is for performance considerations. As it turns out, Star Iliad’s expedition for distortion waves yielded similar results and with the same limitations (albeit we made it support 2 circular waves at a time).

Expedition Result: Success ✅✅

The winding caverns of Star Iliad make it so that enemies that are able to fly or climb should be able to continue their pursuit of the player beyond their patrol zones. To that end, we researched pathfinding for enemies.

Luckily, the literature for pathfinding is pretty settled – use A* search (mostly). There is still work to do in integrating it into the project. For example, you need to think about the granularity of the travel nodes, how enemies can get updated information as new paths open up, or whether enemies are allowed to share knowledge of the map or whether they all have their own model.

(They’re not locked in there with you – you’re locked in there with them!)

Expedition Result: Success ✅✅

This one began when a teammate reported that the game was running pretty slowly – which kicked off a performance investigation. Normally we’d save optimizations for later, but this slowdown was hitting us now.

My research led me to hone in on the number of draw calls. All the lights and graphical effects on screen were exacting their toll on our teammate’s machine.

A draw call is basically the game telling your graphics card:

“Hey, please draw this thing on the screen.”

But each request has some CPU overhead. So the more objects you see – enemies, trees, particles, lights – the more little requests the system has to prepare. Too many, and the game slows down. However, if the graphics are set up a certain way, Unity can batch them together into one bigger draw request. Fewer requests means faster performance!

Our expedition however, sent me down a misleading path where I was told that “Material Property Blocks” would solve all our draw-call issues. And long story short… they didn’t.

Later, the teammate needed to buy a new computer anyway for other reasons – and as we were not able to test it further on her old machine, the expedition was suspended.

Expedition Result: Failure ❌❌

As you can see, not all expeditions result in success – some fail and they take a good chunk of your time with it too. But it’s not the case that if an expedition fails, we give up forever more. We’ll reduce the draw calls yet 😤

Hopefully you enjoyed that little peek into the different technological expeditions undertaken. There’s a lot more expeditions of varying sizes yet to be touched upon (maybe a part 2 next year?)

Most expeditions are things under the hood : like updating tile maps to modern standards, better menus, sensible cutscene flow, efficient asset management across packages, etc. These quiet unsung workhorses ensure a smoother, more reliable experience for players. They’re not as shiny as an enemy hit glow effect but they’re arguably the most important ones.

Thanks for reading! Amazing to think the year’s almost over. The next update will be in 2 months at the end of January next year.

Til then, have a Merry Christmas and a Happy New Year!!