Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Vlambeers' Rami Ismail talks about gaining experience when you're starting out as a developer. His recommended challenge, “Game a Week” sits somewhere between the amazing #1GAM that inspired it and game jams.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)