Why Prototyping is Important

Not a big post or reveal but that’s kind of the point of this dev diary, with rare exceptions. So let me you show you how we dealt with one of the design issues this last week.

Check out this video. Can you tell me what happened here? (You may want to turn on the HD and Full Screen for visual clarity).

If you noticed that, congratulations. If you didn’t, well, the video started with two Charged, high on witchfire enemies (the ones with the flaming sword) and two Uncharged ones. But at one point, one of the charged enemies spent all of his witchfire and became Uncharged.

The idea presented here was to add variety to this particular enemy and have it so they switch between the states. When the witch, controlling the enemies like it’s a chess game to her, grants extra witchfire to an enemy, he becomes Charged and can execute three charged attacks: powerful sword swing, sword fireball, and stab-jump. After that, he becomes Uncharged – and limited only to the regular sword swing – for a while until the witch boosts him with witchfire again.

This adds a small but nice tactical layer to the game. Do I deal with Charged first to avoid being ganked by Uncharged, or the other way around: knowing that Uncharged can’t hurt me from a distance, do I snipe Charged first?

The first issue is that this is hard to notice. You may argue that we should have added an extra “enemy becomes charged”, “Thor charges his hammer with a thunder” kind of animation. Sure, that would help. But what if the player is looking elsewhere, engaged in a difficult combat?

Also, how to show the “I ran out of witchfire” animation post the final charged attack? Technically, the enemy spends the last of the wichfire for the attack, so there’s nothing left after, and thus we don’t really have a foundation or pretext for the animation. And we can’t assume the player will keep the count of which Charged enemy spent how many charges already.

Not saying this is unsolveable, but it was an issue anyway. However, before we even attempted to deal with the problem, we realized we got it all wrong anyway.

To us, a good shooter allows for at least a certain amount of planning that goes beyond the next second. But with enemies – and more of them, the worse this issue became – constantly switching between the states, the gameplay became almost purely reactionary. You just pop the next closest guy. And that’s not what we want.

As an example, imagine you’re fighting three Charged and three Uncharged. You decide to shotgun the Uncharged first. Boom, done. You switch to the Bolt Action Rifle to snipe the remaining three enemies, all Uncharged. And then you get stabbed in the back because one Charged turned into Uncharged when you were busy splitting heads.

In other words, with the states constantly changing, you only have a firm grasp on what’s happening right now. But you can’t plan ahead. Well, other than “kill them all”.

So what we’re doing right now is we’re splitting the enemy into two. One will always be Charged, and one will always be Uncharged. No switching states. Full clarity on what’s going on. Actually, we’re increasing that clarity even more, and will make Charged enemies easier to distinguish from the rest.

This is why prototyping and testing are so important during the development of your game. Many things look really good on paper but then turn out to be a mistake after the implementation. It’s crucial to spot these problems as soon as possible, before you commit resources to make a feature quality.

Actually, the fact that paper design is often so useless, a design document for the game does not exist. Of course we do have spreadsheets with perks, stats, etc. — but we’re not wasting any time on a 100 page document that becomes obsolete after the first prototype. And they always do.

Although if only we had listened to the experience that Bungie designers shared in their GDC 2002 presentation on Halo AI…

…we could have probably avoided the issue simply during the design stage. But hey, lesson learned.

Question of the Week

This game is visually utterly breathtaking. What lighting solution are you folks using? Is it classic baked lighting, or all realtime with depthfield ambient occlusion (and maybe light propagating volumes), or something else?

— Makkon (@BenjaminHale7) June 17, 2019

We have not settled on the final solution yet. For now, we’re mixing full real-time up close with baked in the distance, with a nice invisible transition between the two. UE4!