You have always dreamed of building your own game? You have gathered countless ideas for the next great games in your head or on paper? You finally want to start working and take them to life? Then you are probably ready to become a game developer. But what now? Where to start and what to do? And what about that thing called Unity?
The world of game development is immense and complex. For beginners it is dangerous to get lost in the wild jungle of game engines and programming languages. While there is a lot of information and many tutorials out there, not all of them provide good advice and few are up to date.
Of course, there is no definite way to get into game dev. You will learn a lot of your lessons through simple trial and error. Therefore, this guide is not meant to be a 100% instruction on how games are made but rather a beginner’s manual or a road map to find a good way into the vast continent of game development.
What’s your job?
Let’s start with a very quick look at how games are actually made. What parts make up a game and what jobs or tasks are required to build it?
A video game is a highly interactive type of media. It usually combines many areas of art with computer programming. Here is a rough overview of the core components which most games are made of.
- Source Code/Engine – Programmer/Software Engineer
- Graphics/Models/Animations – Artist/Animator
- Music/Sound Effects – Composer/Sound Designer
- Levels/Maps/World – Game Designer/Level Designer
- Story – Writer
Of course, there are many variations on these and many more important areas (Distribution, Marketing, Financial, Testing, Tool Building etc.), but these core components and the responsible people basically make a up regular game.
Now in the game industry big titles, so-called AAA-games (triple-A), are often made by a team of hundreds of people. Because everyone is a specialist in his own field, work is heavily separated. These blockbuster games also have huge budgets sometimes even outstripping those of big movies.
The opposite of these AAA-games are Indie games, usually made by small teams or sometimes only a single person. Indie games are usually low-budget, self-funded or crowdfunded (later more on that). Since the mid-late 2000s Indie games have gained popularity and because game development and especially distribution (Steam, App stores etc.) have become easier, the amount of Indie developers has increased tremendously.
Our third category are Hobby games. This is where we will start. Hobby games are made by people who just love to create games in their spare time. This includes absolute beginners who have just started trying a few things but also more advanced developers who may have already released a few small games to the public. The line between hobby and indie developers is often quite thin but let’s just say the difference is that hobby devs usually make their games as side projects to their actual job, studying etc. while indie devs are involved full-time and make or at least plan to make money with it.
As we’ve seen, when we away from the big industry and down to hobby development, the above-mentioned jobs are mostly merged and executed by a single person. And that will be you.
Do I need Programming?
Yes. A game is an interactive medium and the interactive part has to be somehow programmed. Assuming you start as a single person hobby developer, that is as much your job as it is to draw the graphics and design the levels.
Now you might have come across systems like Game Maker, RPG Maker etc. which promise easy game creation without any coding required. While these tools are becoming more and more powerful you will still always be limited to its capabilities. In the beginning it might be satisfying to get something out with very little effort but once you reach a certain level of game dev skills you will get frustrated by the limitations and you will notice that in order to build something that is not completely generic you will need coding nonetheless.
If you already are a coder or at least know some basics, that’s great. Go ahead!
If you have never written a line of code before, that’s great as well, just don’t be discouraged when you hear that coding is hard. Coding is not trivial but first, you can learn it with a very straightforward process and there are many good tutorials and resources on that on the Internet and second, coding does not equal coding. Meaning, as a game developer you don’t necessarily have to be a world-class programmer and there are engines (like Unity) which minimize the coding effort to extending the behavior of objects through sometimes only short snippets of code. This type of coding (Scripting) is rather easy to get into and could be a good start if you want quick results.
Game Engine or not?
Now we’ve already come to one of the biggest questions game devs ask themselves.
~ Should I use a game engine and if yes, which one?
This question really depends on many different factors so let’s break it down a little bit.
I have told you that programming is inevitable in game development and games usually require a huge amount of code. Imagine everything that needs to happen in order to produce one screen of a detailed 3D game. The rendering alone is an impressive feat (if you want to know in detail, look up 3D computer graphics). But at the same time your game has to gather controller, keyboard or mouse input, update all movable and dynamic things, calculate and react to collisions, process AI, play sound, send and receive data over the network…., the list could go on forever.
Luckily, the essence of programming is to reuse code that has been written before. We don’t want to reinvent the wheel and many of the listed tasks work very similar in most cases.
A game engine provides more or less basic implementations of these standard game components. It usually deals with all the low-level stuff like communication with the graphics card, gathering input and loading assets. Therefore, it enables the developer to instantly focus on programming very specific code for his game and not hassle with generic things under the hood.
With the above definition, a game engine would be anything that generalizes any part of a game. However nowadays the term game engine is reserved for more sophisticated systems with a certain extent in functionality.
As you may very likely have heard of Unity, I will just take it as an example of a game engine. Unity comes with a powerful editor which lets you easily build entire scenes with Drag & Drop. It lets you import assets in almost every common file format. It does all the lighting for you. It does all the physics for you. It comes with a lot of presets like a FPS (First Person Shooter) controller or a tree generator. And on top of all that it lets you customize everything through scripts.
You wouldn’t want to imagine everything that is going on under the hood of an engine like Unity. And you shouldn’t care either since you want to focus on your game. Or should you?
The power of modern game engines is impressive and especially because many are for free (at least to a certain extent) it is tempting to look no further and just go for them. However, many of the apparent advantages of big game engines can come to your disadvantage as a beginner.
That is why I want to present an alternative: The Game Library. Later we will compare the strengths of these two options so the question will no longer be Game Engine or not, but rather Game Engine or Game Library. Using neither and building everything from scratch is really not advisable and most likely very unproductive for beginners and should only be considered if you are really serious about understanding all the fundamental theory and math behind computer graphics and more (and if you are a little bit masochistic).
So, to the game library.
Just like the game engine, the game library provides a basis of generic functionality to build your game upon. However, the game library is far more lightweight and does not come with a huge set of tools nor a central editor. It stops at a lower level of abstraction which means less out-of-the-box features but far more freedom, control and flexibility for the developer.
Now, you can probably already guess the essence of the upcoming decision:
~ Feature and Functionality vs. Freedom and Flexibility
In the following section I really want to explain to you when to use which of the two, show up strengths and weaknesses and ultimately help you to decide for one.
Game Engine vs. Game Library
Hopefully, after you’ve read this section your have a clear understanding of the two choices. I tried to compare them in terms of strengths, weaknesses and use cases. The positive and negative scenarios are fictional cases which may help you to imagine a developer’s life with the specific technology.
A: The Game Engine
The Game Engine is the powerhouse, the universal toolkit that enables big 3D games with large game worlds. As a single developer you must be selective and disciplined to avoid getting lost in the vast capabilities of the tool. Use the engine as a solid foundation for your game and benefit from its performance and efficiency. But indulge in the huge selection of preset features and assets and you risk becoming an “asset flipper”, unable to make anything new.
You have concrete plans on developing a 3D role-play game with neat graphics. You want to build a realistic game world which the player can explore. You know how to create 3D models in your own unique style or you know an artist who is doing it for you. You take advantage of the powerful world editor of the engine, so you can immediately start designing your world. At the same time, you start to implement some behavior and interactions via scripts. You can focus on specific gameplay programming, you don’t have to worry about graphics performance or physics. Gradually, your game evolves and is playable at any time.
You are baffled by all the features of your engine’s editor. You discover one preset after the other and want to incorporate all of them into your game. You want your game to have fancy graphics, so you browse the engine’s Asset Store for the best-looking 3D models and effects. In the end you have a first-person-shooter-car-simulator-RPG with no gameplay at all. You have scratched everything on the surface, your mess looks impressive on the first sight but you are nowhere near a playable game.
Use it if:
- You want to build 3D games
- You want to create a first-person-shooter in 15 minutes
- You are a 3D artist
- You plan to work with a team who has experience with a specific engine
- You just want to have fun messing around a bit
- Powerful central editor for assembling the game and building the game world
- High level of abstraction (no boilerplate code required)
- Out-of-the-box implementation of many major development tasks
- Very good platform independence
- Great support and active development/maintenance (depends, but usually)
- Industry standard (more or less)
- High level of abstraction: No control over what’s under the hood
- Proprietary (mostly): Engines are developed by big industry players
- Little transparency
- Very expensive (when making some profit at the latest)
- Immense functionality combined with little knowledge of the inside can lead to many issues (performance problems, unwanted side-effects etc.)
- Often generic-looking graphics in the games (players instantly recognize the engine in which your game was made due to similar lighting, shaders etc.)
Which engine to use?
There are two obvious choices: Unity and Unreal Engine. They are the most common ones especially in the Indie scene. They have much in common: huge community, many tutorials, asset stores etc. and both are completely free for non-commercial use. The are many differences but only few that should concern you as a beginner. If you can’t decide, I would recommend Unity because of its flatter learning curve.
- Very active and helpful community, very good documentation
- A little more lightweight, which makes it better suitable for mobile games
- Scripting Language: C#
- More powerful, graphics-wise and feature-wise
- More out-of-the-box functionality
- Scripting Language: C++
B: The Game Library
The Game Library is the lightweight, portable DIY-kit, leaving room for creativity but also assuming responsibility. The library doesn’t know or care what you want but it will follow you in any direction you guide it. Make use of the director’s role and write maintainable code that will suit your individual needs. But lose overview and control of your code base and risk getting stuck inside development hell.
You like coding and want to apply your skills to implement your game idea of a unique 2D puzzle game. Since you opt for a simplistic graphics style you decide to create the assets on your own. You have written programs before, so you have some knowledge concerning object-oriented design. With that in mind you build your own little engine on top of the game library. The library provides most of the low-level code so you are quickly able to get something on the screen. Consistently, your little engine evolves alongside with your game logic. You have written maintainable and reusable code, so the next time you start a game project you can adopt a lot of code and experience.
You have a great game idea which involves a big map and a multiplayer scenario. You are serious about it and want to make most of it from scratch. With your average programming skills, you start to build your own 3D engine for the game. You are not satisfied with mediocre graphics, so you try to implement a lot of complex graphics features and write your own shaders. When you think you’ve got a foundation and you finally try your engine, you end up with a blank screen. You waste a lot of time debugging and rewriting large sections of code. After a while of hacking around you lose interest in the project, before you’ve written a single line of gameplay code.
Use it if:
- You want to build 2D games
- You have experience in (object-oriented) programming
- You want to learn programming or improve your programming skills
- You want good control over your game’s code
- You want to build small games that take up minimal space
- You like challenges and don’t give up immediately
- High flexibility, low level of abstraction: you get just as much as you absolutely need and no more
- Beautiful and clean code and software architecture, no “ugly” scripting
- Open Source (mostly)
- Low level of abstraction: You don’t get much “for free”, you have to do many basic things yourself
- Usually no graphical editor, no world/level editor included (may have to use third-party tools)
- Limited support, often small community
- Limited platform independence
Which library to use?
My two choices for game libraries are MonoGame and libGDX. Again, both are very similar to use and if you master one you will likely be able to use the other as well. Both are open-source and have a more-or-less active community. Both allow rather good cross-platform development. If you can’t decide, I would choose depending on your preferred language (C# or Java) and if you don’t care either, I would go for MonoGame if you’re using Windows and libGDX if you’re using a different OS.
- Language: C#
- Based on Microsoft’s XNA Framework, Development in Visual Studio, so favors Windows developers
- Strong console platform support (Xbox One, PS4, Switch)
- Language: Java
- Slightly better suitable for mobile, more lightweight
- Supports building HTML5 web games
What do I want to make anyway?
You have probably noticed that the choice of the game engine/library depends very much on the type of game you want to build – which brings us to the next big question.
It’s strange, but many game developers struggle with finding out what kind of game they want to develop. If you are lucky enough to have a huge pool of awesome game ideas that are all waiting to be realized, then that’s great for you. But still, you might wonder which ones you are actually able to build, which one is the most fun to build or which one will be the most fun to play.
As with any creative activity, there is always something that will hold you back from doing. To overcome this, it’s important to know you goals and start producing to get closer to them, step-by-step. Not knowing what to build is bad, because it holds you back before you have even started.
We all know that creativity cannot be enforced. Still, there are some methods that can help you to choose your next project.
Ideas come and go and they appear in any place at any time. Develop a habit to write down every single game idea that comes to mind. Work it out as specifically as you can, document all the details, sketch out an imaginary title screen, draw a concept of a level and annotate special gameplay elements etc.
Documenting helps you not only to clear your head from the countless loose ideas that are swirling around but also to work out your idea in detail step-by-step.
One interesting method I heard about involves brainstorming game ideas in three categories:
- Games, you personally want to make
- Games, you personally would like to play and think would be fun
- Games, you think other people would like to play
After you have come up with some games/game ideas in each category, there hopefully are some games which are in 2 or all 3 categories. Those which are in each of the three categories are precisely what you want to develop.
Public Game Idea Platforms
If you can’t really come up with a good game idea at the moment, there are plenty of resources to look for. Many people on the internet who are not necessarily developers or just don’t have the time to build it themselves post their ideas publicly for others to realize. One place for example is the gameideas-Subreddit:
Many great or not so great game ideas are posted and discussed there and maybe there’s one for you as well.
You’ll probably love this part, as research, here actually means playing games. As in almost any discipline, it’s important to get an overview of the existing repertoire in your area. This not only helps you to get inspired but also shows you what kind of gameplay works and what should be avoided. Furthermore, it prevents you from remaking games which already exists in almost the exact same way.
Now, despite what I’ve just said, you should know that gaming hasn’t suddenly become an ultra-productive activity. And you shouldn’t use “I’m doing research” as an excuse for playing. Still, as an all-round game-developer you should of course be somewhat aware and up-to-date of the good stuff that is out there.
As a beginner, especially try to observe the current Indie game trends as you will be more likely to relate with them. Critically analyze them and look for pattern and elements which you could incorporate into your game as well. Often great game ideas just combine several concepts from different games and create a fresh new genre.
This article will be continued very soon. I will cover the next steps towards your first game and try to get very practical. This will include graphical styles, gameplay tips, distribution, organization, psychological advice and many more…