The Waking Cloak Devblog

One of the really fun things about building my own engine and tools is I can just make stuff. That sounds stupid, like duh, but it's very freeing!

A current example is a dialogue editor. I'm moving from NPC/journal/sign dialogue directly in the objects themselves out to external files. Dialogue is just text in JSON now! This makes it easier to:

Find and change dialogue easily without digging through objects in the IDE

Immediately update dialogue in-game without rebuilding

Translate! Translators can work with files!

Mod the game???

You can do this in GameMaker too (or any other good engine), and some folks have created some really neat tools around doing this (see: Juju, Yellowafterlife), so this isn't exactly exclusive to a custom engine. But it does let me make my own neat tools integrated directly into my games.

So before I was just kind of doing this:

Assigning an array of strings to "dialogue", which is what triggers when the player interacts with this lil guy.

I've already mentioned that it's better to have this in its own easily-accessible file, but it's also:

Hard to tell how it will look or paginate in game (ran into this a lot, sometimes it would overflow or paginate weirdly)

Hard to remember effect syntax, like shake (the \\4 you can see in there) or color, or whatever else

So for The Starflower Engine, I made a neat little dialogue editor. :)

It's still in progress (as is everything I guess), and I'm working out the details for choices and flags and stuff, but as it is now it's really fun to preview it immediately, work out the pagination, see the effects in progress, and see how things will branch and effect.

Any dialogues and ids and flags and such used here will also go into the aggregated list of flags, which is another thing I'm working on for visibility, design, and debugging (maybe some kind of... node graph??). It'll basically let me see what the game is doing at a high level glance and easily find what does what (ex: this button opens that door, this guy has that dialogue).

Even though ProtoDungeon: Episode III is still planned to be in 2D, The Starflower Engine can handle the transition between 2D and 3D seamlessly, so I've been experimenting with how some of my existing 2D stuff works with Starflower's model editor. :)

This isn't a final model, just proof-of-concepting something more complex!

First I took some of my house tiles here

Then I split it out to get it ready for a UV texture. Took a bit of tweaking, and may still tweak.

From there it can be pieced together! I made some tools that made this process a lot quicker, namely the "extrusion", which takes the top of the house and lets me expand it downward using the UVs I select from the texture.

There's sort of this pressure I think to always have big, quality, detailed dev posts, and sometimes I get so deep into the weeds that that's even more impossible.

Anyway, with The Starflower Engine, ProtoDungeon is now 3D, and that makes lighting easier! (Even on ProtoDungeon 3, which is still planned to be 2D via orthographic camera transformations). Unfortunately, easier is still really hard so it's been taking me a few weeks, but lighting is going to be really important in these games.

So this is ProtoDungeon 3 in 3D mode with the player light jacked up real big, enjoy!

Flowers is important!

Doing some 🌱 gardening 🌱 in Starflower Engine lately. Got tall grass behaving in 3D and 2D, which was a whole thing, and flower (and other) decorations are working properly too!

Changes!

Full billboarding for tall grass was clipping through stuff like crazy

Switched to full 3D grass (which looked neat in isolation but looked terrible in practice)

Switched back to two rows of grass sprites and added partial billboarding

Fixed grass autotiling (omg it's SO much easier than placing the correct grass entity one by one in GameMaker!!)

Switched all sprites to use the model system (since models are just 1+ sprites) so that I can use the Model Editor

Fixed a bug where entities were stuck in "preview" mode after being placed and therefore not being saved

Made it so that entities with looping animations (like flowers!) play during edit mode

I occasionally get requests to access this file on my Google Drive, and I figured it was time to upload it to itch for the world to see.

This is Vrin, an unfinished open world game I made when I was around 13 or 14 years old! I had massive ambitions, halted mainly by "I have no idea what I'm doing." It's a look into the past, when I made grass textures in Paint with the spray can tool and conversations systems with GameMaker's built in dialogs (this was probably GameMaker 6-8!).

Normally, switching engines 75% of the way through development is a really bad idea. But, like, I’d gotten really stuck on ProtoDungeon: Episode III.

The Stuckness

A lot of factors were in play. The main one was the depth system. I’ve been talking about that years, so I won’t get too deep (ohoho) into that. Just know that the end result was using 3D tricks in a 2D game: z-tilting shader, overriding GameMaker’s rendering pipeline, and geometry built of fake 3D boxes.

It works! But I also had to hand-place almost 600 instances of those fake 3D boxes, and if I ever wanted to change the level geometry, it was a headache. I made a lot of mistakes, so there were a lot of headaches.

My workflow became something like: place tiles on the correct layer, place the correct 3D boxes on the correct layer, place the additional sprites on the correct layer, try to figure out why the player is drawing under the ground, try to figure out how to get sprites to stop z-fighting, realize I did the wrong 3D box height again, close laptop, cry in corner.

If you’re a digital artist, you may have had the experience of attempting to organize your art in neat layers for real this time and then after a few hours realizing you’ve drawn everything to one single mega-layer which shall never become untangled. This is like that except it would break the game whenever I did it. Creating something 3D (even partly 3D) is really hard in a 2D editor.

And even goofy 3D boxes and layer issues would’ve been okay by themselves (there’s a lot of crying in corners in gamedev), but other stuff was starting to fray too as a result of being sort-of-fake-but-also-real-3D-in-2D, as well as just pushing GameMaker probably further than it was really meant to be pushed:

Ladders just gave up working forever

Stairs were a nightmare

A* pathfinding broke somewhere along the way

Custom rendering pipeline became difficult to work with and really non-performant

Actually the game in general was choking on its framerate

Collision was getting really bonkers

I couldn’t decouple my drawing framerate; I was locked at 60fps despite MANY attempts to use delta time or Juju’s awesome Iota library), so this meant the game ran really badly on monitors with higher refresh rates

