Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 18, 2014
arrowPress Releases
September 18, 2014
PR Newswire
View All





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


The 9 common mistakes every indie game studio should avoid
The 9 common mistakes every indie game studio should avoid
November 21, 2012 | By Simon Carless

November 21, 2012 | By Simon Carless
Comments
    24 comments
More: Indie, Design, GDC China



Ichiro Lambe has learned a lot of hard lessons since he founded independent studio Dejobaan (AaaAAAAAaaaaA: A Reckless Disregard For Gravity) over twelve years ago.

At a talk at the Indie Game Summit this week at GDC China, Lambe whittled these down to the nine common pitfalls that most indie studios are in danger of facing.

1. Starting too large

Lambe notes, dryly, admitting that he's fallen into some of the same traps with his indie titles: "People see games like World Of Warcraft or Call Of Duty: Modern Warfare and [believe] they can create an MMO in 9 months." Being overambitious with scoping is a classic indie failing. So why not pick a smaller game?

2. Creating that one perfect game

Lambe suggests that when you have a game in your heart that you simply must make, you can sometimes over-reach technically or conceptually, because the idea isn't scoped correctly.

His advice: "Step back and consider all the other games you might create" - but don't necessarily go for a grand slam first.

3. Manufacturing your game just to sell

Lambe cautioned that after he had success with a Palm Pilot title, he ended up making a large amount of other simple casual titles, and he believes his lack of passion rubbed off and ended up with lackluster results. It's only when you inject a certain amount of passion into the process that you may find a middle ground.

4. Thinking tactically vs. strategically

A lot of developers think of things tactically and individually - switching between game design, PR, and customer service in a very monolithic fashion. But if you think of your overall developer brand, you might want to do each task in a strategic brand-specific way - maybe by using videos to reply to text-based comments on a Rock Paper Shotgun article, as Dejobaan joyously did.

5. Failing to plan

It's easy, as an indie, to muddle along in a variety of inefficient ways. But when you get it together -- as Dejobaan hopes they have with its upcoming Drunken Robot Pornography, where they talked to Steam early and got extensive Steam Workshop integration for item construction into the title -- you'll save yourself a lot of headache down the road.

6. Going it solo

Although you certainly can go at it alone, you'll have nobody to bounce ideas off of. Even as a small studio, if you don't speak to other small independent game studios, Lambe cautioned: "You're missing out."

It turns out that your fellow indies do actually care about you, and they aren't competitive - they are happy to counsel and help and suggest.

7. Imaginary constraints

Lambe joked that many developers think, "'This is how we're supposed to make a game.'

"But let's do something different. There really are no constraints in the game industry, and you shouldn't be afraid of wacky concepts," something Dejobaan often shows with its odd game titles.

8. Ignoring relevant focus areas

A lot of developers simply say "I am creating a game to create a game". They don't worry about interfacing with journalists, they don't worry about PR, and as a result, things don't go well.

You can be creative on your own, but do have to think - at least a little bit - about what the outside world will be interested in, Lambe concludes.

9. Falling in love with your work

An important final rule is relatively simple: "Don't fall in love with it so deeply that you are ignorant about its faults."

Lambe gives the example of a game trailer that might have a 10 second animated 3D logo at the beginning, rather than actual gameplay. You can tell the person who made it was delighted by it, but they are, perhaps, lacking perspective. You need to ask your peers, and you need to show the game to the public through development, Lambe concludes. Only through this will you love your work, but not fall in love with it.


Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada
[09.18.14]

UI ARTIST/DESIGNER
Cloud Imperium Games
Cloud Imperium Games — Santa Monica, California, United States
[09.18.14]

Technical Designer
Cloud Imperium Games
Cloud Imperium Games — Santa Monica, California, United States
[09.18.14]

Technical Designer
Pocket Gems
Pocket Gems — San Francisco, California, United States
[09.17.14]

Associate Product Manager










Comments


Kale Menges
profile image
Smart list. I think a lot of these points remain applicable to successful game development at ANY budget or scope.

Joseph Anthony B. A. Tanimowo-Reyes
profile image
Number 6 is my main pitfall... Mainly because it feels awkward to approach other developers before I get a release under my belt.

