DEV Community: MT Indie Dev

Does Sharing Devlogs Put Your Game Ideas at Risk?

MT Indie Dev — Wed, 11 Nov 2026 01:52:42 +0000

As a solo game developer, I enjoy sharing what I’m building. There is something satisfying about showing a scene coming together, explaining a problem I solved, or letting someone see how much a project has changed.

But lately, I’ve been asking myself a question: how much should I share before the game is released?

Devlogs invite people into the development process. They give a project a chance to find an audience while it is still taking shape. Yet that openness also means showing ideas that someone else could potentially use before you have finished building them yourself.

That possibility makes me hesitate.

When showing progress means revealing the idea

Sharing lighting improvements or a new environment feels relatively comfortable. Explaining a particular puzzle, a story connection, or an unusual mechanic feels different.

For a mystery game especially, those details can be a large part of what makes the experience worth playing. Showing how something works might reveal both the idea behind it and the surprise intended for the player.

Then there is the thought that someone with more time, money, or experience could see an idea, build their own version, and release it first. I cannot say how likely that is. But when you are developing alone and every feature takes considerable effort, it is difficult to dismiss the concern entirely.

“Ideas are nothing without execution”

This is a common response to the fear of having an idea copied, and I understand the reasoning. A concept still needs design, writing, programming, art, sound, testing, and all the decisions that turn it into a finished game.

Still, that answer does not completely settle the question for me.

Execution matters, but so does the thought that went into finding an interesting premise or designing a puzzle. A developer can spend a long time working out how separate details connect. Being told that the idea has little value until it is finished can feel dismissive of that work.

I would rather ask where the practical boundary should be. What can we share openly, and what benefits from staying private until players can experience it themselves?

There is a cost to keeping quiet, too

Waiting until release would let me develop without constantly deciding what is safe to show. It would also mean giving up opportunities to receive feedback, meet other developers, and introduce people to the game.

I enjoy those parts of sharing my progress. I don’t want every post to become an exercise in worrying about who might be watching.

At the same time, I don’t think documenting development has to mean revealing every important discovery. Perhaps a devlog can show the atmosphere, the work, and the challenges while leaving the central story and the most distinctive puzzles unexplained.

That sounds reasonable in principle. Deciding what that looks like for each post is harder.

Where do you draw the line?

I’m still working out how much of my own development process I want to share. I want people to become interested in what I’m creating, while preserving the details I’ve spent so much time imagining.

So I’d like to hear from other developers:

Have you ever worried that sharing a devlog could lead to someone copying your ideas?
Have you experienced it, or has sharing mostly brought useful feedback and support?
Which parts of your game do you deliberately keep private?
Would you share progress throughout development, or wait until the game is closer to release?

How do you decide when sharing an idea helps your game, and when you would rather keep it to yourself?**

A Phantomatic Nightshift — Version 4 Fixes & Updates

MT Indie Dev — Fri, 06 Nov 2026 04:01:33 +0000

Welcome to A Phantomatic Nightshift, where the dead have paperwork and you have a shift to finish.

A short first-person paranormal comedy about bureaucracy, bad decisions, and ghosts who desperately need a hobby.

🆕📢Version 4 Fixes & Updates:

Prevented ghost clutter the Crossing Office by moving the surgeon in the lobby room

Added splash intro

Added CRT material to the Lobby TV

Made the non-quest interactables more visible

Added Crossed names on the Crossing List after each Phantom Pass

Added Lobby Ticket No. incrementation after each Phantom pass

Changed the portal material due to eye comfort

Added intractability to the rules poster. Press E to better see the rules poster

Added Main Menu button functionality in the credits level

Become a Medium member
Subscribe to Pro Writer Tools to remove upgrade prompts from your unlocked stories.

Added on-level Radio Ghost

Enabled VSync to prevent screen tear

🆕📢Version 3 Fixes & Updates:

Camera twitching and sudden rotation

Finished the highlighting system for interactable objects

Changed the menu background

Added a Main Menu button in the credits level

Fixed the prompts appearing after objects are no longer interactable

Changed some wall and ground textures to ones more decent

Fixed several aesthetic bugs

fixed audio lined playing on top of one another

Shortened the Exorcism prayer

Quest Widget fades with the ending fade

https://gamejolt.com/games/a-phantomatic-nightshift/1115136
https://mt-indie-dev.itch.io/a-phantomatic-nightshift

A Phantomatic Nightshift - Game Updates

