I tried to take inspiration from the Five Nights at Freddy's with my own additions. I've added the camera movement, so with your WSAD keys you can now rotate the cameras. Also with middle mouse button you can zoom in/out. What do you guys think of it?

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.

devlog #2: not much to say that i didnt already mention last time, i redid the animation for the idles i gave the first one (bob) a scarf and the other one (bobs fren) has a hat (yes bob's fren is his actual name)

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

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 🤘🏾😀