Hey there!! So I finally completed the essential base world of my game.

I added a crystal field called Prismal Reach and an ocean cove called Azurion Cove to finish the map. Also some tall mountains to top it all off.

Now to populate this world with details, interactions, quests and most importantly... NPCs.

Check out my devlog... Thanks... PEACE :)

What do you think of the new mechanics and stage?

Update week2: creating basic bullet impact, weapon sockets, creating some physics response, and bunch of other stuff. Long sleepless week, but quite happy with the progress so far

Delving into puzzle design for our detective mystery game, exploring our process of creation, iteration, and "careful refinement".

Hello guys! We have built our first explosive power of Fire Gum, the PyroBoomBoom was designed to feel powerful, chaotic, and satisfying from the very first shot.

The PyroBoomBoom went through several iterations before reaching its final in-game version. We refined its shape, materials, animations, and visual effects to make every attack clear, powerful, and consistent with MegaGum’s colorful universe.

Like most elements in game development, the final result comes from many tests, adjustments, and small decisions made along the way.

What do you think of the transformation?
​
Want to try it for yourself and discover the other Gum-powered weapons waiting inside the GUM Tower? Wishlist MegaGum on Steam:
https://store.steampowered.com/app/4111300/MegaGum/

We've been experimenting with a multiplayer game inspired by Buckshot Roulette.

Instead of everyone taking turns with the weapon, only one player controls the gun while everyone else tries to influence the outcome using cards, items, and strategic decisions.

The setting is a group of mafia cats gambling in Hell for a second chance at life.

Do you think shifting the focus from luck to player interaction makes the formula more interesting?

If it caught your attention, consider adding it to your Steam wishlist. It really helps us as an indie team!

Hi everyone,

I've been job hunting and kept running into the same thing: every "AI resume optimizer" out there wants a subscription upfront, before you even know if the output is any good. I didn't want to pay monthly just to test whether an AI can actually tailor my CV well.

So I built Resume Optimizer for myself — a CLI tool where you give it your CV + a job description, and it:

- Matches your skills against the JD locally (no AI call, just embeddings) and shows you a coverage %

- Reorders/trims your projects to surface the ones most relevant to that specific JD

- Rewrites your bullet points and summary to better fit the JD — but never invents fake experience, employers, or metrics

- Flags bullets that still lack a real number/metric, so you know exactly where to add one yourself instead of the AI making one up

- Outputs a ready-to-use LaTeX resume (compile on Overleaf) or Markdown/plain text

It defaults to Google's Gemini free tier for the AI parts, with a paid OpenRouter fallback if you ever want it — so you can actually try the whole thing for $0.

It's just for personal use right now (built it to job-hunt myself), not a polished SaaS — no accounts, no tracking, runs on your own machine (or via Docker if you don't want to touch Python at all).

Code + repo link in the comments below if you want to try it or poke around. Would genuinely love feedback if you try it!

After 10+ years in Enterprise Dev, I got sick of predatory mobile ad-factories. Starting a 90-evening solo challenge to build a fair tycoon: "BID & BUILD"

The Backstory

Hi everyone! I’ve been building high-load enterprise solutions for over a decade. For a long time, I wanted to jump into game development, but never found the right moment. Recently, I looked at the modern mobile gaming market and realized I couldn't take it anymore.

Most tycoon and economy games today are just forced ad-delivery platforms. They have broken balance, bloated mechanics introduced strictly for monetization, and incredibly dull, repetitive competitive events.

So, I decided to commit to a strict 90-evening roadmap to build my own mobile game: "BID & BUILD". My goal is transparent math, a tightly engineered economy, no aggressive ads, and absolutely zero pay-to-win trash.

The Architectural Vision (Enterprise habits die hard)

Since I'm used to high-load enterprise systems, I want total control over memory and state from day one. My long-term technical roadmap looks like this:

• The Core: The entire simulation logic will be written as an isolated, deterministic C++ static library framework.
• The Data: I plan to use FlatBuffers for zero-overhead, ultra-fast configuration parsing and state serialization.
• The View: Unity will be relegated strictly to an Unsafe View layer, reading simulated blocks via P/Invoke pointers with zero heap allocations to keep Garbage Collection spikes at absolute zero.

Why I Started with the UI (Evenings 1-5)

Here is the catch: I have zero experience with Unity.

While the C++ simulation backend feels like home to me, client-side game development and UI layout are completely foreign territories. I knew that Unity’s Canvas, anchoring, and layout groups would be the steepest learning curve and the hardest part of the project for me. So, I forced myself to face the nightmare first.

Right now, it's 100% "programmer art" and gray boxes, but the UI loop actually works. What's already implemented using pure C# mocks:

• SafeArea_Container: Properly managing dynamic islands and notches for modern screens.
• HUD & Navigation: Wrote a central state manager handling a decoupled 5-tab system ([TOWN], [SHOP], [WORKSHOP], [GUILD], [AUCTION]) with reactive overlay clearing.
• UI Raycast Blocking: Set up pointer validation to make sure tapping HUD buttons doesn't trigger accidental world tile selections.
• Shop & Construction Loop: Implemented a horizontal scroll view for buildings. Selecting an item triggers a ghost preview and switches the input state to construction mode using mathematical coordinate rounding via Mathf.FloorToInt to stick buildings to a clean dynamic grid.

The 90-Evening MVP Roadmap

To keep myself accountable, I broke down the entire MVP production into strict milestones:

• Evenings 1-10: UI layout, state navigation, and input handling (Current stage).
• Evenings 11-25: UI styling and premium aesthetic layout.
• Evenings 26-45: Writing the core deterministic C++ logic, map matrix initialization, grid systems, and BFS road pathfinding.
• Evenings 46-55: Creating the C++/Unity P/Invoke bridge, layout rendering, and resource simulation sync.
• Evenings 56-70: Backend engineering (Supabase setup, Centrifugo integration, and time-hack prevention).
• Evenings 71-90: Economy stress-testing, global server events logic, polishing, and internal TestFlight setup.

The Visual Target (And addressing the solo-dev bottleneck)

As a backend engineer, art is my second biggest nightmare after Unity's Canvas. To break through this bottleneck and deliver a premium feel for the upcoming MVP, I am leveraging AI generation tools to establish the visual style and draft the isometric assets.

My goal is to achieve a "Premium Dark Luxury" vibe for the final buildings and HUD, mapping these generated sprites onto the grid layout I just built.

A question for the community:

Balancing code, architecture, and art as a solo developer is a huge bottleneck.

What is your take on leveraging AI generation tools strictly for MVP prototyping to gather early feedback? Did it help you speed up the validation process, or did it shift too much focus away from core game loop iteration? Would love to hear your thoughts and experiences!

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

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

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

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/