MT Indie Dev — Wed, 04 Nov 2026 12:08:25 +0000

🆕📢Version 3 Fixes & Updates:

-Camera twitching and sudden rotation
-Finished the highlighting system for interactable objects
-Changed the menu background
-Added a Main Menu button in the credits level
-Fixed the prompts appearing after objects are no longer interactable
-Changed some wall and ground textures to ones more decent
-Fixed several aesthetic bugs
-fixed audio lined playing on top of one another
-Shortened the Exorcism prayer
-Quest Widget fades with the ending fade
-Available on both itch.io and Game Jolt

https://mt-indie-dev.itch.io/a-phantomatic-nightshift
https://gamejolt.com/games/a-phantomatic-nightshift/1115136

A Phantomatic Nightshift

MT Indie Dev — Sat, 31 Oct 2026 22:42:44 +0000

The dead have paperwork. You have a night shift to survive.

A Phantomatic Nightshift is a short first-person paranormal comedy set in the Romanian Bureau of Phantomatic Crossing. Help peaceful ghosts reach purgatory while dealing with possessed office equipment, mischievous spirits, and a growing suspicion that declining professional backup was a terrible idea.

It’s a night of bureaucracy, supernatural nonsense, and ghosts who clearly haven’t read the office rules.

👻 Play it on Windows: https://mt-indie-dev.itch.io/a-phantomatic-nightshift

Free Assets and the Stigma people enforce behind them

MT Indie Dev — Fri, 23 Oct 2026 19:00:28 +0000

Would you use free assets in your games?

I would, and I don’t think there’s any shame in it.

I’ve never really understood the stigma around using free assets in game development. Sometimes, people talk about them as if downloading a free model or sound somehow makes the rest of your work less valuable.

But why?

For anyone unfamiliar with the term, assets are the individual things that go into a game: trees, buildings, characters, sounds, animations, textures, and so on. Making all of those takes time, and creating a game involves much more than making its individual parts.

If someone offers a useful asset for free and allows others to use it, I see that as an opportunity.

Free doesn’t mean bad.

The price of an asset doesn’t tell you whether it looks good, works properly, or fits your game. A paid model can be unsuitable for your project, while a free one can be exactly what you need.

Some creators choose to share their work because they want to help other developers. Kenney, for example, makes its game assets available under CC0, allowing people to use them without requiring credit. These resources are offered for a reason: so people can build with them.

There’s nothing embarrassing about accepting that help.

Your time matters, too.

Imagine you need a simple chair for a room in your game. You could spend days learning how to model it, give it the right surface details, and get it working in the engine. Or you could find a suitable free chair and spend that time improving something the player will actually do.

Neither choice is automatically wrong. If you want to learn how to make furniture, creating the chair yourself makes sense. If your goal is to finish a playable game, using an existing one might make more sense.

Personally, I don’t think developers should feel pressured to spend days proving they can make an ordinary chair when their game needs attention elsewhere.

That time could go towards a better mission, smoother movement, clearer menus, or fixing an annoying bug.

A downloaded asset doesn’t build the game for you.

This is probably the part that gets overlooked most often.

Downloading a door doesn’t make it open. You still need to decide how the player interacts with it, whether it needs a key, what happens when it’s locked, and how it connects to the rest of the game.

Downloading trees doesn’t create an interesting forest. You still have to build the space, create paths, place things thoughtfully, adjust the lighting, and make sure the game runs well.

The person who made the asset did valuable work. The person who turns it into part of a playable experience also does valuable work.

Using someone else’s model doesn’t erase everything you built around it.

You can use the same pieces and create something different.

Two people can cook with the same ingredients and make very different meals. I think game assets work in a similar way.

The same house model could become a peaceful home in one game and an abandoned building in another. Different lighting, sounds, surroundings, and events can completely change how that place feels.

Custom artwork can certainly help a game stand out. But a game’s identity also comes from its ideas, its atmosphere, its story, and the way it plays.

Every rock and table doesn’t need to be exclusive for the overall experience to feel personal.

Free assets help you find out whether an idea actually works.

An idea can sound amazing when you write it down and feel completely different once you try to play it.

Having models, sounds, and animations available lets you reach that playable stage sooner. You can test a mechanic, try a different layout, or discover that something needs changing before spending months making everything yourself.

And if a free asset still works well in the finished game, why replace it purely because it was free?

I’d rather replace something because it doesn’t fit or causes problems, not because I feel guilty about how much it cost.

Not everyone has a studio’s budget.

