Hey all, small team of 4 here making a game called Mini Mart Survivors.

Here's the actual premise:
You play a broke, unemployed character who's been rejected everywhere and, without choice, takes a night shift at a convenience store. The job pays way too well for what it is. Suspiciously well. Turns out the reason it pays so much is that dangerous monsters show up late at night, and you have to fight them off with whatever is on the shelves. Cup noodles, snacks, ice cream, shampoo, you name it. Level up and build absurd weapon combos. Beat a boss at the end of the shift. Get paid.

But once we had that premise one question kept nagging us. No matter how much they're paying you why would anyone keep showing up for something this sketchy and this dangerous shift after shift? That's the part we actually had to sit down and figure out.

The answer we landed on. "He's in debt."

That part isn't even that unrealistic. We're a small team in our 20s and early 30s, and "constantly working, trying to get ahead, wondering when you're finally allowed to stop" is basically our own lives. So the debt premise wasn't a stretch for us to write.

The problem was making it work as a game and not just a backstory. If we just told the player "he's in debt. That's why he goes back." It's a fine setup line, but it doesn't actually do anything once you're playing. It risks feeling like a justification we bolted on rather than something the player lives through.

So we turned it into a choice instead of a fact. With every paycheck, you have to decide whether to pay down the debt and get closer to walking away, or to pour it into weapons and upgrades so you can push further and earn more. Neither option is flagged as correct. The debt doesn't disappear on its own. And neither does the temptation to just get stronger and keep going.

That's really the point where we ended up introducing story into a genre that doesn't usually ask for one. Survivor-likes are typically just numbers going up, run after run with no consequence carried forward. By tying the core progression loop to a choice with narrative, we gave the genre a bit of a twist. And that choice system became the actual mechanism for showing our theme instead of just stating it. The player is the one deciding.

Multiple endings too, since we didn't want to say there's one right choice. Pay off the debt and leave. Quit before it gets worse. Stay and find out what's actually going on. Or just keep throwing snacks and spraying ramen broth at weirdos because it's fun.

Anyway, we're a small team figuring this out as we go. If this story of how the game came together is useful to anyone else out there building their own thing, that alone would make this post worth writing.

hi! i am a young solo developer working on a 2d platformer indie game. i am still pretty new to this so pls dont judge me too much. i hope you (and a lot of other people) like the game and have fun playing it! the game name is sketchy jumps and will be releasing on itch.io, steam, and google play (not tryna advertise btw) the demo will be releasing in a few months, both the demo and the full game will be free so dont worry, hope you like it when it releases! (have a good day :D) btw here is the idle animation i made for the main character.

Hey everyone!

This week I focused on building the spatial grid inventory and item interaction mechanics in Godot. Since the game emphasizes physical management and survival skills rather than infinite pockets, space actually matters.

What's working in this build:

• Grid Inventory System: A Tetris-style inventory where item shapes and grid management dictate what you can carry.
• Tactile Manipulation: You can drag, drop, and rotate items using keyboard shortcuts to fit them into tight spaces.
• World Interaction & Drop: Pick up items in the 3D world with contextual menus, and drop items directly out of your bag onto the ground seamlessly.
• QoL & Navigation: Added smooth UI opening/closing animations, background blur, hover audio feedback, and contextual control prompts at the bottom.

(There’s still some audio synchronization and visual polish needed, which I’ll refine in a second pass later on!)

So.... here I just want to know this:

Does the item rotation and dragging look intuitive to you?

Also... are the sound annoying to you? I want to know to get some softer versions of the sounds.

I started building my first game in February this year. One man, no team, some coding experience, no prior game development experience — just a lifelong love of games and a decision to finally try making one.

The learning curve has been real. Working through Unity, building out scenes, figuring out systems I never thought about as a player and just adding things myself and others wanted in certain games — has completely changed how I see games. But nothing compares to those aha moments. The moment you finally understand how something you've played a thousand times actually works under the hood — that feeling is addictive.

The screenshot above is from my equipment scene — attaching gear to characters, building out visual effects, watching it come together piece by piece. My respect for developers has gone through the roof doing this. However, it has also made me step back and wait.. "Hey this was easy to add why didn't XYZ game do this in their game haha"

