What’s Wrong With the Triple-A Games Business? (Part 1)

It should be apparent to most observers of the games business, that the “Triple-A” end of the business is in quite a bit of trouble these days.

In my home country of Denmark alone, the biggest of the studios (Io Interactive, makers of Hitman, my old job) has laid off about 60 people in 2010 alone – a substantial percentage of their workforce.
The second Triple-A studio, Deadline (Watchmen), went bankrupt in 2009. I don’t know of any other danish studios that aspire to be the Triple-A variety, but across the globe, core gaming studios are are laying off staff – LucasArts, EA, etc.
All of them are giving us the usual song and a dance about how it’s normal and follows their release schedules, but in the cases where I have insider information, it’s not at all normal.

It’s gotten so bad, that it’s a rare thing to hear a success-story about Triple-A these days.

When you do hear a success-story, it’s usually something like “Call of Duty: Black Ops” – the ten thousandth game from a popular franchise that has a marketing budget resembling the GDP of a small nation, and who are even showering reviewers with gifts to hopefully push that all-important metacritic rating a few points up.
Activision are blowing their entire wad on marketing Black Ops, because it was probably judged (or tested) to be the game that had the highest chance of succeeding at mass market success. Meanwhile, back at the ranch, they are closing Bizarre Creations and probably hurting a lot of other of their studios by so myopically putting all their eggs in the Black Ops basket.
While Black Ops is most likely a fine game (albeit flawed, it seems), it’s has practically bought it’s success (if indeed it’s success is even commensurate with it’s marketing budget).

So what is going on? Why is the Triple-A business struggling?

Continue reading

Posted in Games, Games Industry | Comments Off

Free To Play Part 2

After spending some time playing and analyzing FarmVille, which resulted in an article and a talk at SpilBar in Copenhagen, I’ve gained a better understanding of this business model.

I’ve also realized that though most of the games that employ free-to-play (F2P) as their hook tend to lean towards grind-heavy RPGs or farming games, there’s really nothing in the model that fundamentally requires this to make money.

Here are the key points in F2P, that I find extremely powerful:

  1. You lower the players reticence (and investment) to play your game by making it freely available
  2. You delay the purchase decision until the player is invested in the game
  3. You make it possible (and in some cases necessary) to spend more on the game, than just outright purchasing it.
  4. You make it possible to collect small amounts of money from people who like your game a little bit, and lots of money from people who really like it.

Point 1 is like a product demo, but more appealing since the game is really free, unless you opt into paying. That’s possibly very generous, and possibly just a fake gimmick like that free hit on a crack-pipe the nice gentleman on the corner offers you.

Point 2 is like giving out a product demo and asking people for money when they’ve had a good taste, but better – since they can keep playing and keep delaying the spending decision until they are happy with it. It gives the developer a much larger window to sell something to the player, and it gives the player a much better opportunity to get to know the game before they decide to part with their coin.

Point 3 is great for those super-fans who would have bought the extended gold super platinum extra spiffy jelly filled unrated ultra edition box set of your game if it was a movie (and listened to the commentary track). They get to shower you with love and cash, if they are so inclined. And you get to cater to people who really appreciate your work as a developer, which is fun.

Finally, point 4 is great because a lot of people might not be inclined to give you $50 for a your game (especially before trying it), but they might be having a bit of fun and be willing to spend a dollar. And a lot of players spending a single buck is still a lot of bucks.
The buy-in price and your pay-out happens on a sliding scale from “hmm, yeah, ok, I guess” to “TAKE MY GOLD, DEVELOPER-GODS!”, which is beneficial for both player and developer.

I’m not at all blind to the fact that every one of these points could be laid out in a much more sinister and douchy way. All these points can be used in less than savory ways, which is what FarmVille does – but it’s possible to use these powers for good, if you fight your inner greedy douchebag and actually try to think like I’m descibing it here.

So, I’ve come around – I think this is a powerful business model, which can actually be used in a very wide variety of games. It makes it easier for players to try your game, and easier for developers to convince people that it’s a fun game worth paying money for.

Posted in Games, Games Industry | 1 Comment

Free to Play

I was at a conference in Copenhagen called “Free To Play”, which was about the rise of the business model of giving your game away, and nickel ‘n’ diming your customers for your actual income.

