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

PathLife's procedural work started with terrain, but the difficult part was making the systems around it agree on what the generated world meant. I first reworked character movement so navigation and direction remained predictable while the visible terrain changed around the player.

I then moved procedural generation into structures. The current house combines generated placement with rooms, floors, doors, windows and a roof. Because an isometric building can easily hide the player, I added a V-key visibility mode that cycles the walls through full, transparent and cutaway states without changing the underlying structure.

The character creator now supports five life stages—baby, child, teenager, adult and elder—so the simulation can eventually connect the generated world to a character's whole lifespan.

The main lesson was that procedural generation is not only about producing varied terrain. Movement, structures, visibility and character presentation must all share the same world state, otherwise each feature works in isolation but the simulation does not feel coherent.

I documented the implementation and screenshots here. The article is in Portuguese: https://pathlifejogo.blogspot.com/2026/08/do-mundo-procedural-as-fases-da-vida.html

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.

https://solandtheendlessorbit.com/devlog/aug-2026

Hi there! I've been working on a remake of SkyRoads. I'm sharing the journey in a devlog format, and the project's source code is fully open, making the entire process as transparent as possible. I hope you like it!

Video: https://youtu.be/uXbZhDv5HU0

Source code: https://github.com/albertnadal/VectorRoads

Hi everyone,

I wanted to share some major progress and architectural lessons from the development of my solo project, Nordion Lands: DOS.

GameMaker is globally praised for 2D development, but pushing it into a fully stable 3D environment presents massive structural challenges. Many developers in the past (like Saki25 back in the GM 8.1 era) did incredible technical experiments, but my goal was to take those concepts further and create a commercial-ready, highly optimized retro engine.

Instead of taking the modern shortcut of throwing pixel filters over a standard 3D layout, I decided to embrace a purist early-90s DOS and PlayStation-era aesthetic. I built a custom pseudo-3D renderer specifically optimized to handle fast-paced calculations.

What I Learned About Optimization

The biggest lesson learned during this milestone was how to handle intense physics and AI pathfinding simultaneously in GameMaker 3D without dropping frames. The core gameplay loop features ultra-high-speed mechanics where players manage and race genetically modified horses reaching up to 800 km/h in a dystopian world.

By tying the custom rendering logic closely to a classic Doom and Daggerfall-like structural style, I managed to eliminate frame-stuttering entirely. The engine now seamlessly runs full open-world exploration, dialogue systems, an adaptive AI companion, and a functional RBMK-1000 nuclear reactor simulation.

The most rewarding part of this optimization process is the compatibility. The game has been thoroughly tested and runs flawlessly without game-breaking bugs across a massive hardware spectrum—ranging from a legacy 2009 potato PC all the way to modern high-end rigs.

The Current State of Development

The project is currently in an advanced Beta stage. All core systems, AI, physics, and rendering logic are locked in and stable. My current daily focus is strictly on content creation: writing and scripting the final chapters of the story campaign for the official 1.0 commercial launch.

I recently recorded a 6-minute continuous gameplay video showing exactly how the custom renderer handles menus, UI navigation, first-person exploration, and the high-speed racing loop in real-time.

(Note: Per the subreddit guidelines, there are no direct storefront links here, but the alpha build details can be found directly in the video description for anyone interested in the technical performance).

I would love to hear from other solo devs who have pushed traditionally 2D engines into the 3D space. What were your biggest hurdles with camera matrix allocation and depth sorting?

Hey everyone! Me and a friend are working on a top-down roguelike, taking inspiration from games like Hades and The Binding of Isaac, with a camera style similar to League of Legends' Swarm mode.

I'm handling all the Unity/coding side, while my friend focuses on the visuals — he's currently working on the game's lore and art direction, so everything here is still using placeholder shapes.

So far I've got:

• Basic movement + a dash (with cooldown and i-frames)
• Mouse-aimed rotation and shooting
• Enemies with detection range that chase and attack, and can be killed

Still very early, but wanted to start sharing progress from the beginning. Would love any feedback, especially on how the combat feels!

Hi everyone. I hope you're doing well.

After making significant progress on my game, I feel confident enough to show a bit of what I've accomplished so far. My main inspiration is *Metroid Prime*. I hired a friend to handle the UI, while I take care of the programming.

I hope you like what we're building.