Zareh Garapetian (he/him) is a guest author and game developer of 6+ years.

I knew I wanted to make games since I first played Pokemon at six years old. Now, over 20 years later, I'm finally living that dream as a software engineer for an independent game company.

Today I'll be sharing with you how I got into game development.

If you want to learn game development, it's a dynamic industry full of opportunities. There are many paths to take, and I think it's important to find one that works for you. There will be a lot you'll discover along your journey, and I'll share what I learned in hopes that it'll help you reach your dream career.

We'll cover:

• My journey to game development
• 7 tips if you want to learn game development
• Starting your game dev journey

My journey to game development

The early years

Though I knew I wanted to make games as a kid, I had no idea what that would entail until my early teens. I grew up in Armenia, where there was no active game industry at the time, or industry professionals to which I could look for guidance.

But I did have the internet, so I started researching.

It immediately became apparent that C++ was a popular language for game development. But, as a 15-year-old with limited resources, teaching myself C++ seemed like a monumental effort. So I started learning how to make Flash games instead. The abundance of online tutorials made it easy for me to learn by myself.

If you've ever played games on your computer in the '90s or late 2000s, chances are you've encountered Flash. Adobe Flash used to be a popular game platform, and it's obsolete now, so it isn't applicable to gaming careers these days. Still, learning Flash wasn't a waste – in fact, it helped me in a lot of ways later in my journey to work in game development.

Undergrad & my first job

I started my undergraduate program in Information Technology at the University of Armenia when I was 15 years old. At the time, I had these grand dreams that I would learn graphics programming by the time I graduated. If you're unfamiliar, graphics programming is essentially the work that goes into developing everything you see on a screen in a game.

Unfortunately, my undergrad program had limited resources, and it didn't help that all of the learning materials were in Russian (a language I didn't really know). On top of that, of the 20 computers in our computer lab, only ten would turn on. Of those ten, only five weren't completely riddled with viruses (imagine sharing that between 20-30 classmates).

You may have guessed this already, but I didn't make many learning strides throughout the program. Hopes and ambitions weren't enough. In fact, most of my classmates who learned programming either did it after college, or were fortunate enough to have computers at home that they could use.

To be honest, I was also one of those fortunate ones with a computer at home – but I didn't use it to learn. I just used it to play games in my personal time. I didn't have the self-discipline nor the understanding that I had to commit to teaching myself in my spare time.

It just wasn't clicking for me that I needed to teach myself, especially considering the shortcomings of my program.

Fortunately, I did get some great hands-on experience through my first job during my undergrad years. I worked at TUMO Center for Creative Technologies, which provides free technology education for youth. Even as a 17-year-old hobbyist, I was part of the handful of people who were actually making video games in Armenia at the time. And it turned out that the work I'd done to learn Flash helped me here. TUMO, at that point, was considering using Flash to teach game development. My job was to help determine what the scope of the curriculum would be before the center even opened to students.

Finding my drive to learn

When I graduated with my degree, I felt unprepared to enter the game development industry. I didn't have actionable skills relevant to game programming. I had a few obsolete languages under my belt, and only some of the basics of C++.

While I had a degree, I didn't know if I was even a good programmer, or what my next steps were.

This was when I saw a documentary that changed my trajectory, and the course of my career. The documentary was being screened at TUMO, where I was still working part-time. It was called Indie Game: The Movie. If you haven't seen it, I highly recommend it.

The documentary is about independent game developers who made games either entirely on their own, or with one partner. There was a guy who'd sacrificed his consulting career and underwent hundreds of thousands of dollars in debts to make a game. Another guy was living in a cramped studio apartment with his wife and cats, living on a low income to work on his game. But the common thread throughout each person's story was that each one had a difficulty to overcome, and despite all of it, they made sacrifices to pursue their passion.

The documentary finished, and I remember sitting in the theater in TUMO thinking, "Alright, if these people could take those risks with more at stake than I did, there's no reason I can't take the risk of learning programming while I'm 20 and living with my mom."

I decided to teach myself game programming with C++. If it worked out, it would be great. If not, failing would still be better than not trying at all.

