How I Learned to Stop Complaining and Love the Arch-Vile

How I Learned to Stop Complaining and Love the Arch-Vile

When I first played through Doom 2 fully as a teenager, the Arch-Vile terrified me, inducing total panic whenever one appeared. I would often immediately charge it with the rocket launcher, forgetting that its own movement speed was so fast that between the two of us running towards each other I would probably end up blowing myself up and having to reload a save. Usually that save was from just a few seconds ago, because the sound of an Arch-Vile waking up was enough for me to immediately save my game.

Now, two decades later, as a so-called Professional Game Developer, I’ve spent some time thinking about the Arch-Vile and have come to the conclusion that it is one of the most brilliant and fascinating non-boss enemies in any game, and I’d like to explain why.

All Demons Great And Small

First, let’s rewind a year to before Doom 2, to Doom. Doom has a pretty classic lineup of enemies that spreads pretty evenly into this table:

HitscanZombie GuyShotgun Guy
ProjectileImpCacodemon (also flies)
MeleeLost Soul (also flies)Pinkie Demon (& Spectre)

And then there’s the Baron of Hell, who plays the “boss who becomes a normal enemy later” role and is both a massive tank and a heavy hitter.

Pretty simple, right? Plus, the two flying enemies are cleverly split between melee and projectile, and there are a lot of other clever concessions to tweak the difficulty, like the shotgun guy’s attack being much more deadly up close and the huge delay between the Pinkie Demon’s attack animation starting and it actually doing damage.

So in all, a pretty well-balanced roster of enemies with a fairly even distribution of traits.

So Doom 2 comes out, and it has seven new common enemy types. How do they fit in?

WeakStrongEven Stronger
HitscanZombie GuyShotgun GuyChaingunner
ProjectileImpCacodemon (also flies)
Hell Knight
Baron of Hell
Mancubus (slow, staggered attack)
Arachnotron( medium speed, rapid-fire attack)
Revenant (moves quickly but slow homing attack)
MeleeLost Soul (also flies)Pinkie Demon (& Spectre)None… sort of

Plus the Pain Elemental, which flies and spits out Lost Souls, and the Arch-Vile, who we will get to soon.

“Wait a minute,” you might be thinking, “the new additions completely break the chart,” and you would be correct.

A More Interesting Challenge

The new enemies in Doom 2 represent a huge step forward in how to think about FPS enemies by considering their differences in more dimensions.

For example, every projectile-throwing enemy in Doom uses essentially the same behavior: Walk (or fly) around for a few seconds, throw one projectile, repeat.

In Doom 2, the new projectile enemies have completely different behaviors: The Mancubus fires a volley of six projectiles, two at a time, in an alternating offset pattern; The Arachnotron waits until it has a clear shot, then continuously shoots rapid-fire until the target moves out of its line of sight; The Revenant alternates firing homing rockets and non-homing rockets.

But that’s not all, because id Software thought about how players would try to react to the Revenant (taking cover to wait out a volley of homing rockets) and made the decision to discourage doing too much of that by making the Revenants move very quickly AND giving them an extremely powerful melee attack. So if your reaction to the Revenant is to go hide in a corner to avoid the rockets, you might just get punched to death instead.

Meanwhile, the Chaingun Guy and the Arachnotron both discourage the player from hanging out in big open spaces by punishing them with non-stop attacks after a brief delay. And that chaingun doesn’t have the same huge distance falloff that the shotgun guy’s shotgun has.

Between all of these new enemies, the player has to think a lot more about prioritizing threats than in Doom. In Doom, a large room full of several of each enemy could be managed by constant movement and dispatching the hitscanners first. In Doom 2, between the Arachnotron, the Revenant, and the Chaingunner, running around in an open area taking potshots at the hitscanners will probably go poorly.

Enter… The Arch-Vile

But let’s say you’ve got all of that managed. You can dodge the Mancubus rockets, weave around the Revenant’s rockets, take out the Chaingunners before they can open fire, and kite the Arachnotron. There’s still one more left to deal with: The Arch-Vile.

Here’s the thing: Out of all the dimensions to measure enemies on, the Arch-Vile more or less breaks the table. It moves faster than anything else, does more damage than anything else, does hitscan damage, and to top it off, can actually resurrect dead monsters.

So wait… isn’t that completely broken and unfair? How is anyone supposed to manage that? Normally, a hitscanner who can kill the player in one or two hits if they don’t have full health and armor would be completely unfair.

But the Arch-Vile isn’t completely unfair, because id Software made every effort to telegraph everything about the Arch-Vile as much as they could.

First, though, let’s talk about sound effects. Doom and Doom 2 have some fantastic sound design, and they made the very clever decision to give monsters two important sounds: A wake sound and an idle sound. The wake sound plays the first time a monster sees you. This is great because if a monster sees you before you see it, you know it. The idle sounds are also good because they let you know that there are monsters nearby, so you know to look out.

Unfortunately, though, one of the problems with Doom’s monster sounds is that several monsters actually have the same idle sound, so you can’t really be sure what’s around the corner.

Doom 2 fixes this problem, though. Every new monster has a unique idle sound (except the Hell Knight, since it’s a smaller version of the Baron of Hell with similar sounds). They also have unique wake sounds, and (this is important!) a few even have sounds to announce when they’re about to attack! Specifically, the Mancubus and – you guessed it – the Arch-Vile!

