Rami Ismail (ramiismail.com)                             

Event Schedule

30 April 2014 until 1 May 2014: Gamefounders - Tallinn, Tallinna linn, Estland
2 May 2014 until 3 May 2014: Indie Gameleon -
15 May 2014 until 17 May 2014: DevGAMM - Rusland, Moskou

Biography

Rami Ismail is the Business & Development Guy at Vlambeer, a Dutch independent game studio known best for Nuclear Throne, Ridiculous Fishing, Super Crate Box, LUFTRAUSERS, GUN GODZ, Serious Sam: The Random Encounter & Radical Fishing.

Through his work at Vlambeer, Rami has come to realize that the marketing & business facets of many independent game developers could use some help. As such, he created the free presskit-creation tool presskit() and is working on releasing its first add-on, release().

Believing sharing knowledge openly is the cornerstone of independent development, Rami has spoken on a variety of subjects at dozens of game events around the world, ranging from the Game Developers Conference to Fantastic Arcade & from University seminars to incubator mentorship.

He is a avid opponent of game cloning after Vlambeers Radical Fishing got cloned. He is also a proponent of searching for new, beautiful things in places no-one is looking for them and thus organized Fuck This Jam, a gamejam focused around making a game in a genre you hate. Rami also works closely with the Indie MEGABOOTH team to enable indie studios to showcase at the larger game conventions.

Rami exclusively drinks cane sugar Coca Cola.

 
 
 

RAMI IS CURRENTLY IN THE NETHERLANDS.
YOU CAN REACH HIM AT RAMI@VLAMBEER.COM, , , OR BY CALLING +31 (0) 621206363.

Indie MEGABOOTH

Touching down

The last few months of my life have decidedly been some of the craziest of my life. It’s telling when a website I originally created to track how often I got random checked inadvertently becomes an absurd testament to the amount of work and travel I’ve been pushing recently. Currently, there is not a single time I spent a week in the Netherlands since I started the site on January 19th. I’ve been constantly traveling, to events, conventions, conferences, universities, emerging development scenes, weddings and friends.

Every event, you make new friends, form new bonds and get to talk to people you’ve formerly only spoke to for a short moment. Besides being able to promote my games, inspiring young developers,  helping remote indie scenes or discussing our industry at events, every place I go to is a place where I learn new things and gain new perspectives from eager students and personal heroes. I am extremely lucky to be able to do what I do.

The amount of stupid stuff I’ve done over the past months is overwhelming: we launched LUFTRAUSERS from the GDC showfloor, which led to me running around cursing myself to never launch anything big during an event again, after which I immediately went and we announced & launched Nuclear Throne’s cooperative multiplayer live at PAX. I designed a new, more permanent Vlambeer booth for events in the week and a half leading up to PAX, rather than creating one from scratch every single event – and I’m really proud of how it turned out.

The amount of ups and downs where overwhelming. I spent a few days being sad and worried that we had hurt people with LUFTRAUSERS, and mulled over words for days trying to communicate our stance regarding the controversy properly and with the proper respect a topic like that deserves. A few days later, we managed to pull of a potentially huge thing we’d been working on for a while by making Nuclear Throne the first game ever to be purchasable through Twitch integration. I had to deal with my name showing up on Reddit and imgur in a controversy concerning affirmative action, while LUFTRAUSERS recouped its full investment within 72 hours. I was really sad that for the first time ever, I missed an A MAZE event. A few weeks earlier, I couldn’t be prouder to hold my speaker microphone close to Jukio Kallio, the musician on Nuclear Throne, as he performed the game’s theme song live on the GDC stage amidst lots of attention for the game. George Lazenby, the only James Bond to only play in a single movie, gave me a backrub before sneaking out of a Hollywood award ceremony, as we watched Ridiculous Fishing be nominated for more awards than we could ever imagine. I worriedly watched from the sidelines as the most expensive game jam ever collapsed with my partner in the centre of the storm.

So many things happened around myself and around Vlambeer, but that didn’t stop us from making games.

The entire team has been working as hard as we can to make Nuclear Throne work on GameMaker: Studio. We worked closely with YoYoGames to get Nuclear Throne working on PlayStation 4 and PlayStation Vita. I’m talking to Microsoft about launch parity and we’re hopeful they’re listening, so that Nuclear Throne can launch on their platform too. Vlambeer started using Slack to communicate with each other and our collaborators, AppViz is amazing in making sure we pay the people we work with on Ridiculous Fishing and Super Crate Box iOS and I started using Trello to keep track of my tasks.