Suddenly, my drive to learn had clicked in, and self-discipline followed suit.

The year of self-study

I wanted another shot at a formal education, and it wouldn't be easy. After all, I had a lot of game programming to learn.

I studied for the SATs and applied for a second Bachelors in the US. I wanted to make up for the education I felt I'd missed in my own undergraduate program.

I knew I wouldn't be attending class for a year, so I put my head down and started learning how to program in C++. I cut down my social life drastically. I still saw friends a couple times a week, but nobody would catch me out at the bars anymore.

One by one, I started getting news from the universities I applied to. I got rejected from all ten of them because, well, schools don't want to admit you for a second Bachelor's!

Those rejections really fueled me. I thought- "I'm going to learn this anyway"!

After receiving my final rejection letter, I instantly applied for a Master's at the American University of Armenia (AUA). Then, I started tackling game programming itself. After New Years of that year, I started my first non-Flash game project. It was a 2D RPG engine. It never turned into a game, but it was the first major project I started.

Throughout the year, most of my learning came from reading books. Two books that were influential for me during this year were a general-purpose programming book called Introduction to Algorithms, and a gaming one called Game Engine Architecture. Introduction to Algorithms lays out the groundwork for computer science. These algorithms are basically the alphabet of computer science (if the alphabet needed a 1,000 page book). The second is great for understanding the technology behind the engines that run games.

There are so many learning resources out there, and I used as many as I could, including conference videos, white papers, internet tutorials, and forum posts on StackOverflow.

Game programming involves a lot of skill sets. At this point, I realized I had to tailor my learning for the job I wanted. From doing research and reading forums, it sounded like graphics and physics programming were the most in-demand skills in the game industry. And because they're generally less competitive, they're good skills to have. (This reasoning isn't how I'd recommend planning your career, but more on that later.)

I ended up picking physics programming. I already liked physics. And I'd already done a little bit of it when I was working with Flash before too.

Video game physics is a subset of engine programming, and basically involves programming the laws of physics into a game. But it's less about making the physics accurate as it is about making it look believable enough to fool the player. 99% of this is just about making sure things don't fall through (or clip into) each other. In the real world, you have things like atoms and chemical bonds that keep things from passing through each other. But video games are just numbers, and a computer only does what you tell it to do. You have to program the physics so that say, if you put an item on a table, it stays on the table instead of sinking through.

Losing my insecurity

I ended up getting accepted into the graduate program at the AUA. My time there helped me finally understand that my educational experience could never determine my worth as a developer. With that, I started losing some of my insecurity about whether I was a good programmer.

I'd wanted to go to a top US university, but the AUA used the same curriculum that was being taught in Berkeley. And even then, because of what I had taught myself during my gap year, I was able to waive half of my required courses.

I also realized that Armenia wasn't isolated in the way that it was teaching things. It was just that, generally, you don't come out of college knowing how to make a game.

A year into my masters, I left my job at TUMO, and spent more of that time teaching myself. I actually started learning physics programming and made a physics engine. I applied what I knew about physics programming to my thesis on the propagation of density waves through sub-stellar gaseous disks (don't worry if that didn't make sense to you). It was basically a computer simulation of black holes, and this is where my previous experience with Flash came in handy because it was similar to the program I would use for graphics and games.

Entering the workforce

After TUMO, my second job was in Armenia working for a game development company that did visual effects. I worked there for a year and a half.

Although my goal had always been to move to the US, I waited a long time to get there. I just didn't know if I had the skills I needed to survive and pay rent and all that.

During my last few months in Armenia, I met a self-taught programmer and member of the GameWorks team. I told him, "I don't know if I'll get a job in the US. I feel like I never went to a real college," and he just looked at me and said, "I dropped out after four months and I'm a VP now. No one cares." With this kind of perspective, I could see that my self-doubt didn't have a place on my path to success.

I was 25 when I moved to San Francisco. It took me about three or four months to get my first job there with a Japanese game company called Capcom. I was doing game engine programming with Unity, using C# (which I'd also learned at some point along my journey). The role was a good start for me. I learned how the industry works, expanded my resume, and eventually moved to Microsoft. At Microsoft, I was doing physics once again, but it was more of a consulting role than a hands-on programming role.

