I’m not going to dive deep into technical details. An article called “How C# Classes Work in Unity” might be fascinating. But it’s unlikely to get you any closer to making your first game (at least not for a few years).

At the end of the day, games are more about emotions and experiences than technical implementation.

So let’s start with a simple question: what is every game actually made of?

The Idea

The idea is the reason you’re making the game in the first place. It’s what you want to share with other people. It’s worth defining that reason clearly and reminding yourself of it whenever things get difficult.

It can be anything.

“I want to capture the feeling I had as a kid when I climbed over the school fence after hours and had to run from the janitor.” That’s a perfectly good reason to make a horror game.

If you’re reading this article, you probably already have an idea. Or maybe you just really enjoy reading articles. But if you don’t have one yet, think back to the games you played as a child. Video games came from there. Tags became arcade games and shooters. Hide-and-seek became a horror game. Playing house became The Sims.

The Story

Even the simplest games have a story. Mario is trying to save a princess. The birds in Angry Birds are angry because the pigs stole their eggs. And that’s not even getting into complex RPGs.

You don’t need to come up with the next Crime and Punishment for your first game. Feel free to use the most basic story templates. Just accept that your game should have some kind of story.

Let’s go back to our example of the kid sneaking into school and running from the janitor. Maybe the main character desperately needs to retrieve a book they left behind. Inside are tickets to a concert they’ve been looking forward to for months, and the concert is tonight.

A story gives players a reason to care. It adds emotion to what they’re doing.

If you’d like to learn more about storytelling, I’d recommend this course on Coursera. I personally had no idea how stories were structured when I started (I’m actually trained as a steelworker, of all things), and found it very helpful. It’s short, practical, and explains the core elements of storytelling without wasting your time.

https://www.coursera.org/learn/video-game-story

If that’s not enough, I’d also recommend Creating Character Arcs by K.M. Weiland. Like the course, it’s concise, practical, and full of useful examples.

The Genre

Remember when we talked about having an idea? Now it’s time to think about how you’re going to turn that idea into a game. The same idea could become an RPG, a strategy game, a racing game, or something completely different.

Take our school example. It could become a tower defense game where heroic janitors try to stop an endless wave of students sneaking onto school grounds. Or it could be a racing game. Or maybe it stays a horror game. It all depends on how you choose to approach the idea.

This is also the moment to think about your core game mechanics.

What is the player’s goal? How do they win? How do they score points? What do those points represent? How does the player interact with the game? This is one part you probably can’t outsource to an AI. You’ll have to come up with it yourself.

You don’t need to create a formal design document. Writing a few notes for yourself is enough. What’s important is that you write them down instead of keeping everything in your head. The moment you try to put your ideas into words, you’ll realize how many things you haven’t thought through yet.

Controls, UI, and Visuals

Think about how the player will interact with your game.

Will they move freely around the world? Will they make choices through dialogue options, like in a visual novel? Or will they interact in some other way?

For your first game, it’s important to pick one approach and stick with it. Don’t be afraid to borrow ideas from games you like. After all, every game has a menu button.

It’s also worth mapping out the player’s journey through the game. Most games follow a structure that looks something like this:

1. A title screen and main menu. This is usually where the game loads images, sounds, and other assets, so there aren’t any awkward pauses later.

2. An introduction to the story.

3. The gameplay itself and the mechanics you’ve designed.

4. An ending that reflects the player’s actions.

5. Credits with your name displayed in giant letters.

Almost every game follows some variation of this structure. Feel free to use it as a template for your first project instead of trying to reinvent everything.

Images and Icons

For a prototype, you can simply generate artwork with AI. It’s fast, easy, and more than good enough.

There’s no reason to hire an artist or spend hours drawing things yourself before you’re completely sure what needs to be on screen and where it belongs. For experimentation, AI-generated images are perfect.

Personally, I use ChatGPT to generate images, and that’s been more than enough for my prototypes. Remember: the goal is to finish your first game, not to make it perfect or win Game of the Year.

How Do I Know If My Design Is Good?

Honestly, the best way to find out is to show your game to someone. And to do that, you first have to finish it.

So whatever design you’ve come up with is already a great starting point. The problems you’ll eventually discover are almost certainly not the ones you’re worrying about right now.

If you’d like to develop a better eye for game design, I highly recommend this playlist. It breaks down examples of both good and bad design and, more importantly, explains why they work or don’t work.

https://www.youtube.com/playlist?list=PL8K0_g1wdQeoxta9RyvTK-DnhU4jI2QJN

For building your design intuition, this is more than enough to get started.

And as a bonus, watching it is a perfectly respectable form of procrastination compared to rewriting the logic for the tenth time because the janitor keeps running away from the player instead of chasing them.

Development

So, we’ve finally reached the part where you actually have to build something.

I may be about to say something unpopular, but I don’t think you should start by learning programming from scratch.

Putting everything together - the design, the story, the idea, the sound, the visuals, and making it all work is much more important than knowing how to write code. You can use tools like Cursor or Claude Code. For creating a prototype, that’s usually enough.

The worst thing that can happen is overengineering.

I started making my first game, an interactive essay, in Unity. In the end, I spent several months learning a tool I didn’t actually need, instead of using something much simpler and more appropriate for the project, like Twine.

For a first project, I would suggest limiting yourself to a browser game. AI tools can handle that reasonably well.

But how do you use them if you’ve never tried before?

I would start by describing your idea in a simple document. Literally one A4 page is enough. Write down the player’s journey, the mechanics, and the genre. Then upload that description into any AI tool and ask what is missing. Discuss it a little, refine the idea, and then turn it into a prompt you can use in Cursor.

Before that, you may want to create a couple of helper files, such as agents.md or style.md, to give the AI clearer instructions about how the project should be built.

Sound and Music

I gave this its own section because sound matters a lot.

Sound and music are a huge part of what makes a game feel alive. They create atmosphere and help keep players engaged. Try muting almost any game, even a football simulator, and you’ll notice the difference immediately. Instead of fighting for every ball, you’re just moving a joystick and watching animations.

In our horror game about the student and the janitor, sound can do a lot of the heavy lifting. A floorboard creaks somewhere nearby. A door slams shut. Voices seem to be getting closer. Leaves crunch under your feet.

Those details can make a simple scene feel tense.

Useful Resource for Sounds

https://freesound.org/

Freesound is a large library of free sound effects, ambient recordings, voices, and noises. Make sure to check the license for each file, but for a prototype, you’ll find more than enough material there.

Music

You can generate music with AI tools. I usually use Brev.ai, mostly because I’m familiar with it. Paid plans typically give you the rights to use the music commercially, so using AI-generated tracks in a prototype is rarely a problem.

The goal right now is not to create the perfect soundtrack. The goal is to finish the game.

Putting It All Together

This is the hardest part, but also the most rewarding.

You take all the pieces and make them work together. The music starts at the right moment. The images match the text. The controls do what they’re supposed to do.

What helps me is making a simple checklist and working through it one item at a time. As the project grows, and it will grow, it’s much easier to keep track of what still needs to be done.

The feeling of launching your first game and actually playing it is incredible. Something that was just an idea a week ago, or six months ago, or even a year ago, is now a real game.

The problem is that this stage can go on forever.

You notice a typo in a dialogue. Then a piece of music feels wrong. Then an image needs replacing. Then something else catches your attention. Set yourself a deadline for polishing. Personally, I try to keep it under two weeks.

Players will always find problems in places you never expected. Not in the areas where you spent hours trying to make everything perfect.

A Very Important Principle

Following this rule has saved me months of work.

At one point, I spent several days making the edge of my game’s map animate smoothly because I wanted it to look beautiful, a bit like Civilization. In the end, I removed that mechanic completely.

I’m not saying you should make games carelessly or settle for low quality. What I am saying is that it’s more important to have a complete game than a collection of perfect individual parts. Otherwise, you might grow old before you release your first project.

Don’t try to make Fallout. Make something small. Ten or fifteen minutes of gameplay is enough. Just make sure it’s finished.

Make something you can show to other people.

Releasing Your Prototype

So, you finally have a game. Well, technically a prototype.

It runs on your computer or phone. That’s already a big achievement. But now comes the next question: how do you share it with friends and get some feedback?

