Making games is so easy! Part Deux!

Alpha

The goal I’ve always heard for Alpha is that you’re supposed to be feature complete and by the end of it you should be content complete. Feature complete means you shouldn’t have any new systems being implemented in Alpha. You should have all the tools to create the content you need, they just might not work great or have various bugs. Content complete is that everything that’s going to be released with the game is actually in the game, hooked up and playable. It still needs time for polish, to fix bugs and make it feel great though.

So you’ve got your foundation of the game completed and you’ve just got to create the rest of the content. What could possibly go wrong?

Unfortunately there are quite a few of them. Due to tech debt your tools are really hard to use and you don’t have enough time to complete everything that was promised by the end of Alpha. Scope creep has occurred and the game you thought you were making has turned into this big crazy epic and requires more assets, more time and more complicated tools that weren’t appropriately budgeted. Let’s drill in on scope creep and why it’s so harmful at this stage.

Scope creep is when the definition of what’s going to be in the project gets bigger and bigger over time. This usually happens in a very well meaning way as people want to be more ambitious, they see opportunities to really wow the player, or because they just played a really great game and they want element X from that game in your own. Usually the project can handle adding a small change here or there, but it’s over the lifetime of a project that they start to add up to size-able change that can really change what you’ve been working on and how much needs to be created to support it.

One simple example of this would be adding multiplayer into a game. If you were working as a singleplayer game and are trying to midway through the project swap to multiplayer, you’re now having to make sure that everything can work in a networked environment. Things need to replicate from the host to the client, you’ve got to make sure that things stay in sync, all of the clients need to recover gracefully when the host leaves for whatever reason and the list goes on of extra work from what can seem like a simple thing.

Even something like adding pvp to a co-op pve game can be tricky. Previously you may not have had as much cheat detection in your game as you figured if someone cheated in a pve game it’s really just hurting their own experience for the most part and maybe hurting the economy of your game a wee bit. However in a pvp game you definitely would want to have some checks if players are doing things that look exceptionally shady like shooting through walls or across the map, but it can be hard to find that thin line where someone is too good, or there’s a bug in the game, as compared to they’re just completely cheating. In addition some of these checks can actually cause some gameplay knock on effects. If you’re checking to make sure that the player is shooting at something that they possibly could have shot at before dealing damage to the target, there is now a delay in there as you validate. This can lead to gunplay feeling sloppy as you shoot, see an impact and a few frames later damage is dealt.

At the end of the project your scope (and scope creep) needs to be managed to make sure you can still deliver the game on time and at the quality you want it to. If not it can lead to a lot of hard decisions like cutting core features and players feeling like there’s a missing hole in the game.

Beta

Beta is all about putting the finishing touches into the game. The game should be ‘done’ now where it’s fully playable and all of the systems are in the game, but they’re in various states of working from barely to somewhat. It’s time to crunch and get the game into shape. This is the final time for content creators to make significant changes to the game as the team starts to make sure the game is stable and performant.

The big problem with Beta phase tends to be the lack of time to do everything. Everything needs to be done at this point. There’s still some content that needs to be finished, there’s a bunch of content that needs polish and love from creators, the game needs to have better performance and all of the last finishing touches need to be implemented. But there’s only so much time left and that means that people are going to crunch to try to get everything in and prioritize what they can work on for the rest of the project.

There’s been enough studies on the effects of long term crunch on work now to clearly show that crunch leads to a net negative effort to work. However it’s really hard to not think that with a limited amount of time left that the only way to get everything done is put in more time and try to squeeze out more effort. But that leads to sloppier work which introduces more bugs into the game, which you then need to spend time fixing bugs you or someone else introduced into the game due to being in a tired state.

Finalling

Now you’re trying to get this game out the door and into people’s hands. That means you really really need to focus on stability (and hopefully you’ve been stable up to this point anyways). If you’re releasing on consoles you’re going through a certification process with first party to make sure that your game is up to their standards and you might be running into roadblocks there. Developers are on a tight leash as to what they’re allowed to fix or change at this point. That’s for a very good reason as even very minor and small changes can drastically break the game in quite surprising ways (I remember an audio designer broke the build by having an extra space or return in the ini file they checked in). Things are fragile, people are tired or burnt out, and everyone is just trying to get it all done.