Game compilation now took an aggravating amount of time to complete

I love GameMaker, and all this stuff is doable, but at some point I had to realize I’m effectively creating a 3D game (even if it looks 2D) in a 2D engine.

Experimentation & The Map Editor

I did a lot of experimentation. Part of this was related, part of this was just because I really wanna try pixel art in full 3D someday. You may remember this tech demo from a few years back. Then, I more recently had some decent attempts in GameMaker since I hated using Unity SO much. I called the framework “Diorama” or “3Diorama” (I was trying to be clever). It could swap between 2D and 3D seamlessly, and it’s maybe the closest I got to what I wanted to do:

Unfortunately, In the end, it was still pretty clunky to work with and place stuff. So, I drafted a spec for a map editor that would hopefully resolve most of the annoying fake 3D box placement issues. Even if it was just some nice shortcuts to display and swap between layers, and to get some better visibility on “where stuff was” in 2D, that would be a pretty major boon.

I still have the spec. It would save as json, then pipe instances, sprites, and room layout into GameMaker. The additional benefit I was aiming for was, since everything would be json, I’d theoretically be able to make changes and then live-reload rooms to see the changes without recompiling the game (important since it was also starting to take a really long time to compile).

MonoGame quickly became the candidate of choice for this. It’s a framework more than an engine. It gives you a few basics (like VERY FEW basics) and sends you off on your way to figure everything out. It really doesn’t do much for you at all. The upside of this is that you can basically do whatever you want. Engine doesn’t have a feature? Add it. Really good for a custom map editor.

And I’ve wanted to work in MonoGame for years, so this was as good a chance as any!

Then, amidst all this spec-writing, architecture, and planning, I had a very dangerous thought.

After all, why not? Why shouldn’t I create my own game engine?

There was sort of a “grass is greener” thing going on for sure, as well as going against all the common gamedev advice, but… what if I really did finally make the jump to MonoGame? It actually made a lot of sense. Why export to json and then build some sort of clunky GameMaker import with live-reloading if I could just… do it all in MonoGame.

Aside from the technical feasibility (since MonoGame is an open-ended framework, you can kinda just make it act like GameMaker lol), I also just have wanted to do this for years. I’m trying to lean more into my instincts about things, rather than what I feel like I’m “supposed to do” according to common advice. I want to work on the things I want to work on. If this were a job instead of my hobby, or if I was on a team, there would be some more give-and-take here, but even then I’d still want to push for what feels right instead of a general cookie cutter approach.

So I did it.

I built a 3D pixel art engine that can flatten itself into 2D, and I called it the Starflower Engine.

(This is a sort of deep-cut reference to when I almost changed Studio Spacefarer’s name to Starflower because I ran into a UK studio called Spacefarer Games, but they turned out to be nice and the rename turned out not to be necessary. I still like how Starflower sounds though, and “Starflower Engine” is a mix of fantasy and sci-fi that appeals to me)

I’m having a blast and got some deets to share with you, but first, here's what it looks like so far with me rebuilding ProtoDungeon: Episode III:

Starflower Engine: What it do

Starflower Engine is basically my dream game engine (albeit a scrappy one lol). It’s a pixelart-based engine that:

Supports 2D or 3D top-down pixelart and can easily switch between the two on the fly

Runs reminiscent of a C# version of GameMaker - entities instead of objects, C# instead of GML, but you’ve still got Step and Draw

