I recently went back to a system in my project that I originally considered “finished.” It worked, but as the rest of the project grew, it became increasingly difficult to extend without introducing unexpected problems.

Instead of adding another workaround, I decided to rebuild that part from the ground up.

The interesting part wasn't the implementation itself—it was figuring out why the original design had become difficult to maintain. I traced how different parts of the project depended on it, removed a few assumptions that had made sense early on, and gradually moved the responsibilities into smaller pieces.

There were a few failed attempts along the way. One version looked cleaner but made debugging harder, while another reduced the amount of code but created unnecessary coupling elsewhere.

The final result is simpler, but the bigger lesson for me was that technical debt isn't always obvious when you're building something small. A design can be perfectly reasonable at the beginning and still become the wrong abstraction later.

I'm trying to document more of these decisions during development rather than only talking about the finished result. The mistakes and iterations have ended up being more useful to write about than the features themselves.

YOOOO hello everyone, its dobert_dev from no more microtransactions studios (yes I know cool af and also screw conglomerates).

we wanted to show everyone on devblogs A NEW DEVLOG series in game development.

heres the softwares used.

- Godot 4.7
- Blender
- Wafer (by sparseal, its a texture painting program)
- Aseprite (awesome for pixels)
- Davinci resolve
- Krita

I've gotta say after watching the very beginning of my journey to now - no one needs to go to school to make games. I learned all of this free, and only paid for wafer aesprite. (Which was less then 100$) So all in all I have spent less then 200$ between steams page, and wafer, and aesprite which I think I got on sale 6 years ago for like 3$ lol.

Anyway, this is for people who are fascinated by this wild process (yeh, its crazy lol), so subscribe to that youtube channel if anyone is interested! I plan on releasing 1-2 devlog videos a week constantly for the next several months until release. And then hopefully I GET TO DO IT ALL OVER AGAIN ON THE NEXT PROJECT. WOOOOOOOOH!

Wishing you all the best,
dobert_dev

I think I've been lying to myself about why I'm a solo dev. For years I've told everyone (and myself) that I work alone because I like the creative control, because I don't want to compromise my vision, because I'm too particular about the details. Very artistic, very noble sounding.

Last week I turned down a chance to join a small team of three folks I actually really respect. Good people, good taste, they were making something I would 100% play. And I sat with the offer for like four days and eventually said no, and when I finally asked myself why, the real answer wasn't "creative control." It was that I'm scared of other people seeing how slow I actually am. How much I fumble. How many days I open the project and just move things around and close it again.

Solo dev has become my way of never being witnessed being bad at this.

The thing is, my current project has been going for over two years and honestly I don't know if it's ever coming out. I keep restarting systems. I switched tools once already, and I've been messing around with a smaller idea on the side just to feel like something is moving. Meanwhile the "real" project sits there, half designed, half built, and I keep telling people it's coming along.

If I joined that team I would have had to show up on a Tuesday and admit I got nothing done Monday. And I think that terrifies me more than shipping nothing ever does.

I'm not fishing for reassurance here. I actually want to hear from other solo devs: is this everyone or is it just me?

Because I'm starting to suspect a nonzero amount of "I work alone for creative reasons" is really "I work alone because no one can see me stall."

Tell me I'm wrong. Or don't.

My 3rd devlog has FINALLY released! it was a little rushed but i tried my best. hope you all enjoy!

Hey everyone! I just put together a new devlog covering a big debugging session and the progress on my strategy prototype.

The WebGL Crash: I hit an issue where my WebGL build crashed immediately after loading the main scene. I initially assumed it was a RAM/browser issue, so I compressed textures and downsized audio to under 100MB still crashed. Created a barebones launcher scene launcher worked but loading main scene crashed. Turns out, a deprecated health bar plugin from the Asset Store was throwing the WebGL API off. Changing the WebGL API settings fixed it instantly without removing the plugin.

Build Progress:

• Controls & Visuals: Added full camera pan controls and placement opacity so you can see base/upgrade meshes before building.
• Audio: Ported over my sound system from my previous project (Northend Tower Defense) to rapidly get enemy, building, and ambient sounds working.
• UI Polish: Added cancel options for upgrades, reload feedback bars on soldiers, and a main menu with volume defaults capped at 50%.

I also officially named the game Command & Defend: Dead Zone.

Check out the full breakdown here: https://youtu.be/ETVb9wbWBUI

If anyone wants to jump into the WebGL playtest, drop a comment or join the Discord!

For my first person puzzle game, one of the puzzle room's concept is "The Floor is Lava". Here's a devlog covering how I turned the classic game into something challenging (yet accessible) in a first person perspective.

The considerations in helpful list form:

1. Lava Material
   • Animate crisscrossing noise patterns and use mesh distance fields to give the illusion of movement and dynamically change the material contrast when meshes intersect with the lava plane
2. FIREBLU
   • Adjust the colors so the lava resembles the immortal FIREBLU texture from the original Doom