Alex Rose
profile image
Great list!

I do get really paranoid about point 9 a lot. There are features that have been in my game since the first few weeks, and I wonder if they're bad and I've just gotten used to them. I like to install a beta build on random people's phones at uni and then ask them what they think a week later to tackle point 6. Most people on my course have an android and are happy to get a free game.

As for point 2, I'd like to think to an certain extent every dev should be looking to make their game as perfect as possible. I've pushed my development back over double my initial expected time because I keep coming up with new features or easing/tweening, and I think if you know there's some way to make your game more interesting/aesthetically pleasing you should try and get it right. I think it's important to make a game as you would want other games to play.

Also, aren't strategic and tactical synonymous :P?

Matt McConnell
profile image
http://www.diffen.com/difference/Strategy_vs_Tactic

Essentially, strategic thinking is far-reaching or on a larger scale, while tactical thinking is more moment-to-moment.

Greg Quinn
profile image
"Don't fall in love with it so deeply that you are ignorant about its faults."

This is the toughest one for me. On an 18 month project, I find it very hard to accept criticism on certain features.

scott anderson
profile image
Awesome list. Enemy Airship had like 6/9 of this problems :).

Alan Barton
profile image
Ok, starting from point 6, i.e. fellow indies helping each other, I would like to ask,

... How can new startup indies add and plan Steam integration early on (as in point 5 above)? Because Steam integration sounds like its a catch 22, where we need our game to get through Steam Greenlight, before we can get access to the steam SDK?

i.e. from Steam's own FAQ...
"1. How do I get access to Steamworks?
To get access to the Steamworks SDK, you still need to go through Steam Greenlight. All of our publicly available information is located here. If you have further questions you can contact"
"2. My game is in early development stages, don't I need to plan for the SDK integration now?
The Steamworks SDK is easy to integrate, so you can wait until your game is further along in the development cycle before worrying about it.". i.e.
http://www.steampowered.com/steamworks/FAQ.php

... Its a catch 22 which prevents planning a lot of Steam integration. (It sounds a crazy nonsensical rule, as it prevents indies from improving the way their games can integrate and earn money from Steam (as Steam integration needs to be left to the end of development) and so that impacts Steam's own income as well). Whereas if we had many months to work on improving Steam integration, we could add a lot more, such as in-game micropayments which would benefit Steam's income as well.

Or is this a misinterpretation of what they mean by "still need to go through Steam Greenlight"? ... Is there a way to get the steam SDK early on in the development process?

Luis Guimaraes
profile image
"Being overambitious with scoping is a classic indie failing. So why not pick a smaller game?"

I'm not anywhere nearby being Chess master but I used to play it a lot with friends back in school, and at one point I decided to download a known java Chess project (http://jose-chess.sourceforge.net/) that simply changed everything how I used to look at the game. Playing against it will sometimes make you wonder is the software wants to humiliate you for the evil visceral fun of it.

But after facing it over and over there's a point at which you start to seamlessly guess his next move without understanding the reasons behind it, you just do. That's where the pattern recognition power of the human brain is kicking in and you're looking at the big picture in a different way.

Coming to analyse it later you start to find out what every single move of the software is about, and it's defying one of the very core rules of the turn-based nature of the game: that each players gets to do one single movement. And that evil piece of software is doing 2,3,5,10 "moves" at once in each turn.

So students, do you want to build the next Call Of Duty: Modern Warfare? Slice it down into every single little working feature you need, and release a small, consistent, polished indie game for each one of those features, exploring the most interesting scenarios you can squeeze out of it.

This way you'll have a steady flow of finished games being released, cycling through multiple studies and experiences over various stages of prototyping, iteration, polishing and releasing full games. And at the end you'll have a lot of experience in development and design, and a lot of nice released games that will become your masterpiece once you connect them all together, with the added expanded vision you'll have acquired at the end of the process to make it far better than what you initially planned for.

Start small: plan for 3 games, where the first 2 ones are based off simple core mechanics, and the 3rd one is made from the sum of the first 2 ones.

Make the most you can out of each turn you get to play.

Scott Sheppard
profile image
This is absolute gold.

Nathan Champion
profile image
I wonder if anyone with experience could chime in with regards to the choice of starting with an empty project or going with an available engine.

Adam Culberson
profile image
That depends. You definitely don't want to re-invent the wheel more then you have to. Most platforms have some sort of free or almost free framework to start with. I started my journey with XNA which is really just a framework without any kind of visual tools and made two Xbox indie titles which led to me getting a job where I now use Unity 3D where a lot can be done visually but scripting is obviously required to get anything meaningful done. Starting from complete scratch is a waste of time however. There is no point in trying to solve problems already solved unless your intention is to learn how it's done vs actually getting a game completed.

Greg Quinn
profile image
As Adam said starting from scratch is a waste of time.

With Unity3D you can get up and running VERY quickly.

Besides, writing your own 3D engine is no small feat, and it's been done by companies with very clever people over many years, so you don't have to.

Amir Barak
profile image
Not every game has to have an "engine" behind it. Unity3D is good at certain things but I wouldn't recommend it as a starting point to anyone interested in game development from a programmer's perspective.

There are also benefits to starting out small with your own "inventing the wheel" approach; if nothing else you'll use the larger tools more efficiently since you'll understand the why and not just the how...

Great list of points, never suffered from 9 though I always struggle with 1 and 2 :D

Antoine CLERC-RENAUD
profile image
Great and useful list. Point 6 is extremely important but delicate as well. Thanks for the valuable information.

Daniel Campbell
profile image
As someone who's been working, and failing, in the indie sector for years now I can say that this is one of the best collection of basic rules out there. If you could add one more, I'd feel comfortable calling it "The Ten Commandments of Indie Development." :-)