Has a live map editor - you can run in play mode, walk somewhere, realize you want a wall or enemy there, switch to edit mode, place, and then switch back to play mode

Acts a little like Lego or Minecraft in the editor - tile/voxel placement with autotile and other conveniences (I actually am having too much fun making stuff)

Runs with uncapped framerate - logic runs at 60fps but draw runs at max velocity

Performs extremely fast - tons of headroom for both Update (Step) and Draw on all sides

Has a built-in lowpoly model editor using sprite composition - UVs against a texture which can pop out for live editing in Aseprite (and the texture gets wrapped up into a texture atlas for more performanceeeee)

Enables record-and-run automated testing that can play through actual levels to verify mechanics and game all still work

Contains a built in MP4 recorder for convenience using ffmpeg, because why not

Runs with my own custom rendering pipeline, including day/night palette swap shaders, shadows (via the same color swap lookup dictionary used for night), CRT and effects, etc.

Is extremely customizable because yeah it runs on MonoGame and the engine guts are all right there

And more stuff in the works now and whenever I need it. It’s pretty rough around the edges of course, and it’s really only focused on this exact type of game(s) I’m making (though, if a few years down the road it becomes polished enough I’d love to share the engine for free).

But as it is now, I’m four months in and enjoying gamedev, really enjoying it, for the first time in years. Feels like all the stuff I’ve always wanted to do but stopped myself because it seemed like “I shouldn’t.” I’m learning that’s not how I want to be creative anymore.

So to end all of this, here’s a fun little video I made that summarizes the first four months of Starflower Engine’s development:

I'm going to put this plainly to start and then explain myself a bit more throughout because I don't want this to feel like some kind of bait-and-switch.

I have a nuanced opinion on generative AI: I think AI is an abysmal replacement for human thought and creativity, was unethically trained, is overhyped by tech bros and CEOs, and is a massive money and energy sink; I also think it's getting good at coding, and while I have significant reservations about this as well, I've found it's a pretty decent coding assistant.

I've had to use it in my day job (as in, it was officially part of a research/proof-of-concept project I was assigned to), where I'm thankful it's viewed as, at best, an assistant and never a replacement for our developers. And let me tell you, there's nothing like firsthand improvement way down in the weeds to realize how hugely overblown this whole AI thing is. Don't believe the executives who are claiming it will replace humans anytime soon. It's way too stupid. It's maxed out its intelligence stats and made wisdom its dump stat. I've witnessed firsthand how much work it actually takes to get it to work. But it's also freed us up out of a pretty big backlog of very mundane gruntwork so we can work on stuff that's more important.

I've used it in gamedev too. I've used it to help me debug, teach me how to use shaders, and build tools so I can actually spend more time making the games. I've been extremely hesitant to say this because I know how generative AI is (rightfully) viewed. However, I also want to be honest: I use Claude Code.

But I'm not letting Claude Code make a game for me (it's not good at that anyway). I've been moving away from GameMaker into MonoGame, which is something I'll dive deeper on in another post soon! For now: MonoGame is a framework more than an engine; it's very bare bones on its own. You're pretty much just given a bit of code and told “have fun." No editor, no sprite management, no object/entity creation, not even stuff like window resolution management. But also a LOT more freedom, and, AI aside, that resolves some really tricky issues I was starting to run into at the fringes of GameMaker's capabilities (I do love me some GM, but it’s a 2D engine, and I was having to do some really janky stuff to get “3D-in-2D” working).

So my use of Claude Code is more in building a focused editor/engine than anything else. Any features built with Claude Code are limited to features that any major game engine already has. It's only assisting in building features Unreal or GameMaker already have. In a word: scaffolding.

In more words, I only use Claude Code for:

Debugging

Optimization

Using it to analyze freely licensed code for educational purposes

Building editor features that other engines have by default

Moving my own code from GameMaker to MonoGame (this is the bulk of my use)

I will not use generative AI for:

Art

Sound

Music

Special effects (puffs of dust, weather, that kind of thing)

Puzzles

Mechanics or game design of any kind

World design

Characters

Writing

Lore

Dialog

I'm still over here placing tiles by hand. Any game made by me, or Studio Spacefarer if it grows beyond me, will be made by humans and not AI. In my use, AI must be limited to being more like a machine that's assisting in building my tools. It's not the painting, the painter, or even the paintbrush. It's a 3D printer that helped assemble a new palette board or canvas frame.

And the only reason I'm getting anywhere with it is because I know what I'm doing with code, and I know when AI is trying to give me bs. I’ve been a professional developer for almost 14 years, and on the side I have 7-8 years of code for The Waking Cloak and ProtoDungeon. This isn't some vibe coded mess or a stack of cards. It's targeted, specific use with the intention of hopefully one day not even needing AI.