Unfortunately this is where you pay for everything that’s gone wrong up to this point. Sometimes that payment is small, either because you’ve got a relatively simple game you’re working on, or you’ve had good due diligence on the team to keep scope in check and tech debt low. Or more often is the case the payment is high and people are scrambling trying to figure out what is wrong, trying to get enough caffeine in them to keep focus and awake. You’re heavily triaging your problems at this point as something that’s crashing the game is a hell of a lot more important than something that only happens in a small area of the game. However small problems can be really hard to rule out fixing. If it’s something that only happens in 1% of cases but you’re planning to ship to millions of people… that’s still over 10k people that’s going to affect for every million you sell!

In addition you’ve got to figure out a good way to allow people time off to recover, find out what is going on in their life again, and be ‘normal’ human beings so that they don’t burn out when they start working on the next patch, feature or game. This gets hard as people on teams tend to be exceptionally specialized. There’s a lot of tribal knowledge that you need in order to make pieces of the game and budgets for teams are tight that you don’t have that much redundancy in people. This becomes a nightmare in scheduling downtime for people while figuring out when and whom you need to work on the next piece of the game.

Live Service

And now we get to the ‘final’ piece of game dev and that’s the continual support of your product. That can be in the form of just patches to fix bugs and address quality of life features, or it can be constantly new content to be delivered for a ‘proper’ live service, or it could be new dlc and expansion packs being created for sale. Whatever the case you’re entering into both an exceptionally fun part of development as well as an incredibly challenging one.

Now that the game is out you can see how the world at large is reacting to your game. You can prioritize features that would make the most impact, see what needs to be fixed, and have an idea as to what people like, what they don’t, and potentially glimpse out why. However it generally takes a long period of time to create content and get it to the consumer. Just creating content alone can take easily up to 3 weeks for a lot of ‘simple’ types of content and that doesn’t start to include the time to test it, get it certified through first party and then out through a patch or your live service delivery method. That means you’re back into scheduling hell trying to figure out how to be able to provide a constant amount of content for consumers while not burning out your staff. As a couple of additional wrinkles you should have started this in the beta phase of development so your live service and patch systems could have been tested and there was content waiting to be delivered on day one, week one, month one, but your entire team was most likely too busy trying to just get the game out the door to do that. You also need to have a schedule that is flexible enough to allow you to react to what fans want from your game and be able to deliver that if it’s quick to do so.

Live service is an intricate balance of scheduling all of the demands on the team, however it can also be really rewarding to the team. You’ve got a captive audience waiting for more content and you can see how they’re reacting to your creations immediately and react accordingly. There’s no 2-3 year wait to see if people will like or get what you’re trying to do, but instead there’s a hopefully open communication there. As well you tend to be able to be a bit more creative now that you know what your game is and isn’t, and are able to figure out what the box you’re working in.

TLDR

Games are incredibly hard to make, from the simplest ones to the incredibly complex AAA blockbusters. They take a lot of effort and a lot of things go wrong. Honestly, it’s sometimes amazing that anything comes out and is as good as the games we see each and every day. And at the end of the day it’s a bunch of incredibly passionate people who just want to make games for other people, so cut them a bit of slack. It’s a human being that’s reading your comments so be constructive, but fair.

4 thoughts on “Making games is so easy! Part Deux!

  1. I really like reading this part 2! I found it relatable and professionally put, but also constructive. Just a thought, not sure how many that are not developers would understand all the abbreviations and the internal language. Then again it’s easy to find out about them and it would be people interested in the industry that would find this place ^^. I’d love to see a post about your experience with first party, publishers and similar kinds :D.

    Like

    1. Thanks a lot! Hm… I had hoped that I had described things for people who weren’t developers to be able to get a rough understanding of what I meant. Sometimes it’s so hard to remember what people who aren’t in game dev would know 😦
      Hm… I’m not sure there’s too much I can say on that stuff personally. I’ve tended to be a bit more removed from those interactions outside of responding to bugs from either QA or Design side.
      I’m thinking of writing about empathy and why it’s so important as a developer and specifically as a game designer next.

      Liked by 1 person

      1. That sounds great! Looking forward to that one! Sorry that wasn’t too constructive! I was thinking of terminology like what does “first party” mean and “pve” “pvp” but I might be overthinking it XD!

        Like

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