So, thanks to great sound design, players know when an Arch-Vile first sees them, they can hear it roaming around, and they hear when it’s about to attack.

But that’s not all, because the Arch-Vile’s extremely powerful hitscan attack does something totally unique to warn the player: It spawns a fire sprite directly in front of the player’s view! Thanks to this, players always know when the Arch-Vile is about to attack, and after a few bad hits, they’ll remember exactly how long they have to get to cover.

And there’s the nice thing about the hitscan attack that telegraphs in advance: You know when to run to cover. Fortunately, even the tiniest sliver of cover blocking the Arch-Vile’s line of sight will block its attack, and the Arch-Vile doesn’t move while attacking (since it has to play a cool attack animation), so it’s reasonably easy to grab some cover for the split second the attack actually connects.

This deadly hitscan forces the player to weave in and out of cover until they can get a good shot at the Arch-Vile. If the Arch-Vile only had that deadly hitscan attack, though, players might be tempted to just avoid it entirely. But the Arch-Vile can also resurrect dead monsters, which makes leaving it alone a completely different problem. Its quick movement speed means that if it can’t find a player to attack, it can close distance on the nearest dead monster very quickly and bring it back to life, making leaving it alone for even ten or twenty seconds a potential disaster.

What’s fascinating about this design is that by making the Arch-Vile simultaneously extremely dangerous AND able to resurrect enemies, the player is incentivized to do two mutually exclusive things: Run for cover and wait until the right moment to attack, or try to kill the Arch-Vile as quickly as possible so it can’t resurrect a room full of other monsters.

Then again, every time an Arch-Vile decides to resurrect a monster instead of attacking the player, they’re stuck in a resurrection animation for a few frames and thus vulnerable to attack, so there’s yet another tradeoff.

This is what I love about the Arch-Vile: It breaks all the rules of the game while simultaneously using the conventions of the game to give the player an opportunity to learn how to overcome it anyway. It’s an insanely tough enemy, but it telegraphs its actions so clearly – more clearly than any other monster in the game – that the player can’t help but learn to understand it. It looks great, it sounds great, it’ll kick your butt, but that makes it all the more satisfying when you blow it back to hell.

LD41 Postmortem Part 2: Building And Reflecting

LD41 Postmortem Part 2: Building And Reflecting

As I said in Part 1, Ludum Dare 41 was my first game jam, and I was determined to produce a complete game. Part 1 describes how I picked an idea based on some criteria I laid out, and in this second and final part, I’ll describe what went right and wrong in making the game.

As a reminder, the theme of Ludum Dare 41 was: Combine two incompatible genres.

So, my concept was this: Combine FPS with a cooking game. Shoot monsters and throw their bodies into a stew in the middle of the level, based on a provided recipe. Simple enough, right?

Some important links:

My notes for Monster Stew, including monster ideas and a level layout idea.

What Went Right

Simple enough idea to execute

I’ve got years of programming experience, but not a whole lot of that is what you would normally call “game programming.” Sure, I spent a few years building games on Facebook, but that was still web development – php, JavaScript, mySQL, etc. And once I became a game designer full time, it was on a large enough team that I didn’t really have to do any programming.

Now that I’ve gone “full-time indie,” I’ve obviously had to learn a lot more game programming… but I’m still learning just enough to do what needs to be done, so I can do it and move on.

All that is to say that when I decided to make a first-person shooter using Unity, I would be doing a fair number of things that I had never done before. Because of that, the concept needed to be simple enough that I could dedicate time for trial and error for the stuff that was new to me.

Fortunately, the number of components for a game like this is fairly small. To get an idea of exactly how small, check out the scripts folder here and you can see just how few scripts there are to make the game work:

  • Bullet
  • Enemy
  • FaceCamera (For rotating the quads that act as billboarded sprites)
  • FirstPersonController
  • GameStateManager (Manages recipes and spawning enemies)
  • MouseLook
  • Rotator (All this does is rotate the stew so it looks animated)

(Note that since I entered the Compo, I needed to make the source code publicly available. I also included my Photoshop and Logic project files as well.)

The art requirements were fairly light as well, and I decided that the enemy art was going to be childishly simple on purpose, and everything else was just going to be simple and would more or less look like what you might call Extra-Shitty Quake.

Configurable Enemies

In order for a cooking game to be interesting, you need multiple ingredients… which in this case also means multiple enemies. And for multiple enemies to be interesting, you need different behavior.

To keep things simple, I wrote down some enemy types: Basic, Projectile, Fast Tank, Flying, and Big Bad. Knowing that those were my goal types, I could design an Enemy component with adjustable parameters for health and projectile firing. (I then doodled some weird enemy designs based on puns, and that’s how I do game design, everyone!)

The Enemy component on the Dog-O prefab.

I also used Unity’s built-in NavMesh components for enemy movement AI. Those components have some parameters that can be adjusted to change the enemy behavior, like movement speed, and turning radius.

Combining my Enemy component with the navigation component gave me just about everything I needed. I made sure to include an Awake Distance parameter – this determined how close the player needed to be for the enemy to become aware of them and begin pursuing and/or shooting them. I also adjusted the settings on the NavMesh Agent so that projectile enemies would stop short of the player so they could shoot, while the non-projectile enemies would get all up in the player’s business.

