In the last devlog I was calmly talking about the Blacksmith and her forge. One character, one scene, a reasonable plan. Very professional. Very naive.

Because the real target was a playable demo slice for AdventureX, and by May 21 I had to stop endlessly improving things and actually upload a build.

So this time I’ll try to talk mostly about what is inside the demo from the player’s side. And for fellow devs, or anyone who enjoys production pain, I added little Developer’s Cut blocks under the sections.

What’s in the demo

First of all: it’s not the full game. It’s one slice of the village - enough to meet Zoti, rescue the Goose, poke at a couple of puzzles, and talk to one very busy Blacksmith.

• A main menu - so it feels like a real game from the first click
• Zoti’s opening - she wakes up, falls into trouble, and the story begins
• Freeing the Goose - your sidekick is stuck, and you need to help
• The well - a rope puzzle, a bucket, and water to fetch
• The water tower - a separate spot entirely: ladders, height, and rotten planks
• A long talk with the Blacksmith - errands, opinions, and forge noise
• A demo end card - so you know where the slice stops

Main menu

The build no longer drops you straight into a random Unity scene. It starts with a real main menu: background, logo, main characters and the interactive menu - all the fancy things that say “yes, this is supposed to be a game.”

Zoti’s opening and fall

Zoti does not enter the demo gracefully. Obviously.

She wakes up in the village - dead again, unreasonably optimistic as always - and almost immediately falls into trouble. I wanted the first seconds to feel like a proper little scene, not just “camera fades in, now click something.”

Freeing the Goose

Remember the Goose from earlier devlogs? Honk, Pack, Pick, all that extremely serious gameplay design?

In this demo the Goose starts stuck, because apparently even sidekicks need an introduction quest. Before it can help, you need to help it first. Only then do the Goose actions start making sense in the actual flow, not just as funny buttons in a trailer.

The well

The well is the more puzzle-ish part of the slice.

You untangle rope knots, lower the bucket, and finally get water - with the Goose helping once it’s free. I made the first version of this puzzle while working on the announcement trailer, but for the demo it had to stop being a prototype and become an actual story beat.

The water tower

The water tower is its own hotspot: height, rotten planks, and Zoti trying very hard to convince herself that climbing is fine.

The Blacksmith

The Blacksmith from the last devlog became the anchor of the whole slice.

She is not just hammering in the background anymore. She talks, sends you on errands, reacts to your very questionable plans, and generally behaves like the only responsible adult in the area. Which is impressive, considering she’s a zombie.

Her forge is a real place now too: fire, bangs, bucket drops, and plenty of things to poke at.

Green skin, silver ponytail, leather apron - and a lot of opinions about your choices. She is basically running the village’s to-do list, whether Zoti asked for one or not.

Where the demo ends

When the slice is over, it actually ends. Revolutionary, I know.

There is a clear demo end card instead of a sudden drop into unfinished content. Village music carries through, so the whole thing should feel like a small opening chapter rather than a scene that simply ran out of road.

Submitted - and two weeks after

May 21: the build went up for AdventureX. I posted “I made it… 😮‍💨 Now - only hope and patience 🤞” and then mostly stared into space for a while.

Not everything after that felt like relief. Steam quietly removed a batch of wishlists - normal churn, but it still stung. And anyway, a week after that, I finally beat the 100-wishlists milestone, which is HUGE!

Then a small bright spot appeared: the first article about Sly Crow went up on Adventure Game Hotspot. The universe has a sense of balance, I guess.

What’s next (for you)

I’m still aiming for a public demo more people can try - hopefully by autumn. AdventureX feedback will probably decide what catches fire first.

If you want to follow along or support the project early, wishlists still help a lot. Even after Steam eats some of them. =)

Wishlist Sly Crow on Steam

Thank you for being with me, and stay tuned!

I decided to start from the Blacksmith because I had quite a clear vision of the character and environment. Oh, and small side note before we start: wishlists quietly crossed 50 last week. Tiny in Steam terms, I know - but still a nice little milestone. Thank you!

The Blacksmith

It all started from scratch - a few scribbles, a lot of erasing.

I wanted someone strong, powerful, and obviously hammer-for-a-living - broad shoulders, heavy boots, a proper tool belt. And since this is a zombies village, she's a zombie too - just a bit more muscle and a bit less decay than the others.

It looked quite promising, so I proceeded and got the concept version:

Green skin, silver ponytail, leather apron, a red-hot piece of iron in the tongs. I was pretty happy with how she turned out.

