In 1987, Zelda II: The Adventure of Link graced the NES with some significant changes to its highly acclaimed prequel. It boasted side scrolling platforming, RPG elements like experience points and levelling up. It featured a free-roaming world map in addition to combat and item progression that not only unlocked the critical path forward, but also offered new ways to dispatch Ganon’s followers. The sum of which made for an adventure that felt somewhere in between the traditional Zelda titles we are typically more familiar with, and a Metroidvania-style action game. It was a critical and commercial success to be sure, and you can also be sure with that kind of success, comes one thing: imitators!

No, we aren’t going to attempt to improve a groundbreaking and thoroughly enjoyable game like Zelda II! We will however take a look at one of the titles that drew much inspiration from Link’s second outing, and learn a thing or two about action games along the way.

The Battle of Olympus first came out on the NES in 1989 and was later ported to the Game Boy by Radical Entertainment in 1993. Taking place in ancient Greece, Hades, the dark ruler of the underworld, has kidnapped Helene. It’s up to Orpheus to gain the favor of the gods and rescue her.

The Battle of Olympus is all you would expect from a Zelda II clone. The player can use a sword to attack enemies and a shield to defend himself. You can find health, defense, and speed upgrades throughout your adventure, and take on optional side quests if you so wish. Yep, it’s certainly a Zelda II clone. Except for one thing… it’s just not as good.

While I think the redesign of the environments and HUD to suit the lower resolution of the Game Boy screen is done very well, the combat, a mechanic you really want to nail in an action platformer such as this, leaves much to be desired. In this article, we will focus on a single element of the game’s design, with the expectation that it will improve the most important fun factor of The Battle of Olympus: combat!

In Argolis, one of the first areas of the game, Orpheus comes across two unique enemies. One is some sort of worm creature that drops from the tree canopy as the player walks by and the other is um, well, I’m not entirely sure what it is exactly, but it looks like a little bear that throws a small spear.

The worm itself is designed well when it comes to telegraphing its attack. In other words, it gives a visual cue that it will attack and, in turn, the player has time to either avoid the attack or prepare to slash their sword to dispatch the enemy before they are damaged. As seen above, it does this by jumping and falling from the tree canopy above when Orpheus comes within range and these two states (that of an upward jump and ensuing fall) is time enough for the player to respond. 

The bear on the other hand, just zooms on in, stops for a couple of frames, the spear floating around its head immediately shoots towards the player and the bear then scurries off-screen. All of this has taken less than a second and when I first played this game, I just stopped in my tracks as this little cretin affronted me. I took the incoming damage, not entirely sure what happened when the dust settled. To be fair, you can get the shield which will deflect projectiles like this later in the game (even though it’s already visible when you first start the game? Not sure what’s going on there…).

Back in the day, when technology couldn’t handle huge amounts of data packed into a ROM, and video game rental stores preferred to stock harder games to force gamers to rent and re-rent titles, the name of the game (so to speak) was to develop a very hard title. This strategy increased longevity and made sure anyone renting the game would have to cough up more cash if they wanted to see the end credits. In order to make a game harder, some developers chose to make things perhaps a little too unfair by throwing enemies and obstacles at a player so fast, it was unreasonably challenging to succeed unless a high amount of level layout memorization was achieved. 

Thankfully, those days are over (in theory anyway), but even before the release of The Battle of Olympus, there were some excellent examples on the system that showed you could deliver a challenging action game and treat the player fairly by implementing well designed telegraphed attacks. Let’s take a look at one of the best games on the Game Boy and how it designed these important and nuanced design elements: 1991’s Ninja Gaiden Shadow.

Here is one such enemy design that we can learn from. The grenadier enemy delights in lobbing grenades at Ryu, but he doesn’t chuck it without warning. There are a total of three states this enemy can be in at any one time, which cycle through a repeating predictable pattern. They are:

• The idle state
• The attack telegraph state
• The attack state

If we break it down further, we can determine how many frames these states last, and hone in on the details more precisely. 

Now let’s do the same for our bear friend and compare the differences:

It is quite a different approach to enemy design, isn’t it? I left an idle state out in Table 2 because the bear doesn’t really have one (unless you want to count the three frames when it stops). The bear’s approach is its telegraph and coming in at nearly one second, it’s time enough to prepare to jump over the spear projectile once you know it’s coming. 

Comparing the two, the time taken for the player to observe the entire state cycle of the grenadier, from idle to close of attack state, is all of 160 frames (or 2.6 seconds) while the bear’s state cycle takes 65 frames (just over a second) total. What’s great about the grenadier is that he sits in one place, allowing the player to observe the full cycle in complete safety. The worm shares a similar behavior in that you can at least watch it on screen before getting closer to it, but it must be noted that this worm will ambush you once within proximity, so you can’t quite tell what it will do by observing it from safety. Of course, there’s nothing wrong with the odd ambush if designed well.

In any case, let’s get to work on this Bear enemy and see what changes we can carry out to make this encounter a little more reasonable!

We could do a number of things here. We could retain its “rush in and ambush the player behavior” but slow things down and include a pose of the bear readying itself to throw the spear. Or we could redesign the ambush altogether to have him pop out from behind a tree – maybe by peeking his head out before jumping and then throwing his spear. But because this is the early game and we want to make sure the player can see the enemy’s whole cycle, we are going to take a page from Ninja Gaiden Shadow and its grenadier enemy, applying a similar design strategy. 

Now the bear will no longer rush in. He will spawn in, stand still with an idle animation for a period of time, then telegraph his spear throw by drawing his arm back with spear in hand, throw it, and then the cycle will repeat. But we won’t stop there! We can do one better and give him a random attack pattern that will either throw the spear straight ahead (in which case the player will need to jump over it) or he will throw the spear above the player’s head (in which case the player will need to avoid jumping). This should add an extra level of complexity to the bear’s attack and, as he is staying still, the player will now have the pleasure of cutting him down too!

Here are the new sprites for our attacks, all designed with as much efficiency as possible so that even with our larger scope of actions, we only have an extra two sprites added to the scene. We have:

• An idle animation
• A telegraph for when the Bear throws his spear straight ahead
• A separate telegraph for when the spear will be thrown above the player’s head.
• And I made the spear a bit more chunky so that it’s more easily distinguishable while it’s flying.

And here is what the two separate attacks would look like if we were to implement them.

Each attack is telegraphed in accordance with the action that will follow it and the spear itself acts as a kind of pointer that indicates the projectile’s incoming trajectory. After setting the attack telegraph state to last something like 30 frames, it should make for a slightly challenging yet fun little moment as apposed to a confusing one. 

So there you have it! Because attacks and the moments preceding them tend to be quite a hectic sequence of events, designing telegraphs can sometimes get a little tricky. But if you slow each moment down and watch how you react to the information provided onscreen when you’re either playing a game or designing your own, a well-telegraphed obstacle that is challenging but above all fun to overcome, will always be achievable. Let us know how you might approach your own Redux of this odd little Bear yourself via the GB Studio discord!