I ended up cutting the Flying enemy because I didn’t want to spend time writing any more navigation code, and if the flying enemies were just using the nav mesh but higher up, they wouldn’t really be very different from the other enemies anyway.

Adding Some Juice

I decided in the first few hours of development that I wanted the game to be as juicy as I could manage in the time I had. Players needed to know when they were hitting enemies, and when enemies were hitting them. Death had to be dramatic and entertaining. And very importantly, players needed to know when enemies became ‘Awake.’

I made sure to spend a few extra minutes on all of these details. There are little particle burst explosions for when the player hits an enemy. And there’s a burst of ‘blood’ coming from the player’s perspective whenever they’re hit.

I also took a swing at game sound design, which I had only really done once as a quick pre-alpha pass for my game-in-progress, Moustachevania. I used Logic’s built-in drum sounds plus a ton of reverb and effects to make explosion and shooting sounds, and I used my own voice (hey!) for almost everything else. I even did my version of the Quakeguy jump grunt, even though jumping really doesn’t add much to the game.

The sound of enemies going into the stew is a combination of an SP12 drum machine crash cymbal and me blowing bubbles into a large glass of water.

In general, I think I pulled it off; The game feels responsive and sounds pretty good.

I didn’t get this 100% correct, though; Many players didn’t notice the ‘Awake’ sounds – they were a combination of too quiet and not dramatic enough.

Playing To My Strengths

While I did set out to do something new from a tech standpoint, I also wanted to make something that was distinctly… me. The game combines a lot of disparate things I love: Retro first person shooters, weird monster designs, bad puns, serious parodies of seriousness, goofy sound effects, unsettlingly weird music, etc.

If you add an ingredient that isn’t needed, you get this fun Game Over message.

It was enormously satisfying to make. And some players, I think, even appreciated the jokes!

What Went Wrong

No FPS Dry Run

I didn’t know for sure what genre I was going to tackle before the theme was announced… but I’ve always wanted to make an FPS myself and I never got around to it. There were a lot of components I used for the game that would have been common components for any FPS, and if I had just spent a few hours at some other time to learn them, I would have saved a few hours of learning them during the compo time.

I followed an FPS controller tutorial to build that component quickly, and at some point I switched the movement method to one that (accidentally) ignored collisions. The result of this was that the player could walk through walls, and I didn’t really figure out that this was the problem until after the deadline. It actually doesn’t affect gameplay too much, but it was a frustrating rookie mistake!

Similarly, I learned NavMesh more or less from scratch during the jam. It’s not difficult at all (in fact, I was amazed at how easy it was, with one caveat I will describe below) but still… I should have done a dry-run with it earlier just to get familiar.


Before I set up NavMeshAgent, I had a Rigidbody on enemies and used it to add some recoil whenever they were hit by a player bullet. Once I added NavMeshAgent, things got weird.

I spent a whole lot of time trying to figure out why my movement seemed to get so buggy once the enemy was moving and then was hit by a player bullet. Turns out, the instructions for NavMeshAgent explicitly recommend not to move its Rigidbody while active, because they both end up fighting over moving the GameObject.

Ultimately, I had to ditch the recoil feature and just make the enemy pause their forward movement when hit.

Of course, there’s an easy way to do this involving turning the agent off. Or, you can actually just extract the directional information from the agent and apply force in the right direction to the Rigidbody manually.

In other words, there are ways to solve the problem, but because I was inexperienced, sleep-deprived, and in a hurry, I just wasted a bunch of time trying to salvage a feature that I had to abandon.

Physics Are Hard

To add onto to the previous problem, I also wanted to let players push the enemies around when they were dead in order to put them in the stew.

Turns out, this is hard. Or rather, it requires more knowledge of Unity’s 3D physics than I had and was willing to learn in the short time available.

Fortunately, I came up with an alternate solution: Picking them up and throwing them. This solution actually turned out to be more fun than pushing them around would have been, so ultimate it worked out. Still, it was another time sink.

Too Loose With The Theme

This is something I was worried about when I started building the game, and the Ludum Dare reviewers confirmed it: The genre combination wasn’t all that interesting from a gameplay perspective.

This sentiment was shared by a few people who commented.

In concept it sounds pretty cool, but in execution it was functionally not all that different from a fetch quest in a first-person RPG, or any of the “pick something up and move it from here to there” puzzles in Source-engine games.

As such, ratings for Theme and Innovation were lower than I expected.

Wrapping It Up

I think one of the most interesting psychological aspects to creating art is that we always come up with different criticisms of our own work depending on what phase of creation we’re in. Putting it in front of an audience triggers deeper examination and, if it’s still possible, fine-tuning, for instance.

I decided to wait until LD41 ended and scores were made public before writing this postmortem. And, well, I was disappointed with my scores. But that also made me think hard about what my goals were, and to try to remember that the main goals are to just build something and have fun!

So, by that criteria, it was a complete success.

But… seeing the scores, seeing which games did well, really made me think about how to treat a game jam as a game design exercise. The winning games are generally very simple from a technology perspective, so all the cleverness is in the game design itself.

One reason I decided to use a lot of new stuff for LD41 was that I don’t feel proficient enough in Unity’s 2D toolset (which I’ve been using to build Moustachevania) or in any other game engine for it to be too much of a time advantage to use that, so I figured I might as well learn something new anyway. A lot of the people who enter Ludum Dare seem to be seasoned developers who are very comfortable with the technology they use, so LD is, for them, almost entirely an exercise in design and execution, with little to no part of it being about struggling with the tools or tech.

I don’t have a prescriptive takeaway from that. My advice is to just know what your goals and limitations are, and to try to build a game that fits within both. It’s just fine to fumble around in something new and build something you barely consider a game, and it’s also fine to pick up a technology you know incredibly well and can be productive with.

I won’t be able to enter the next Ludum Dare because it overlaps with the Outside Lands music festival, which I attend every year with my awesome wife. But LD41 will definitely not be my last game jam. It was a great experience, and I recommend it to anyone who builds or wants to build games.

The final level layout. This didn’t fit anywhere else so I put it at the bottom.

LD41 Postmortem Part 1: The Games I Didn’t Make

LD41 Postmortem Part 1: The Games I Didn’t Make

Ludum Dare 41 was my first game jam, and I was determined to produce a complete concept. I’d read some horror stories about developers who overscoped their games and couldn’t really finish them by the deadline, and I wanted to avoid that. Unfortunately, I also had a minor cold, so I knew my productivity was going to be hampered. Oh, and my wife was working night shifts at her job during the week, so our sleep schedules would both be thrown off. Hooray!

One of my design skills that I’m most proud of is the ability to model game systems in my head and find problems quickly. This can be dangerous, of course, because if I use it during brainstorming it can hamper creativity by closing doors too quickly. But when brainstorming ideas for a game jam, it’s actually perfect because I don’t have a lot of time to work out design problems; I need a concept that I can for sure build, and that satisfies the criteria I laid out for myself.

Oh, it’s also worth mentioning that I wanted to make a game for the Compo, which allows for 48 hours and has strict “make everything from scratch” policies.

So, here were my criteria:

  • The idea needs to be simple enough to be a “complete thought.”
  • It needs to fit the theme – “Combine two incompatible genres”
  • I need to be able to execute thoroughly on both genres so that the concept doesn’t feel like a cop-out
  • It needs to be something that I can pull off with my very limited art skills
  • It needs to be in Unity, because that’s the engine I know best at the moment and I need to be productive
  • Preferred: I want to make something 3D.

So, let the brainstorming begin.

Idea 1: Roguelike Walking Simulator

This is the discarded idea that I spent the most time on. One of the things that appealed to me about it was that I could use my voice and build a narrative. I enjoy both voice acting and writing stories, so this would seem to be a good choice. I also enjoy weird narratives, and nothing could be weirder than a randomly generated narrative.

As I pursued this idea, I thought about how silly I could make it. I wanted to create a bunch of rooms, and then fill them randomly with objects. The objects would be silly too – my brainstorming list includes “Disco ball, flan, cactus, suitcase, giant sausage, large orange, and dais.”

Roguelike Walking Simulator brainstorming. Yes, my handwriting is awful.

Finding an object would trigger narration tied to that object which would contribute to a larger story. But I would also make the game shorter than the length of the story, so that the only way to get the whole story would be to play through the game multiple times and try to figure out how all the elements fit together.

But then I started to have second thoughts. Roguelike implies more than just procedural content generation; It also implies things like permadeath, and an actual challenge. I considered changing the genre definitions to “procedural generated walking simulator,” but procedural generation is a method, not a genre.

I also considered adding some challenging elements or some kind of death mechanic, but nothing made sense with the rest of the concept.

So I moved on.


It’s a pinball shooter! The idea here is simple: Spacebar controls the flippers, mouse aims, mouse click shoots.

At first, this seemed like a perfect fit. Neither of those mechanics seem especially hard to build. Unity comes with enough built-in physics that I could probably make a pinball game pretty easily.

But… could I? In theory, maybe. But game physics are full of gotchas, and I don’t have enough experience Unity’s physics to confidently make a game based entirely on physics.

There’s also the problem that a good pinball game actually has a lot of moving parts, and I’ve never made one before. I would have to build out curves that would work properly with the physics to move the ball around, bumpers, and those things that hold the ball for a second and then spit it back out again…

On top of that, I would need shooter mechanics.

I also explored how a level would be designed. A single board may not be enough fun or enough gameplay; Multiple boards would require a lot of design work.

At that point, I couldn’t see a way forward that wasn’t altogether Way Too Much Work. And so, onto the next idea.

Ideas 3-X: Brain Dump Time!

It was after dinner – several hours had elapsed since the theme was announced, and I still didn’t have an idea. At this point I decided to just start trying to metaphorically stick my finger down my brain’s throat and vomit out as many ideas as possible.

This is how I brain-vomit ideas onto paper. It looks like it, too!

I thought, what have other people made with Unity? I remembered all those tiny horror games made with Unity that are basically “don’t let the monster get you,” and I thought – what if when the monster gets you, he asks you questions? Hey, it’s a horror/quiz game!

But then I remember that there’s an entire game in one of the Jackbox Party Packs that is literally a horror quiz game, which made my idea feel less interesting. Also, I felt like if I was going to go to all the trouble of making a game, I should probably find a more interesting concept than “avoid a thing and then take a quiz.”

Next up, a match 3 platformer! I’m a huge fan of games like 10000000 and You Must Build a Boat (okay that’s basically the same game) where there’s a match 3 mechanic and action/RPG mechanics. (I also think Puzzles and Dragons is utterly brilliant.) I considered a more deliberately frustrating, troll version of a match three game, where the match 3 part of the game is in the middle of a platforming level, and the player has to walk around the level picking up colored bubbles and dropping them on top of other ones to match.

