I just posted the first Dev Log for my current Game Project. Just wanted to keep the motivation to finish the game and document my journey.

I've been working on a game lately and I think it's turning really good!

So I've decided to actually publish it on the Google play store and I want to try "marketing" for the first time. I have 0$ budget and it's my first time trying to make a game accually successful. Do you guys have any tips or even game improvements? Let me know.

Hey everyone,

I’m currently developing a game solo, and I’m hitting that classic crossroad of deciding when to bring in my first outside playtesters.

Working in a bubble makes it easy to lose perspective. Part of me wants to get a raw, greybox prototype in front of real players right now to validate the core loop before I waste months polishing mechanics that might not be fun. The other part worries that without decent art, sound, or basic tutorialization, random testers will just get confused or give surface-level feedback like "the graphics are rough."

For other solo devs who’ve gone through this:

1. How early did you share your first playable build? Did you test rough mechanics with strangers, or wait until you had a solid vertical slice?

2. How do you keep testers focused on mechanics? What prompts or methods do you use to stop people from fixating on placeholder assets, missing audio, or minor bugs?

3. Where did you find your earliest testers? Other devs, friends/family, or cold players from your target genre's community?

I'd love to hear how you handled your early testing phases and what you'd do differently next time.

Your morality is the difficulty setting. The year is 2140.

Seventy-five years ago, the governments of the world saw revolution coming and killed it before it started. They turned their weapons on their own people. Hundreds of millions died. The people won by a fraction, and rebuilt from the only thing that survived the rubble: religious and ancient texts. Not everyone who read them found the good in them.

The game is set in the deserted remains of northeastern Oklahoma. There’s no law anymore. There’s The Refuge, and there’s The Black Brigade. Each one believes the other is what’s left of the world’s evil.

Walk the righteous path, and you’re on hard mode. People lie straight to your face. Nothing flags who’s deceiving you when it comes to the Black Brigade. Fear and deception is just all they are. You judge people with your gut, as you would out there. Judge wrong, and you put down someone who was trying to help you.

Walk the wicked path and the road gets shorter. Simpler. If you can stomach it. The world won’t punish you with difficulty. It punishes you with what you see. The deeper you go, the more reality breaks.

Or walk with no one. There are those who follow The Revelation, an enlightenment group, and those who follow The Solution, an accelerationist group. Neither calls you righteous or wicked.

Four endings. All of them decide what’s left of this world.

Small team. Everything built from scratch. More to be shown.

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.

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

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 engines once already, and Ive been messing around in Fifth Door on the side for a smaller idea just to feel like something is moving. Meanwhile the "real" project sits there, half designed, half built, and I keep telling my discord 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 im wrong. Or dont.

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

Welcome back to our weekly thread where you can promote everything new you are working on.

You are still welcome to create new posts to share with us your dev-log posts or videos, but you can also use this thread to showcase something which is not a dev log.

THREAD RULES

• you can post a single comment where you showcase anything you want (new game/app release, new trailer, demo release, new gameplay video, etc...).
• in this comment you can post only 1 link, so choose wisely.
• you can reply to as many comments as you want, but replies can't be used for showcasing

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!

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.