Voltron: Defender of the Universe

Year:

Platform:

Genre:

2011

Playstation 4, Xbox

Top Down Shooter / Brawler

Role:

Lead Designer

Game Overview

Yet another top down shooter! This one used the classic Voltron IP with the five robot lions combining to make the titular Voltron, battling the forces of Doom in all their mechanised and giant Robeast forms.

Design Objectives

Having (close to) full control over the game design I set a number of goals which were heavily challenged at the start of the project. Initially the outline was to make an Assault Heroes 3 but with robot lions. I pushed back and wanted to make the game more aggressive. Giant robot lions should behave like, well, lions. For me this meant lots of changes to the original gameplay template. Other seemingly odd features were also included, all of which needed careful diplomacy.

Make the player feel like they were in control of a giant robot lion - an aggressive war machine
Use enemy templates to develop a wide range of foes
Apply the lessons learned from making previous top down shooters but don't be restricted to those mechanics

Successful Features

The game was aggressive - the lions moved like lions, using a series of blended animations and able to leap onto enemy tanks and fliers to rip them apart - removing the grenades from the Assault Heroes style concept. New spaceborne flying levels were included in a homage to Galaga and each environment featured unique and interesting gameplay. It also looked good, with cell shading and visual effects I based on the original cartoons. Each planet had its own unique setting and even weather. Each level extended this further, each one introducing a new type of gameplay for the player to learn and overcome.

Camera

Here I made a number of nonstandard choices - the camera was dynamic and I made it follow a number of different factors;

Player's movement direction
Players aim direction
Enemy hotspots
Arena hotspots

The camera had a much further look ahead and angle adjustment than most were comfortable with - they wanted a more traditional top down view, saying that the player would lose visibility behind. This however was exactly what I wanted; the player had most visibility to the front and so had to push forwards and attack.

Offscreen Attacks

Some enemies had the ability to attack the player even when off camera - a large reticule would appear on the floor to telegraph the incoming attack. The player had a few seconds before the artillery would hit, usually plenty of time to avoid it as long as they didn't sit still. I introduced this mechanic in the very first level. To halt the incoming bombardments the player had to push forwards and hunt down the enemies. Again, the player is rewarded, even obligated, to push forwards, be assertive and aggressive.

Pouncing to Replace Grenades

This feature got a lot of pushback at first. The original direction was to simply include grenades, exactly as they had been implemented in Assault Heroes. This seemed a missed opportunity to me; I wanted the lion to 'throw' its entire body in an aggressive pounce. Able to snatch fliers out of the air or jump on a tank and rip it to pieces. Depending on which lion, area effect damage of varying strengths and sizes was also included.

The initial prototype versions worked great; a simple mechanic that the player enjoyed. After leaping on a tank, the player was prompted to then use melee to smash it to bits - this left the player vulnerable to nearby enemies since they couldn't shoot, but also stopped the tank from fighting back. A perfect risk / reward setup.

Unfortunately, towards the end of the project a bug snuck in and a delay after the pounce landed on a tank meant the player was usually ejected from the tank, making this feature much more difficult for players to understand and take advantage of.

Enemy Spawning

The spawners were based on what became known as a doughnut system. Originally I was thinking along the lines of the Left 4 Dead AI Director, where the zombie horde chose spawn points just outside the player's LoS to corral them into combat zones. This idea was in response to the 4 player coop mode. Initially I wanted a shifting series of zones to follow the players around the level, adjusting as players were close or far from each other.

After a few experiments I found that this wasn't going to cut it and a simpler, static point spawn system was needed. The dynamic system was too dependent on other players being in the game.

This doughnut system was used for spawning hordes of enemies and with a few simple configurations and a bunch of overlapping spawners the level designers could make very complex setups without getting bogged down with fiddly implementations.

Each spawner had the following parameters:

Enabled; the level designer could access the spawner via script
- true / false
Enemy Template to Spawn
Distance; how far from the player to consider the frequency and randoms
- Close
- Mid
Frequency Min / Max; How often to try and spawn an enemy, chosen randomly between the min and max values
- Close
- Mid
- Far
Random; choose a random value from 0-1 and if its below this value for the distance, spawn the enemy
- Close
- Mid
- Far
Spawns
- Max Total; stop spawning forever once this many enemies are created
- Max Active; never have more than this many active enemies from this spawner
Spawn Position; where to create enemies
- Center; only on the center point of the spawner
- Close; random location within this distance
- Mid; random location within this distance