A solo developer might be handling the gameplay, environments, menus, sound, testing, and writing. That’s already a lot for one person.

They may not have the money to hire people for every task, or the years needed to become good at every part of development.

Free assets make it easier for people to learn and give their ideas a real chance. They can also leave room in the budget for things that need special attention: perhaps an original main character, music, or an important location.

Using free resources where they fit can help you afford custom work where it matters most.

Of course, you still need to choose carefully.

Not every free asset belongs in every game.

Some won’t match the look you’re going for. Some might slow the game down or take too much effort to adjust. You also need to check what the creator allows you to do with them and give credit when required.

And you should be honest about your contribution. Using someone’s model is fine when you have permission. Claiming you made that model yourself is a different issue.

Those are fair things to discuss. But none of them makes using free assets shameful.

Judge the result.

If a game looks messy, runs badly, or isn’t enjoyable, those are fair criticisms. Explain what isn’t working.

Simply saying “that’s a free asset” doesn’t tell me what’s wrong with the game. Paying for the same object wouldn’t suddenly make the gameplay better.

For me, the question is simple: does this asset fit what I’m making, and does using it help me move the project forward?

If the answer is yes, I’m happy to use it.

I respect people who create everything themselves. I also respect people who know where to spend their time and use the resources available to them.

So yes, I would use free assets in my game. Why should a useful resource become something to be ashamed of just because it didn’t cost money?

An Indie Solo Gamedev's perspective on Public Building(credits to Hanzla Baig for the ideea)

MT Indie Dev — Thu, 22 Oct 2026 15:57:55 +0000

Indie game development often begins with something deeply personal you really want to build. An atmosphere you want to create. A story you cannot stop thinking about. A mechanic you would love to experience as a player. Before anyone sees a screenshot or watches a devlog, there is already a reason you chose to build this particular game.

Then you start sharing it.

At first, building in public feels exciting. You show a mechanic, someone responds, and suddenly the work you have been doing alone becomes a conversation. A little encouragement can mean a great deal when you are learning, solving problems, and trying to turn an idea into something playable.

But that attention can gradually influence more than what you post. It can begin to influence what you build.

A visually impressive feature receives more interest than a system you spent weeks developing. A funny bug attracts more attention than an important milestone. One particular style of content performs well, so you make more of it. That is understandable. When something connects with people, you naturally want to understand why.

The difficulty begins when that response becomes the main reason behind your next decision.

You start choosing tasks partly because they will make a good upload that people will engage with. You spend time polishing something for a video while another feature, essential to the game, waits unfinished. You feel reluctant to share quieter progress because you already expect it to be ignored. Slowly, the audience’s preferences begin taking up space once occupied by your own intentions.

No one has explicitly asked you to change your game. Yet you find yourself changing its direction to keep people interested.

For a solo developer, this can be especially difficult. You are already responsible for learning, implementation, debugging, design, and countless decisions. Sharing development adds another responsibility: presenting that work in a way people want to watch. Eventually, it can feel as though every development session must also produce something worth posting.

Some progress simply does not work that way.

An evening spent fixing an interaction problem may produce no striking footage. Reworking a confusing interface might look like a small change despite requiring considerable thought. Building a reliable foundation can take weeks before there is anything exciting to demonstrate. Those efforts still matter to the person who will eventually play the game, even when they attract little attention online.

The emotional difficulty comes when you begin using that attention to judge yourself.

It hurts to put care into something and receive almost no response. It can hurt even more when people previously engaged with your work, then lose interest as you return to the direction that makes you happy. You may start questioning your ability, your project, or whether the effort has any value at all.

For some developers, that pressure can contribute to exhaustion, low mood, and eventually the decision to stop. An activity that once offered encouragement becomes another place where they feel they are falling short. A passion once holding you together starts breaking you apart!

That possibility deserves an honest conversation. Building in public can bring connection and useful feedback, but it can also become emotionally draining when every post feels like a verdict on your future.

I still choose to share my development. I have not received all the interaction I hoped for, and I will not pretend that never disappoints me. Of course I want people to care. Sharing something personal usually carries the hope that someone else will find meaning in it.

But I also want to recognize my own game when I look at what I am building.

I want to make decisions because they serve the experience I imagined, while remaining open to feedback that can improve it. Players can reveal confusing mechanics, unclear information, or problems I have overlooked. Listening to them is valuable. I can take those observations seriously and still decide which suggestions belong in my project.

