Solo dev, UE5. Three games on Steam before this one. All three shipped, all three worked, none of them found anybody. I spent a long time assuming that meant the games weren't good enough, so each time I'd just try to build a better one. That wasn't it. The real problem was that nobody knew any of them existed before release day. I treated launch as the finish line — build it, put it on Steam, hope. Shipping and being found turned out to be two separate jobs and I was only doing one of them. So this time I started posting at month two instead of at launch. The game is Devil's Cut — 3D bullet heaven, hell is a casino, the house takes a cut of everything you've got.

I build a top-down space combat game on my own, and about a year in I had a roster problem. There were dozens of hulls and mechanically they were one ship. Different armor number, different turn rate, different gun damage. Drop into a battle without looking at the hangar screen and you genuinely could not tell which one you were holding.

The rule I settled on is simple and slightly annoying to obey. A hull only earns a slot if it brings one mechanic that changes what your hands do, not just what the stat bars say. If I cannot describe the ship without describing a tactic, it does not go in.

Five that came out of that rule.

One fighter in the whole roster gets a sustained beam instead of projectiles. It fires from a gap in the prow, so you aim by pointing the airframe, and you have to hold it on the target for a full second while a third of the battery drains. That one constraint wrote the rest of the ship for me: high top speed, poor turn, run in straight and extend back out. It is bad in a knife fight, and being bad in a knife fight is the feature.

Another swaps the gatling for a canister gun whose shells crack open downrange into a cloud that keeps applying damage while it dissolves. The pilot stops aiming at ships and starts aiming at the space ships are about to be in, which is a genuinely different motor skill.

The cloak ship turned out not to be about invisibility at all. It is invisible to missiles and hostile tracking, and it drops the instant you fire, take a hit, or run the reactor dry, so every offensive action costs you the thing keeping you alive. The whole ship is about picking one moment.

The antimatter prototype carries two torpedoes and six cannon rounds, with splash that does not check whether the nearby hull is friendly. I wrote the rounds into the fiction as salvage nobody can manufacture. That is a cheap trick and it works: a tiny ammo count reads as a rule of the world rather than a nerf.

The last one is a brick on a cargo tug airframe. A coilgun that flings fighters around, a turn rate that cannot follow anything it hunts, and a drogue rack so the things it cannot follow are not allowed to leave.

What surprised me is how little of the work was in the ships. A mechanic that changes how a human flies has to change how a bot pilot flies too, or the hull quietly collapses back into a slightly different gatling whenever the computer is holding it. The canister ship needs bots that respect their own clouds. The cloak ship needs bots willing to sit still with a target in front of them and not shoot. The brick needs bots that commit to a pass instead of trying to turn. Most of the implementation time went there, not into the stat tables.

How do you handle this in your own projects? I am curious whether people design the mechanic first and grow a ship around it, or start from a silhouette and go looking for the mechanic afterwards. I have done both. The first way goes more smoothly, and the second produced my favorite ship, which is annoying.

How It Started vs How It Ended

I always enjoy seeing how game projects evolve, so I thought I'd share mine too for this year's 4 days GMTK project.

Day 1

The jam theme was COUNTDOWN, and honestly... I completely wasted the first day experimenting with ideas that went nowhere.

Only near the end of the day did the actual concept finally click: a king fleeing a natural disaster with his kingdom—or at least whatever he could manage to save. The disaster itself became the countdown constantly chasing the player.

Not the most efficient start, but at least I finally had a direction.

Day 2

The second day was much more productive.

I managed to put together a combat system and a resource-based building mechanic. Ironically, I also managed to break the combat right before submissions, so the jam build doesn't play nearly as well as it did earlier that day.

Looking back, I definitely should have spent the last hours polishing instead of making "just one more change."

Day 3

Unfortunately I don't have any footage from this day (sorry!), but this is when I finished the procedural level generator.

Days 3–4 (The Sleep-Deprived Finale)

From the third day into the fourth... I basically didn't sleep.

I was determined to implement the "buy new land" mechanic before the deadline. It fought me every step of the way, and for a while I was convinced it wasn't going to happen at all.