I just wasn’t that excited about it though. It seemed more like a “hey look at this goofy concept” than something that could actually be a fun game. I mean hey, a game that’s basically 100 fetch-quests, right?

And finally, a stealth physics game. I thought about taking two concepts that are completely opposed to each other: Games where you have to break as much stuff as possible (like Angry Birds) and games where you have to break as little stuff as possible (stealth). So, I imagined building structures out of physics objects and letting the player fling their stealth agent around, over, and through them while causing as little destruction as possible.

But that would present one of the same challenges that caused me to rule out pinball: I don’t know enough about Unity physics to confidently build that game. And I know that Angry Birds, in order to offer as much destruction as possible at 60fps, has finely tuned physics code. And that’s something I had neither the time nor the expertise to manage.

Final Idea: FPS Cooking Simulation

The pitch I wrote down on paper is simple: “Shoot enemies, push their corpses into stew.”

I wrote down the major tech requirements, and it was only two bullet points:

  • FPS controller
  • Camera facing sprite script

In truth, that wasn’t actually the full list. I also realized I would need to learn and use something to build level geometry, so I picked ProBuilder (which is now officially a Unity product, and free).

There’s also the fact that I’ve wanted to build my own FPS for years, literally since I was in third grade and played Doom for the first time. My notebooks from then until age 12 are full of sketches of levels, monsters, and weapons for an imaginary FPS. (That wasn’t my only imaginary game – there were many others!)

And my plan as an indie developer is to eventually build a fully featured FPS inspired by Doom 2, Quake, etc.

So this felt like a good start.

Before I close out Part 1, let’s see how the concept fits my requirements.

  • The idea is definitely simple enough to be a complete thought. The shooter mechanics can be simple, and the cooking just needs to be “include the correct ingredients or you lose.”
  • It fits the theme.
  • Given the simplicity of both genres (IE the requirements for a game to fit the genre are simple, unlike, say, Roguelike) I can execute on both fully enough
  • I can pull it off with my limited art skills by using billboarded sprites in a 3D world.
  • It can be done in Unity
  • It’s 3D

So, at that point, I had chosen a concept I was 100% sure I wanted to execute on. In part 2, I’ll explain how I did it, and where I made mistakes.

10 Live Service Game Tech Mistakes And How To Avoid Them

10 Live Service Game Tech Mistakes And How To Avoid Them

Building your first live service game? While there are countless articles about what technology to use, how to handle syncing between clients, and all those other issues that are core to live service games, there are a lot of specific issues that you’re likely to encounter late in the project… or possibly once you’ve already soft launched!

Yup, sometimes you don’t realize you need something until you really, really need it.

Can’t Force a Restart And Update

“Of course we can force an update,” you might say, “every time the game starts, we check to see if an update is needed!”

Unfortunately, for many games that’s not enough. In a PvP game, for instance, everybody needs to have the same assets and data available, so if one person fights another person who has the newest, hottest character or gear or ability, it’s available and supported.

The easiest way to handle this is to send back the current earliest supported client, asset, and/or data version with every API call, or at least with many of them. If the current client is earlier than that version, it boots the player to the title screen and downloads the update.

I’ll add the caveat here that there are multiple types of updates. Client updates for mobile games are a completely different beast, because the app stores don’t guarantee that they’ll all be available at the same time. For this case, you’ll need to get even more clever, possibly keeping content gated until 24 hours after the update is “live,” or actually finding ways to partition users.

On the other hand, for all types of updates besides mobile client updates, you should have full control over the process and be able to force an update whenever you need. That includes assets, data, localization, etc.

This applies most strongly to multiplayer games. There are plenty of live service games that are still essentially non-social single-player experiences – they may not need immediate updates.

Only Supporting One Version At A Time

(This applies specifically to mobile games.)

Speaking of client updates, I’ve actually been locked out of a game before because they released a client update and made it mandatory BEFORE it had propagated throughout the app stores everywhere.

Supporting two versions at the same time is a lot more work, especially for server engineers, but if you’ve got the team and budget to support it, it’s a lot better than the alternative of locking people out of the game because an update isn’t going to be available for another few hours.

This is a really tricky set of weeds to get into, so I’m not going to prescribe a solution. Definitely talk about it in advance though.

Can’t Message Players Immediately

Let’s say you just released an update and there’s an ugly bug that 5% of players are seeing. You can’t roll back the update, but you need to let them know to sit tight because a fix is coming soon.

But wait! Maybe the game only allows you to do updates that kick the player back to the home screen and alert them that an update is happening. That’s overkill.

Including a way to silently update data and localization (which generally are small enough to download quickly and without fanfare) will save your butts when you need to make quick changes and bug fixes without major disruptions to the game experience.

And that brings us back to the original problem: Messaging players immediately. The ability to add an interstitial dialog with some quickly-assembled text that appears the next time they visit the home screen is going to be extraordinarily useful the next time something is on fire and it’s going to take more than a few minutes to fix it.

Localized Generic Downtime / Error Messages

Let’s say your game is localized in a bunch of languages and you generally need twelve to twenty four hours of turnaround time for translations. You can’t exactly rush out a detailed message to players about what’s wrong and how you’re going to fix it in every language. What you can do, though, is to have some pre-translated messages for different severities of problems, and a pre-built popup with a button that sends players to your forums.