At Microsoft, there was this huge contrast between working in a huge company, as opposed to the smaller teams of my previous positions.

Working in a smaller team, I felt like the things I was doing were really visible. It was very satisfying, and Microsoft was great, but I missed being on a smaller team. I stayed at Microsoft for another year and a half before I was like, "Okay, I want to do something more creative – and I want to actually work on games."

Getting my dream job

When I was ready to leave Microsoft, there wasn't much of a game industry left in San Francisco. A lot of the companies had moved to either Seattle or Los Angeles. There were basically only two companies left in San Francisco that I cared to work for. Both of the companies were small independent game companies.

Ever since I saw Indie Game: The Movie, I wanted to be involved in independent game development. I applied, and to my surprise, I got hired by one of them. I've been working at my current company for over two years now. I can't share the details of my work, but I'm thrilled to be in the indie game world. It's surreal how things came full circle back to this point.

If I went back in time to tell my insecure self that I'd eventually make it in independent gaming, I don't think he'd believe it. And maybe if he knew that all along, he wouldn't have worked so hard to prove himself.

I love the dynamics of working at independent game companies. Generally, decisions at bigger game studios are more heavily led by marketing teams and investors, which affects your creative liberty as a developer. But at independent studios, we get a little more flexibility to take risks and get creative. I work on a small team now, and I love constantly communicating and interfacing with developers and designers. I also get the opportunity to apply (and learn) a lot of different skill sets. In any given month at an indie studio, you can expect opportunities to work on UI, gameplay, and audio. Contrast this with bigger companies, where you could be tasked with making the trees sway for most of that time.

7 tips if you want to learn game development

1. Pick a side: the low level or high level

If you haven't already, you'll want to figure out which side of the game development spectrum interests you the most:

• The low level, where you'll be doing engine programming
• The high level, where you'll make games using premade engines

On the low end, your product is the game engine, and on the high end, it's the game itself.

Today, pre-made game engines like Unity and Unreal allow you to make games without needing to know engine programming. Even though I learned all the low level stuff in my journey, you really don't need to do it if you're not interested. You can just use a premade engine.

Both ends of the spectrum are crucial to game development. They need each other because an engine alone isn't a game and similarly, you can't build a game without the engine. There's a lot of overlap, but they involve a different scope of knowledge.

I like to look at this distinction as, are you interested in the technology itself, or do you want to make games?

Engine programming has to do with everything that happens under the hood in a game. This includes graphics programming, physics programming, and programming animations. A lot of this work will affect the visuals of the game, like the shadows and lighting, and the mechanics of a person running. But you'll also be concerned with the technical details such as speed and performance optimization, memory management, and quality. For example, you'll be figuring out if the game can run on the PlayStation 5 as fast as it runs on a computer. Companies that don't use pre-made engines need developers on their team to work on their in-house engine, which is where you'd come in. You'd also make tools that can help artists make parts of the game (e.g., to make the trees sway or flowers bloom).

If you're just interested in making a game and have access to a game engine, you can make games without getting entrenched in the technical stuff. In any case, the topics that concern engine programming are still involved under the hood of these tools, but there's a limit to how much you can customize them. For instance, you wouldn't be involved in memory management, but you would still be learning the physics system and graphics system for that particular engine.

Choosing the side that's fulfilling for you may take some exploration. If you're into technology and figuring out how things work, you might enjoy engine programming. But as you get deeper into those minute details that fine-tune a game, you might feel a little further from the big picture of the game. If you don't care about the details that affect how the game looks and runs though, just skip the low level stuff and make games with a premade game engine. The caveat is that if you are interested in those low level details, you won't be able to access most of them with a premade tool like Unity and Unreal Engine, so you'll have to relinquish some control if you take that route.

If both of these roles sound equally appealing, you could also explore the in-between role of being a Technical Artist. If you want to make games, but you don't like programming enough to want to stare at code all day, this role involves a nice mix of creativity and engineering. You can combine 3D modeling and programming. You might do some low level programming (e.g., graphics programming), but you won't need to dive deep into the usual low level concerns like memory management. If you're an artist and you find this appealing, it's another option to look into.