The animation detour

And here I ran into some trouble with the animation. This is a fairly minor character, so I didn’t want to spend too much time on its animation. But the pose I originally picked - an almost frontal one - required quite a lot of extra intermediate keyframes with a different layout.

The thing is, using such a viewpoint requires making her hand sometimes behind the body, and at the "smash" point, in front of it. And the visible part of the hammer is changing a lot.

After some experiments, I decided to change the position and use 3/4, to keep her hand always behind the body.

And the trick worked! Of course, a lot more animations and poses are still ahead, but the idle is ready.

The Forge

In parallel with the character, I started blocking out her forge - the scene where the player will actually meet her in the demo.

The first pass was very drafty - almost pure line-art, with the character dropped in just to check scale and composition:

The goal at this stage is not to make it look pretty - it’s to plan items’ placement and leave enough space for character navigation. Boring but necessary stuff - I already learned once that pretty mockups aren’t the same as playable scenes.

A couple of days later, with colors roughed in and the background filled out, it started to feel like a real place:

Step by step, the forge becomes a real scene. Of course, a ton of details are still ahead, but the skeleton is there and it’s navigable.

What’s Next

1. Finish the Blacksmith’s remaining animations - resting, talking, a couple of reactions
2. Polish the forge scene - from coloured sketch to shippable art, plus hotspots and navigation
3. Move on to the next villager - I won’t spoil who, but the write-up has them ready
4. Keep AdventureX in sight - that’s the deadline driving all of this

Thank you for being with me, and stay tuned!

Wishlist Sly Crow on Steam

The announcement trailer is out - complete with gameplay, mood, and plenty of goose nonsense. The sound design finally caught up too: everything got recorded, cut, and stitched together. For the first time, it actually feels like a real version of the game I’ve been carrying around in my head all this time.

Right after that, the Steam store page went live. It’s collecting wishlists now - for real, not in that theoretical “once I finally make the trailer” way. In the first two days, the page got 22 wishlists. In Steam terms, that’s tiny, obviously - but when you’re making this thing mostly on your own, seeing those first numbers appear is a pretty wild feeling. So thank you to everyone who clicked that button early.

Capsule work

While wrestling with the capsule art, I also spent some time with SteamCapsule, and honestly, it was a lifesaver. It gave me a much better sense of what actually works on a Steam page versus what only looks nice in isolation. Promo art is very much its own weird little craft, and I realized pretty quickly that a nice drawing does not automatically make for a clickable capsule.

Huge thanks to the people who made that tool - it feels very indie-friendly, which I deeply appreciate as a person currently trying to learn twenty jobs at once.

Wishlist Sly Crow on Steam

Well, the trailer still isn’t done. But this time I don’t feel guilty about it, because what I’ve built instead is real gameplay.

The Steam Pipe Puzzle

Last devlog I said: "I think it will be a steam train repair puzzle. Pipes and steam!" — and that's exactly what happened. This turned out to be the biggest single feature I've built so far.

The idea is simple: the train's steam engine is broken, and you need to connect the boiler to the consumers by rotating hexagonal pipes on a grid. Think of it as a hexapipes puzzle, but with actual steam flowing through once you get it right.

What started as “just a little puzzle” quickly grew into something much more ambitious. The grid is procedurally generated, so each playthrough gives you a different layout. There are 21 different pipe types — straights, corners of various angles, T-junctions, Y-shapes, crossings, and some exotic ones like “BirdLeg” and “Crab” - don’t ask 😅.

The best part is the steam propagation. Once you connect the paths correctly, steam actually flows from the boilers through the pipes, with animated visual effects — color, speed, trembling. There’s even a barometer on each consumer that fills up as steam reaches it. It feels really satisfying when everything clicks into place and steam starts rushing through. At least for me.

Oh, and the puzzle supports multiple boilers, meaning you might need to route several independent paths simultaneously. That alone bumped the difficulty and replayability up quite a bit. I’m still not sure about final balance of difficulty for the game - playtests should help here.

Inventory Glow-Up

One thing that always bugged me was how items just… appeared in the inventory. No fanfare, no feedback. After years in software development I learned an important thing about any UI - it must be responsive!

So I built a pickup FX system: when Zoti picks up an object, it flies from the world into the inventory slot with a smooth animation. And on top of that, Sly Crow now has item combinations - drag one item onto another to try combining them. If it works, you get a nice VFX and a new item. If it doesn’t — well, you get a different VFX that basically says “nope, try something else.”

