VOID//SIGNAL — Final Devlog

After way too many hours of coding, debugging, testing, breaking things, fixing them, and occasionally staring at the compiler wondering what I did to deserve this, I finally finished VOID//SIGNAL.

What started as a simple idea turned into a much bigger project than I expected. I wanted to make a small sci-fi game about a robot trying to survive on a damaged ship, collect resources, solve problems, and eventually find a way home. Somewhere along the way, that turned into crafting, weapons, enemies, puzzles, multiple areas, hazards, salvage, terminals, dialogue, and an unhealthy amount of C++.

So… what did I actually make?

VOID//SIGNAL is a small sci-fi survival/exploration game built in C++ with raylib.

You play as a robot whose crewship has been destroyed, leaving you stranded on a damaged ship. Your goal is to explore the different sections of the ship, recover useful resources, repair systems, deal with hazards and corrupted drones, solve puzzles, and eventually work your way toward escaping.

The game has several different areas to explore, each with its own problems and objectives. There are also different resources to collect, crafting systems, weapons, salvage, environmental hazards, and interactive systems that make the ship feel less like a collection of rooms and more like something that is actively falling apart around you.

I also wanted the game to have its own visual identity without relying heavily on external assets. A lot of the visuals are drawn directly through raylib, including the rooms, interfaces, effects, lights, and other environmental details.

Basically, I wanted to see how far I could push a relatively simple setup and turn it into an actual game.

What was challenging?

Probably the hardest part wasn’t making one individual feature.

It was making all of the features work together without destroying each other.

At first, adding something new was pretty straightforward. Then the project got bigger.

Suddenly, adding a crafting system meant thinking about inventory and resources. Adding weapons meant connecting those resources to another system. Adding enemies meant dealing with combat and waves. Adding rooms meant making sure objectives and interactions worked correctly in each area.

And then C++ would occasionally remind me that I had become too confident.

There were definitely moments where I would fix one error, compile the game, discover another error, fix that one, compile again, and somehow create a completely different problem.

The crafting system was one of the bigger challenges because I ended up separating it into two different systems: the robot’s own crafting system and the dedicated weapons table. I wanted the two systems to feel different instead of having one giant menu that tried to do everything.

The enemy wave system was another challenge because it had to work alongside the rest of the gameplay instead of just spawning enemies randomly and calling it a day.

And then there were all the smaller things that nobody really notices when they work correctly: interactions, room transitions, objectives, UI, hazards, resource tracking, puzzles, game states, and making sure the player can’t accidentally break the entire game by pressing something at the wrong time.

What am I most proud of?

Honestly, the biggest thing I’m proud of is that I actually finished it.

It’s very easy to start a game project and keep adding ideas forever. At some point, I had to stop thinking about what else I could add and actually make everything I already had work together.

I’m also proud of how much of the game was made from scratch. I didn’t start with a giant game engine or a huge collection of assets. I built the systems myself and used raylib to handle the actual rendering and game functionality.

I’m especially happy with how the different mechanics ended up connecting.

Exploration leads