But I also get it. There are issues with using generative AI at all, even if I'm not using it to make my art for me.

One such consideration: LLMs were unethically trained. Even code was scraped without consent. This is a prickly issue, and I don't like that it happened. However, my usage doesn’t meaningfully change this historical training cost. I don’t endorse it. I’m only making a constrained choice within imperfect systems, and I remain uncomfortable with it.

(So why choose it at all? Because it has overwhelmingly enabled me to get back on my feet and actually enjoy gamedev again with very limited time and resources. Instead of fighting at the edges of GameMaker’s 2D capabilities, I’m using custom-built capabilities that work for my very specific use case.)

Another consideration: is coding with generative AI an energy hog? Am I burning down forests for convenience? This worried me greatly, so I stopped using AI and did some research into it (actual reading, not just googling vaguely). I was very surprised by what I found. Even under heavy use and including the cloud-based processing, text-only Claude Code is roughly equivalent to gaming on a desktop PC. There aren’t solid numbers here. But in terms of order of magnitude, we're talking pretty tame. Sources here.

The real culprits are image, audio, and especially video generation. These are significantly more intensive than text, and I will not be using these.

Even if AI gets better at that type of thing, even if we were talking energy-efficient, high-fidelity, convincing, “beautiful" output, it's still not worth it to me creatively.

Art should be human. AI should at most only enable more human creativity, rather than supplanting it. So while I'm using AI, my line will always be that it enables me to enjoy making the game, rather than making the game itself. Robots don’t get to do the fun part! I care too much about making games to let something else make them for me.

They're semi-educated assumptions!

I guess this is a postmortem, except I'm not really grieving the death of a thing. I don't consider ProtoDungeon dead. It's just very, very small. I could call it a smallnalysis but "postmortems" are actually a thing in gamedev so I should probably use the commonly accepted terminology

Over 5 months, ProtoDungeon Episode I has sold a total of 75 copies, and Episode II has sold 47 copies over 3 months. If this were my day job... well, it wouldn't be my day job anymore. But as a side hobby with very limited time? Not too bad!

Postmortem / Smallnalysis GO

I'm pretty much going to ignore the game's visual appeal and fun factor here, partly because it's subjective, partly because on these postmortems (at least on reddit) you always see armchair analysts doing that anyway, so I'll let them weigh in if they ever find this, I guess lol.

But, for some more objective stats:

ProtoDungeon 1 had less than 120 wishlists at launch

This number is amazingly ineffective on Steam. If you want to sell a game, you need more than this. Like, orders of magnitude more.

Honestly the Steam pages weren't up for long enough. That alone is a big factor, but I also didn't really have a lot of traffic in general. It's possible that this was in part due to the game's quality or inherent attributes, but also because I was still relying on social media to an extent. More on this later.

Many of my friends and family and online followers already got it free on itch.io

Actually some friends and family bought it AGAIN on Steam which is so lovely, but I also don't blame anyone for not buying something they already got.

They're short

Short games don't do well on Steam

They're linear

Linear games don't do (as) well on Steam

They're priced under $10

I don't remember if that's the actual turning point for price to increase the perceived value of a game on Steam, but I also don't feel good charging $10 or more for games that are 40-60 minutes for most folks. (Should they be free? Apparently that's also a huge no on Steam. Unless it's a demo. Are they demos? Kind of?? But also no???)

No (recent) visibility

I pretty much noped off social media right before launching my games, and I used to feel kind of like I'd screwed myself over (even though I still stand by the decision), BUT recently I found out that social media really doesn't convert well to sales anyway! This is extremely freeing and validating! I don't have to feed my soul to the demon machines!

So if that wasn't it, what happened? Well according to the research, the best way to get visibility for indies is streamers. The only folks who have streamed my games did so like six years ago (and I love them for it, it's just not exactly generating hype at this point).

Also according to the experts, devs don't really need to worry about their short linear games being spoiled by streamers or potential players "getting their fill" by watching the game played. Apparently that's just not a big factor in reducing sales. So, yay! On the flip side, short linear games don't do well on Steam soooooo

