It Takes a Village to Ship Great Online Games

I was reading an IGN article, Turns Out The Hardest Part of Making a Game Is...Everything, by Rebekah Valentine and it truly is spot on. Making games in general is no easy task. Making great online games during the times of COVID is a feat in itself!

I got my start in video games, on a small central online team within Microsoft Game Studios, working on online features such as Auction House, Trading, and UGC for first-party Xbox 360 games - Forza, Project Gotham Racing, Gears of Wars, Viva Piñata, you name it.

At the time, I learned the reason why the game teams preferred to offload the development of the online features to a central tech team within MGS, rather than doing it in-house. It’s the constant communication and partnership between game teams and our central online team that makes it fun and rewarding. In a sense:

Let the online guys do what they do the best, build online features, while the game teams focus on making a fun game.

Years later, after working in EA and Ubisoft, I saw the same sentiment. Some things don’t really change: it still takes a village to ship great online games, because shipping games is HARD.

Technologies may have changed over the years with serverless code execution, managed databases, microservices pattern, open-source technologies, containers, and orchestration.

But in the same vein, online game development has also gotten a lot more complex over the years with cross-platform, platform identity federation, rapid iteration in the live service model, or even, the race to the metaverse.

Let’s dig into what I’ve learned over years of building online games, and why we do the things we do at AccelByte.

A Typical Online Team Setup

When we talk about an online team - or the set of people that is responsible for creating online features used in games - this is what we normally talk about.

When you only have one team working on one game, your online team might look like this:

The caveat here is that one person might be wearing multiple hats and responsibilities.

Here are some typical roles of an embedded game online team:

Online Director / Online Producer

• Act as product owner for online domain.
• Define online scope for the game.
• Owns quality for online features of the game.
• Makes prioritization calls for online domain.
• Owns online budget, infra budget.

Online Designer / Live Service Designer

• Define online gameplay design, often works with UI designer as well (“how things should work”).
• Own online gameplay balancing for live service (economy, skills, etc).

Project Manager (also called Development Director)

• Project management (“when things can be delivered”).
• Manages resourcing and risk planning.

Community Manager

• Engages community, works with designer to tweak design or balancing.

Engineer & Ops

• Responsible for online features in-game, backend, infra, and everything in between.

As your studio starts working on multiple ongoing projects, you might decide to spin up a central online/tech team, for several reasons:

• Making your game team lean, and letting them focus on building features.
• Centralizing the operation activities to run the live games 24x7.
• Centralizing the online tech, taking requirements from multiple games, and avoid reinventing the wheel - solve it once, solve it for everyone.
• Keeping the learning and experience of dealing with game launches within the central team - like best practices for platform certifications, balancing between scalability, availability and security.
• Seeking opportunities to reduce the infrastructure and running systems cost down with things like AWS Reserved Instance reservations.
  

Here are some of the typical roles from the central online team:

Product Owner

• Collects requirements from game teams. Oftentimes, the requirements will come from the designers from the game side.
• Makes prioritization calls for online domain.
• Define roadmap for the features to serve the games.

Project Manager (also called Development Director)

• Project management (“when things can be delivered”).
• Manages resourcing and risk planning.

Engineer & Ops

• Builds centralized/common features that will be used by multiple game teams, deals with scalability, availability, functionality, security of the features.
• Helps game teams to use and integrate the tech built from central team.

One thing is clear, game teams tend to want to focus on making the best player experience, and not get bogged down by adjacent items to worry about, such as: keeping servers running 24x7, active monitoring, query optimization, infra cost, and so on. That’s why often as organizations scale up, having a centralized online central team is inevitable.

Should I Build, Buy or Rent a Backend?

Somewhere during the game development cycle - typically somewhere between the concept phase and pre production, the team needs to decide the overall online strategy for this game.

The decision goes way beyond the online tech feature set or how scalable it is:

• Cost of running the infra, services
• How can we iterate online features quickly
• Live operational & standard operating procedures
• What will happen if the game blows up in popularity

These days, building online features up to launch is arguably the easy part. Post-launch is where the real challenge begins.

Which will almost always turn into this discussion...

The Fourth Option

At AccelByte, we offer a fourth option.

We learned that none of the options above is ideal, so we approach it from a different angle. Instead of positioning ourselves as a backend engine middleware or a vendor, we’d like to think that we are your partner in shipping your online games - during development, certifications, launch, and all throughout your game’s live service cycles - so you can focus on the fun part.

We understand how important it is to understand what the code is doing, the need for game developers to go deep into what’s in the box. If some of your players’ matchmaking tickets are timing out only when the CCU goes beyond a certain threshold, you might want to understand what the code is doing, and how to optimize it based on your game usage pattern.

What if our out-of-the-box service does not fit with what you need? You can fork our service and customize it, or build it from scratch with our server SDKs. Don’t have the backend engineering muscle? Let us work closely with you to understand your game’s requirements, and build a custom service for your game.

However, most of the time, you’d rather focus on making your game fun and engaging, and you just want someone to run the entire backend for you - and deal with the things that would otherwise be distracting to your team members, such as upgrading kubernetes clusters and archiving database snapshot images.

Unfortunately there is no easy button to ship a successful online game. There is no magical platform that solves all launch problems. Having scalable tech, a battle hardened team, careful planning and constant communication between the business, creative and the engineering roles are all needed in order to secure a great launch. Since we all know that Murphy’s Law is a party pooper.

Interested in learning more? Reach out for a demo here.