That being said, the next month is going to be relatively slow in terms of travel, and as I’m sitting on a couch in my home country of the Netherlands, an all-too familiar feeling creeps up on me: it’s post-GDC gloom, a month late or so, but recognisable as always. It’s a sinking feeling that you get when sitting alone, after having spent a really focused time with inspiring and amazing people, seeing beautiful things and becoming increasingly hopeful about the future of our medium.

The time that I have the next two weeks that isn’t spent on Vlambeer and Nuclear Throne will be spent on continuing distribute(), hopefully finishing a web-based side-project I’ve called Repository, and setting up a proper postmortem event in the Netherlands.

I guess I’ll answer some ask.fm questions and go to bed.


Wuppo!

Work-in-progress student game Wuppo doesn’t really have a website yet (get on that!) but it looks sort of wonderful.


P1000014

A warning about contracts from the sidelines of the most expensive gamejam in history

Yesterday, the game developers community talked about GAME_JAM, a failed reality TV show about game jams. It fell apart for a variety of reasons, all better explained by the links in this article. This blog describes my part of the story, a minor part as I perceived it from the perifery, and includes some important advice on how to deal with contracts as an independent developer later on.

As any terrible legal story starts, this one starts not much longer than a week ago.

It’s the third day of  the Game Developers Conference, almost two weeks ago when I’m posting this. A bunch of independent developers are sitting in a local restaurant having a meal, and one of them is mentioning a contract that they’re unsure about. The contract is for something called GAME_JAM. I had been told about the idea: a Polaris-run reality show about game jams, an exciting venture for everybody involved. Not only will it help demystify development a bit more, it will expose the massive audiences of Polaris to an important part of gamedev culture. It’s an exciting idea, and like Amnesia Fortnight or Super Game Jam, GAME_JAM has tremendous potential to do good for our scene.

GAME_JAM is being organized by a group of well-liked people in and around the independent game development community – curators, friends and business partners – and the premise is great. Involved in GAME_JAM as participants are my friends Zoë Quinn (Depression Quest), Robin Arnott (Antichamber, Soundself), Davey Wreden (The Stanley Parable) and my partner, Adriel Wallick (Game A Week, Rock Band Blitz), so I offer to read the contract for them.

I am not a lawyer. Never claimed to be, never wanted to be either. I am a game developer that has assisted independent developers with hundreds of contracts and negotiations, and I try to advise developers that are less versed in legalese.

Like everything in the indie scene, some people know more about certain subjects than others and we try and share and broadcast that knowledge as much as we can. A lot of the more business-savvy developers help out with reading contracts. I just happened to know everybody involved in this story, so they came to me. As you read more legalese, and deal with more companies of varying sizes, you start to recognize certain patterns, phrases and tones in contracts.

In the restaurant, five minutes of my life are spent in disbelief: the contract is awful. The most striking points in the contract include:

  • Exclusivity: participants were not allowed to appear on similar shows or syndicated YouTube networks for the full duration of the main broadcast timeframe for GAME_JAM.
  • Waiver of privacy: participants had to agree to waive all rights to privacy in any area that is not the bedroom or bathroom. This includes the ability to use hidden microphones and cameras in any area of the production, including “co-ed living quarters”.
  • Right to misrepresentation: GAME_JAM held the right to, in all and any way, misrepresent the developers, their actions and intent for dramatic effect. This wasn’t limited to exaggeration or fabricating stories.
  • Obligation to travel: participants are obliged to travel to the event, and to any other promotional activity or show GAME_JAM required of them. Flight expenses would be paid for only if the participant was more than 200 miles away.
  • Marketing: participants would be required to participate in branded activities, including but not limited to ‘drinking Mountain Dew’. On top of that, participants would be required to advertise the show as requested by GAME_JAM, and would not be allowed to speak ill of the jam, its sponsors or its organisers.

It’s baffling to read that the full budget for GAME_JAM was apparently over $400,000 considering the fact that there is a clause in the contract that asks developers to risk having to pay for their own flights if they’re close to a location they’re required to visit.

The full benefits for the developers in exchange for signing this do not exceed $300 each (threehundred dollars, that is not a typo), lodging and return flights. The participants weren’t in GAME_JAM for the money or fame, they were in it because they genuinely believed they could show the world this little part of game development culture in an honest and diverse way, and they were willing to try that even if that meant they had to drink Mountain Dew.

