Game A Week: Getting Experienced At Failure
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Iâve been receiving an increasing number of requests about âGame a Weekâ, something I mentioned in one of the answers I gave at my ask.fm profile in the last month. âGame a Weekâ sits somewhere between the amazing #1GAM that inspired it, and game jams that tend to last 48 hours.
Gaining experience by making games inÂ a short period of time
People have been making games in shorter periods of time for a long time now. In fact, my Vlambeer co-founder Jan Willem Nijman started most of his career at the Poppenkast, a community that would often push itself to make games with three hours or so without proper warning. Someone would just post a message with a theme and a deadline, and dozens of little experimental games would pop up.
When Iâm recounting Vlambeersâ history at events, Iâve often been heard saying that most of the hundreds of games Jan Willem would make were terrible. Itâs true. Of Jan Willemâs impressively prolific history (which includes pre-Vlambeer titles like COPTRA, 10800 Zombies, Pro Killer Man, The Gutter and Atomic Super Boss), most of the games he made are failures only seen by a few, often only by himself. He carried that process with him into Vlambeer, where weâll often glance through a folder with hundreds of prototypes we made discussing what to focus on next.
One of the most common requests for help I get is people asking me how to deal with their âdream gameâ failing. Jan Willemâs approach seems best to me, a giant folder full of failed little prototypes, a folder in the back of another folder with interesting prototypes. Itâs a repository of knowledge, one level deeper into his mind, of what doesnât work and what does work, but needs to be fleshed out.
Jan Willemâs superpower is a solid understanding of interaction, impact and values. When we just started, he would simply blurt out a magic number to fill in for a certain parameter when Iâd ask. Being a programmer, Iâd program a slider to play around with the value, and without fail end up exactly at the value I was told in the first place. I thought of it as a âsuperpowerâ at first, until I realised this wasnât some magical understanding of numbers - it was hundreds of projectsâ worth of experience.
Thatâs when i realised that design experience isnât in the size of your games, or even in the scope of it - itâs in the number of projects youâve been through. That sounds like a ridiculous claim to some, but letâs run through the mental stages of developing a game the way I see them: conceptualisation, identification, development, polish and release. Everybody has a different expression of these stages, but everybody goes through them for each released project.
Conceptualisation, or: âhow about we try doing something like this?â
The first moment of any creative project is a spark of inspiration - a thought, an interesting thing youâve seen or heard, a system you thought of, a story you want to tell or a world you want to create. It can be anything, in any context - you might be at a game jam or staring out of a window on the train (or both). Either way, thereâs an idea.
Thereâs a giant overvaluation of ideas in those that arenât creative. People tend to say âitâs about the ideaâ, or somebody âstumbled uponâ a great idea. Ideas are worthless in and of themselves. Theyâre thoughts, fragments - raw and fleeting - but more importantly, undefined. You can test this really easily: think of any idea and write it down in a few lines. Let somebody else read your idea and explain to you what they think it means. Chances are your ideas couldnât be further apart (this is also relevant to learning how to pitch, but thatâs for another day). The word âsunâ is associated with holidays by one person, and with astronomy by another, so imagine how much unspoken disagreement there is about a sentence, or a paragraph.
If I say âa shooter game in which you have to avoid airstrikesâ, you might nod along and think âthatâs coolâ, but itâs already hard to decide whether Iâm talking about a topdown game, a side scrolling game, an isometric game, a first- or third person game. Games are infinitely complex, and a âgame ideaâ canât be caught with words. Itâs like sheet music - you can catch a shell of what it has to be, but it takes the execution of the piece - the experience of the conductor and the orchestra bring it to life. Two orchestras performing the exact same piece can give really different interpretations of the same work. Games are no different.
Thatâs why it is important to put your game into a playable state as soon as possible. Work on the core interactions, the things people will be doing most. Make sure you can communicate that by letting people interact with it, rather than explaining it.
If you donât know how to make games, download something like Game Maker, Unity, Stencyl or Construct. The PixelProspector repository has an amazing website with amongst others, a list of game development tools.
Identification, or âmaybe we should go with this idea.â
It takes making a whole lot of those little prototype to get better at the second âmilestoneâ of development: identifying a game with potential.Â Thereâs no real way to explain in words what the thing is you should be searching for - itâs a sense of wonder or intrigue or just enthusiasm for a game. Itâs experience thatâll make you better at this stage, though. Itâs the constant failure of games based on a certain feeling, and the relative success of those based on another feeling. At some point, you start to recognise which responses are valuable and which are less so.
This is the stage in which you decide which prototypes become projects to work on, but this process also takes place on a smaller level with design decisions. While a lot of major design decisions should be conscious, informed decisions, a lot of micro-decisions you make on a project tend to be more automatic. Theyâre based on experience, rather than theoretical knowledge and argument.
Itâs the thing Jan Willem got really good at when it comes to values, and the thing I focus on when selecting projects for Vlambeer to focus on. Identifying what is worth investing your valuable time in is extremely important, and getting better at that means you have to spend a lot of time in conceptualisation. It also means you have to take enough projects through this phase to see how they pan out.
During this phase, your eyes shouldnât be âon the ballâ - you should not be headed for a destination, but wandering aimlessly until you find a direction you enjoy. Toy around with ideas, take the game in interesting directions, donât be too set on what youâre making yet. Thatâll come later.
At Vlambeer, we spend about two weeks in this stage for our large projects, and less than four hours for game jams in general. If by the end of that period, weâre not still having fun creating the game, we drop it. If we canât keep ourselves motivated for just two weeks, weâre not dedicating months of our lives to it. Weâll just be miserable if we do that, and weâd rather be happy.
Development, or âthisâll take only two weeks.â
Thereâs a golden rule in development that you can only learn through practice. The rule is that every given task take two weeks. However, if you subdivide those tasks that take two weeks into smaller tasks, those smaller tasks will also cost two weeks each.
Development has an interesting progression. At first, the project is new and exciting - everything you add has a significant and notable effect on the game. Youâve created a blank world, and youâre defining things as you go. This doesnât feel like work to most people. Itâs also the phase in which a lot of projects waste a lot of time. A lot of a projects âscopeâ is organically defined in this phase, and this is where you slowly start progressing from âwanderingâ to âmoving towards a destinationâ.
After that, the production phase of development occurs. Production is hard work, but the good news is that hard work is easy. You simply sit down and do it. This is where motivation and discipline become extremely important. When you started this project, you had something that caught your attention. That mightâve changed, or evolved, but youâre still moving forward. Keep moving. Donât lose sight of the end of the tunnel, even if you canât see it yet. Keep moving. Start cutting things that donât work, or that contradict the message of the game. Keep. Moving. Donât forget to take care of yourself, to find little distractions if your mind gets filled up and upset with the monotony of what youâre doing, to keep learning and to stay happy. Stay happy and keep moving. Donât crunch, donât exhaust yourself, but keep moving.
Eventually, thereâll be light at the end of the tunnel.
Polish, or âdid I actually fix that one bug in the main menu?â
At this point youâve got a game thatâs playable. You can sit down and let somebody else take place behind the controls, and if youâve been doing it right you already know what kind of experience theyâll have with it through playtesting. Regardless, thereâs usually a lot to clean up still - remnants of ideas that didnât work out, terrible UI decisions made early on and never fixed, little confusions and tiny bugs from fixes made right before you shut down one of those days a while ago.
This is where you take your game and make sure people can enjoy it optimally. You created this thing for people to play with, and you owe it to the game to make sure they can. That doesnât mean to dumb it down, or to âadd birds to itâ - it means to think about what youâd need yourself to enjoy the game if you had never heard of it. It means to think about who youâd want to play this game and how they need to be instructed (or not) and to make sure things are where theyâd look for certain things (or not).
This is where you write your little pitch for on your website, and where you start wrapping up. The main menu gets a last overhaul and you suddenly realise that your pause menu still looks horrible.
Release, or âI hope people donât think itâs terrible.â
You hit the button and the game is out there. Thatâs it. Youâve poured a lot into it (or you made it really quick) and now people can play it. The way developers react to that varies a lot depending on their personality, their emotional state, the amount of time and emotion they poured into the game and the reception of the game.
Releasing a game is not the end of it. You deal with feedback and criticism, or a complete lack thereof. You end up wondering what you couldâve done differently and you will immediately think of at least a dozen things that you shouldâve done better or differently.
If the game is a success, this is where you deal with press and feedback and if itâs commercial, you deal with the finances and legal aspects of making a successful game, and the emotional impact of making something people seem to like. If your game is a failure, this is where you deal with the emotional impact of making something people seem to ignore and in some cases, the financial troubles that come with not earning any money through your work.
Either way, you learn to deal with feedback, and you get better at reflecting and finding ways to improve yourself and your title. Releasing your game to the internet invariably shows you things youâve missed, things you assumed wrongly and things that fail to communicate - but it also shows you what worked and what didnât. Take some time to take it all in.
The story of the pottery school
Now, the above applies to every game. It applies to KARATE as much as it does to Ridiculous Fishing, the first of which we made in under one hour and fifty-seven minutes and the other took two years. We learned more from Ridiculous Fishing, obviously, but we had the experience at that point to sit down and make that game. Things changed along the way, goals shifted and our idea of what the game was evolved over time, but we knew we could tackle it if we pushed hard enough.
For people starting out, the amount of experience you need to be able to create a âdream gameâ is overwhelming - and I believe the best way to gain that experience isnât to work on your dream game (which is in itself a problematic concept, but thatâs also for another time). It is to make a lot of games to learn, and then deciding whether your dream game is worth working on at all.
Thereâs an anecdote which I canât for the life of me find a source for, but it is a simple idea and backed by many creatives. An old pottery school asked students to create vases, and the teacher split the group up in two groups. One group was allowed to work on thinking up and creating one perfect vase for each semester, and the other group could only work on a vase for a week at most before destroying it. At the end of the year, they compared the vases created by both groups and found the vases made by the group that made a vase a week much more refined, stable and aesthetically pleasing.
The reasons for that are simple: one has more experience with success, and more experience with failure. Not just on a project level, but also on the level of tiny decisions made, of how long to bake the vase, what type of glass or clay to use and what material doesnât mesh well with what. Failure is generally not a problem unless you fail to learn from it. It is a problem when youâve gambled everything on something you donât actually have any experience for.
That story of people being extremely successful on their first game? That doesnât exist. Fullbrightâs Gone Home is a debut game, but it is the debut game of people that have been working in AAA for a while. Hyper Light Drifter is a debut game for Heart Machineâs Alex Preston, but he spent years years making little failed prototypes to consolidate his dream game into the highly successful Kickstarter.
When I found myself - five or six years ago - being a programmer with a reasonable amount of theoretical design knowledge, but without a lot of practical design knowledge, I sat down I drafted a simple challenge for myself. For a period of time, I would make a little game every week next to my normal work. If thereâs a reason I can hold myself in a design argument nowadays, itâs because of a combination of reading books, attending talks, listening to smarter people talk and making thirty-some games that were terrible.
A Game A Week
Iâve been recommending people asking me how to get into making games to do the exact same thing, with a single update for the social media age. The longer you maintain the challenge, the more experience you have.
- Make a game every week. Start the project after Monday 12:00AM and finish it before Sunday 11:59PM. It does not matter whether the game is digital or analog. It does not matter what you use to create the game. The only rule is to make a game.
- Release the game every week. Whatever you make, whether it is complete, stable, polished or good, release it to the world through a website you specifically set up for this goal. Spread the link to the page of the game of the week on every social medium you own. Ask people to give you feedback. Wordpress or itch.io are quite capable of handling this.
- Do not revisit a game. You can go back and revisit games after youâre done. You cannot work on previous weekâs game or idea again the next week. This is not about exploring specific games, this is about gaining experience. If a game is so special it sticks for a while, you can work besides Game A Week or after youâre done. You still have to complete something else each week.
- Try and avoid patterns in your work. Try and do something completely different each week. Instead of making digital games, try making an analog game. Instead of making an action game, make a puzzle game. If you find yourself in a pattern, take note of that pattern and break out of it for a week or two before deciding to head back. Make patterns a conscious choice, rather than an accepted and unquestioned reality.
- Reflect. Spend each week talking to some people that played your game. Write down your findings in a journal (or in a blogpost, like Adriel Wallick does at her excellent blog). Write down what you made, what went right, what went wrong and what was interesting.
Game A Week is a challenge that forces aspiring developers to create a high volume of games. That is not the only valid way to gain experience, and it is definitely not reflective of the only type of games you can make. Regardless of what you want to make, going through the full development cycle frequently will make you better at making games.
Â As soon as you feel your games are interesting, try and find people to work with on these tiny games. There are a variety of interesting forums and communities that will help you out creating little games if your work is good enough. Donât be disappointed when people donât want to help out: see it as a solid piece of feedback indicating that you still have a way to go.
If you want to be a game developer, start making a lot of games. Make awful games, make games that disappoint you, make games that make you doubt your ability, clone games that you like within a week and even fail at that. Thereâs one difference between people that want to make games and game developers. It has nothing to do with failure or success, good games or bad games. The only difference is that game developers are making games.
One game a week. Good luck.