The same applies to posting. I want to share when I have something I feel ready to show. A regular schedule may help some developers, but I do not want mine to become an obligation that makes development feel like feeding a content calendar. Sometimes the work needs time, privacy, and room to be unfinished.

If you enjoy what I share, thank you. Your interest means something to me. If it does not appeal to you, I appreciate you taking a look. There is no formula that will make one game meaningful to everyone, and trying to find it could consume the very enthusiasm that made me start.

For me, continuing means accepting that some updates will receive little attention and some people will move on. I can feel disappointed without allowing that disappointment to choose the next feature.

I started with a game I wanted to create. Sharing the journey should leave enough room for me to keep creating it.

Tea House Area - Fencing, Pathways, Pond Area | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 22:42:19 +0000

In this Life of Alex devlog, I continue building the tea house area at Kazuhara Resort in Unreal Engine 5. This update focuses on defining the space with fencing, adding stones along the pathways, and introducing a pond with a bridge and fencing around its edges.

Piece by piece, the area is taking shape, with clearer routes through the garden and more detail surrounding the tea house. Join me as I bring these elements together and continue shaping a peaceful setting to explore.

Landscape creation and terracing process for Kazuhara Resort | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 17:48:55 +0000

In this devlog, I showcase the landscape creation and terracing process for Kazuhara resort in Unreal Engine 5. Using Landscape Mode’s Sculpt, Flatten, and Smooth tools, I shape the terrain, create distinct terraces, and soften the transitions between elevations.

The focus is on building a foundation for the resort, balancing usable flat areas with the natural slopes of the surrounding landscape. It’s a look at the work behind shaping the environment before the finer details bring it to life.

Evening the Terrain & the construction of Road Infrastructure | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 17:43:28 +0000

In this devlog, I continue shaping Kazuhara Resort by evening out the terrain and building its road infrastructure in Unreal Engine 5. The focus is on preparing the ground and creating routes that connect the resort’s different areas.

I showcase the Flatten and Smooth tools to level uneven surfaces and soften transitions, the Ramp tool to connect different elevations, and the Landscape Paint tool to define the road surfaces. These changes help establish the resort’s layout and make the terrain more practical for further construction.

Ragdoll Physics Issues | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 17:33:54 +0000

While implementing player death and ragdoll physics, I ran into a persistent Chaos physics issue. The death system and ragdoll activation work correctly, but once the body hits the ground, it begins violently twitching, bouncing, and rotating, sometimes appearing to push through the Landscape.

I tested several potential causes, including terrain collision, CCD, impact velocity, physics simulation nodes, modular mesh collision, damping, collision presets, and constraints, but the instability remained.

During debugging, I also discovered that I had initially been troubleshooting the wrong Physics Asset. After switching to the correct one, the issue still persisted.

The current investigation is focused on the Physics Asset's collision bodies and whether overlapping or conflicting bodies are causing Chaos to continuously apply forces to the ragdoll.

Death system: working

Ragdoll activation: working

Possessed inflatable tube-man physics: still under investigation.

Sprint & Stamina | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 14:56:04 +0000

This devlog showcases my Blueprint-based sprint and stamina system and its integration with the player’s health and thirst.

Hydration decreases at a normal rate while walking. Sprinting consumes stamina and accelerates hydration loss, giving faster movement an additional resource cost. Once stamina is depleted, the extra hydration drain from sprinting stops, while the normal drain continues. If hydration reaches zero, the player begins losing health.

These connected systems make resource management part of traversal. Players need to balance speed with their physical condition, using drinks to restore hydration and medkits to recover health. The UI tracks each stat and highlights critical levels, providing clear feedback as resources run low.

Interaction Awareness System – Custom Depth & Icon Widgets | UE5 Devlog

MT Indie Dev — Wed, 21 Oct 2026 14:49:52 +0000

Hello everyone!

In this development log for Life of Alex, I’m showcasing the interaction awareness system I’ve built to help players identify objects they can interact with naturally while exploring the world.

The system combines icon widgets with custom depth shaders, allowing interactable objects to provide clear visual feedback without overwhelming the screen or breaking immersion.

Icons help communicate available interactions, while the custom depth effect highlights relevant objects and makes them easier to distinguish from the surrounding environment.

This system is part of my ongoing work on making exploration and interaction in Life of Alex feel intuitive, responsive, and visually consistent.

Life of Alex is currently in early development, so everything shown is still subject to change as the project continues to grow.

Follow the development journey for more systems, environments, gameplay mechanics, and behind-the-scenes progress.