Hello players, we are aware of some issues since the last update and are working on fixing them ASAP! For more details, check out the forums,” or something like that.

Can’t Have Arbitrary-Length Messages

Game UI is hard. It’s hard for a lot of reasons. And that difficulty often results in tradeoffs. One trade off might be that you avoid scrollbars or auto-sizing text.

Unfortunately, in a reasonably complex game, you’re eventually going to want to give players plenty of information in your in-game update notes. Not all of it, of course – that’s for the forums – but enough so that they have a good understanding of what’s changed without having to leave the game.

And that’s going to require scroll bars, or at least a scrolling text window, or at LEAST a popup with text that automatically sizes.

Maybe you can save this for later. But if you have the option to add it early, do it. I’ve seen firsthand that having more specific update notes in the game will save a ton of player confusion and complaining elsewhere.

Implicit Rather Than Explicit Data And String References

Now we’re getting into nitty gritty technical implementation details.

Imagine this hypothetical conversation between a designer and a programmer:

Designer: “Each character will have a unique ability.
Programmer: “Always? Can you guarantee that each character ability will be unique?
Designer: “Umm… yes. Yes, for now.
Programmer: “Okay. In that case, I’ll save you some data entry time and make the ability names and descriptions automatically reference strings based on the character ID.
Designer: “That sounds useful, I like not having to do data entry. How does it work?
Programmer: “Well, if your character ID is AXE_GUY, then the ability name and description will be AXE_GUY_ABILITY_NAME and AXE_GUY_ABILITY_DESCRIPTION.
Designer: “Sounds great! Now I don’t have to input or manage those string names!

And then they both realize it’s lunch time, hold hands, and skip across the street to the deli together, singing songs and being merry.

Of course, at some point, this plan is going to go wrong. Maybe all characters get another ability, and it strains the convention (AXE_GUY_ABILITY_2_NAME?). Or maybe alternate versions of characters are added that have the same abilities but different skins or stats, and you literally need two characters to use the same string. What’s the solution? Do you duplicate the string text in every language to a new string id? Do you force one string to reference the other? Do you create a separate doc entirely consisting of aliases of string names to other string names?

Or you can avoid this whole mess by not having references and names that are based on ids or other references. It’s a bit of extra up-front work for designers, but it will save headaches later when you decide to start bending or breaking your conventions.

Schedule Coupling

This is a weird one, and more of a convenience feature, but hear me out. If you’ve got a big timed event going on, you’re going to have lots of different individual features that will be turning on and off – pop-ups/interstitials, sales, packs, items, PvP events, PvE events, etc.

Now, you COULD schedule each of those individually.

But if you make a mistake, weird stuff happens. Let’s say you screw up the timing of a sale and it doesn’t match what the interstitial says. Angry players! There are so many combinations of issues that can arise via scheduling items separately.

Here’s an alternate solution: Build all of the events without a scheduling component. Then, build a separate scheduling component that acts like a SQL join table – one start time, one end time, and a list of the ids of all the items that will turn on and off at those times.

Your QA people are going to thank you. Your players won’t thank you because they won’t really think about the fact that everything is working as intended, but that’s okay. You’ll know in your heart that you did the right thing.

Time Zone Confusion

Speaking of timing: This is a reminder that if you’re going to build time-based features, make sure that every single person on the team gets together and agrees on how you’re going to manage time zones.

If this isn’t explicitly defined, the larger the team you have, the more opportunities you’re going to have for inconsistency here. One programmer might build a feature to expect UTC times, another might build a feature to expect a formatted time in the local time zone.

All of this confusion will create extra work for designers and QA.

So, agree on one system early on and make sure everybody sticks to it.

Confusing Or Inconsistent Data Conventions

This will happen naturally over the course of a project: As the design evolves, through trial and error, and as everybody figures out what works and what doesn’t, the ways in which design data is defined will change.

So, you might end up with some XML files, some JSON files, some CSVs, maybe even some custom formats that are like CSV but not quite. Maybe the XML conventions will be inconsistent between the use of properties vs children, or nested objects vs references using id properties.

Again, this can happen naturally over the course of the project. Just look out for it – talk in advance about your needs. It should be a collaborative process between designers and programmers. Designers should understand the data format and feel comfortable working in it, reading it, and making recommendations. And programmers should understand the design needs so they can proactively suggest changes that will make life easier for everyone.

Lack of Tools Due To High Standards

Okay, everyone always complains about tools. I’ll bet if you polled most live service game teams, tools would be on 90% of wishlists.

Here’s the thing: Tools don’t have to be fancy. They don’t have to be custom-built apps. They don’t have to be web apps. They can be as simple as an Excel spreadsheet that uses string replacement functions to spit out XML.

I’ve personally been responsible for tens of wasted hours on tools that were built and then ultimately unusable within weeks because they were so complicated that as soon as the game features changed, the tools no longer supported them. And keeping up tools support is a full time job!

If your team is starving for tools, consider lowering the bar.

I once ran a live service team for a game that had most of its support removed – we were the skeleton crew keeping the lights on. And one day I got fed up with all the manual data entry and realized that I could build XML templates in Excel and make it auto-generate everything I needed, and all I had to do was copy the XML from Excel and paste it into a text file.

