Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 1, 2014
arrowPress Releases
November 1, 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:

Have fun making money and games!
by Samuel Rantaeskola on 04/17/13 05:45:00 am   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.


(this post is also printed at

Over the last years I have met a large number of seasoned console game developers that are now creating smaller games. The common story I hear from them is that they are tired of the challenge riddled environment; they want to go back to their roots. In 2010 I had similar feelings, so I was sketching on a method on how to transfer a large studio to a garage-of-garages. The development method I was drawing up is very similar to the approach that many successful developers are using today; a partly self-filtered, partly market-filtered shotgun approach. Basically, it’s about creating as many games as possible to be first to the next thing. The problem to solve is that we can’t be sure what the rapidly changing market is looking for, and we can’t rely on a few people to be able to predict it.


The method

Development process

A diagram showing the phases of taking a game from prototype to shippable and finally maintenance of the successful games.

The method is by far most efficient in an environment where talented developers can make great games without much supervision. Failing early and often is one key ingredient; the second is to capture successful games and rapidly develop them further. It relies on collective wisdom, rather than creative leads that directs and reviews; everyone is a creative decision maker.

Before I explain the method, let’s make a few assumptions:

  • We have 50 talented developers with different competencies.
  • We have at least enough money enough to fund development for at least half a year.

Week 0 – Creative seeding

A new development cycle starts with all available developers gathering. The goal is to come up with a number of simple concepts that can go into prototyping.

When a number of concepts have been selected, the developers form teams of maximum 5 to create prototypes.

With about 50 developers, we should have roughly 10-15 game ideas that go into production.


Image 1


End of week 4 - Prove it

At this time all prototypes should be completed. The whole company meets up and looks at the current batch of prototypes. The purpose of each prototype is to prove fun; there should also be a rough plan on what is needed to make a shippable version. Everyone in the company grades the prototypes. The best ones are now moving into stage two of development.

Image 2


Start of week 5 - Make it

We now have a small number of good prototypes. The first step is to build a backlog that describes the work left to a shippable state; as well as a rough idea on how to expand the concept after releasing it.

The prototype teams might now be expanded with people from scrapped prototypes, so that each prototype can be taken to a shippable state within 12 weeks of development.

Image 3


End of week 16 - Ship it

All of the prototypes that were developed further should now be shipped to their intended target platform. After shipping the game the teams should now spend time helping on marketing the games, we don’t want to separate marketing from development. After a while the teams will go back to the start to fire a new barrel of prototypes.

Image 4


Improve it

If a game is successful the team needs to be very fast to execute on the plan on further development, to make sure to maintain the interest in the game. Team members are now moving back from current assignment to hop on the further development of the hit. The game will move into a continuous development cycle which is focused on frequent upgrades.

Image 5

Potential flaws

Since I haven’t tried the method in reality I can only speculate in the flaws of it. Here are some things that could be problematic:

  • Self-organized talent – The team needs to consist of people that are very creative, talented and good at driving themselves forward. They are attractive to every game developer out there, so they are hard to find in abundance.
  • Cash flow – If the first batch of games flop the team could run out of cash pretty rapidly.
  • Voting - This is the component I’m most uncertain if it will work in reality. The risk is that people are so passionate about their prototypes that the voting creates internal friction.
  • Focus – Creating a framework that keeps the organization focused while still not being restrictive can prove to be a challenge.


There are many organizations out there that are using a similar approach, and I think it can work as long as the casual segment is still booming. The risk is that success will slow the teams down, once a number of games becomes successful the studio will transform from a creative power house to a service focused beast. To prevent this, the studio needs to continuously find talent that can come in and start filling the barrels.

Related Jobs

Forio — San Francisco, California, United States

Project Manager / Producer (Games)
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

Multiplayer Level Designer - Treyarch
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States



Thomas Happ
profile image
This seems a bit weird, but I feel like this could weed out a lot of wonderful games from being made - games that would be outshone at the 4 week point, but which can only start to be fun after enough is invested in it. Or games that aren't meant to be fun. Or that are enjoyable due to their amount of polish more than the core mechanics. Maybe a bit like the effect test screenings have on Hollywood movies?

Samuel Rantaeskola
profile image
Yes, the risk is that you miss on a few good games. The method is like letting the horses out of the stable, then bet on the fastest ones. Sometimes a slow starter will win the race.

With the time constraints I set up I think you'd be looking at typically 1-2 mechanic games most fit for this method. However, you could extend the period, but that would also require a lot more cash up-front.

Daniel Cook
profile image
You might find these older articles on the Stage Gate process (what you discuss here) interesting:

Project Horseshoe overview of Stage Gate as applied to the game industry.

Discussion of agile thinking and Stage Gate

For what it is worth, Spry Fox uses a variation of this. The stages are not synchronized so people are regularly peeling off to work on prototypes. Seems to work quite nicely.

Some key factors that I've seen helping:
- Very talented and experienced developers. Your success rate will likely be a lot lower with inexperienced teams that can't easily wear multiple hats.
- Strong design leadership. Decisions need to be made on a regular basis so teams have a forward momentum. A strict voting system and heavy process only goes so far. Note that any design leadership only works with tons of team investment and buy-in. On Leap Day for example, many of the final decisions are almost always a mind meld of Jason Coleman and my thoughts. (You can have leadership without dictatorship!)
- Early stages are often very fuzzy. The criteria needs to be pretty permissive here. Often a '1 or 2 team members believe in the concept' instead of '1 person thinks it should die'.

take care,

Samuel Rantaeskola
profile image
Thanks for the links, they were indeed very interesting.

I couldn't agree more with the first article. Now, 6 years later it looks exactly the same. I found this statement particularly true for the console market:
"We have little ability to predict if a game will succeed or fail in the market. In the absence of science, superstition reigns unchecked."

My personal view of things is that the traditional AAA development which the first article is very focused on has a lot to learn from the practices in the casual games. The big obstacle to overcome is how to align several independent teams so that they are delivering towards the same vision.

In regards to your comment on strong design leadership vs a more collaborative effort I would love to see how they compare in realty. I can definitely see problems with a "leader-less" organization....

Samuel Rantaeskola
profile image
On a second note, as a producer in an independent studio I really didn't like how the funding of a game is usually set up. Having the whole budget and release time defined before a game is even in a playable state is not a good idea and is subject to so much problems in production as politics kicks in.

From a production point of view I would have preferred a "Vertical slice" contract that stipulates the amount of money you have to prove the game. When that money is up you better have something to secure a full contract. The release time shouldn't even be discussed until that contract is fulfilled.

The biggest issue I see with today's setup is that we tend to "lend" money from production to create an enticing vertical slice. This means that we have too little money to actually create the game, either more money has to be added or quality has to give.

Julio Rodrigues
profile image

In the beginning of your article you've said that we need to have knowledge about our customers. Do you have any practical advice on how we, as developers, can gather this kind of data during early development?

Sebastiano Mandala
profile image
your theory looks in line with the lean startup methodologies, but it is not quite there yet. Have you ever read the lean startup book?

Samuel Rantaeskola
profile image
I haven't read it yet. It's on my to-read list though.

To be clear, I don't want to come out as an inventor of this method, it's just a summary of what I felt would have been a nice way of restructuring a one team studio. I don't think I had read about it anywhere back then. But then again, all thoughts are just a extrapolation of already existing knowledge :)