2. Narrow your focus and specialize

This advice is a little more relevant if you're looking to do engine programming, but it also applies if you're interested in making games.

It all boils down to the fact that you can't effectively learn all aspects of game development.

No matter your ambition, you'll have to accept that you're just not going to cover all the bases that go into developing a game. You simply can't master modeling, art, sound, animation, and physics programming. If you wanted, you could learn all of those things in time. But if you want to be an effective contributor to game projects soon, you should narrow your focus and specialize. When I was learning, what helped me the most was just picking a focus area. It helped me get a greater depth of knowledge while I learned.

For engine programmers, you'll want to be familiar with as many subtopics within this practice as you can (e.g., graphics, physics, animation, etc). But it's good to have an intermediate understanding of one of these focuses under your belt. In my case, I chose physics programming.

If you're going to use a game engine, just pick one engine and focus on that. You're going to need to learn how to use the engine's sound, physics, and map generation system, you want to cover as many bases as you can of that specific engine. Unlike in engine programming, specializing in one particular area such as audio programming or physics won't get you far with a game engine, because the engine takes care of most of the work for you.

Having a niche specialty just makes you a little more hireable – even if your role isn't going to involve that specialty. For instance, in my current job, I don't do physics programming. But when I told them I knew it during interviews, they were like, "Oh, wow, that would be nice to have. In case we do need someone with this experience, we don't have to worry about it."

3. Build a learning strategy and take one step at a time

I'd been learning various aspects of game development since I was 15 years old, but it wasn't until my gap year that I discovered the benefit of taking one step at a time. When I decided the first rung I needed was the basics of learning C++, I was able to learn much more effectively. That strategy followed me once I got to learning the game-specific skills as well.

Whatever your goals are, build a learning plan that covers the concepts you'll need to know for your dream job. Then tackle one objective at a time.

Once you decide which side of the spectrum you want to work on, you can build a plan for yourself.

If you want to learn engine programming, I'd say to learn C++, build an engine, and learn the libraries you'll need to use (e.g., to program the physics, graphics, and animations). And then, since a lot of jobs require Unity or Unreal Engine, it's probably a good idea to apply what you learned to Unreal and Unity. In my opinion, the skills transfer more easily from engine programming to game engines than the other way around. It's like the comparison between transferring painting skills to Photoshop. If you're a painter, tackling Photoshop is just a matter of learning to use the tool. There's a little heavier lifting if you go the opposite direction though since you'll be learning both the foundations of art and the tool itself. (Side note: There are languages you could use other than C++ as well, such as Rust, but C++ is an industry standard and my personal preference.)

If you're on the game-making side of the spectrum, pick a language based on the game engine you want to learn. Unreal Engine uses C++ and Unity uses C#, but there are other languages that are used for different engines (e.g., Lua, JavaScript, or Python). Pick the one that you're most comfortable with or use the one that's used by the game engine you want to work with. After learning the language, you can use it to implement and learn game-specific concepts for that engine.

4. Showcase your passion in a portfolio

Every developer should have a portfolio of their work, and it's no different for game developers. But your portfolio should display more than your technical skills.

In the gaming industry in particular, people like to see passion. This is true of the places where I've worked, at least. We look for genuine enthusiasm, curiosity, and an eagerness to learn.

Passion is important because it's not easy to work in this industry. There's always some level of instability in your job. So it's good to show that you're really committed to the work for its own sake.

Commitment is also important because the timescales of game projects are so long. Employers want to know you're not just interested but committed enough to follow through on projects with your full effort (instead of stopping midway when things get tough).

On a technical level, your portfolio is showing your skills and your ability to build projects. But the effort you put into your projects can convey your passion and commitment. They should also show that you really like the process of making games.

In my portfolio, I had a physics engine and an RPG engine. I also made a very basic demo game in both Unity and Unreal engine.

Putting extra effort into your demo game can show your commitment and love for the process. Instead of keeping it basic, you can make it a little dynamic. Include audio, a little bit of animation, and a "you win" or "you lose" screen. It's not about making it perfect. You just want to go beyond writing the code for jumping over boxes in a game.

5. Break the game and teach yourself

Most people in the game industry are self-taught. And we learn new things on the job every day.

There’s no single book that will teach you game development. Similarly, no single academic program or bootcamp can teach you everything you need to know. So no matter what route you take, you'll need to know how to teach yourself.

We're lucky that there are so many resources out there to help us learn today – but even these learning resources can't be expected to teach us everything we need to know. You'll need to examine whatever you learn critically. You'll rarely find a resource that's dishing up code that you can reuse as-is in your program. You'll need to apply what you know to figure out how to make it work for your situation.

For example, I learned a lot from online tutorials during my year of intensive self-study. One of the things I learned was making shadows. But you can't just copy/paste a tutorial's code for shadows into any program. You need to do a lot of work to make sure your data is going in the right way. And that's where things get a little more tricky. Unless it's a tutorial series, you have to guide yourself through this step to figure out how to make that code work in a gigantic system that you've already built.

Most of my learning came from following my curiosity. I'd find an interesting concept that I wanted to follow, such as how to make shadows in video games or how to generate mazes for those puzzle books. Then I'd find a tutorial and see how it's done.

As you're exploring topics in game development, following your curiosity will help keep your learning interesting, and could also lead you to the specialty that will fulfill you the most.

6. Make do with what you have

It's easy to get caught up in shiny AAA games like the new God of War, where it's so realistic you feel like you could walk into the TV screen. But a lot of games that go viral aren't that complex. If you don't have access to amazing engines, it doesn't mean you can't make something that goes global. Take Flappy Bird, for instance. That game blew up, and it wasn't super complex.

Game development can have some high technological requirements, and not all of us have the resources to fill those.

Everyone's going to have an ideal opinion about how you should approach making the game. But if you have an old computer that can't run Unreal Engine, then forget about Unreal. Just because the whole industry seems to use Unity, it doesn't mean you need to use Unity. At the end of the day, remember that you're serving the player – and for the player, how you made the game is irrelevant. For all they care, you could've manually used old chip cards while building it or bought a premade game and changed some assets around.

One of the upsides of the gaming industry is that at the end of the day, the person playing your game couldn't care less about how it was made.

7. Do what you enjoy

If you're going to be a developer, you can get paid more and get more job stability in any other industry than games. If you're going into game development, you're not in it for the paycheck or the job stability. You're in it for the love of games. So you may as well take it to the extreme, and just do what you enjoy.

If I could go and tell my younger self some advice, I'd have said, "Ignore what you read on the forums. Just because graphics and physics programming are in high demand, it doesn't mean you should do it."

Luckily, I ended up enjoying engine programming, but initially, I'd really just wanted to make games. And most people who are interested in the game industry want to make the game, not the game engine.

There's undeniably a risk that comes with doing what you love. It might mean that it'll take longer for you to find a job or a stable one. If you can afford to take a risk in exchange for enjoying your career in the long term, then take it. Your learning journey will be more interesting to you, which is its own form of wealth. But not all of us can afford to take risks – if you can't, then ignore this advice!

Starting your game dev journey

Ultimately, your journey starts whenever and however you want.

I got a lot of advice during my own journey, and now I'm the one who's sharing advice. That said, don't take anyone's advice to heart – including my own. If anything doesn't resonate with you, toss it! I know I certainly got a lot of bad advice along the way.

At the end of the day, your game development journey is in your hands. You're the only person with your particular set of playing cards. So, follow your lead and be prepared to learn a lot!

Happy learning!

Liked this piece? Don’t miss any of our other coding stories! Scroll down to subscribe to our blog newsletter. Also, check out my other piece: 7 tips for self-taught devs (& why you should call yourself one)

Continue learning about games & programming on Educative

• Why you should learn C++ for game development
• 6 coding best practices for beginner programmers
• 7 tips for self-taught devs (& why you should call yourself one)

Start a discussion

Which video game has inspired you, or is inspiring you, to pursue a career in game development? Was this article helpful? Let us know in the comments below!