It wasn’t the ideal tool but I saved an enormous amount of time.

wrapping it up

I worked in live service games for many years and several capacities – programmer, game designer, and producer. I’ve seen just how much can go wrong, and sometimes I think it’s amazing that any games get made at all! Hopefully, this has helped make things just a little bit easier for you and your next game.

Need help building out your live service game? Get in touch!

Clash Royale Is Like Poker

Clash Royale is one of the most popular games in the world. It’s also one of the most financially successful, generating at least a billion dollars a year worldwide. Now, given its success, a fair amount has been written about its design. There’s plenty of analysis on how it monetizes, and on the specific metagame, optimizations players can make between time, in-game currency, and real money… but what I want to talk about is different.

I want to talk about how Clash Royale uses some of the key elements of poker in its game design.

Now, the best poker players can figure out what cards another player has based on very limited knowledge, and oftentimes their success will be based on their ability to make an educated guess about their opponent’s hand and their strategy. And knowing their personality and play style helps, too.

To boil it down, each player has things they know, like what cards they have, what cards have been revealed, and how much money is on the line. They know what each other player has bet, too.

And then there’s the soft stuff, things that are open to interpretation. What’s the personality of the other players? What kind of risks do they take? What’s their mood? Is there a tell?

Okay, so keep that all in mind.

Back to Clash Royale. I’ve seen it compared to Chess, which is a game of pure strategy… but each player has the same knowledge of the board at all times. Players might not accurately predict each others’ moves, but given exhaustive effort it’s theoretically possible to do so.

I’ve also seen Clash Royale compared to Counterstrike. I think this is a great comparison in the sense that all players know what’s possible, but there’s no way to predict the decisions of the other team except by looking at their past actions and hoping that they signal future actions.

Thing is, in Counterstrike, once a round is over, that’s it – you can’t build off of the success or failure of a round. You just start over and hope to do better next time.

Clash Royale has also been compared to MOBAs. This is insightful because there are multiple paths to victory, and each player can have a drastically different loadout. But in a MOBA, each team knows what they’re up against in advance. They know the heroes, they know their moves, they just don’t know how the other players are going to use them.

To summarize:

Chess: Full situational awareness at all times, no randomness, no variation in starting state

Counterstrike: Incomplete situational awareness, no randomness, but player-driven variation in starting state (which is unknown to the opposing side)

MOBAs: Incomplete situational awareness, no randomness, more dramatic player-driven variation in starting state (but some of it is known to the opposing side)

Poker: Incomplete situational awareness, randomness, players have no control over the starting state

Now, think about those traits. How does Clash Royale fit in?

Like poker, each player has incomplete situational awareness; They don’t know what’s in the other player’s hand at all when the game begins. They have to piece it together as the other player plays their cards. And once they have played a card, the other player has to remember that it’s there, keep track of how many cards are played, and have an idea that on average a card will show up ever four cards played (since a player can only hold four at a time).

Like poker, the starting state is random, but like a MOBA, the player still has control over the loadout.

So, to use the existing terms, Clash Royale is in a unique position where a match exhibits the following characteristics:

  • Randomized starting state, but from a fixed set of possibilities defined by the player
  • Incomplete situational awareness, since players don’t know each others’ hands, like poker
  • Learning other player’s hand over time, like poker
  • Learning the other player’s style over time, like poker
  • Using the knowledge of the player’s hand and play style to predict their behavior, like poker

Of course, you can’t explain the game entirely through poker, but I do think the most interesting aspect of gameplay is when you’ve mastered your understanding of each card, because at that point the most important part of your strategy stops being about you and starts to be about learning what the opposing player has and then trying to predict and manipulate their behavior.

In other words, you can bluff, you can intimidate, you can cause panic. You can take advantage of the fact that they don’t know what you have, even though you may not be entirely sure what they have. And that sounds a lot like poker to me.

Monetization Design: The Basics

Monetization Design: The Basics

Monetization can seem foreign to designers who are new to it, and I’ve actually seen designers throw up their hands and declare “Well, I don’t play f2p games and I don’t understand why people would spend money on them anyway, so I’ll just add a bunch of monetization features that I’ve seen in other games!”

This can lead to some bad decisions.

So, rather than create a guide that just contains a laundry list of design features and buzzwords, I want to try to dive deeper and explain why successful f2p games work, and specifically here, I want to focus not on what’s going on in the developers’ minds when they build the game, but instead on what’s in the player’s minds when they play it, and possibly even before that.

A few notes before we begin: First, what I’m saying here applies to all games with microtransactions. That includes entirely f2p games as well as retail games that feature microtransactions. I’m going to say f2p here, but the same principles can apply elsewhere. And second, I’ll often simplify the details for the sake of explanation. That’s because the point is to understand how to think about designing games, and not to learn the specifics of any one game. In other words, I want you to see the forest for the trees.

Let’s start with something that sounds obvious, but it’s worth saying out loud: Different games attract different audiences, and different audiences will prefer different ways to spend money in the game.

There have been many games with microtransactions that didn’t monetize (or worse, that pissed off their players) because they didn’t understand this rule and tried to apply the wrong business model to their game.

Now, the right business model should emerge based on player expectations of what the game is about. If your game is basically unknown to the player, then the game can set those expectations in the opening few hours of gameplay. If players are coming in with expectations already, then you better not disappoint them!

A lot of players complain pretty loudly online about pay to win. And for many games, pay to win isn’t appropriate. But there are some games that are completely pay to win, and their players are okay with it. Why? Because those games deliberately selected for those players.

Let’s take an example of a game that is very, very pay to win: Mafia Wars. Back in the early days of Facebook games, before FarmVille, there were a bunch of these types of games on Facebook that figured out a simple way to convince players to make the game viral: Tie their in-game power directly to the number of their friends they could invite to the game. Many of them were Mafia-themed, and Mafia Wars was the Zynga version. Inviting friends makes sense because the in-game justification is that you’re growing a criminal empire. Now, it logically follows that each member of this criminal empire is going to need at least a weapon, and you can buy that weapon with in-game currency… but you can also buy an even better weapon with real money. And thus, a very direct pay-to-win model is born.

This is actually cleverly tempered, though, because you can only have a certain number of mafia members per player level, which means that the more a player levels up, the more friends they can invite… and it also means that the more they level up, the more money they are allowed to spend. That has the added side effect that the power difference between free players and paid players starts small and increases over the course of the game. When you start, the ‘pay to win delta’ feels small because it is, and after a few months of play, the ‘pay to win delta’ is massive.

Now, you might be thinking, that sounds really obnoxious – the game wants me to pay money for every person I invite. And you should know that it’s all optional – you can play the game forever without spending any money. But… the game also has some very powerful items available as rewards in PvP, and if you want those items, you need the most powerful mafia. And if you want the most powerful mafia, you have to pay.

The game makes this clear early on – all of these elements are available to the player pretty quickly. And so, having most likely entered the game via an invite from a friend, and with no other knowledge of the game, players get all the information they need and can decide whether or not to keep playing, and whether or not to pay.

Heavily pay to win games like this have poor early retention; Players will decide whether or not they want to invest the time or money in the game, and most will make the decision that, well, it’s not worth it.

However, heavily pay to win games like this, when executed well, can have excellent long-term retention for the small percentage of players who stick with it. These types of players are competitive, they’re often willing to spend money to feel the satisfaction of winning against another player, and they pick one or two games to invest that kind of time and money into. It basically becomes their main hobby. And it can last for years.

Let’s get back to rule number one: Different games attract different audiences who have different preferences about how to monetize the game.

Can you imagine if the Mafia Wars model was applied to a modern AAA game? What if Destiny scaled your character’s power based on how many friends you could add to an in-game contact list? And what if you could pay money to increase your power based on your friend count? Fans would be livid, they might even burn down the internet. Yes, the whole internet.

Now, let’s look at a game that started as a retail game but became f2p in a way that reinforced the core gameplay: Team Fortress 2.

TF2 recognized two key things that would make it work as f2p: First, that the game is fundamentally based on skill and teamwork, and that any changes absolutely could not undermine that. And second, the game is basically a silly cartoon version of the original Team Fortress concept, and that’s what made it unique in a genre dominated by super serious military shooters. The f2p elements doubled down on both of those core principles.

First, let’s just reiterate how TF2 handles its economy: Players earn items simply by playing the game. The items appear in players’ inventory randomly while they play. And sometimes, players will receive ‘crates,’ which contain items but can only be unlocked with keys, which can only enter the economy via direct purchase with real money. Players can trade any combination of things with each other – keys, crates, and items – so a free player can still get keys if they have items that a paid player wants and they make a trade.

The items themselves are mostly cosmetic, and many are quite silly. This solves a key problem that players have in a game like this, where players can choose their class of character but otherwise look the same as everybody else playing the same class. The cosmetic items give players a chance to customize the look of the character without affecting their silhouette, which means that players and enemies alike can still identify which character class they are at a distance.

The non-cosmetic items are where the game gets really interesting. Every non-cosmetic item has some kind of tradeoff – for every stat it increases or ability it adds, it compensates by removing an ability or reducing a stat. This means that all players are basically on even ground regardless of their equipped items, and equipped items effectively create additional character subclasses. Tradeoffs get very, very creative, too – there’s a rocket launcher that heals its user on hit but has to be reloaded more often, various items that have additional abilities at the cost of not being able to do critical hit damage, and a weapon that does less damage but allows switching between weapons faster. There are a few weapons that completely change the functionality of a class, like replacing the sniper rifle with a bow and arrow, or replacing an entire class loadout with a sword and shield.

For players who learn their alternate weapons and items exceptionally well, there is kind of an advantage, but only insofar as other players have to learn how to deal with them.

So, that’s a f2p model that completely respects principles of the original game: The game continues to be skill-based and reinforces its silly aesthetic.

These games are polar opposites on just about every spectrum. TF2 was a mass-market retail game that became f2p; Mafia Wars was a game exclusively on Facebook that was always f2p and spread via social network invites and ads. But what both games have in common is that they have a thorough understanding of the expectations of their players. And they consistently build features that reinforce those expectations. Team Fortress 2 rewards play time with items but only ever favors skill level and teamwork when it comes to actually winning, and Mafia Wars rewards play time with power while rewarding real money with even greater power.

So, if you’re a designer building a f2p game and you’re considering a feature, always ask: What kind of game do players think this is? What are their expectations? What parts of the game are sacred? Is the audience interested in rewarding skill, effort, time, money, or some combination of those?

The answer is different for every game, and it’s your job to figure it out.

Need help? Get in touch and let’s talk!