Overview
Project: Mothership Mayhem
Estimated Development Time: 30hrs
Lines Of Code: 1,250 (Including comments and spacing)
Description: The purpose of the formation manager is to create and keep track of a group of units, giving the illusion that these enemies have transformed into a single massive unit.
Objectives:
1. Load pre-created formations.
2. Gather specific enemies for the different spots within the formation.
3. Alter each enemy's stats depending on the formation.
4. Determine leader units and setup the disband condition.
5. Animate the formation as a single unit.
6. Carry out the formation's behaviors.
Thought Process and Choices
Why I chose to use a Formation Manager:
Since a Formation Manager isn't exactly a standard system that game developers use within in the industry, I'll tailor my answer more towards why formations were needed in Mothership Mayhem. In all truth, the answer to this question is fairly simple: it breaks up gameplay. If you got a chance to read over the Mothership Mayhem page under 'Projects,' you'll notice that one of the big aspects of the game is a strong replay value. Part of this forged through the randomized aspects you find in the second half of the game(Level 2+), but we found through feedback that people were never surprised with only the randomized layout. We needed something big and unexpected to occasionally emerge, requiring completely different strategies to overcome.
One solution would be to add new enemy types, but outside of enemies being very art dependent and slow to implement/balance it still would only be more of the same. The next solution was to create bosses or even a set of mini bosses; once again, very art dependent. And not to go off into to much of a side topic, the worst aspect of final project at Full Sail is the process of getting final assets. You have to go through a middle man, emailing their course instructor, making the iteration process very very slow.
So this means we needed to use the assets we already had access to and yet diversify gameplay. Making a big spider out of all out smaller robots had been something we joked about when discussing the issue, but when I got to thinking about it I realized it was actually possible. At that point we all agreed that formations was the way to go.
Risks:
1. The concept of formations in Mothership Mayhem didn't even arrive until late in development. Additionally, having no resources to reference made it was fairly difficult to predict potential problems. This meant if formations didn't make it into the game I could potentially lose 2 sprints(each sprint is 1 week) worth of work on other aspects of gameplay.
2. Not only did I need a manager to handle all the formations during gameplay, I also need a way to create these formation, which meant an editor. Editors aren't difficult but are time consuming.
Results:
I managed to complete the Formation Manager on schedule, but some aspects of the code were rushed and hurt me to look at, yet I had no choice but to get it into the game. The editor was also it bit on the tedious side to use. To my surprise, though, my producer and the final project staff were so impressed that the gave me a Course Director Award. A Course Director Award is basically an academic achievement for going above and beyond, and is rarely given during final project. You can imagine how overjoyed I was to see my sleepless nights noticed and appreciated.
Design and Development
I'll start off by explaining what a formation is and what an encounter with one of these behemoths consists of, then I'll give more detail into how the manager works.
Formation Encounters:
A formation encounter is when group of bots group up to create a larger enemy. Each formation has their own behaviors and require different strategies. The enemies within these formations can be killed individually, but typically have their health increased 7-10 times their normal values. The tradeoff is that their is always one or more leaders, marked out by being turned red. You can think of these leaders as weak-points; If you kill all the leaders the formation disbands, returning to normal gameplay. There are 3 phases to these encounters: construction, combat, and disband.
The construction phase actually has the most going on, at least for the manager. The manager must gather the correct enemies for the correct positions, change the stats and look of each of the enemies, determine which enemies are the leaders, and possibly demonstrate what the formation is capable of to the player. The combat phase carries out the behaviors of the formations. This can be anything from slamming a hammer down at the player or shooting arrows made of Light Bots The disband phase is exactly what it sounds like, releasing control of the remaining enemies and reverting their stats back down to normal values.
How It Works:
There are really only two parts to the formation manager: the animation system and the behavior handler.
The animation system is simple. There is no blending or more advanced techniques being used. What would be considered joints or bones in a normal animation system are formation slots. These slots contain data such as what type of enemy should be used, if it can be a leader, and stat changes should occur to the enemy. The animations also have tags that are attached to certain keyframes. These tags are used for activating both visual and sound effects.
The formation is basically an entity in and of itself. All movement and changes in orientation is done from an unseen commander. This commander also acts as the relative center for all of the slots in the formation, so when the animation is done interpolating the final position is offset by the commander's. Enemies within the formation relinquish all their control to the manager, making it easy for the formation manager to simply move each of its members when these final positions have been calculated.
The behaviors work the same way using the commander. All targeting, animation changes, attacks and other behavior are first performed by the commander then iterated onto the members of the formation.
Postmortem
What I Would Have Done Differently:
Unfortunately, due to the time constraint the Formation Manager wasn't as data driven as the other systems I had developed to this point. Behaviors in particular were hard coded. If I had to do it again, I would have started off by creating a scripted system.