Navigation

What I have learned in 5 years of game development

This year marks my 5th year of game development and I’m kicking off a series of blog posts to document my journey. Think of this as a form of public journaling made by and for myself as a way for me to reflect, track my growth, and share my experiences.

If you happen to stumble across these posts, I hope they inspire you in some way, whether you’re just starting out or somewhere along your own path in game development.

These might sound mouthful, like Zote’s 57 percepts, but I like the irony of reading my past self trying to teach a lesson to my future self. So here goes nothing:

Embrace Mount Stupid

There’s no denying that I too fell victim to the climb up Mount Stupid.

From the foot of it, the peak is right on sight. As soon as I finished my first tutorial, i felt unstoppable. My confidence was at an all time high, and my dream game felt just around the corner.

Mount Stupid

Needless to say that wasn’t the case. But I will admit: my naivety gave me the boost I needed to get started. If you don’t dare you don’t succeed, and I only dared because I was at the peak of Mount Stupid. I started looking right away at procedural generation of terrain, to make a giant open world game, and told myself that even if I failed, I could always sell my terrible 3d models I’ve made in blender with weeks of experience in 3d modelling.

To be honest, falling from the peak wasn’t a harsh reality check that people often make it to be it to be, but rather an eye opening landing that made me discover how much there really is to learn.

Design is everywhere

Having a background in computer science, I’ve always felt more comfortable solving technical challenges rather than design ones.

I love it when I’m told what to do, and I just need to do it. But unfortunately in games, figuring out what to do is often a much greater challenge, at least for me.

While playing games, design is often overlooked. If you don’t notice it, it usually means that the designers made a good job at making their decisions feel natural, intuitive, and invisible.

Every decision is deliberate: where the camera should be pointing after a cutscene? Should jumping cancel an attack? What happens if the player does something before another? And to all these question, there’s rarely a right answer.

I remember that back in school, the subjects I excelled at were the ones with clear right and wrong answers. In math, if you solved every question correctly, you got full marks — simple. But in an essay? Full marks always felt out of reach. There was no perfect answer, only better ways of expressing an idea, and that ambiguity is what designers need to deal with all the time.

Design is not only about the mechanics, that only cover the game design aspect of it, there’s then level design, sound design, narrative design, UX design, economy design, cinematic design… the list goes on. Practically everything in a game is touched by design in some form, and these fields are so different from one another, so.. How does a person even make a game?

This leads to my next point:

Pick your battles

Game developers can’t master every aspect of making games, but they can excel in a few key areas that make all the difference. Some games are celebrated for their mechanics, others for their stories, and others still for their aesthetics.

As developers, we tend to gravitate toward certain parts of game creation. Those become our battles to pick. And losing ground in one area can often be balanced by winning in another.

For example, bold and extreme stylisation might be a clever shortcut for a developer who lacks traditional artistic skills but it can also become a defining signature for the game’s look and feel.

Solo developers have to wear a lot of hats, but some hats will fit you better than others, and that’s ok.

Sometimes Good Enough Is Good Enough

Learn to fail fast

Pretty self-explanatory: learning is a tedious and time-consuming feat, but learning by making is usually the fastest way to improve. Just don’t get too attached to your initial projects when you’re starting out, because you’ll discover better ways of doing things almost every day. You might feel tempted to rewrite your entire codebase every few weeks, but a better approach is to fail fast, let go, and start fresh on a new project armed with your newfound knowledge.

It’s not just about making games, it’s about people

Sometimes, you have to choose between the game and the people who make it, between creating a great game and keeping your team happy. Everyone has different opinions on what makes a game great, and trying to satisfy them all often leads to a game that pleases no one. Sometimes, you have to let go of your vision of the perfect game to make people happy. After all, games are made by people.

This is especially true in game jams, where everyone’s vision often doesn’t align, and with no clear hierarchy, decision-making can become a delicate balancing act since everyone is on equal footing.

But don’t get me wrong: mixing and matching ideas can lead to great ideas too. When diverse perspectives come together, that’s when unexpected and creative ideas have the highest chance to emerge!