Justin Sawchuk
profile image
Yeah I hear that. Going to release my own game soon and the publisher said " One particular concern is the space theme as it rarely sells games without a brand". I am hoping that space themes are back.

Jean-Michel Vilain
profile image
OK let's consider points 1, 2, 6 and 9 :
Starting too large
Creating that one perfect game
Going it solo
Falling in love with your work

If every indie dev had listen to you, then we wouldn't have Fez, Minecraft of Braid.
Sick of these X random bullshit points lists.

Ian Morrison
profile image
Sorry, but I don't think those points mean what you think they mean.

Using Minecraft as an example... it started small before it ever grew big. It was an iterative, "lets see what can happen" project from an experienced developer, not a "the one perfect game I'll ever make" sort of project. Notch certainly didn't "go it solo" in the sense that the article is talking about... while he might have been working on it on his own, he didn't develop it in a vacuum. He was constantly talking to customers, other developers, and being involved in various communities. And he certainly never stopped seeing the flaws in his own work, or we'd never have seen the endless back and forth of community feedback that occurred and made Minecraft a far better game for it.

Those four rules could be rephrased something like this:
1) Know your limits and understand the true scope of your project
2) Don't have tunnel vision. Create, without being held back by the pursuit of some magnum opus.
6) Don't develop your game in a vacuum
9) Be able to stand back from your work and look at it objectively

Luis Guimaraes
profile image
@Mark

"1. Do not try to recreate the pleasures of your youth. Generally results in mediocrity."

Actually you should, but not without putting some thought on why it was so good.

http://www.gamasutra.com/blogs/LuisGuimaraes/20121030/180414/Surv
ival_Horror_Then_and_Now.php

Luis Guimaraes
profile image
@Mark,

Ha, somehow I missed the sarcasm tone of your previous posts. Indeed.

Sam Loesch
profile image
1. All of those developers had other, smaller projects before their big success.
2. The author is advising to wait on your "perfect" game until you are ready. Clearly they were ready.
3. Don't really care about Minecraft, but Braid and Fez were both developed by more than one person.
4. "Falling in love" with it and loving it are different; he clarifies that the difference is being the ability to see flaws in it. The Fez developer redid the whole game 3 times, I'd say he saw some flaws in it. Braid also went through many stages of prototyping and trimming the fat, albeit early on.

Lima Junior
profile image
Great list!

Jeff Murray
profile image
10. Ignore all advice from everyone else.

Matthew Burns
profile image
Great list! Number nine can really mess up your ability to stay in "reality."


none
 
Comment: