https://www.youtube.com/watch?v=dKaEGdsr2i8

Bullet heaven meets base building in a survivorslike set inside a broken computer. Fight corrupted files, stack upgrades, and place automated helpers that shoot, shield, repair, collect, and trap while you stay alive.

I'm a part-time solo dev making SpaceLift in Godot, a sci-fi adventure about an engineer trying to survive and repair a failing space elevator.

Here's the trailer. I'd love to hear what you think.

Steam: https://store.steampowered.com/app/4855950/SpaceLift/

A simple LookAtModifier3D goes a long way

We all know solo game development is basically a never-ending boss fight against quite a few enemies, like scope creep and marketing. Personally, those are definitely my hardest problems. Today I wanted to talk a bit about how I tried to keep scope under control while working on my game.

This isn't universal advice, and a lot of it depends on the type of game you’re making. But I figured maybe some of this coudl help other solo devs who are currently one YouTube tutorial away from accidentally turning their "small indie project" into a 12-year MMO development cycle.

simple enemy AI is underrated

One of the biggest traps I avoided was overengineering enemy AI.
At first I had all these thoughts:

• Maybe I should implement advanced pathfinding.
• What if enemies coordinate attacks?
• Should I learn behavior trees?
• How many states should my enemies ' state machine have?

Then I remembered I'm one person and I'd also like to finish the game before the heat death of the universe.
So my final enemy "AI" is simple:

• constantly move toward the player
• move left and right in a zig - zag pattern
• randomly jump every few seconds

That’s it.

No behavior trees. No fancy navigation systems. No "tactical combat decision making." The random side movement and jumping are enough to stop enemies from getting stuck most of the time, and honestly? In motion it feels way better thn it sounds on paper..

keep your art style within your actual abilities

I'm primarily a programmer, both in gamedev and in my day job, so I had to learn Blender from scratch. That alone already eats a huge amount of time.
Then comes the next problem: making a large number of detailed, high-quality 3D assets as a solo developer is hard. Like, 'spend 14 hours modeling a rusty pipe and still hate it' hard.

So instead of fighting that, I leaned into simplicity:

• simple geometry
• heavily reusable assets
• stylized over realistic
• designing assets specifically so they can appear in multiple places without looking weird

These also helped me to have a consistend design language over my assets.

level design should support your limitations

Your levels shouldn’t just support gameplay - they should support your production limits too.

Because my enemies use very simple movement, I designed levels in a way where that movement still works well. Wider spaces, readable layouts, fewer situations where enemies completely break themselves trying to reach the player.

Same thing with assets: levels are designed around reusing pieces as much as possible. If a wall, platform, or prop can appear in ~20 places with minor changes, that’s a huge win for a solo project. A lot of scope creep comes from fighting against your own systems instead of designing around them.

picking tools that let you iterate fast

I specifically chose the Godot engine because it's lightweight, simple to master, and extremely fast to iterate in. The native Blender file importing alone saved me lots of time.
I also intentionally stuck with GDScript instead of C#.

Could I make some systems 'cleaner' or “'ore optimized' in another language? Probably.
But fast iteration beats theoretical perfection when you're solo developing. Being able to quickly test ideas, break things, fix things, and move on is incredibly valuable.
A lot of unfinished projects are technically impressive.
Very few are actually finished.

Final thoughts

I think one of the hardest lessons in solo gamedev is accepting that limitations are not always bad. Sometimes limitations are what actually force the game into a shape you can realistically complete.
Every feature sounds cool in isolation. The dangerous part is that every feature could add:

• more bugs
• more balancing
• more assets
• more edge cases
• more testing
• more time
• more motivation loss Sometimes the smartest thing you can do is intentionally make the 'good enough' version and move on.

Again, these are not universal advice. But these worked for me quite well.

The game I'm working on is called Defrost, and most of the things above are pretty visible in the trailer (hopefully this doesn't break the rules):
https://www.youtube.com/watch?v=QTYLjI8De0g