So, how did this work? Essentially, the distance controlled everything about the spawner. The two centric rings were visible when assembling the level and gave the level design team a clear view of how the level would react as the players navigated it. Two concentric rings marked the spawn distances (hence the doughnut naming). The close distance was typically used to disable the spawner if the player got to, well, close. This was to avoid annoying damage from an enemy appearing right next to the player. In some cases it was useful to create in your face ambushes, however. The mid distance doughnut was typically where the level designer would want enemies to begin spawning. Anything beyond mid distance was considered 'far' - usually the level designer wouldn't use this in normal play, but it was useful for arena battles.

Various random factors allowed play to remain fluid and added a slight unpredictability to events; this meant the player could never fully relax.

The advantages of this system were huge. By setting up a handful of spawners the enemy templates would take care of the gameplay on their own, creating an emergent style of play that allowed me to create an endless arena mode - great for testing the enemy templates and fun to play. I ended up testing that mode a lot!

Here is an example layout for an arena battle.

The spawners in this example will deactivate if the player is within their close distance, produce enemies at a moderate rate when within the mid distance and slowly if the player is far.

Soldier
- Cannon fodder
- Can be simply walked over to kill them, although this can cause the player to take unnecessary damage
Rocketeer
- soldier with a homing rocket launcher
- Surprisingly dangerous, especially if they collect into groups
Flier
- An annoyance that can be easily shot down
- Can deal moderate damage if allowed to survive
- Can be pounced on; instant kill
Tank
- Resistant to damage
- Moderate rate of fire
- Cannon attack is dangerous
- Can be pounced on; the player must then thrash away for a brief period to destroy it

As the player responds to the different threats, they move around the arena and the frequency of spawns modifies. After a given maximum is reached (which may not take into account all spawners) all spawners deactivate and the gameplay segment is complete.

Heal by Score

It's debatable if this feature was successful or not; lots of video playthroughs complained about it at first. Essentially, the player recovers health by scoring. The player scores more for killing enemies quickly thanks to a combo multiplier which decays over time.

The idea was twofold; reward the player for their aggression and the health bar is actually a 'risk' bar since the lion is never destroyed - it just suffers a critical malfunction and needs some time to recover.

During this recovery time, the player is ejected from the lion and must survive on foot until the lion reactivates. This feature was entirely stolen from Assault Heroes and proved to be a fun 'last chance' style of play.

One of the side effects of healing by health was the groups of people that could be rescued. Getting close to a group caused them to cheer and then be beamed up, rewarding the player with a hefty score bonus, which meant they also got healed. This made the rescue groups essentially medkits.

Despite the grumblings, I stand by this system since it adheres to the original design pillars. It could have been better highlighted within the tutorial level and UI however.

Mission System

I believe a good objective system is critical for most combat games. It allows you to tweak the ruleset and conditions for winning and produce variation in the gameplay with very little effort - as long as it is well planned. The system for Voltron was not complex, but it did the job. The next objective was always visible - either as an icon on screen or a compass icon offscreen that would show the player which direction they had to proceed in.

Waypoint - player must reach this point
Horde - Lots of enemies must be destroyed, each identified by an 'enemy' icon
Boss - player must defeat this large enemy, if they do then any underlings nearby are destroyed

Secondary objectives involved finding five star points scattered around each level, rescuing survivors and racking up higher scores by eliminating foes quickly.

Conclusion

Lots of the gameplay wasn't understood because of a lack of UX in game hints and because during the tutorial section I allowed the player to pass a section without doing the correct action (rip a tank to pieces) at a request from QA. This was a major mistake, but one I learned from.

Another place where we had limited budget was in the 3D models - I had to salvage lots of enemies from previous prototypes to make sure I had enough. I also did lots of enemy recolours to fill out the roster. Each variation had unique attacks and behaviour, but the meshes were the same.

Another problem was the Voltron battles. They were indecipherable and not fun. I'd focused so much on making the lion modes awesome that I couldn't properly resolve the debates around the Voltron mode and what was eventually implemented was a weak QTE fight which nobody liked.

Levels also became progressively bigger as the game progressed, finishing with huge rambling layouts which could have housed multiple levels. I should have trimmed these down mercilessly!

There was a huge fan following, which I hadn't expected because Voltron didn't air in the UK when I was a kid. If I'd focused more on the UX and managed to design a decent Voltron mode things might have been a lot different. Instead it got an average score from the reviewers. I still like the game however - a lot of what I tried to get across did work, although the execution was uneven.