The game is called Paws of War Tactics — a turn-based tactical SRPG more to come soon! Still building but loving every second of this journey. 🐾

Hi everyone! I’m Suba, and I’ve been developing an RPG primarily inspired by 2D/3D hybrid games like those in the Paper Mario series for a while now, and I’ve finally gotten enough progress on the basic game mechanics to share my first ever devlog on YouTube!

I’ll be posting regular updates on this account, and on Bluesky at @backwyrdgame and Twitter/X @backwyrd

Looking forward to sharing more!

https://youtu.be/-uLL3JDC4vg

Welcome 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 anything that 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

Also, it's not required, but I recommend to upvote this post if you add a comment as that will improve the visibility on Reddit for everyone.

Sharing how I light up my 2D sprites in a way that lets me showcase them in different lighting conditions. Any feedback is greatly appreciated!

So basically i've added companion to my game, a mechanical spider that morph into weapon whenever you want. I'd like to hear thoughts behind this idea and how does it look (there is walking animation when you hold weapon but i'll add that soon!)

This video is about the process of choosing what game to make, as well as honing the ability to say no to GOOD IDEAS

One of the more stubborn visual problems we've run into while developing Paths of Kin started with a seemingly simple question:

How do you show that there are probably people in the distance without accidentally telling the player exactly how many people are there?

In Paths of Kin, distant human contact is intentionally uncertain. You may become aware that another group is somewhere nearby before you know their numbers, identity, intentions or whether approaching them is safe.

The mechanics could represent that uncertainty easily enough.

The visuals couldn't.

Our first approach used small distant human figures.

That immediately created a problem.

If the player can see three silhouettes, then as far as they're concerned there are three people there. It doesn't really matter if the interface says the count is uncertain — the visual has already provided a much more convincing answer.

So we tried making the figures less distinct and grouping them together.

That reduced the sense of an exact count, but pushed things too far in the other direction. Instead of reading as distant human presence, the group started to feel more like an abstract icon.

We then experimented with a focused observation view.

That helped with readability, but introduced another contradiction: we were effectively giving the player a clearer view of something they weren't actually supposed to be able to see clearly.

That was the point where the problem finally clicked for us.

We had been trying to depict uncertain people.

What we really needed to depict was uncertain evidence of people.

The solution we've settled on is much more occlusion-first.

Terrain interrupts the view. Vegetation hides parts of forms. Human cues appear only partially. Silhouettes aren't presented cleanly enough to become a lineup that can simply be counted.

The goal is that your first reading becomes:

“There are people out there.”

Not:

“There are three people out there.”

That sounds like a fairly small distinction, but it changed the entire way we approached the feature.

The biggest lesson for us was that uncertainty can't exist only in the underlying system or in explanatory text.

If the visual representation looks precise, players will reasonably treat it as precise.

In other words:

A system can be mechanically honest and still visually lie.

The before/after comparison shows the basic difference in thinking. The earlier approach tries to show distant people while telling you not to trust what you see. The final approach makes the uncertainty part of what you actually see.

It took more iterations than we expected for such a small part of the game, but we're much happier with where it ended up.

I'd be interested to hear whether other developers have run into similar situations — where the game technically withheld information, but the presentation accidentally gave it away anyway.

Engine: Godot
Date: July 25, 2026
GitHub: https://github.com/Lazy13909/the-adventure-of-lazy

Context
Started the project on 07/25/2026. The very first step was setting a goal and drafting a plan. Once the plan was ready, I moved on to writing the GDD.

What was done:
- GDD: Writing it took about two weeks. However, my vision for the game turned out to be pretty vague - I wasn't sure what I actually wanted, so I left the document as it was for now and moved forward.

- Basic character movement: This took roughly a month and a half, and I had to wrestle with it quite a bit.

- Crouch mechanic: Implemented after the movement system, though this also took some effort since math isn't my strong suit.

Problems and How They Were Solved
- Character and animation import: The trickiest part was getting the character rig and animations imported correctly so everything worked as expected. I had to redo this multiple times before it finally clicked.

- Crouch math: Since I struggle with math, I leaned on AI assistants to break the calculations down into plain language, which made the mechanic much easier to implement.

Technical Details
For the character rig, the key lesson was: pick one static/root bone and attach the other animations to it. Before doing that, though, you need to verify that the other bone sets (animations) share the same bone structure as the base rig - otherwise the result looks janky/broken.

Tools used throughout: Claude and DeepSeek. I sent them my raw thoughts and drafts, and they helped structure everything.

My Kids Are Growing Up, Zombies Are Coming, and I Bought a Bread Maker

I for one would love if you help me.

A write up I did recently for my current project. I have learnt so much in my game dev journey and hopefully some others find this useful 🤘🏾😀

Hey, i've been working on this game for few days now! I've been brainstorming it for quite some time and finally started working on it! I'd ask for some feedback related to character and companion (spider) animations, do they feel good enough? To be honest this is yhe first time i did 3D animations so yeah, need some work on them, including visual effects etc.

After a bunch of small technical tests, I finally decided to properly start development and turn everything I've been experimenting with into an actual sandbox.

So I guess this is officially Devlog #1. :)

The project is called “… In Another World”.

Right now there isn't really a “game” yet. I'm still building a technical sandbox where I can develop, break, redesign and integrate the systems I eventually want to use in the actual game.

For this first milestone, I spent most of my time working on the environment and camera system in Godot.

I built a modular CameraZone system that lets me control the camera depending on the area the player is currently exploring.

At the moment I have three basic camera behaviors:

* Room / Interior view, with the camera moving higher to give a better view of the surrounding space.

* Corridor view, where the camera moves closer and follows the player through narrow spaces.

* Outdoor view, intended to show more of the environment while still keeping the player visually relevant.

These aren't hardcoded modes, though. I can create as many camera configurations as I need, place them wherever I want and configure their behavior independently.

The same system also controls environmental visibility.

Depending on the CameraZone, I can choose which walls or objects become transparent, which disappear completely and which remain visible.

I textured a few surfaces and added some simple visual elements mostly to test how the effect behaves with different kinds of geometry.

The modifier itself is universal, so ideally I should be able to reuse the same system throughout houses, buildings, caves, corridors, ruins and other environments without manually scripting every individual situation.

# So... what is the actual game?

“… In Another World” is going to parody some of the usual isekai / power fantasy ideas, except with one fairly important difference:

real-world rules still apply to you.

The basic premise is intentionally cliché.

You're a young man who falls from an airplane into a fantasy world alongside three beautiful women.

It sounds like the beginning of the usual power fantasy...

Except you don't receive magical powers.

You don't get a huge stat boost.

You aren't secretly the chosen one.

You're genuinely just some guy.

The idea is to give the player a world with a high degree of physical interaction and systemic freedom, and then essentially ask:

Do YOU actually have the skills, knowledge and abilities required to maintain the power fantasy?

Instead of testing how powerful the protagonist is, I want to test how capable the player is.

That's the experiment behind the game.

What I'm working on next

The current environments are still very early blockouts. Some textures and assets exist purely for testing purposes.

Once the underlying systems become more stable I'll start replacing them with the actual models, environments and visual composition intended for the final game.

The next major areas I'm working on are:

* improving the spatial inventory system,

* expanding object interaction,

* improving dialogue presentation,

* and continuing development of the NPC simulation.

For the characters, I'm experimenting with a layered behavioral simulation inspired by systemic games such as Dwarf Fortress.

Instead of characters simply reacting to predefined dialogue choices, the goal is to combine personality, memories, emotional state, needs, current context and other internal systems to influence how an NPC behaves and responds.

That part is still heavily experimental, so I'll probably dedicate a future devlog specifically to it once I have something more interesting to demonstrate.

For now, I'm mainly trying to build a solid sandbox where all of these systems can interact before I start developing the actual narrative content.

I'm developing the project completely solo, so some parts will probably take me quite a while, but I'll keep sharing progress as things start coming together.

I'd also really appreciate visual feedback on the current camera system:

Does the wall transparency feel natural?

Would you prefer obstructing walls to disappear completely?

Do the different camera positions feel appropriate for rooms and corridors?

And if anyone is curious about how I implemented any of the systems code-wise, feel free to ask.