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 is available! Courtesy of Baojie)

A Quick History

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)

The Types of Content

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

1. Developmental Updates

“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)

2. Technical updates

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!)

3. The Apology Update

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 Balsana Yoga pose. Not to be confused with a Dogeza motion)

4. Traveling Dev Logs

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.

5. The Marketing & Hype-Building Update

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!

The True Goal of a Dev Log

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!