Introduction
I recently had the opportunity to share some tips and tricks with game development students at both Stockholm University and the Swedish Game Awards Conference - and since I don't seem to have made too big a fool of myself, I thought I should share the Toolbox I offered with the rest of the world as well. This is a list of things that will hopefully stop budding game developers from reinventing the wheel and tumble into pitfalls that others have already been in. The insights below have been collected while I was working at a publisher, a mid-size developer and my own indie company, as well as from other people.
Just like with a physical toolbox, you don’t have to use all of these tools. You might find that some of them are like those weird ones in the corner you don’t really know how to use. Some, however, might turn out to be your hammer and screwdriver.
So, let’s get started!
(By the way, you might need some popcorn. This is a long one.
The Toolbox
1. Make games
It pains me to see how necessary this point seems to be, when it should be fairly obvious. If you are a game student and plan to work with games for a long time, you should at the very least put in 8 hours a day, and do so with joy! I’m not saying you have to start crunching even before you get your first job - but you can't be bothered to at least spend the equivalent of a normal work day on studies and game development every day, how can you assume that you will enjoy actually working in the games industry?
You can either go the whole mile and spend your spare time making games with friends or on your own, or you can focus on the part of game development that you have a personal interest in - be it making 3D models, writing, modding, or what have you. This will show a future employer that you have passion and ambition, which will give you a brightly colored life vest out in the sea of students who want to break into the industry. More than that, you will have things to put in your portfolio, which is critical when looking for a game job.
2. Make mistakes - and admit it
Your time as a student is the ideal, safe environment to try new things, and to fail. So do it! It is okay to make mistakes - as long as you admit them, learn all you can from the experience, and then move on. To many people, trial and error is the best way to get familiar with new things, so embrace that and create an environment among your fellow students where it is okay to fail. If you don't have that, people will not make less mistakes - they will just lie more about it. What sounds like a more sustainable way to make a game, do you think? You will also learn more this way, as you will be less likely to take the safe path you already know.
This might seem horrible but personally, I get inspired by other people's mistakes. Hearing about failed projects, or even better the mistakes a developer did on a successful project, makes you look at yourself and your own projects in a new light. Surely if they could do that, you should be fine? It makes people you admire look human and their accomplishments more reachable, which, if nothing else, helps relieving imposter syndrome.
3. Ask for help, pay it forward
For some, asking for help when needed is probably the most natural thing in the world - but for others, me included, it really isn't. You want to be the lone hero, who can tackle any challenge on your own. That, however, can be directly harmful. Few will acknowledge your ability to isolate yourself and create something alone - it's far more likely that people will appreciate your ability to show that you are human and not too proud to ask for help.
Time for a personal anecdote! When I did not land a publisher for my game Midvinter, I was really bummed out. I cancelled the dev stream I had planned for that evening, and more or less wanted to shut myself in and not meet anyone for a few days. But then I remembered this great TED Talk by Amanda Palmer. In it, she basically encourages people to show vulnerability and ask for help - because that is when other people will step up and shower you with love. So I wrote a message for my friends and followers on Facebook, explaining the situation with the publishers and asking them to please share and like posts, so that I could get more visibility through them. The response was overwhelming (for a company that size), which of course proved that I have awesome friends - but also that people are more than willing to show that they have your back when you ask them to. Keep that in mind!
Just don’t forget to offer support back to the people who help you, and be there when they actually need you. Also, pay any help you get forward to others. We all benefit from an open industry where people help each other, so it’s win-win-win all around.
4. Game Jams
Just like your time as a student is a great time to try new things, so are game jams. You go through almost all phases of game development in just a few days - and even if you do not have a finished game in the end, you will most likely have learned a lot and made some new friends. If you are not able to make it to the ones that take place in a particular physical location, there are many that run online over for example one month. On the final day, you simply submit your game to the jam’s website. Check out itch.io for jams like that!
5. Open Development
As a small developer - either while you still study, or if you chose to take the indie path after graduation - you can’t afford to have secrets. AAA companies do, but they also have marketing budgets the size of small countries’ yearly expenses. In order to sell your game in the end, you want to build a fanbase already during development - and what better what to do in than to include people in what you are doing? Make them feel involved, and they will be so much more loyal to you! A nice side effect is also that you learn a lot from watching other people playing your game and discussing ideas with them. They will most likely find things to do with the game that you did not even know about yourself, and tell you that the best part of your game is something you would never have anticipated.
Remmeber, ideas are cheap - execution is everything.
Let me write that again, in bold.
Ideas are cheap - execution is everything.No one is going to steal your idea. If there is one thing the games industry has in abundance, it’s ideas for games. Even great ideas - mindblowing ideas - are as common as bugs in the production phase. What matters is what you do with your idea. Therefore, you are better off allowing people to give input on your game, adjusting your development based on their opinions. It’s the difference between protecting an idea that in the end is not interesting to anyone, and making a game in the open that aligns with what people actually want.
6. Unique Selling Point
In my experience, students are good at making pretty cool games, but not necessarily unique ones. To some extent, that’s okay - you need to learn the craft before you can master it, and looking at what other people have done is a great way of doing that. If you want to sell your game at some point, however, you will have to give a good reason as to why someone would buy your game instead of the one next to it.
The Unique Selling Point (USP) is what makes your game stand out from the crowd. What’s the edge? What’s the deal? This, you will have to be able to communicate to your consumers - and also investors and other potential partners (more about that below).
You see, back in the age of physical games on a shelf, you competed only with the games released at roughly the same time as yours. After a while, they were replaced with other games, and so it went on. Today, as we continue to move more and more towards digital platforms, you compete not only with the games released at the same time, but also all the games ever released on that platform. If you make a game inspired by DotA 2 and put it on Steam, you are competing with DotA 2. The player needs to have a clear reason as to why they should choose your game instead of all the other games in the same genre.
7. Elevator Pitch
Imagine that you step into an elevator, and - lo and behold - standing there is a representative for a publisher, or your CEO, or maybe a journalist. You have one minute to pitch your game idea, before they get out of the elevator. Go!
The elevator pitch is a quick description of your game, with a good reason as to why someone would be interested in it. The USP needs to be front and center, most likely along with a mention of theme and setting.
If you are heavily inspired by the Diablo game series, you might feel compelled to say something like:
“It’s kind of like Diablo”.
Expand on that!
“It has much of the gameplay of Diablo 3, only your primary weapon is a badass rocket launcher. Also, it takes place in the New York subway system.”
While that might not be the best idea ever (but how about that game with excellent execution?), it gives a fairly good view of roughly what you would experience while playing the game. The listener will be much more interested in learning more, than if you would have stopped at the first sentence.
This is hard, no doubt about it - but it is worth it. If you have trouble finding your Elevator Pitch, I would recommend going to conferences and game developer meetups, if you are able to. In an environment when people are more than happy to hear what others are working on, you will most likely have plenty of opportunities to tweak your pitch and fine-tune it based on the reactions you get.
8. Synchronize within the team
While you and your team are working on your game, you may suddenly find that you have some trouble knowing what kind of game you are actually making together. The artist’s colorful, Blizzard-esque art might not work with the writer’s dark and gritty noir story, and suddenly you realize that the programmer has implemented a complex crafting system for a game focused on sneaking. It could work - but without great execution and clear leadership, you are more likely to end up with a game that feels like it doesn’t know what it wants to be.
A former colleague taught me a good way to avoid this. Everyone on the team should write down the game’s elevator pitch - in their own words - on a piece of paper. If these all turn out to be more or less the same, you seem to be fairly synchronized when it comes to what the game is all about. If not, you will have to take a step back and agree on what your vision is, before you continue.
9. Minimum Viable Product
When making, say, a set amount of characters to your game, don’t work on one until it is 100% done before you move on to the next one. Instead, make the right amount of okay characters first, and then iterate, itarate, iterate. The product of each iteration should be a model that’s a bit better than the last one, and good enough to show other people while still not necessarily all the way there. This way, you minimize the risk of running out of time and/or money all of a sudden, leaving you with one perfect character and a bunch of white capsules.
You also decrease the risk of wasting time on unnecessary things. One example: I recently heard about a student who had made an enemy for their game that was probably good enough for Pixar. Every hair of its fur was there, and it was beautifully animated. The only problem was that it had to be very small once in the game, so none of the details would actually be visible to the player. If they had just thrown an early, rough draft into the game right away, they would have realized that much earlier. In the end, the student could probably have spent a couple of weeks or even days on the character, instead of two months.
It’s also easier to get feedback on your game and the part of it you are making this way. Instead of going “oh and all those gray boxes will be buildings”, you can then say “those buildings are WIP (Work in Progress), but I think you get the idea”. If the viewer is at least somewhat experienced, they will see in which direction you’re heading. It’s easier to test the game this way as well, for the same reason. It’s hard to make sure for example the combat system works properly when it’s just boxes jumping around - even the most crude models will help visualizing what you have in mind.
10. Plan
When you get that great game idea you will most likely be tempted to just jump straight into it and start coding right away - trust me, I know. But try not to do that. Start by planning the project, both when it comes to time estimates and schematics for the systems themselves. How will the features interact with each other? What exactly can the player do when in the Marketplace? All things like that should go into your Game Design Document (GDD), before you write even the first line of code.
When you know which systems you want to use, start estimating how long time it will take to implement them. This, of course, goes for art, writing, sound etc as well. It always takes longer to create something than you think, so be generous here. If you have a financial budget to stick to, this is where you go through that as well. Make sure you know how much leeway you have if the project takes longer than anticipated, and remember to put some money aside for things like software licenses and marketing. This is an artform in itself, so I recommend reading other, more in-depth articles on the subject.
Once you are ready to start developing the game, make sure the whole team is up to speed with what everyone else is doing, whether or not you are on time, and what is next in the pipeline. This is achievable by using a Kanban board and/or Scrum. You can keep your tasks in either a physical or digital place - as long as you do keep track, and everyone in the team has access to the same information.
11. Production, Alpha, Beta, GM
Let us quickly look at the stages a game normally goes through when in development. People will tell you different things here so don’t take for granted that your future employers use exactly these definitions - but I will use terms I have been taught and am personally comfortable with.
Going from left to right in the bar representing development above, you will find that the majority of the time consists of production and pre-production. Their relative sizes may of course vary a lot, but this simply means that a well-planned projects spends a lot of time preparing for production and then even more just creating the basic systems.
When the game is starting to shape up, you enter Alpha. A good definition of Alpha is “feature complete”, which means that if you want an approved Alpha build, all systems will have to be implemented and working (albeit with a few bugs). This means that for example the dialog system needs to be in the game, but all dialogs do not have to be finished. It is important to remember that after this phase, you can no longer implement new features. It is far too dangerous, since you risk breaking other features late in development if you do.
To get an approved Beta build however, all those dialogs mentioned above need to be in the game. They are allowed to have flaws, but there can no longer be any major placeholders. Beta can therefore be described as “content complete”. Character portraits, animations, sound effects, game modes - they should all be done and implemented at this point.
After the Beta phase, you are getting close to release. There are many different words people use here - but for the sake of this post, I will only use Gold Master (GM). The term comes from the music industry, and refers to the actually golden disc which all other records were copied from. For games, that is the build that is as close to perfect as it can be. After completing a GM build, you should freeze the code and not touch it between then and the actual release. If you still have fixes to make before release, you should work on a separate build meanwhile, and release a stable version as a day-one patch. This decreases the risk of introducing new bugs when fixing others just before launch, making it a safer method than not freezing the code.
12. Test, test, test