The majority of the other clauses were simply deal-breakers: a lot of the developers can’t afford travel under 200 miles, the marketing of most of these indies depends in some part on YouTube and the participants were mostly up and coming developers with a reputation to think about. Allowing GAME_JAM to misrepresent their actions and words could have terrible results for their future carreers.

There was a certain tone in the contract that tells you that whoever agreed to send this contract to the developers is completely oblivious to game jams and lacks any respect towards the participant. It also tells you that the organisers did not expect GAME_JAM to yield enough ‘drama’, and that they felt the need to be able to inject drama into it.

Within minutes, I made the note on my phone at the top of this post, and it encapsulated the entire contract in a few lines. I read it to the potential participant to explain how bad things were. They were shocked and we immediately reached out to fellow participants, one of whom contacted a producer on the show to start negotiating. My advice was to not sign the contract or any other legal document GAME_JAM would send.

While the developers had been approached by friends and good people to participate in the jam, that chain of people had been completely circumvented by the legal team sending the damning contract. The contents of the contract and the restrictive terms were a surprise to pretty much anybody along the chain of command that the participants could reach.

Something was terribly wrong.

I normally tell indie developers to negotiate every contract, even if it’s absolutely terrible. This is the first time I told anybody to tear it up and walk away. The contract was terrible, the event was days out, apparently the event was being organized by fragmented parts of a production nobody really had a full grasp on. Renegotiating anything on this scale tends to take weeks. We had days.

I got in touch with someone I know in the organization and tried to get a grasp of what was happening. I just wanted to be near my friends in case something bad happened, so I applied as a last-minute narrator or ‘industry expert’. I hoped they could fly me out to Los Angeles, skipping manning our LUFTRAUSERS booth at Rezzed in Birmingham, UK to make sure everybody would be OK. Maybe there’d be something I could do to help out, but for now, we needed to make sure nobody signed the contract.

We shifted strategy. With the event happening in only a few days, I recommended the participants to not sign the contract instead and make a request to renegotiate the contract to get rid of the most brazen points. Without the contract signed, they could still participate in the jam, and then they would be able to negotiate the terms, decide which affordances to allow GAME_JAM and select or limit the content of the footage GAME_JAM could use.

In the best case, everything would be fine, they’d be able to negotiate the deal afterwards and use a productions’ worth of footage as leverage. In the worst case, they’d still be able to walk away and openly discuss the jam.

After spending a few days winding down from the Game Developers Conference in Los Angeles together, I flew out for Eurogamer Rezzed and Adriel remained in Culver City for the jam. We’d be in touch in case anything bad happened, and she promised not to sign anything under any situation, even if a renegotiated contract was better. We were departing from a bad situation, and anything could look like an improvement. We didn’t need improvements: we needed a good contract.

The participants sent a request for renegotiations and the ‘team leaders’ spent the majority of the next day renegotiating a new contract. They received it a day before the event would kick off.

What I was worried for happened: even though the contract was much better – it revoked the misrepresentation clause and specified the exclusivity much more in the developers favor – it was still quite terrible.

I recommended once more not to sign until all terms were acceptable, and I couldn’t emphasize that enough. The potential circumstance of being on-set, with large production crews and your fellow developers waiting for you to being the only one not to sign was always-present, but that doesn’t matter in legal cases: if you put your name on the dots, that’s your responsibility, and you deal with the consequences.

As the first line of Zoë’s completely unrelated article imply, she did cave under that pressure and the slightly better terms. These are not simple emotional forces to deal with, and knowing there’s a huge production team literally depending on you signing is paralyzing. The other developers I advised stood ground, and refused to sign regardless of the potential negative effects on the series.

Either way, GAME_JAM didn’t go well. Between making a total farce out of game jams, it was misogynistic, misinformed and disrespectful. There are a few times when I’d rather have my gut feeling be dead wrong about something, but this was one of them. I received three tweets from the participants containing the hashtag #ramiwasright.

But I can’t be more proud of Robin, Davey, Zoë, Adriel and the other developers for walking away from GAME_JAM. The most expensive game jam in the history of mankind fell apart within a day, and the reason people were able to walk away relatively unscathed was because they had strong principles, they stuck together, and those that didn’t sign were able to do that walked away without risk of legal repercussion from the contract.