You need to put it online. For a first project, I would recommend two simple and free options:

GitHub Pages

A free hosting service from GitHub. Perfect for browser-based prototypes. ChatGPT can walk you through the setup if you’ve never used it before.

itch.io

A large platform for indie games. One of the nice things about uploading your prototype there is that when you send the link to your friends, they’ll think:

“Wow. It’s an actual game.”

What Happens Next?

This is where things really begin.

You collect feedback. You realize the game is boring. People stop playing halfway through. You start questioning all your life choices.

Don’t panic.

Almost every prototype is terrible. (Mine certainly were). And this is your first game. More importantly, it’s a finished prototype. That’s already more than most people ever make.

After that, you’ll start thinking about analytics and marketing. You’ll probably rebuild half the game. Maybe you’ll make a second game instead.

But that comes later.

This article ends with your first prototype.

Good luck with your games. The same idea will turn into a completely different game depending on who makes it. Nobody can make your version except you.

Even if your first games are terrible, you’ll probably love them anyway. I know I love mine.

And one last thing: this is easier than it looks.

P.S.

Just so this all feels a little less intimidating, here’s my first game.

As you’ll quickly notice, it’s not a masterpiece. It’s not going to change the history of game design. But it is a real thing that people can play. It also contains plenty of bugs and mistakes.

https://buildtounderstand.dev/thechoice/

Over time, it eventually turned into this game, which has now been played by more than 10,000 people:

https://thechoice.quest/

So don’t worry too much about making your first game perfect. Focus on making it exist.

I set out to build a simple quiz about the triune brain model.

Instead of a lecture, I wanted people to learn by spotting patterns in their own behavior.

Players apply the model to everyday situations and build intuition about how the different systems work.

This quiz is part of a larger project explaining how depression works and how different brain systems interact in emotional regulation.

Structure

The experience begins with a very short introduction and quickly moves into questions.

The quiz has two stages:

Stage 1. Understanding the differences between the three brain systems.

Stage 2. Recognizing which system is driving behavior in real-life situations.

Learn first, then apply.

Core mechanic

Each question describes a short everyday scenario: reacting emotionally, acting automatically, focusing intensely, or avoiding something stressful.

The player chooses which brain system is most responsible for the reaction. After answering, they receive a short explanation.

Abstract neuroscience becomes a pattern-matching game.

Randomization

Questions are drawn randomly from a larger pool.

This means that each playthrough is slightly different and players can repeat the quiz without getting the same experience.

Result

At the end of the quiz the player receives a summary showing how accurately they identified the different brain systems.

The result also serves as a reflection point. It helps players see which systems they understand well and which ones they still confuse.

Shareability

The final result can be shared on social media.

People share results and compare with friends.

Tools

• Code: Cursor

• Illustrations: custom artwork by a designer

• Music: BrevAI

Try it

https://buildtounderstand.dev/thebrain/

Goal

I wanted to turn ideas from the book Guns, Germs, and Steel by Jared Diamond into an interactive format.

I wanted to show how civilizations develop, which factors influence that development, and how those factors interact over time.

I didn’t want to just retell the book. The goal was to let the player feel the logic through participation. To understand the system by making choices inside it.

Main idea

Instead of presenting history as a fixed sequence of facts, I wanted to make it feel like a chain of pressures, conditions, and trade-offs.

The result changes depending on the player’s choices, so the same longread can end in slightly different ways. That variability helps make the ideas feel more alive.

World design

I created a different fictional map for the project instead of using recognizable real-world geography.

This helped avoid spoilers about which civilizations historically developed faster or slower. It made the player focus on the factors themselves rather than on what they already know from history.

Structure

The experience is built around a simple rule: one turn = one factor.

The player moves through factors step by step, from the simplest to the more complex ones. This creates a clear learning curve and makes the historical logic easier to follow.

Instead of overwhelming the player with everything at once, the longread introduces one important variable at a time.

Beginning and ending

There is a story at the beginning, and it loops back at the end.

I added this frame to create more immersion and to give the player a reason to care about what is happening. It helps the project feel less like an educational article and more like a journey with a clear arc.

Ending and replayability

The final result does more than show what the player has built so far.