Pickup	Combine

Zoti Gets More Alive

Zoti keeps getting better. Remember the emotion overlay system from the last devlog? I extended it further. Now I can layer any emotion on top of any animation from the action list. Sad while walking, surprised while idle, crying while talking — Spine's track system handles it all.

Enter the Goose

Remember the Goose? The sidekick that’s been hanging around since the early devlogs? Well, it finally got promoted from a background decoration to a real, interactive character.

The Goose now has its own Spine skeleton, animation controller, and - most importantly - its own action UI with three commands: Honk, Pack, and Pick. Each one triggers different interactions with the world. Need to distract someone? Honk or Pack. Need to grab a small item? Pick. Objects held by characters follow bone positions properly, so the Goose can actually carry things in its beak.

Building the Goose also pushed me to create a proper NPC system. Characters can now wander (targeted or randomly) around their area, so the world doesn’t feel static when the player isn’t doing anything.

Oh, and I added a Zombie Chicken to the village. Because why not.

Zoti Speaks (for real this time)

This is something I’ve been wondering about for a long time - Sly Crow now has a lip sync system!

To make it work I use Rhubarb Lip Sync to generate phoneme timing data, and custom integration with Spine to switch mouth animations in real time.

It hooks into Adventure Creator's speech system, so setting up a voiced line is as simple as adding speech ID to dialog line. Lip sync data and localization are resolved automatically. It also supports multiple languages - each locale can have its own voice-over files and lip sync data.

After some time of manually adding voice-overs in trailer scene, I got tired - manual part of the pipeline is quite annoying - running Rhubarb on every audio file, naming the output, placing it in the right folder… that got boring fast. So I built an automation tool right inside the Unity editor. Now, when I import a new voice-over file, the lip sync data is generated automatically - Rhubarb runs in the background, the JSON lands in the right place, and the dialogue CSV stays in sync. There’s also a batch mode for processing multiple files at once, which saved me a ton of time when I recorded a bunch of trailer lines in one session.

Hotspot Highlighting

One thing that was really missing from the game was visual feedback for interactive objects. In modern point-and-click adventures, you usually have some way to tell what you can interact with - otherwise the player is just pixel-hunting across the screen.

So I built a hotspot highlighting system. Now the player can easily highlight all interactive items! I tried to make it not obnoxious - just enough to say “hey, you can do something here.”

Trailer Progress

All of this work goes straight into the trailer. All scenes now have finalized assets, the Goose is interacting with the world, JohnyAce is animated in the city scene, and there’s a moody night forest rainy setup.

The trailer isn’t just a cinematic walkthrough anymore - it actually shows gameplay now. Puzzles, inventory, conversations, character interactions… But, it’s not finished yet - the last thing that left is sound design. Background music, ambient sounds, footsteps… A lot of things to do =)

What’s Next

1. Finish sound design - Voice-over system works, but I need to record and process more voice lines and ambient sounds.
2. Record the trailer - all the scenes are getting close to trailer-ready. It’s time to stop building and start capturing
3. Steam page - still the goal. The trailer is the last big blocker

I know I’ve said “this quarter” before. But this time the pieces are actually there. The gameplay exists. The systems work. So soon, I will just need to hit record.

So, the plan was to make multiple scenes showcase, uncovering the world and the main story

And the first thing to prepare was the production-ready view of the main character - Zoti.

Redesigning Zoti

New art style, new animations, new everything. The old design just wasn’t cutting it for what I wanted to show in the trailer.

To make the character feel more alive, I also added an emotions controller, based on Spine animations mixin.

If you’re not familiar with Spine, here’s the simple version.

Imagine you have one animation of Zoti walking, and another one where she just blinks. Typically, if you wanted her to blink while walking, you’d have to create a whole new animation from scratch. Same problem with emotions: walking + angry, walking + sad, walking + surprised… the number of combinations explodes very quickly.

Spine’s mixin system solves this elegantly. It lets you layer animations on top of each other. So the walk cycle drives her body and legs, while blinking or facial expressions play independently on her face. In practice, this means Zoti can walk normally while looking angry, confused, tired, or surprised — without me having to redraw every possible combination.

I like to think of it as animation Lego blocks: small, reusable pieces that snap together in different ways depending on what the scene needs.

As a result, the emotion system became much more flexible. Now Zoti can walk, run, interact with objects, and express emotions simultaneously, dynamically, rather than being baked into dozens of separate animations.