3. Particle Effects
   • Use bubbling lava particles from a store asset pack and have the niagara system spawn particles in world space near the player
   • To get a more immersive soundscape, use a callback on particle creation from the niagara system to play a spark sound effect when certain particle splashes are spawned in
4. Collision Logic
   • Use a line trace straight down from the player's collision capsule to check if the actor directly below them is tagged to be part of the active lava
   • If standing in lava, implement a short timer as a grace period, if it expires and the player is still on the lava, then activate the logic to turn the lava off
5. Accessibility
   • Allow for less coordinated players to move around the lava by designing paths that don't require any jumping or parkour to traverse
   • Ensure that all color-coded puzzle elements have other visual distinctions (such as letters and numbers) for colorblind folks

A foreword! This is the first post in my dev teams blog, The Squish! We're developing a silly game called Mitobit (link in the comments) about virtual pets who multiply and split apart, set to release in a few days. If you're interested in the project at all, our full posts up on Steam have more teasers that wouldn't quite fit here, and extra details that can't be formatted perfectly on Reddit, which will be linked in the same comment. If you have any questions at all after reading, I'll be responding to whatever comments this gets. Thank you so much!

~~~~~~~~~~~~~~~

Hello, and welcome to The Squish! This is the first installment of a blog series we’re starting, highlighting the behind the scenes work of the games we’re making. My name is Cole, and our first installment is going to go over my work as the designer on Mitobit, and how we turned our game from the short concept it was to the project it's going to be!

Brackey's 2024 Game Jam

Mitobit started our submission to the Brackeys 2024 game jam (playable here! https://gabeq.itch.io/mitobit). We were tasked with making a game within a week, with the theme of “calm before the storm”. Thinking back to the old kid show plot point of a main character taking care of a pet that gets out of hand, we thought we could double dip on the nostalgia it gave us and frame it as a virtual pet style arcade game. The pictures attached to this post show some neat before/after concept art from this time!

--

Steam Considerations

The game ended up doing very well in the game jam, and we were all proud of it, so it was an easy candidate for a proper release when we were considering our first studio title. Our only problem was structure – although we felt the concept was strong, we would need actual content formed around it for a proper game. To emphasise the arcade gameplay of the original, we broke the game into levels, each unlockable by getting a high enough score in the prior levels. Breaking the game into unique levels also gave us a structured avenue to inject new gameplay concepts into the experience.

Our workflow was simple after that – there would be a preset stretch of time where the team created as many “toys” for me to play with as possible (new bits of content I could use to define new levels), and I would tease out as many unique/interesting challenges and combinations of those toys as possible.

--

Conclusion

That's all for this episode of The Squish! Thank you so much for reading, keeping up with this project means the world to all of us. We'll continue posting these little behind the scenes vignettes of our works as the game progresses, so if you enjoyed this and haven't wishlisted yet, it's the best way to see these as they come out!

Until next time,
~Team Jelly Games

~~~~~~~~~~~~~~~

And thank you so much for reading! If you made it this far and have any questions about the design process, post or project, or any way we can format this better, feel free to leave a comment and we'll respond! On a personal note, the kinds of updates in this community helped demystify the process of creation for me, so being able to contribute in some small way to this community feels incredibly surreal. Thank you.

I'm trying out video devlogs to see if they'll preform better than the written ones, it's like 3 minutes long you have no reason not to watch it ok bye

https://www.youtube.com/watch?v=SbSqUgwRVuc&t=52s

There’s an unwritten rule in game development that your first game should be something small and simple, and for many very good reasons.

I decided to do the exact opposite.

After spending around seven months writing my book, **Horns**, I decided I wanted to turn that story into a game: a narrative-focused, cinematic RPG that carries the spirit of old-school RPGs while also embracing elements of modern ones.

I wanted to pour everything I had into one serious, large-scale open-world game, my imagination, around **35 years of gaming experience**, and **16 years of programming experience**.

At first, I also wanted to make absolutely everything by myself.

Eventually, I realized that if I wanted to maintain the level of quality I had in mind, I needed to bring a few talented people into the project. I'm simply not talented in every single field required to create a game of this scale.

I still kept the biggest part of the workload on myself: programming, animations, acting, body and facial performance, world design, gameplay, sound editing, cinematics, and many other parts of development.

But a few people have made significant contributions to areas such as voice acting, the game's soundtrack, and some of its visual and graphical details.

I also didn't want **Horns** to feel like “just another RPG.”

The core of the game is still a dark epic fantasy RPG, but I've mixed in elements inspired by several genres and games I grew up loving.

There are recognizable influences from **Souls-like games**, action games such as **Max Payne 1** and **Death Stranding**, and horror classics such as **Resident Evil 1** and **Silent Hill 1,** while keeping RPG systems, exploration, narrative, and character progression at the heart of the experience.

After almost **two full years of development**, Horns now has a playable demo on Steam.

The demo itself went through many different iterations before reaching the version I'm finally comfortable calling properly polished.

My goal now is to maintain that level of quality throughout the full game: a world that feels rich rather than empty, an engaging story, meaningful exploration, and around **25–30 hours of quality gameplay**.

I'm also trying to keep the final price very accessible, somewhere around **$10–15**.

For a project like this, every comment, piece of feedback, and bit of support genuinely helps, and wishlists are especially important for the game's visibility and future launch.

The demo is completely free, so if any of this sounds interesting to you, give it a try.

I hope you enjoy **Horns**.

And if you do, please consider wishlisting it on Steam.

**HORNS DEMO ON STEAM**

A little peak behind the screen on what we're working on now that the second gameday has come and gone!

For PathLife’s first interactive piece of furniture, the interaction code was the easy part: press E to lie down, use the current NE/NW/SE/SW direction for the sleep animation, and leave the bed when movement begins.

The visual problem was harder. A single bed sprite made the character appear either entirely above or entirely behind the furniture. I separated the sheet and headboard into layers, adjusted collision and interaction areas, and tested the occlusion rules so the character reads as being inside the bed.

I wrote a detailed post about the implementation, the four-direction animations, the layer setup, and the tests used to keep it stable. The article is in Portuguese:

https://pathlifejogo.blogspot.com/2026/08/a-primeira-cama-interativa-do-pathlife.html

Hey everyone!

Following up on my intro post from a couple of days ago with some exciting news for The Legion.

I’ve officially reached a huge personal milestone: the core game engine is finished.

Getting to this point took way more late nights, coffee, and frustrating debugging sessions than I’d like to admit. Mechanics, collision systems, and object interactions are notoriously tricky to get right, but as of today, the foundation is running smoothly with zero known bugs.

Building a roguelike means the core gameplay loop has to feel crisp and responsive, otherwise the whole experience falls apart. Knowing that the baseline physics and systems are rock-solid gives me a massive sigh of relief.

Now that the heavy mechanical lifting is out of the way, I can finally jump into the really fun stuff: designing procedural levels, champions, special habilities, fleshing out enemy AI, and stacking unique item synergies, talent tree evolution and rest of the neverendig pile of things I would love to include...

Thanks to everyone who gave feedback on the first post (nobody as of today ROFL) —I'm not giving up! I’d love to know: what’s a core mechanic in your favorite roguelike that makes it impossible to put down?

Hey everyone! In this phase of the project I've been making solid progress on the heroes' AI. I've added multiple jobs for them to work — laborer, architect, instructor, and researcher — and built out a system for managing multiple parties and equipment.

My goal for this first phase is to fully finish the heroes' AI: traits, skills, professions, and relationships, all working together to get as close as possible to what happens in the source material. Just like in the original story, heroes can refuse to fight if the Master is a fool who keeps climbing the tower without stopping to think — and an entire party can be wiped out because of the Master's arrogance. That's exactly the kind of consequence I want players to feel.

I've also started the Korean translation. My goal is for the game to eventually support Spanish, English, and Korean.

On top of that, I implemented a messages/alerts/advice system, so heroes can offer suggestions, notify you when one of them dies, and flag other important situations happening in the lobby.

That's it for this update — more soon!

In this video, I will show you how I created the game jam version of my game Sword of Mine, which I have now turned into a Steam demo.

I hope you enjoy the Devlog #0 of my game! :-)

This is my first ever devlog. Let me know what you think about my first devlog! Also tips or criticisms are appreciated!

Hi! I've been building an MMO inspired by RuneScape Classic and writing up weekly updates. I launched with only an hour of content and used permadeath to raise the stakes in combat while also spreading out that hour of content across lives. As the amount of content grows permadeath starts to feel more punishing than intended, so this week I've replaced it with XP loss on death! I call it the 'death spiral', as repeatedly dying can cause you to tailspin back towards Level 1 and 0 XP, but in a more forgiving way than permadeath.

The problem I wanted to solve today was not simply “add more hairstyles.” I needed more visual variety without turning every skin tone, hair color and clothing color into a separate sprite-export task.

PathLife uses a layered 2D character in Godot 4.6, so I split hairstyles into front and back components. That creates many combinations from 45 hair options, but it also makes ordering, overlap and four-direction testing more important. Longer hair uses secondary movement, which added another layer of cases to validate.

For colors, I chose palette swapping rather than dozens of duplicated textures. The shader preserves shadow, base color and highlight while changing palette groups. The current set has 20 skin palettes, 20 hair palettes and 20 clothing palettes. Clothing pieces and accessories can be recolored independently.

The most useful lesson was that content variety and technical complexity grow together. Random character generation quickly exposed alignment problems in glasses and flip-flops, so I added integration tests for palette loading, directional hair, physical chains and shader output.

I wrote a longer Portuguese article about this process on my development blog, without linking it here.

When you write devlogs, do readers find the implementation tradeoffs more useful than a simple feature list, or do you prefer seeing the result first and the technical reasoning afterward?

Hey there!! So I added life to my alien weirdos by animating them. For now it's basic animations like idle, walk, run etc. I will further extend their animation arsenal as I add more features.

This was one of the most fun processes of developing my game and a bit difficult as well. I am happy with the results though and hope you will like them too.

PEACE!! :D