(Episode III actually will end up being a slightly bigger game, but that wasn't a result of this smallnalysis, that was just preexisting wild scope creep)

Steam art

My images for Steam (the capsule, header, and so on) are not pro level--I simply didn't have the funds to hire an artist for episodes I or II, and I refuse to let AI create those for me. So I made them myself! And you can definitely tell. I don't have any idea how much this has impacted sales, but I'm certain it's a negative amount. [Episode III's art is a HUGE improvement since I commissioned an Actual Artist Friend]

What Shall Be Done

Mostly nothing. I'm doing this my way. It's a hobby, not a job! ProtoDungeons will still be short and pretty linear. The Waking Cloak will be the much bigger game, and less linear. I'll still charge less than $10 for ProtoDungeons (I think, unless they get bigger). As more come out I may consider deeper sales on the earlier episodes, too.

However, I'll try a few things!

Getting Steam pages up more in advance - this may require me to do some more "vertical slicing" dev so I can get a basic trailer and art assets up and running.

Contacting some friendly streamers! I'm thinking I'll hit up all sizes of puzzly/adventure-type streamers, big to small, but focusing most of my efforts on the smaller guys. Just feels more appropriate and community-focused. Also may see if anyone wants to run PD1 and PD2, even though they've already been released.

Even MORE not posting on social media (this blog excepted). I'm just not going to bother and won't feel guilty about it.

Professional artist Steam assets - at least as much as possible. I hired a friend for Episode III's assets, and they are a massive improvement over I's and II's. If I make enough beyond covering for future episodes, I may go back and commission new assets for PD1 and PD2.

I know you guys like ✨charts✨ and ✨data✨ so here is my very meager (but very exciting to me!) contribution from the 2025 Fall Sale on Steam.

I am what you call "a very small solo dev without visibility," so numbers are pretty slow in general for ProtoDungeon Episodes 1 and 2. In the prior month I sold two games (which is still neat for me). The first episode is substantially more successful, as well.

The Fall Sale ended up going very nicely, relatively speaking, with that context in mind! I wound up selling an average of one game per day, a +1450% increase over the prior month lol. Numbers are obviously skewed here (though in which direction I'm not sure) by me being so low on the totem pole, so keep that in mind in your devious marketing calculations.

The fall sale is over for now, but keep an eye out for the winter sale! You can wishlist the games here in anticipation:

ProtoDungeon: Episode I

ProtoDungeon: Episode II

As usual, I've been quiet for a while, so here's the progress on the PD2 update on Steam! The current version on Steam works, so almost all of these fixes are a result of updating to the latest "Waking Engine" framework. (Waking Engine is what I'm calling the mechanics/code/assets for The Waking Cloak, ProtoDungeon, and anything else down the pipes that winds up using this!)

Updates

Implemented CRT filters

Implemented new menus, etc.

Updated title screen card from white to black

Updated water to latest version (so if you jump off the bridge you'll drown, instead of just not being able to fall off at all)

Changed save functionality to no longer save as soon as you get an item; we don't need this anymore as we are no longer sending the player back to the start of the room if they fall in a pit

Bugfixes

Fix: starlight ring use crashes the game :)

Fix: bridges (all of them)

Fix: cliffside colliders (you can drown now so let's be careful)

Fix: various objects positioning after sprite origin changes

Fix: intro cutscene broken

Fix: title screen broken

Fix: missing region borders

Fix: if you quit and reload you can get the ring item over and over

Fix: ring block disappears immediately upon creation

Fix: arrow generator positions

Fix: UI missing starlight ring

Fix: stairs

Fix: invisible key

Fix: upside down key (??)

Fix: "FATHER" headstone moves when you push the mausoleum button, whoops

Fix: mausoleum exterior not displaying, covered by mask

Fix: basement block not saving position

Fix: moon plant and sun headstone not disappearing at day and night respectively

In Progress

Finalizing z-tilt on various objects/decoration

Finalizing perspective change from 2D Zelda-like interior perspective to full orthographic cutaway perspective

It's here!

The Steam Autumn Sale!!

This is the first one I get to actually participate in!!!

Go grab them games on sale!!!!

ProtoDungeon: Episode I (50% off!)

ProtoDungeon: Episode II (50% off!)

The PD1 update taught me it's probably better to just switch to the new perspective and depth system, rather than halfway switching and retrofitting a ton of stuff in a questionable way. There are still some quirks of the design (such as in the image here), but overall it's been a smoother process.

Most other walls have been converted here, but I'll need to work out how to represent north-facing walls without messing with the footprint of things (since that does actually affect the puzzles). Thankfully there are only like two locations that do this.

Less exciting for y'all, but I also converted all The Waking Cloak projects into one repository, with WakingEngine as the core project. I then export this as a versioned package to the PD1/PD2/PD3/TWC/etc projects, and just set a few macros at the roots. This way all code and improvements are much easier to share between all games, and I don't have to keep copy/pasting entire project directories whenever I want to pull new features since that is pretty... time consuming and error prone.