Of course, this wasn’t just Spine work - some coding was required too. But thanks to the spine-unity-runtime, hooking everything up turned out to be surprisingly painless.

The Train

The next big thing was making a train chase scene. It took a very long time to make, but I’m kind of proud of the result. Again, Spine provided a lot of help with it. Physics and transform constraints in such cases are great and easy!

Objects bouncing, wheels rolling, and even the visible part of the engine are implemented using those constraints, not just bone transformations. Technically, the engine really rolls the wheels!

The Detour

Then I got… distracted. It all started from the problem of “sticker” effect in the village scene - I made all buildings, but they looked like they were floating over the background. Manual adjustments to the shadows improved things a bit, but buildings were still not fully integrated into the scene. And the main advice I found is to hide the lower edges of the buildings behind the grass/ground.

And from an art point of view, it looked like a real challenge - drawing so much grass manually is very time-consuming.

At this point, I remembered that I am a programmer in the first place, so I thought, “Why not automate this process?”

So, I made a script that allows me to create a path and automatically place a random grass sprite from an atlas. To keep control over the result, grass is generated in the editor, not at runtime, so I can still edit/remove each sprite separately for artistic purposes. And it saves some resources in runtime.

“That’s cool,” I thought, and immediately reused the same script with another atlas to generate background trees for the village!

So far, everything has gone well - this script looks really useful, because it allows covering any edge with any kind of stuff. And the process of working on it was also so satisfying, since most of the time I did what I know best - programming.

All of this led me to the detour mistake. Somehow I came up with the idea that it will be the same or even more helpful to make… a road generator 🤯

Yes, you read it right - procedural road generator for a 2D game with pseudo-perspective support. Really, now I don’t have a clue how that happened, but I spent a couple of days working on it, and even got some results. And to be honest, I might spent much more time on that, but luckily I received a wake-up call relatively fast.

The Wake-Up Call

I already mentioned that I’m listening to and watching podcasts and other useful content on YouTube quite often. And I was fortunate to stumble upon a video from Chris Zukowski accidentally: How to NOT screw up your indie game launch. 30 mistakes in 30 minutes.

All the advice in this video is super helpful. But for me, the groundbreaking one was about trailers: “Indie game trailers should show gameplay, gameplay, and gameplay.” Not just cutscenes or pretty environments - an actual vertical slice of what playing the game feels like.

This was like a cold shower - what am I even doing? Spending dozens of hours on the road generator to skip 2-3 hours of drawing static roads? Crazy…

And this also affected the whole plan of the trailer. At the moment, all I had was kind of a cinematic walk through the scenes, and this is not actually what I want.

Real Gameplay

After a short revision, I figured out how to show gameplay alongside the world reveal. Still, I realized that one of the significant parts of the gameplay is completely missing from the trailer: puzzles. In Sly Crow, the player will not only have inventory and conversations. There will be plenty of puzzles to solve along the way. And none of them are presented in my trailer plan.

So, the next couple of days I spent designing and implementing the first real puzzle: the player needs to untie the rope at the well to use the bucket.

And again, most of the work was done in Spine: each knot and rope has its own animation, and the puzzle’s state is reflected in the way those animations mix.

Where We Are Now and what’s next

There is still plenty of work to finish all the desired scenes, including gameplay inside them. Currently, I’m working on NPCs and UI:

UI

NPCs

And here’s what I’m tackling next:

1. Update the UI - I don’t want to go into the trailer with the default Adventure Creator’s UI
2. Introduce more gameplay - each scene (excluding short cinematic placements) will have a part of actual game actions
3. Add one more puzzle - I think it will be a steam train repair puzzle. Pipes and steam!
4. Actually finish the damn trailer - No more “just one more cool system” detours.

The Steam page is still the goal. Not “someday” - this quarter. I need that page live so I can start collecting wishlists and getting honest feedback from potential players.

At the same time, I fell into a YouTube rabbit hole of dev podcasts and marketing guides. And that’s when it hit me: I’m seriously lagging behind with marketing.

The biggest missing piece? A Steam page.

To make one properly, though, I need more than just a description and a logo. I need screenshots that actually tell a story — and, of course, a trailer.

So, I decided to start building it.
After exploring the differences between announcement, gameplay, release, and cinematic trailers, I realized that the best fit for me right now is an announcement trailer - something that says: “Hey, this world exists!”

A good trailer (except for fully cinematic ones) should be a kind of vertical slice - a tiny, playable-looking window into the world. In my case, the announcement trailer’s goal is to make players feel what the game will be about - not just see it.

