Profile

Cover photo
Flying Roosters
2 followers|353 views
AboutPostsPhotosVideos

Stream

Flying Roosters

Shared publicly  - 
 
DanC at it again! Good read!
Daniel Cook originally shared:
 
A recent question has been "Why don't you just sell Triple Town for 99 cents and make tons of money off a hit iOS game?" Instead, I've dedicated a large amount of time to pursuing far less respected and somewhat explosive free-to-play models.

Question: Why?

Answer: Because I want to keep making original games for the next twenty years without a boss and the current packaged goods model has shown little evidence of allowing for that long term.

The trap of packaged games
When I look at self-described indies, it is most common that they are following variations on the decades old downloadable/retail model. There's a packaged product that you pay a fixed price for through a third party distribution network and then if you are lucky, you sell that player another game later on. Most folks don't even question this. It is just how 'good games' are made.

This is the business model that I've participated in for the past 16 years. And I have friends that have been doing it longer than that. In that time, I've noticed a list of deadly traps that perhaps only a dozen out of the thousands of game companies manage to survive.

Successes are sporadic
When you make a game that earns 1+ year's salary, it feels like you've made it. 90+% of devs would be delighted to be in this position. For the moment, let's assume you've made it. For what it is worth, I've been there twice.

Having succeeded, many devs assume that they are inherently talented and can repeat that success with only a small amount of additional work. In reality, the number of 'developer successes' that have created multiple highly profitable games is surprisingly low. Go through your list of 'indie successes' and ask how many have created more than one hit game. More than two? Your list is likely dramatically smaller.

This isn't a new problem. Many of the 3rd party developers that existed around the turn of the century also were also small teams that made it big and then pursued the next big hit. They made good money on ports and contract work. Some created new IPs that never quite reached the same levels of success. Almost none of those companies are still alive today. Oh, our brain's tendency to focus on successes tends to blind us to the facts, but the reality is brutal.

Success leads to scale which leads to risk aversion and fragility in the face of volatility
There's a specific revenue graph that you see for a typical packaged or downloadable game. You get a big spike of money that slowly trickles down to almost nothing. These are hit games in a hit driven industry with hit shaped revenues.

This has some fun psychological implications. When the money is good, it seems like it will never end. As a result, teams tend to overextend themselves. They hire on additional people, and they take on more ambitious and exciting projects. They invest in all the heavy lifting associated with moving their hit to other platforms and new audiences.

Also, many teams get their big successes in emerging markets that mature within a few years time. Where they once could spend a few hundred thousand and hit it big, they now need to spend a couple of million. Scaling is only logical. And why not? You've got the cash and the next success will pay for future successes.

At some point, the money starts fading. The next game or port suddenly needs to be a success. You make decisions that start matching what the market is doing. You start listening to experts. You start looking back on your past success and trying to emulate them. All this makes it more difficult to comprehend and react to new opportunities. You've gone from a fresh new success to a fragile bloated company.

The inglorious end
There are variety of things that a company will do at this point. Arrangements with more stable entities like publisher where future games are traded for cash infusions are the most common. Developers, in their heart of hearts, just want to make games and if that means signing fiddly little legal agreements so be it.

At this point, it doesn't take much to prompt a sale or bankruptcy. The stuttering success engine fails once too often. Bills come due and alternative funding isn't around. There is no portfolio large enough to smooth the curves. In the end, it isn't the average income over time that kills teams. It is the extended low points in the highly variable cycle of highs and lows. Sometime you fail 10 rolls in a row.

The game is rigged against developers
This pattern repeats with each opening of a new market. It happened with PC games. It happened with Playstation era console games. It happened with the casual games market. We are a mere few years from the death spirals in the console downloadable market. It is in the middle stage with social and mobile games where early successes still strut about feeling invincible.

Developers start out as independents and end up either out of the industry (very common) or working for someone else. It may take 10-15 years, but it is surprisingly predictable. I've come to the conclusion that long term, the hit-driven model found in disposable, packaged games is an anti-developer business model.

Many newer developers see emerging markets promoting a few Macaulay Culkin-esque successes and think replicating their pattern is how you win. I see the same market with forces not much changed from cycles past and see a repeat of the shattered dreams of dozens of my close friends. Why is it that slowly unfolding dynamics are always a surprise?

Exceptions
There are absolutely exceptions. As I was tallying up a handful of studios that managed to survive this inevitable decline, I was struck by how few of them played the standard game. The big independents are obvious.
- Valve owns a distribution platform.
- Epic owns a very popular engine business.
- Blizzard has the world's largest MMO (and they still sold out).
- Insomniac formed sweetheart deals with Sony that resulted in launch title marketing with nearly guaranteed sales.

