Are we all “Games as a Service”?

Lucy Morris
5 min readNov 4, 2020

--

Development as a Service?

Our industry works in weird and interesting ways.

Comparing the way we do anything, from customer engagement to production practices, will more often than not find itself lacking a comparable equivalent in other industries. Having recently released a game, I’ve found myself in conversations with people outside of games trying to explain the life-cycle of a game title these days — why I’m still working just as hard on the title post-release, why the launch was only one of many steps and by no means the ‘be-all-end-all’ of the process, why I’ve been ‘on call’.

And the more I thought about it, the more I started to think — have we evolved to such a competitive point in the market now that all titles are naturally expected to become ‘games as a service’?

Wikipedia helpfully defines GaaS as:

In the video game industry, games as a service (GaaS) represents providing video games or game content on a continuing revenue model, similar to software as a service. … Games released under the GaaS model typically receive a long or indefinite stream of monetized new content over time to encourage players to continue paying to support the game.

In the traditional sense of defining GaaS, no, we’re not all free-to-play titles, nor are we all churning out downloadable content for products we’ve just shipped. But we are a continual service if we want a fighting chance, these days. We are providing continual support and in a lot of cases, updates and content if we want to be seen.

If you want featuring in a holiday sale, you need to update with holiday-themed content. If you want to capitalise on momentum after release, you need to keep a watchful eye on issues in reviews, and plan into production (where feasible) ways to mitigate these things; fix them, add content. If you want to keep your community happy, you need to be on call — watching the social media channels, keeping an eye on emails, vetting content curators, doing interviews, responding to reviews that present issues.

Production and launch are only the tip of the iceberg, plunging us right into this ‘games as a service’ cycle that feels like a hangover, if hangovers had the ability to consistently exist for months on end.

What I am saying:

  • we are more expected than almost any other industry to be constantly on call for issues, even more critically after a launch. We are expected to be continually responsive. Turn things around at an inhuman pace, because that launch window is so critical — and then, to a lesser extent, around the windows of visibility events to follow.
  • it is expected to launch patches immediately, if not within days of finding an issue — launch bugs can make or break a title, and losing that edge to negative reviews no matter how quickly or easily the bug is fixed can impact the entire title’s lifespan. This leads to that ‘on call’ pressure.

What I am not saying:

  • we are all free-to-play, or that this tirade fits every developer like a glove. More like, this is a recurring theme I’m seeing recently, and I think it’s a good thing for us to talk about.
  • that customer support is bad — it is not, it is critical, and I want nothing more than for my players to have a good experience. But why are we expected to perform at a high level of responsiveness and pressure?

A Very Scientific Survey

Before I write anything controversial, I try to litmus-check whether or not I’m just having a grouch — whether or not the issues I’m wondering are issues are present for anyone else, or is it just me? So I asked a few questions to developers on Twitter who have commercially released at least one title about things I’ve been thinking about regarding ‘all games are a service’, and these are the answers.

(Keep in mind, anyone could’ve responded to these, but there is some good discussion in the comments so I’m hoping that the data has a modicum of value. I’ve done some rough ‘math’ to take out the show me the answers options.)

Did you patch your title within 24 hours of releasing? (This includes making a patch build, submitting it to a platform review queue, or making a patch build and pushing it to users live.)

76% — Yes (57 votes)
24% — No (18 votes)

How many patches did you push within seven days of release?

4% — Zero (2 votes)
85% — 1–3 (46 votes)
11% — 4+ (6 votes)

Have you built or pushed a patch outside of your normal working hours for your title? (after hours, or overtime)

75% — Yes (43 votes)
25% — No (14 votes)

Have you felt pressured to create a patch outside of normal working hours (after hours, or overtime) because of negative reviews, complaints or social media pressure?

70% — Yes (35 votes)
30% — No (15 votes)

Do you currently have negative reviews on your product (on any platform) for issues that have since been patched?

76% — Yes (34 votes)
24% — No (11 votes)

In the two weeks following your release, how many hours of overtime related to patches/updates did you work?

35% — None (15 votes)
44% — 1–10 hours (19 votes)
21% — 15+ hours (9 votes)

In the two weeks following your release, how often did you respond to customer inquiries/complaints/bug reports outside of your normal working hours?

19% — Not at all (8 votes)
33% — Once or twice (14 votes)
49% — Often (21 votes)

Again, this survey is pretty hasty and unscientific, but the numbers suggest at least a commonality emerging that we should start discussing. We’re more connected than ever, which brings both good things, and bad. We’re feeling more pressure to be on call, to respond, to ameliorate and to improve — engagement of which is great in reasonable doses, but do we have reasonable expectations for our hours post-launch anymore? We need to provide a continual service, not just to protect our long tails and community, but also to compete in a hot market.

Especially for smaller developers, where customer service is an in-built, expected job of one of the development team, this is a concern. Is this sustainable? Is this healthy?

Are we now ‘development as a service’?

(For more spicy takes on game launching, feel free to read my other article: Launch Day: the emotional cost of releasing a game.)

The cover photo used in the header image is by Polina Tankilevitch https://www.pexels.com/@polina-tankilevitch.

--

--

Lucy Morris

Studio & Creative Director (Starcolt). Develop/MCV 30 Under 30. Loves radial menus.