It was interesting and educational, but there was a general sentiment of “watch out, paid games industry – you’re not going to exist in a few years, because this business model will steal your customers”.

While I think it’s an interesting business model worth exploring, I think there will always be a market for people who are willing to pay a premium to play a game that was lovingly crafted to tell an engrossing story and paint a beautiful and visually coherent fantasy world, rather than to keep you grinding playing forever and while buying virtual virtual hats for real money.

Posted in Games | Comments Off

Duct Tape Programmer

Joel Spolsky wrote an article called “The Duct Tape Programmer” a couple of months ago.

I couldn’t agree with him more, and – apart from the rolling out of bed in dirty clothes – consider myself a duct tape programmer.

Posted in Development | Comments Off

Using Issue Tracking

A while back, after avoiding it for a very long time, I finally caved and installed Bugzilla on my server. Then I took the painstaking and boring step of migrating all my todo list items from basecamp to bugzilla.
Later, I took the even more boring step of prioritizing the tasks, assigning them to milestones.
Finally I occasionally add time estimates to the bugs.

I am a one-man team with 3 external people on my current project (Deep Blue Sea 2).

I had considered a full-featured system like Bugzilla to be completely overkill, and I tried a bunch of different alternatives:

I’ve even talked to people who run companies that have 8+ people and even 30+ people, who have also avoided a full issue-tracking system because it seemed like overkill when they were such a small team.

Here’s my opinion: They are wrong. If you have more than 0 people, issue tracking has something to offer.

When I migrated to Bugzilla from Basecamp, I had about 50-60 todo’s on my todo lists, making the lists large and hard to hard to manage. Many of the items encompassed large tasks (2+ days).
Moving to bugzilla allowed me to have many more tasks (current bug id’s are nearing 500, after 2 months of use), let’s me view, sort and order them in many different ways (per milestone, prioritized, per assignee, per component, sorted by estimated time to complete, etc).

I completely understand the sentiment of “ugh… time estimates. Cumbersome input… stupid managers setting stuff to highest priority… blergh”. But just because your previous boss used systems like this to make your life worse, it’s a mistake to think that you, personally, can’t gain something from them.

Use your issue tracking for these reasons:

  1. Never forget an idea or bug again – capture ALL of it with your system, then use priorities and far-future milestones to indicate that they are nice to have, or happen rarely.
  2. Get short lists of issues/tasks that only pertain to your current situation, rather than a giant jumbled mess. If you are working towards a functionally complete Alpha milestone, you don’t need to see Beta milestone tasks.
    If you are pressed for time, only view the critical bugs with priority 1 or 2, rather than the suggested enhancements with priority 5.
  3. Have a central place for information concerning a task or bug - In bugzilla (and other systems), you can have entire conversations and track status changes for a single bug over time.
    When I receive an email from a tester with information pertaining to a future task, I copy/paste it into the bug history and trust that I’ll see it when I start working on that task, rather than having to go digging through my email history.
  4. Automatically let people involved with a task know of changes to the task – Bugzilla will send emails to all parties involved with a bug, if you change it’s status or write a new comment or question. I usually use this as a communication system when discussing tasks/bugs, rather than have email conversations with people.
  5. Easily reassign tasks to other involved parties and get notified when they change something – This is basically item 4, but in reverse. It’s great that I can assign a task to my graphics artist, and get notified when he completes the task, or asks a question about it.

Invest the time it takes to get comfortable with the system – bugzilla seems horrible and cumbersome when you first try it, but it has lots of nice features, like stored searches or bookmarkable templates, that allow you sidestep the complexity and quickly get the bug list you need, or add a new bug.

Posted in Development | Tagged , , | Comments Off

Writing Proper Descriptions

When you write down a bug description, a code comment or a note for yourself with regards to your project, take special care to write it as if you’re writing to someone else (who is also on your project).

I can’t count how many times I’ve fallen in the trap of quickly jotting down a note/comment/bug intended for myself, and as a result having absolutely no clue about what it means a mere week after I wrote it.

Oh, and this also goes for commit messagse when using source control – write proper descriptions, even if you’re just one person.

Posted in Development | Comments Off