The smaller exceptions are also fascinating
- Spiderweb stayed small and served the same community for years
- Habbo grew slowly with an online multiplayer game.

The companies I find inspiring use a variety of techniques to reduce income volatility.
- They vertically integrate key aspects of production or distribution as profit centers.
- They build ongoing revenue streams usually in the form of a service.
- They cut out the middlemen and create long term relationship with customers.
- They religiously keep control of their cashcows. And milk them for years.

The revenue curves are distinctly less spiky and sporadic. They have longer tails and often fall down to a floor raised substantially above zero. There may be tough times but outright death is far less likely.

I look to these examples and pursue the following with all my projects
- I want my games to be services that last a decade or more.
- I want strong relationships with players and the communities they form.
- I want to build steady streams of revenue that grow slowly over time, not big sporadic hits.
- I want to remain independent and in control for the next twenty years.

And selling a 'complete game for a fixed fee' doesn't really meet many of these goals. (And before you say 'Minecraft', let's give it another decade. :-).

Imagine free-to-play games as practiced by a private company that makes games with long term retention for passionate players in a tightly knit community. That fits my personal goals substantially better. So I'm experimenting. I'm learning. Spry Fox may not figure it all out this time, but at least we are driving in the right direction.

So why you don't see Triple Town being slapped with 99 cent price tag and being sold like any other disposable wannabe hit? Been there. Done that. This time around, I'd much rather work towards having a lot fewer customers that see my games as a lifetime hobby. So I can continue to make great games for them for the rest of my life.

References
http://kotaku.com/5876693/every-game-studio-thats-closed-down-since-2006
1
Add a comment...
Have him in circles
2 people

Flying Roosters

Shared publicly  - 
 
Interesting tips on prototyping games!
Stuart Jeff originally shared:
 
Game Prototyping Tips That Work For Me:


1. Momentum is key. Iterate, iterate, iterate! The game should be changing all the time so think hard about doing anything that takes more than a day to do. The game MUST be playable as often as possible. If you can’t play the game, then you can’t see what is actually working.

2. Do not paper design. Create a short paper sketch for what you hope to create that focuses on a few simple themes rooted in a mechanic. Implement that mechanic as quickly as possible and iterate to strengthen it. Once in the code, stay in the code! Talk about what is working and what isn’t and get right back to changing the actual game instead of a paper about the game. Focus on making the game great rather than making the game sound great.

3. Don’t use real game art assets. Prototyping works best when you are rarely stalled by a lack art assets. Producing nice assets takes time and stalling iteration to make them kills momentum.

4. Don’t use programmer art either because it gets in the way of a lot of people’s enjoyment of the game. If the player can’t tell what something is supposed to be then they are going to have a really hard time understanding what you are trying to do with your design. What you want is a clear, easy to produce, abstract form to relay the mechanics of the game to the player. It is critical that you discover a style that works for your game which leaves as little ambiguity as possible.

5. A great game is fun even when played with squares. Aesthetics should add to the experience rather than define the experience. Work out a fun game first and then figure out how to create an aesthetic that enriches the experience.

6. Break down disciplinary walls. The designer should have the final call but it is important that everyone on the team have an open dialog during prototyping. The designer needs to understand how the game is built so she can best understand what is possible and easily reachable for iteration. The programmer must understand the designer’s intention so that the code can be crafted to maximize iteration flexibility for the design space that the designer is interested in exploring. Similar ideas hold for interacting with art. The importance of a solid team that works well together can never be overstated.

7. Practice non-attachment. Game development is a process of addition and subtraction. Sometimes a good game can be transformed into a great game by cutting a feature that people love. Build it up and then strip it down. Weigh the game on actual play rather than imagined play. Strive constantly to close the gap between the game in your mind and the game as it exists.

8. Spend as much time understanding why something is working as you do trying to understand something that isn’t.

9. Start with a toolset that you are comfortable with. For me that is Unity but I think any engine, including an engine you’ve written yourself, is fine. The important thing is that game prototyping should be about making a game NOT about making an engine.

10. The only optimization you should be thinking about is how could you iterate on the gameplay faster. Execution speed, robust code design, and even writing modular shouldn’t be on your radar during your prototyping phase. The only exception to this rule is if your frame rate is so low that it is preventing you from enjoying the game.

11. Get the game in the hands of others as soon as is practical. You’ll never learn so much about your design as you will when you close your mouth, hand the controller to someone else, and see what they do. Resist the urge to attribute negative feedback to user error. Even if it actually is user error, it is your job to craft a game that can handle that error gracefully. A lack of understanding by the player should never be ignored.
1
Add a comment...
People
Have him in circles
2 people
Basic Information
Gender
Male