It also suggests how the situation would continue developing based on the player’s earlier decisions. This makes the ending feel more like a consequence than a score screen.

It also improves replayability, because different choices can lead to different developmental paths and different interpretations of the same system.

Why this format mattered

The most important part for me was not accuracy in the sense of retelling every part of the book.

What mattered was creating a compact interactive experience where the player could feel how geography, resources, and other structural conditions can influence the rise of civilizations.

I wanted the logic to be understandable through interaction, not just through explanation.

AI tools I used

Code: written with Cursor

Images: ChatGPT

Music: BrevAI

Try the game on itch.io

At the same time, I knew my limitations. So I started looking for a tool that would make things easier.

I began with Unity because I’d read that so many games are made with it, and I had seen countless YouTube examples of Unity projects. I installed it and started learning. About three months later, my game was still technically in its infancy. The story was already in my head, but the technical side was a real struggle. I had chosen a tool that was complete overkill for the simple mechanics I wanted.

I realized I needed a toolkit for Unity and started trying different ones. I even bought Adventure Creator (https://adventurecreator.org/). It definitely sped things up, but it still buried me in details for another six months. The toolkit was excellent and very intuitive, but even it turned out to be overkill for what I wanted - just text + choices, with those choices saved into variables. I got lost in the forest of my dialogue trees and realized I needed something simpler.

After some more googling and watching indie devs on YouTube, I discovered Twine (https://twinery.org/). It had everything I needed to begin: a simple interface for game logic and a way to quickly build a prototype. On top of that, I had once heard a little about HTML and CSS years ago, so at least I recognized some familiar words and syntax.

With Twine, I built the very first version of my game (something I could actually play myself) in just one day. No graphics, just a branching decision tree. BUT IT WORKED! I could open it in a browser and play it through to the end. (It was terribly boring in that first version, but still).

After a couple of months working with Twine, I finished my beta, which is now fully playable:

https://buildtounderstand.dev/thechoice/

The lesson I learned: you don’t need to chase industry standards or use powerful (and really amazing) tools if they’re not necessary. Start from the actual problem and the result you want. Don’t overcomplicate things. A quick result - something you can actually show to someone is often the best motivation to keep going.

I already call myself a game designer. Sure, I don’t have the skills yet, but I’m learning to think like one. That’s why I decided to write about it here, on this blog. First, it gives me the motivation to keep going. Second, I want to record my thoughts and approaches. Writing them down forces me to understand them better myself. And third, I simply love reading real stories of people who start from zero, do it openly, and share how things evolve. So I want to become one of those stories. After all, games for me are above all a way of telling stories.

The first story I want to tell is about human ethics and justice — or, more precisely, what we mean when we talk about them. A few years ago, I was deeply impressed by Harvard professor Michael Sandel’s famous course on Justice (you can find it here: https://pll.harvard.edu/course/justice). I wanted to discuss these complex ideas with my friends. But here’s the problem: none of them were ready to spend dozens of hours digging into the nuances of ethical theories. So I thought, what if I made a game for them? A game where they could step into difficult situations, face tough moral choices, and see how they would respond. Because when you’re forced to choose, you start thinking about why you made that choice, and which principles guided you.

That game exists now, you can try it here:

https://buildtounderstand.dev/thechoice/

It’s beta, but it works.

But I also promised to share what I learn while making games. Since this post is about stories, let me tell you about some of my early experiments.

At first, I made the game like a narrated lecture. It walked players through ethical dilemmas and then explained them. And it was HORRIBLY BORING. I couldn’t even finish playing it myself. But then I shifted the player’s perspective — instead of being an outside observer, they were dropped right into the situations. Their own skin was in the game. And that changed everything. Let’s be honest: it’s one thing to read about a shipwreck that led to cannibalism, and quite another when the one they’re about to eat is you.

And that was the first big lesson I learned: when you tell a story, it has to be the player’s story. Their choices. Their emotions. You can’t really teach something. But you can give people a tool to try it for themselves — and maybe learn through experience.

Don’t explain it in theory. Give them a chance to try, fail, and discover.

P.S. And if you didn’t click the link to my game the first time, here’s a second nudge:

https://buildtounderstand.dev/thechoice/