Contracts are serious business, and they can be both good and bad. I like to think of them as a way to keep people from arguing over dumb things. Here are some general pointers for contracts:

  • Get a lawyer if there is any option. It’s possible to find lawyers that’ll work for free or a revenue share. In pretty much all cases, having a real lawyer can save you from being tricked by strange wording tricks, misunderstandings and misinformation.
  • Only trust bad gut feelings. When it comes to contracts, trust your gut feeling only when it’s warning you. Don’t sign a contract because your gut instinct tells you it’s OK: always check with people that are capable of verifying a contract, preferably an actual lawyer. If you feel bad about a contract, do not sign, figure out why, and negotiate those terms.
  • Contracts are negotiable. When you receive a contract, it’ll typically be written to be as positive for the sender as possible. It is always possible to renegotiate terms that make you uncomfortable or problematic. When you negotiate, point out the specific clauses that are problematic, point out why they are problematic, and suggest dropping the clause, adding to it, rewording it, or making it more specific.
  • Anything between the lines isn’t there. If there is no end date to a contract, there is no end date. If the contract states ‘all and any’, it means ‘all and any’. If the contract says you will be obliged to participate in ‘branding activities’ for ‘Mountain Dew or affiliated companies’, you are literally signing a contract that could force you to go skydiving with a PepsiCo parachute.
  • Define as much as possible. What is a branding activity? What are the affiliated companies? How long will you be required to participate in these ‘activities’? Will you still be required to do these after recording the original show? Ask every possible question and have the contract redrafted until you can’t be forced to do anything that you’re uncomfortable with.
  • Nobody really understands legalese. We’re talking about words written by someone with an education of nearly a decade with some of the most stringent entry bars of any possible carreer. If any wording is unclear, ask it to be reworded as something that does make sense to you. It’s OK to ask for clarification on legal jargon you don’t understand, it’s not OK to sign something you don’t fully understand.
  • You only have obligations after signing. There is no timeframe and no maximum number of revisions. If the other party complains you’re taking too long or the deal needs to hurry up, remind them that you are under no obligation to sign quickly. You never have to sign now. You’re allowed to request to take the contract home or to run it by legal advisors. Signing binds you to the rules of the contract, not them – of course they are in a hurry.
  • You can walk away. Not signing and missing out is better than signing something bad and being part of it without recourse.

GAME_JAM is over, and it’s an important lesson to all of us. Developers tend to be friends and we want to see each other succeed. We want new people to join the medium, we want to educate and share knowledge. The reality is that outside of our scene, that’s not always the case. I’m so glad everybody got out OK. Huge shoutout to the developers involved and to Jared Rosen, who broke the story on IndieStatik risking his own job. My apologies to those involved in the (great) original concept, who saw the production slowly corrupted by external forces.

Contracts are useful, but they can be extremely dangerous. Handle them with care, and if you’re not completely sure what you’re signing, get help.

For now, I can recommend Super Game Jam as a good insight into the reality of game development and game jams. Don’t forget, the original idea of GAME_JAM was great.

Let’s go and demystify game development.


A Light In Chorus

A Light In Chorus

At Rezzed, a developer of A Light In Chorus showed me a trailer of the game and I ended up replaying it forty times just to come up with every possible design affordance this graphical style offers.


LUFTRAUSERS

How I learned to stop worrying and love the RAUSER

Vlambeer released LUFTRAUSERS last Tuesday during the 2014 Game Developers Conference. LUFTRAUSERS had an exceptionally rough development cycle, originally being slated for spring 2012. Regardless of the delays, the reception was absolutely amazing: the game released with only minor problems, it’s sitting on a stable 80+ metacritic, the game recouped all expenses within 48 hours or so, and people seem to absolutely love the game.

The games that Vlambeer make feel comfortable to me. They’re games that allow you to get better, they are simple and straightforward but new and novel. They’re friendly, even though they can be dystopian and difficult. You know, you’re just jumping around grabbing a crate and shooting some monsters with a bazooka. You’re flinging fish into the air and shooting them with a bazooka. You’re running around the wastelands trying to shoot giant scorpions with a bazooka.

LUFTRAUSERS is different. LUFTRAUSERS is angry. LUFTRAUSERS is upset. It wants you to destroy things, to continuously blow up things, to never back down. If you do ever back down it is to allow yourself to heal so you can be more aggressive.

I know why the game is like that. It was originally conceived right in the middle of a really depressed time – right in the middle of us dealing with Ridiculous Fishing being cloned. It was a final desperate attempt to pull Vlambeer out of a tailspin that would’ve led to us simply giving up on game development. We are angry. We were upset. In that mental state, we worked on defining LUFTRAUSERS.

I guess what I’m saying is that there’s a weird emotional disconnect between me and LUFTRAUSERS.