Vertical slice

Here’s the rough outline of my vertical slice so far:

• The hook, revealing the story setup.
• World atmosphere, showing parts of different scenes.
• A few emotional moments (mainly between Zoti and the Goose).
• A visit to the antagonist’s lair.
• And finally, a mysterious ending that leaves questions hanging.

Trailer Look

Having a close-to-final look at the trailer is preferable. To make it work, I started by updating Father’s design and refining the Farm Field scene — that’s where the hook happens. The animation is still a bit rough, but it already gives shape to the trailer’s opening moments.

As the next step, I drew a rough storyboard for the next parts of the trailer. So, now it has started to transform from a fuzzy dream into a real problem that seems solvable in a sensible amount of time.

And there’s a good reason to push it forward

At the end of November, I’ll be at the AdventureX Conference in London (just attending, not exhibiting - this time!). My goal is to have the Steam page ready by then, so I can show the trailer, share the page, and collect real feedback from people who love this kind of games and are more experienced in making ones.

It looked lovely. It felt right…

It was completely wrong.

At least from a level design perspective.

After finishing that pretty layout, I finally put Zoti inside it. And I instantly realized that it was not playable =( Walking across the scene was just too long (35 seconds). The distances and pacing did not make sense once I viewed it through a player’s eyes instead of an artist’s.

I had drawn the detailed version before understanding the functional one.

That’s the mistake.

So, to not fall into the same trap twice, I went back to the design basics instead of immediately redrawing everything:

• Experimented with how long it takes to cross the screen at normal speed until a sensible time was found
• Drew new bounding boxes to see how puzzle sequences might flow
• Tested ideas right on the sketch

Basically, I stopped treating scenes as paintings — and started treating them as playable spaces. Once I rebuilt the village using those principles, everything felt tighter, more purposeful.

Small, but critical outcome and reminder for myself

Don’t get seduced by pretty mockups.

Draw faster, test earlier, and let playability lead the art - not the other way around.

🎥 The video version of this devlog: The Dumbest Level Design Mistake I Made (and What I Learned)

And as soon as that puzzle piece fell into place, another one followed: the sidekick design. This was a huge relief because I’d been stuck on it for a while. Having the art style locked in made it so much easier to imagine how the sidekick should look and behave. I won’t spoil too much yet, but let’s just say — the goose has landed.

I also started sketching out the second scene: Zombie Village. The Blacksmith’s house is done, the Carpenter’s house is also in place, and now I’m scratching my head over who should be the third villager. The world needs to feel lived-in (or, well… half-lived-in), so having the right mix of characters really matters. Got any fun ideas for who else should live there? Drop me a comment — I’m curious what kind of weird villagers people would expect to meet in a zombie village.

Oh, and I’m toying with the idea of making a YouTube video where I show how I’m designing levels that actually tie into the narrative, not just generic “catch-22 room”. I think it could be fun to share the process — plus, it forces me to explain my own logic out loud, which usually makes me spot things I’d miss otherwise.

Quick side note: social media is brutal. Growth feels glacial, and it’s way too easy to get discouraged when you see big accounts everywhere. But hey, I’m still here, still posting, and not planning to give up anytime soon. If anything, slow progress is still progress, and that’s the indie dev way, right?

So here it is - my very first gameplay demo. Drafty, raw, a bit broken… but alive. And honestly, that’s what matters most right now.

Mini-game is unbalanced, has no frame, and has an annoying bug: the rope with a magnet sometimes gets stuck on an invisible collider… I’m guessing it’s bumping into the player’s or hole’s bounding box instead of ignoring them.

The UI is straight out of Adventure Creator’s default template. Definitely not how it will look, but for now I’m keeping it as-is until I know exactly what I need.

But here’s the cool part: bugs aside, the whole first scene in Zoti’s house is actually playable! That moment when you can click around, see things moving, and it feels like a game - that’s pure magic.

I’ll share more about this first scene and the mini-game soon. For now… it’s undead 🧟‍♀️✨

If you’re into 3D, there’s a whole universe of modeling software, shaders, physics engines, giant stores full of ready-made assets. If you’re sticking to 2D, like me, that’s a different rabbit hole: pixel art editors, painting apps, animation software, each with its own fanbase and “this is the right way” crowd. Everywhere you look there are pros/cons lists, YouTube tutorials, and long threads arguing why Tool A is better than Tool B. It’s great that so much exists… but honestly, it can paralyze you. You spend more time watching other people explain tools than actually using them.

At some point I realized the best choice is usually the one that takes the least effort to just start. The tool that doesn’t fight you, that lets you get something on the screen fast — that’s the winner.

A bit of context: I’ve been coding for almost 25 years now (yep, I’m that old). I’ve touched a dozen languages, done my fair share of story writing, given talks that were basically live storytelling, and for the last five years (with breaks) I’ve been into drawing. Put all that in a blender, and you get a weird mix that shaped how I chose my GameDev tools.

Development

Since coding isn’t really a blocker for me, I didn’t have to stress about language limitations or whether I could handle the tech. That part’s covered. So instead of worrying about syntax or frameworks, I could just look around and see what engines were out there. The main thing I cared about was: does it run basically everywhere?

Well, not literally everywhere. My real target was PC — that’s where I see the game living first. Maybe later I’ll branch out to tablets if it makes sense. What I really wanted was an engine that makes publishing to Steam and other popular stores as painless as possible. That trimmed the list down pretty quickly, and in the end it really came down to just two giants: Unreal Engine and Unity.

After a bit of googling around, Unity started to look way more 2D-friendly than Unreal — and since that’s exactly what I needed, it felt like the obvious deal for me.

Framework

I started by checking out Unity’s 2D plugins, trying to figure out what people usually use for adventure-style games. That search eventually led me to Adventure Creator. And honestly, the thing that convinced me right away wasn’t even the feature list — it was the showcase of games already made with it. Sally Face, Boxville, Kathy Rain - impressive set!

Adventure Creator

Once I dug into the details, it wasn’t just the finished games that impressed me — the actual feature set looked like it was built exactly for someone like me.

Technically, it gave me all the boring-but-necessary parts out of the box. NPCs, inventory, navigation, dialogues, and even visual flows. That means I can spend my time on the fun stuff — story, puzzles, and weird jokes.

And honestly, Adventure Creator deserves a full article of its own, which I’ll definitely write later.

Art

My art journey was kind of a zigzag. Started with pencils and liners, dabbled in watercolor, then jumped into digital with a Wacom + Krita. Wacom was awesome… but also super static. You’re stuck at your desk, and I’m more of a “draw wherever” type. Eventually, I ended up on the iPad with Procreate, and that changed everything.

Procreate

Procreate felt like a no-brainer. One-time and very affordable payment (bless), no subscription nonsense. And it makes full use of Apple Pencil’s tricks — pressure, tilt, all that jazz. Basically, it turned my iPad into a sketchbook I can pull out on the couch, in a cafe, or on a train. And I definitely use this ultimate ability all the time now.

The only weak point compared to my old Wacom was the “paper” feeling of the surface — Wacom just nailed that texture. Luckily, that’s something you can fix on iPad with a Paperlike screen, so problem solved.

Animation

Assuming I’m using Procreate, the first thing I tried was Procreate Dreams. And it’s as cool as Procreate itself, but frame-by-frame animation for gamedev? Way too much work for a one-person indie game. Also, the animation asset sizes balloon like crazy. Not great either.

Back in the day, I played around with skeleton animation in Moho (then known as Anime Studio). However, I wanted to keep the hand-drawn vibe, and vector graphics just felt too clean and sharp for that. So I went digging for tools that handle 2D raster animation.

I knew I needed something with skeletal animation to save time, but it also had to respect my hand-drawn art instead of forcing me into a polished vector look.

Spine

Pretty soon I came across Spine, and wow — perfect match. It does skeletal animation, works great with raster art, and still lets me keep the scrappy hand-drawn style I want. For me, it hit the sweet spot between efficiency and aesthetics.

Spine is covered really well with reviews already, but I feel like it deserves a separate article as well.

That’s where my toolbox stands right now. It’s a mix of the big mainstream stuff everyone knows and the smaller helpers that keep me sane. Together they cover most of what I need without burying me in options I’ll never touch. Next up, I’ll start sharing how I’m actually using all of this to shape the first scenes of the game — where these tools stop being checkboxes on a list and finally turn into real characters, puzzles, and environments.

At the end of the day, though, it doesn’t really matter if you’re using the “industry standard” or some quirky niche app. The best tools are always the ones that help you move forward with your game instead of wasting weeks just learning the tools themselves.

So if you’ve been stuck in research mode (like I did for a while), maybe this is your reminder: pick a tool, any tool, and just start building. The game won’t make itself — but it will come to life once you stop comparing and start creating. And honestly? That first messy prototype will teach you more than a hundred YouTube reviews ever could.