Helvengard #003
Building My First Real Game

After spending a lot of time working through tutorials, I reached a point where I knew I had to change something.

I didn’t want to follow step-by-step instructions anymore.
I wanted to build something on my own.

Not something big.
Just something real.

Something that I define.
Something that I decide.
Something that actually belongs to me.

At that time, something happened that changed everything.

My son saw what I was doing. He got interested, asked questions, and at some point we said:

Let’s build a game together.

That moment was different.

It was no longer just experimenting.
It became a real project.

We made a simple decision:
We are going to build something — and we are going to finish it.

We chose an idea that felt manageable.

A game inspired by something I used to play as a kid.
A small, structured game with clear mechanics.

On paper, it looked simple.

In reality, it wasn’t.

We split the work naturally.

I handled the programming, the engine, and the systems.
He focused on graphics, assets, and the visual side.

This setup worked extremely well.

Each of us had a clear responsibility.
Each of us could move forward independently.

And that created momentum.

This was completely different from tutorials.

There was no guide.
No one telling us what to do next.

We had to decide everything ourselves.

What comes first?
What do we actually need?
What is essential — and what is not?

Most of the time, we didn’t write things down.
We had ideas in our heads and immediately started implementing them.

And that worked… at least in the beginning.

At the start, everything felt exciting.

We made fast progress.
We saw results quickly.
We built features and tested them immediately.

Sometimes we even took full days just to work on the game.

That phase was incredibly valuable.

Not because everything was perfect,
but because we experienced what it means to actually build something.

But as the project grew, things became more complex.

Systems started to interact with each other.
Small changes caused unexpected problems.
Things that worked before suddenly broke.

That’s when we started to realize:

Building a game is not just about adding features.
It’s about understanding how everything connects.

Despite all of that, we kept going.

Step by step.
Problem by problem.

We didn’t stop when things got difficult.

And eventually, we reached the point where the game was finished.

Not perfect.
Not polished like a big studio game.

But complete.

Playable.
Stable.
Working.

We even published it on Steam.

That experience changed my perspective completely.

Finishing a game is not about perfection.
It’s about bringing something to a point where it works as a whole.

Most people start projects.
Very few actually finish them.

And finishing teaches you things that starting never will.

For me, this was a turning point.

Not because of the game itself,
but because I proved something to myself:

I can take an idea and turn it into something real.

And that’s when I moved from learning to actually building real games.