Early access in gaming: Agile business development in AAA gone wrong

As a comment to the following video states:

‘I accidentally bought an Early Access movie at a Walmart a few months ago. The second act repeats seven times and half the dialogue is is unspoken text, but the story is basically alright. Maybe it’ll get better with future updates but I have no idea how to update dvds, please help.’

This is an article in the ‘Research’ category where I dive into a subject on game production.

In my opinion, Early access is just a reminiscent of a gone-by area of the style of funding in AAA, trying to get the pro’s of something new but not wanting to let the old go. And yes, the end product is even less desirable than doing it ‘the old ways’. As pointed out by the reviewer in the video above.

Into the deep

Let me break down what I see is happening.

Clinton Keith in ‘Agile Game Development with Scrum’ sums it up nicely. Game dev started in the 1970 with the arcade gaming. Games where very expensive to make back then due to the hardware. As a result, they adopted project management strategies. A much used one back then was line style projects like waterfall. The use of waterfall stayed mainstream until around 2008 (the year of Clinton Keith’s book). By 2008 project were enormous, especially the AAA games with hundreds of people working on a single game. But waterfall had the ‘issue’ of detecting failures a bit too late. So A lot of studio’s were looking into other project methodologies by then, reflected in a couple of good book publications on game development in those years.
Things started to change from the years 2010 and on. But a lot of the ‘old’ is still there. And a few problems aren’t just solved by using Agile or another project methodology.

Finding the ‘Fun’

Finding the ‘Fun’ is the main concert for a game dev project. And a hard to crack nut. Look at the following graph from the book from Clinton Keith:

The red line is about finding the fun in traditional waterfall projects. The blue line is the (optimal) curve when you use Agile project methodologies.

I personally don’t buy into this graph as that ‘Agile’ gives you this earlier and better understanding of ‘Fun’ no matter what. This graph is a good demonstration however about the problems game development is facing and the knowledge you only can acquire over time and when all game components come together.

From what I have seen in AAA gaming so far, game development is most of the time still executed as a line project. They describe a goal, get a few brilliant people to figure out how to get there so most things are accounted for (this is the important part of line thinking: smart work preparation, dumb work execution), create a few development teams to execute on the plan, and deliver all the goods at the set date.

The AAA game industry has a good reason to build games this way. From the business side the funding is coupled on hitting milestones. You can only account for milestones if you are detailed about the deliveries. As a result all experimentation and tuning is done in the design and pre-production phase. From then on most decisions are ‘locked’ and the production is scaled up.

When you are about to hit a milestone date but are not ready yet, you start to crunch. When even crunching doesn’t help, you start to drop non-essential functionality. And when even that doesn’t help, you either consider moving the deadline or start dropping essential functionality.

This hard-locked funding system seemed to work well in the past times. Although there were always signs that it wasn’t the best encouragement for good game development. But they did stick to it because… of the money and control.

So?

Well, it seems the factory floor working force of the Bioware studio’s are doing their work. They are delivering nice stories, worlds, assets, sounds and everything else.

But the project management… this is the most obvious: if you’re half-way into the project, big chance you don’t have anything working yet. (Working as in: it could sell for some money) Some less essential parts can be finished, but you need all parts together for it to be ‘the thing’ as specified at the start.

It is exactly this issue that early access has: it is a product that only functions as a whole, but someone decided to declare a few parts ‘optional’ and release it anyway.

But… planning is everything?!

Don’t get me wrong, I get it on the business side. You want to plan in advance to know how the whole game plays out. And that planning then gives you the (although false) hopes that you have something worthy to invest in.

From my combined thoughts of how things have worked out, I understand the early access move. If a game company had planned a big game IP, and suddenly sees diminished interests, they wanted to get a piece of the cake while they still can. So there is the early access release for said big game IP.

The early access move became relevant in the last years because there is an increasing pressure to deliver. Gaming has gained significantly increased exposure in the past 15 years. And I think most of the pressure on game studio’s is from the money-injecting side that want Return On Investment and low risks, and see a goldmine currently hitting the big veins they were after.

What do you oppose for AAA?

There are two things that needs to be addressed. One is already evolving, but the other isn’t.

  1. Better Agile by using working and fun sub-deliveries.
  2. Better game business development by using other systems to control the funding.

The number 1 is already being addressed by people like Clinton Keith. There is a whole movement of better use of the combined intelligence of high-performing teams even during production and beyond, and using iterative approaches to the daily work of game development. Even more, AAA studio can’t get the high-sought after people no more if they don’t provide an inspiring working place.

The number 2 is just not there for AAA. The industry is moving to more Agile business dev practices with mobile in the front lines. But the AAA on PC and console just cannot transpose those idea’s from the mobile productions to the large-scale AAA production.

Well, look to it from the other side, from the consumer perspective.

There is a world out here: people’s tastes changes over time. One year your game is the ultimate, next year no-one plays your genre anymore. And that’s a problem in an era where games take 3 to 5 years to develop.

I am thinking about these things for a while now. They are really hard to solve, because there are so many things involved.

But wouldn’t it be great if a game was able to evolve? That you could make a small game first with a small user base and small scope, and iterate on that? (but without calling it sequel x?) I think everything is in place in the current times we live in to make this happen:

  • Very good and easy update infrastructure everywhere (and that people nowadays are trained to accept updates as something good)
  • Much better access to information (and training, and resources, etc)
  • Multiple ways of monetizing (that people are accustomed to)
  • Dev teams are up to this task (and almost expecting to develop that way)

We could start with developing different than before. The planning-and-then-executing isn’t working any more, so get rid of it. Start experimenting with practices that enable continues releases to customers.

Published by Erik_de_Roos

Erik de Roos is a Freelance software developer.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: