Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 23, 2014
arrowPress Releases
July 23, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Game A Week: Getting Experienced At Failure
by Rami Ismail on 02/26/14 11:16:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
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.

What’s next?

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.


Related Jobs

Gearbox Software
Gearbox Software — Plano, Texas, United States
[07.23.14]

Release Engineer
Turtle Rock Studios, Inc.
Turtle Rock Studios, Inc. — Lake Forest, California, United States
[07.23.14]

Technical Artist - Turtle Rock Studios
Hyper Hippo Productions Ltd.
Hyper Hippo Productions Ltd. — Kelowna, British Columbia, Canada
[07.23.14]

Senior Unity Developer
Nordeus
Nordeus — Belgrade, Serbia
[07.23.14]

Senior Game Designer






Comments


Doctor Ludos
profile image
Excellent and very inspiring article, thanks a lot for sharing that!

The hard part (at least for me) is to go from "Woaw, he's true, I really should try to make games more often" and "but with full-day job and a family, it's not that easy to find time to do it...".
In the end, I always feel a bit "guilty" when I have to release a "not polished enough" game because I no longer have the time to work on it, but it's either releasing it "imperfect" or never releasing it, so the choice is obvious to release it anyway...

In regards of your experience with this kind of "hardcore training", do you have any advices on keeping motivating in spite of "real life" obligations?

Rami Ismail
profile image
As Adriel points out in her wonderful blog about her experiences doing this, the games themselves eventually become motivation. It's the first few weeks that are the toughest - like any habit you need to grow into. Explain what you're doing to somebody you care about and ask them to help keep you going.

Like you said, releasing something 'imperfect' is better than not releasing at all. It'll free up your mind, it'll teach you to deal with problems and it'll inform you how to make next game feel a little less 'imperfect'.

Michael O'Hair
profile image
A week?

How about this: start a project, FINISH the project, and then start a new project. It may take a week, a month, a year, whatever; but a great concept should be fully explored and developed. The short time limit encourages a kind of factory crunch mode. Who does their best work under the gun... other than people who churn out the same widget over and over again? What's the worth of a Pac-Man or Doom clone a week? I think we all have enough of those lying about, saved for posterity or something. It's a good idea not to endlessly improve and iterate on the same old ideas throughout eternity, but it's an even better idea to FINISH YOUR GAME and move on to new projects after it's finished.

And reuse your code, if applicable. You're not going to reinvent the wheel in seven days. Don't fail on purpose; if you feel inclined to swing for the fences, do so. Failure should be the result of taking risks, and risk is where lessons are learned and boundaries challenged. "Nothing ventured, nothing gained." But you've gotta VENTURE first. Your first project might not be a smashing success, but there's also the possibility your FINAL project (and possibly some of those in the middle of the road) won't be either.

Rami Ismail
profile image
This is not about making the best work. This is the equivalent of doing silhouettes for drawing - you make lots of things to get better. There's no crunch mode - if you're crunching, you're scoping wrong.

The worth of a Pac-Man or DOOM clone is that now you know why certain decisions were made the way they are, and if you managed to get far along enough now you know what makes those games tick. Maybe you don't see the value in that, and that's fine - we don't have to agree. I'm saying that without fail, anywhere I go, any school I visit, the people that have made the highest volume of (terrible) games tend to be the people that are working on the most interesting games.

Finishing your games is great, but if you need to get good at making games first, how about making games. Not every drawing has to have beautiful line art, it can be a doodle, or a sketch, or a silhouette. No drawing teacher ever suggested that your first drawing should be fully drawn out. At some point, you'll start drawing your lines with more confidence, and eventually, you're working on finishing full drawings in a week. At that point, you can see if you want to go beyond working on a drawing for a week.

Why would that be different in videogames?

Thomas Palef
profile image
I've actually been building one HTML5 game per week in 2014. And the experience so far has been amazing.

You can try my games: http://www.lessmilk.com

And here's a gamasutra article I wrote this week about the lessons I learned: http://gamasutra.com/blogs/ThomasPalef/20140225/211663/

Rami Ismail
profile image
Wonderful! Glad to hear it's been working out!

Will Hendrickson
profile image
Wonderful article, thanks Rami!

While I haven't had such a strict prototyping schedule, I have one massive project file that has 40gb of content, which I often use to just throw things together.

I find that in addition to gaining valuable experience, I have developed quite a useful code base from it.

I definitely advocate this type of exercise. I just wish that when I first started out developing games professionally I had used this approach. It would have saved me a lot of trouble over the past years.

Rami Ismail
profile image
Think even of that last thing as experience. :)

Muir Freeland
profile image
I used to make a lot of stuff with RPG Maker in the early 2000's. The first couple things I made were well and truly terrible. I remember packing this one game full of totally needless swear words because I thought it made the dialogue edgier or… something. Obviously, part of getting over that was simply growing up and not being twelve years old anymore, but I think a lot of it was just doing it and getting it out of my system, as well.

A few dozen games of all shapes and sizes later, there are still things like that -- little dead-ends that I need to work out of my system. There probably always will be. I like the idea that it's okay to fail through them quickly, learn, and move on instead of dwelling on them with giant projects.

Jorge Gonzalez
profile image
Thank you very much for this Rami, i was actually inspired by this article and Adriel's blog to start my own A Week A Game challenge, i'll be starting with a 8 weeks/games goal, but i hope i'll be able to stretch it as much as i can after that.

I'll be posting my results in http://mondongorongo.wordpress.com/ (it's in spanish though)

Once again, great article

Nate Buck
profile image
I just made an account to thank you for the blog post! I've been chugging along at my "dream game" for months now without making any real progress, and this was just the advice I needed (even though I've heard bits and pieces of it here and there before). I had just set the bar way too high for the amount of effort it would take me right now. Thanks for helping me realize that.

Now to get a new game done before GDC...

Colin Witow
profile image
I too feel inspired by this concept. Reading it now, it seems like such an obvious solution to the "Can't quite get a game put together because of unknowns" problem.

I'm going to try this myself, once I find a place to host a website/blog. It will probably start out pretty simple as I've never successfully put something together before.

On that note, quick question. What constitues a game? Obviously some sort of game mechanic, but does that also include a title screen, scoring, sound? As I progress I'm sure I'll start putting all these together but for starting out at what point can I consider it a game?

Billy Clack
profile image
Hey Colin, if you want a simple blog, check out www.blogspot.com . It's free, and owned by Google, but it gets the job done. I just record videos of the games, put them on YouTube, then link them directly from the blog.

Rami Ismail
profile image
As soon as it does anything at all it's a game as far as I'm concerned. You can only get better, and you'll define your own boundaries for the definition at some point. Don't worry about that sort of thing for now, just get creating!

Billy Clack
profile image
Hey, great article Rami. I decided to give it a try. I've been a programmer for a long time now (graphics in general), but when it comes to games I'm the kind of guy who builds up an idea in his head, designs it, I let it steep in there. Then when I develop I either reach roadblocks during development and get caught up in my day work, or I get disheartened since I'm building a lot of the architecture (engine functionality, base code) and not a lot of actual gameplay to show for it. I've started a game a week blog at http://gawahse.blogspot.com/ after reading this article, and although there are only two little weeks completed, I feel rejuvenated that I'm actually creating things again and getting my ideas out, as rough as they are. This was just the thing to get me motivated again :-)


none
 
Comment: