GameFeelings

This is an article in the ‘Behind the scenes’ category where I shed some light on what it takes to make games. I warn you: they are real, these articles might discourage you to develop games yourself.

TLDR: The byproduct of non-Agile development (long development times, bad attuning to consumers) was always there, but its costs has increased so much that it is now unavoidable to start using Agile development methods.

In my daily life I am a senior software engineer, practicing the latest insights on Agile development. I have seen many organisations, small and big, old or brand-new (even startups). Using this insight I can spot a lot of problems with the often plain wrong methods of development the game industry is using.

Yes I think the game industry can be much more Agile, and no they are not “in a special kind of industry that can’t benefit from being agile”.

First a quick introduction to Agile development. Because it is often used as a buzzword with few meaning left in it. Non-agile is the factory line: in advance you plan and rule out all odds, the actual work is thus repetitive and not requiring a lot of skills (although you can argue it can still require some practice… but that’s exactly the problem: no thinking involved). It is input driven: someone somewhere decides what has to happen, everything and everyone falls in line to execute on that. Everyone has a predetermined place and function. You don’t need trust, you need rules.

Agile is the opposite. When you are agile you think of what you want to achieve, and make that happen with respect to the current state of the world and the tools at hand. By building on trust, by being in connection with everyone, by embracing the unknown. Yes that sounds idyllic, because that’s how humans like to be.

But why all this Agile or non-Agile? Why bother with project methodologies anyway? Just build that game already!
Well, the following picture illustrates how a perfect world would look like. Look at all those connections. It would be great if we would build products in a world where all those connections between the content creators and consumers were flawless.

However as you probably know from your own experience, all connections between humans suffer from communication issues. This is the same picture, but now with the possible issues.

The idea is that a project management method helps you cope with these communication issues. The non-Agile project methods, where almost all game developments methods belong, have the following characteristics:

• You prepare to make a good-enough product that is sell-able to the masses. (This was done to account for the increasing costs of production, and the consumers accepted it because any product was better than none product at all)
• You try to mitigate the communication risks by using experts to understand the market’s needs. (This was necessary because your goal was to make something that had maximal impact on as many people as possible, but don’t listen to the individual)
• You plan in advance with what to build for what cost/benefit. (Because you had to prepare a whole factory line, where profits comes from doing it as efficient as possible)
• You add a line hierarchy with narrow boundaries to manage your workers. (Because of all these activities, the organisation is like a machine where every gear has its place. But those gears can’t do more than they are ment for, for then the whole thing would turn out to be less efficient.)
• You use mass media and and deals with large selling companies to get your products to the consumers.

But times are changing. A lot of the problems the non-Agile methods accounted for have been minimized in other ways:

• Creators and consumers can find each other much more easily. (Much less need for all kinds of parties acting as the middle-man. The internet with platforms like Steam have brought both much more close together.)
• Costs of tooling is so much more lower. (You can work from home, get tooling on-demand without upfront payments.)
• Access to skills has changed radically. (Flex workers all over the world are available to you with specialized services.)
• Access to information has changed radically. (You can learn basic to advance skills using the internet (and time/practice) where previously the access was the limiting factor now our time is the only limiting factor.)

Add to this that these non-Agile methods come at a huge cost: the distance of the consumer to the creator is almost automatically enlarged, the time to respond to changes is in terms of quarters and years, and with each change large losses in productivity are unavoidable.

These costs of non-Agile are currently outweighing the benefits.

Gamers nowadays point these things out. So, besides the fact that the world is changing faster than ever, the costs of the non-Agile methods are becoming the real issue. Here is a video of a review pointing out issues with game updates that inspired me to write my thoughts down:

The industry is trying to cope with the changes. The rise of Indy development, introduction of DLC, beta releases have become ‘Early Access’, whole new models like micro transactions combined with games-as-a-service.

One could argue that some of these are Agile development, especially the ‘games-as-a-service’ model. A lot of those games increase their features over time, thus start small and become great over time (or that’s their target).

But I think there is very few agile development going on here. No one listens to the consumer. Or when they do, their communication lines are clouded up with bad incentives… or even worse the development teams (or more often: their seniors/leaders) only pursues their own ego’s.

And from what I see almost no game company is building games incrementally, continuously having a sell-able product, and closely listening to the consumer on what to build next. (Don’t mention Early access, it is often executed so poorly it deserves a blogpost on its own.)
Thus they still suffer from the big problems that non-Agile development has nowadays.

I see a few games that do point in the right direction. One of the latest games I found was ‘Realm Grinder‘. A nice little game that received a lot of good updates over its lifetime that all increased its value, even with game-play altering expansions. The trick here is that these kind of games rely on introducing changes in game-play during the play-time every so often to keep things interesting. I think more game types should try finding out if it is possible to incrementally add to the games without altering all previous build stuff.

And I think I should mention ‘No mans sky‘. Not because of the horrible communications before launch, but because of the big updates that got to the game FOR ALL USERS. Even for those users who did pay already. Many studio could take example from that. I think It increases the bonding gamers have with you. And money still comes from new players that enjoy the experience, finding a live and well-patched game.

I will close this blogpost with a how-to. How to know if a decision on organisation structure of project methodology is Agile or not? I try to think of it as follows.

The past is: thinking in advance (official name: input driven). The future is: building what’s needed (official name: output driven).

All else is just a remnant of the past. People craving for power and thus aligning the organisation to fuel that craving. Departments creating work to stay relevant. So called ‘experts’ that place the consumer at a distance of the creators, significantly worsen the communication between those two.

This is an article in the ‘Behind the scenes’ category where I shed some light on what it takes to make games. I warn you: they are real, these articles might discourage you to develop games yourself.

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.’

In my opinion, Early access is just a reminiscent of a gone-by area of the style of thinking, 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.

Let me break down what I see is happening. And why I think that it is actually a nice try but executed miserably. As an example I will use the case of Find the Gnome to incorporate some of the learning I did myself.

From what I have seen in gaming, games are executes as line projects. You 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.

This seemed to work well in the past times. But that is a fallacy. That is because there was way less external pressure to improve on how to deliver games. Back then there was no real incentive to change. 30 years ago the entrance fee to the gaming industry was very high: you needed connections everywhere to get something build for the right platform and get it published. A few knew how this trick was done, where the lucky first, and could then reign on their thrones for ages.

I do think the old way of building games is addicting, especially for the happy few that are on the thrones. Designers with names, publishers with rock-solid IP’s, console builders with marks on the lives of many.
I did experience this ‘god complex’ myself. When I build Find the Gnome I wanted to do everything myself. Because that’s the most easy way to get credits. So today there is always someone who gazes at me in awe at being able to at least finish a game (for what’s in the name ‘finished’ anyway) and publish it on steam (for what’s that worth anyway nowadays). And all this recognition feels so good…

But as stated, line-thinking is not the best way to create things. It suffers from a lot of problems. 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.
(Read my article on Agile vs non-Agile game development for more about those problems)

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.

Don’t get me wrong, I get it on the business side. There is a real 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.
You need money to continue developing: there is an increasing pressure (to deliver) the industry is facing because of the significantly increased exposure gaming has gained in the past 15 years. Most of this pressure is from the money-injecting side that want Return On Investment and low risks.

I tried to do Find the Gnome on my own because I feared the idea of someone with money directing me in the moves I had to make. I have had my fair share of video’s where people complain about the bad incentives the introduction of investors adds.

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 to make this happen:

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

The only important thing is to keep developing with an Agile mindset (in contrary to the line-thinking). Aim your work and your organisation on the creation of needed stuff (the output). Because that way you don’t sneek in line-thinking trough a backdoor.

More on Agile is in this blogpost. That post goes more in depth what’s Agile and why you want it as your game development method.