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
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
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
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
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!