Nothing exemplifies this disconnect better than the combo counter. It’s aggressive, it forces you to keep fighting and it stops you from taking too long while healing. To me, it almost feels like something slightly alien in our games. You can’t really afford to drop your combo if you want a great LUFTRAUSERS score. So you keep destroying things because we tell you that there’s no other option to play the game well.

When you’re working on a game with a few people there’s no way to keep a reflection of yourself out of the final game. If you define the core designs, rules and ideologies of a project in a certain mindset, redefining those simply requires restarting the entire project. Too many decisions branch out from those earliest decisions, and changing those often ripple through a project in unpredictable ways, creating contradictions and dissonance.

We stayed true to the original concept and ideology – LUFTRAUSERS is strict, genuine and aggressive. It is upset, just like we were. All the things that people praise the game for now are things that we took from our mental state two years ago and -often without realising it- worked into the game. When I play LUFTRAUSERS, it reminds me exactly of how angry and upset I felt when we started on the project.

I don’t feel like that anymore.

I guess what I’m saying is that there’s a weird emotional disconnect between me and LUFTRAUSERS.

This is a common emotional problem for a lot of long-term projects and something I’ve often talked about with other developers, but in this specific case there are a few factors that make that feeling stronger. After we defined LUFTRAUSERS, we started taking better care of ourselves, Ridiculous Fishing released and had an amazing reception and we started the most fun project we’ve had so far in the shape of Nuclear Throne. Where we felt lost and uncertain before, our actions feel more defined and purposeful now. We’re proud and happy and excited.

It didn’t help that LUFTRAUSERS sat in QA and certification for eight months without us really changing the game anymore. That’s demoralising in itself, but it also amplified the feeling that LUFTRAUSERS is a game made by people that don’t exist anymore.
Doing interviews and talking about the game felt like I had to wear a mask, because LUFTRAUSERS felt so distanced from myself. It wasn’t until I figured out that I could talk about the game in terms of this particular estranged feeling that I was capable of doing launch interviews. I simply didn’t really know how to get enthused or excited about a game that stood so far away from me.

And when I first started reading the reviews, I was confused. Was I supposed to be happy or not? Were people celebrating a part of me that didn’t exist anymore? I didn’t know what to feel, and apparently the way I deal with that is just feeling nothing instead. It was the largest possible contrast with Ridiculous Fishing, where every great review that came in led to instantaneous celebration. Here, Jan Willem chose to just try and ignore the fact that the game had launched at all. I just read through all of the reviews and simply didn’t feel anything.

Launching during the Game Developers Conference is a terrible idea, but it was perfect for launching LUFTRAUSERS.

Leading up to the release, I was more nervous than I’ve ever been for any game we’ve launched before. The press is all occupied, developers are too busy to play your game, nobody has access to good internet to download the game and nobody is tweeting about a game they’re playing. I felt lost again, and I didn’t know how to cope with that. But launching at GDC really helped me talk to people that did get the game, and see and hear the buzz in person rather than as an abstract Twitter feed.

As the good news kept coming in, and people told me how they felt, and the sales figures came in, I slowly stopped thinking of the game as an artefact created by someone that isn’t me. Instead, I started thinking of it as an artefact from my history – the slightly darker album of a band you like – and I actually started feeling good about the whole thing. We knew LUFTRAUSERS is a solid game, and it is a game that we worked on for a really long time, and we’re really happy you like it. Even though the Vlambeer that created it doesn’t really exist anymore, we still do exist. We’re just different now, we’ve moved on, we’re working on new projects.

LUFTRAUSERS launching as successfully as it did is the epilogue to our Ridiculous Fishing chapter. Just like in the Polygon video, we rationally thought of it as just the post-credits epilogue to the cloning story. Somewhere deep down, though, I knew that we put a lot of ourselves in the project – a lot of our anger, a lot of our knowledge and a lot of our style.

I am really happy a lot of you out there saw those things too, and that you helped me rediscover those things that helped make me so, so proud of LUFTRAUSERS in the first place.


Ira Glass

Game A Week: Getting Experienced At Failure

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.



recommendation

Wuppo!

Work-in-progress student game Wuppo doesn’t really have a website yet (get on that!) but it looks sort of wonderful.

recommendation
First Strike

First Strike

During my visit to Zurich a few days ago I was most impressed by the production values and DEFCON-style fun…

recommendation
A Light In Chorus

A Light In Chorus

At Rezzed, a developer of A Light In Chorus showed me a trailer of the game and I ended up…