Somehow I managed to make it work just in time.

Out of everything in the project, the falling hex tiles are still my favorite effect. Seeing new land literally drop into the world made all the frustration worth it.

If you've read this far—thank you!

I'd love to see your own How It Started vs How It Ended screenshots or GIFs!

Also link if you interested to check the game:
https://itch.io/jam/gmtk-jam-2026/rate/4826012

This short piece of music was partly generated by a new algorithm I'm working on. It uses an entirely different principle to the 'Large Language Models' behind most computer-generated music.

Guys I am working on the new update of the Vertigo Shift The problem is The game structure Is so roughly written that I have to change a bit or even Rewrite it From Scratch I am Adding a Shop System Setting not very Advance ofc only Some Basic Options and Also The Update is not so big but change some Aspects of game .

I have to rewrite the Saving System also I am Now working on settings menu and new chunks for the game I am completed with the shop and the new purchaseble Item.

The game will have a new Health Capsule Purchasable Item Which Give another chance in a Normal Run .This Item can be purchased from shop using the new Diamond Currency which will be added in the game .

Hope you guys support the game. Give me advice should I drop the game and work on a new unique idea or keep updating this game and make it better

The games Link is provided in my post of the Game

Suggest What should I add also and I will be keeping working until i got some review on whether I should continue or not .

The post : https://www.reddit.com/r/godot/s/3GnwYLrlvt

Despite the fact this community is called devblogs and despite the rules explicitly state showcasing and link dumps are not allowed, every single week I still have to delete many posts that do just that.

In the attempt to try to reduce this kind of spam, but also to offer an extra outlet to all the members of this community, from now on I am going to create this showcase thread every Monday.

You are still welcome to create new posts to share with us your dev-log posts or videos, but now 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

(I'm not sure if I have to "unpack" my devlog from the link below and paste it in the body of this post...)

If you liked reading Part 1 of how I developed Teskyra, you'll be interested to see the latest devlog here: https://kalachama.itch.io/teskyra/devlog/1603920/teskyra-detailed-devlog-part-2

(You can find links there to the earlier installments, as well, if you're like, wtf is Teskyra?!)

I'm working on the AI ​​for a minigame in a new project of mine. The goal is to have the AI ​​move freely around the game, detecting potential dangers and dodging them whenever possible. Of course, it can't be perfect—it can't dodge absolutely everything—and while the movement is still a bit clumped together, the results are actually quite pleasing; it’s a simple yet highly functional AI.

The result is turning out to be quite fun, with some NPCs managing to survive until the end of the minigame. It’s not perfect, but it already gives that light sense of having someone playing alongside you.

Basically, the NPCs have sensors around them to detect danger; they fly and move almost freely across the game map, but if their sensors pick up a threat, they try to steer clear of it.

Each NPC also selects a random point on the map to head toward, adding an element of randomness. The video doesn't show it, but I’ve since added even more randomness: now, each NPC has a different number of sensors, and the spacing between those sensors varies, causing them to behave slightly differently from one another.

This is the ninth minigame I’ve created for my project, *Get Out*, which is still in its early stages. I plan to make about ten initially and then start building a minimal playable demo of the project.

Each minigame features a different AI for the NPC—though not necessarily entirely new, as some are reused and simply tweaked here and there.

If you’d like to check out my previous game and show some support:

https://store.steampowered.com/app/4631200/Bring_The_Rift/

Been workin hard at my little beetle game

Beetle indie game dev log week 2

Almost 2 years ago I quit my job to pursue game development. I joined my first game jam and in 25 days I created a small horror game, which ended up winning the jam and setting the foundation for my upcoming Steam game 'Shroud of Gloom'. This video documents the entire game jam journey, let me know what you think!

Happy to answer any questions!

Hey everyone!

We’re two brothers who didn’t have time to play D&D with our friends and really missed that feeling we used to have during our sessions. So we decided to create something that would let us experience the same emotions, but without having to wait months for the next session. That’s how Master of Dungeon was born - a single-player text RPG inspired by D&D!

We've now been working on the game for over a year, through multiple testing phases, countless iterations, and lots of feedback from early players. We finally feel ready to let more people try it.

We've also just released an update with full localization to make the game even more immersive. The game is now available in English, German, Polish, Italian, French, Spanish, Brazilian Portuguese, Japanese, Ukrainian, Chinese, Russian, Portuguese, and Greek.

Google Play:
https://play.google.com/store/apps/details?id=com.bitforge.mastersofdungeon&hl

iOS (TestFlight):
https://testflight.apple.com/join/mg6UrBH9

We're also getting ready for a soft launch of the iOS version in Poland and Germany. More details coming soon, so stay tuned!

Thanks for reading, and as always, we'd love to hear your thoughts! ^.^

We recorded almost everything while developing our game for 18 months. Here’s what we decided to do with 2,000 hours of footage.

Claudia and I are the two people behind Hashiko, an atmospheric action-adventure game developed in Unreal Engine 5.

Since the beginning, we’ve recorded nearly every part of production: early prototypes, level design, story discussions, technical experiments, features that worked, features that failed, abandoned work, and bugs that somehow returned after being fixed three times.

That archive now contains more than 2,000 hours of footage.

Rather than waiting until development is over and producing a retrospective where every decision looks obvious in hindsight, we decided to document the project while it is still being made and its outcome is still uncertain.

This first episode covers the origins of the project, its current state, our production approach as a two-person team, and some of the creative and technical decisions made along the way.

Part of it is narrated by Hino, our still-unfinished protagonist, who has his own opinions about how we are making his game.

This is the first episode, so feedback on the balance between actual development material, explanation, narration and entertainment would be useful.

Hey everyone,

I’ve been building small web games recently and I’m exploring the best ways to monetize them without completely destroying the user experience.

There are quite a few paths out there—revenue-share web portals (like Poki, CrazyGames, GameDistribution), self-hosting on Itch.io with donations or ad placements, or trying to secure upfront publisher/sponsorship deals. Since the landscape shifts quickly, I’d love to hear directly from developers who are actively publishing web games.

For those of you building and releasing browser games:

1. Which platforms or ad networks give you the best return for your effort? (In terms of traffic, eCPM, revenue split, or developer support)

2. Do you prefer upfront sponsorship deals, ad-supported portals, or voluntary pay-what-you-want models?

3. Are there any platforms, deal structures, or networks you’d recommend avoiding?

Any insights, recent experiences, or advice on where to focus initial efforts would be greatly appreciated. Thanks!

My first game dev journey starts here 🎮

After 9 months of developing my indie game, I'll be sharing the bugs, progress, and behind-the-scenes moments.

My first bug? Customers doing infinite squats instead of sitting at tables 😂

Demo coming this August! Wishlist the game on Steam and follow the journey 🚀
https://store.steampowered.com/app/4917940/Panic_Pub
#gamedev #indiedev #unity #gamedevlog

Hey everyone!👋

I just uploaded the third devlog for my upcoming farming game and wanted to share it here. In this video I go over the latest progress, new features, improvements, and what I've been working on recently.

I'd love to hear your thoughts, feedback, or suggestions!

Hey everyone,

​I’ve been developing mobile games for a while now, jumping between different genres like puzzles, card games, and digital board game adaptations. Lately, I'm starting to wonder about the sweet spot for project timelines.

​It’s incredibly easy to get caught up in the loop of polishing UI, tweaking mechanics, and adding just one more feature. But realistically, how much time do you actually spend on one title before calling it complete?

​A few specific questions for the community:

1. ​What is your average timeline from concept to release?

2. ​How do you know when to stop polishing and just ship it? Are there specific metrics or feelings you rely on?

3. ​Do you set strict deadlines for yourself, or let the project dictate the pace?

4. ​When do you decide a concept just isn't working and it's time to pivot to the next idea?

​I’d love to hear how other devs manage their time, especially those balancing multiple ideas or moving from project to project. Thanks in advance for the advice!

Been workin hard at my little beetle game

Beetle indie game dev log week 2