3/24 - 4/6: Preparing for Content Lock

We had quite a bit of progress over the past two weeks. Here is all of our updates:

Planning and Assigning Tasks (10 hours)

My main priority was to assign the tasks for my pod members, which includes 3 artists, 4 programmers, 1 designer, and 2 sound designers (pod members have been shifted around and some non-MDP members were forced to drop out since my last blog post). The primary challenge was concentrating all efforts on the 5 enemies that were still in the game and ensuring that those enemies would be polished. A large part of this task involved communicating with the pod members and the rest of the studio leads about the plan for the enemies.

A ton of cool stuff finally got in the game. The animations were finally integrated, the sound effects could finally be heard, and the enemy behavior became more polished. Below are the things that my pod members created and integrated over the past two weeks":

An editor script that uses a formula to assign each enemy a “difficulty rating”. This number essentially tells a level designer how easy/hard an enemy is to fight against. This allows level designers to better balance their levels, as they have a better understanding of the difficulty. You can read more here.

This s is the Acrobat, an enemy that leaps around the screen diagonally in an attempt to keep the player on it’s toes.

Here is how I broke down handing out tasks:

• All my artists were focused on rigging and creating animations for the various enemies in the game. Some found this task to be relatively easy, while others found this to be relatively hard due to the amount of technical knowledge required to animate. I see this as a place to improve next semester, since our first two weeks can be more focused on getting our members comfortable with Unity. Every animation that’s supposed to be in the game is in.

• Programmers were split between different things. Some programmers were focused on making tools for level design. Others were focused on refining the enemy behaviors. Many of the programmers were asked to make scripts that were used in the animation interface.

• Designers were focused on “fine-tuning” the enemies in the game. This time, they were able to get input from other level designers, as opposed to just the test levels that were previously being used. This led to lots of great decisions being made, as we now had a more concrete understanding of the game. For instance, we changed the Stalker to be a turret to better fit with the challenges that the level design had planned.

• Sound Designers were focused on creating the sounds that would be in the game. Their job was a lot easier this time around, as they were able to see the animations in the game and better understand how to make their sound effects. Another place to improve for next semester is to start creating the animations early, so that the sound designers have an easier time with the enemies.

Bug Fixing and Integration (9 Hours)

Another main focus of the week was integrating everyone’s work into the game, That meant the following:

• As rough iterations of the enemies were coming out, many bugs occurred. For instance, the Qrabz was randomly getting stuck inside the terrain of a real level. I had to go into the specific level and figure out why the collisions were being weird. After around 20 minutes of digging, I realized that the Cinemachine Colliders, which surrounded all real levels but were never inside any test levels, were colliding with the Qrabz and causing really strange behavior. So I had to disable the collisions between enemies and cinemachine colliders. Integration issues like that took up quite a bit of my time.

• I integrated all our the sound effects into Wwise, our audio middleware, and into the game so they can be heard. This involved importing the sounds, hooking them up to events in wwise, building all the sounds, and then calling the audio events in Unity.To do this, I needed to make a bunch of helper scripts in order to trigger the audio events. For instance, the Acrobat makes a sound whenever it collides with anything. So I made a script to trigger the audio event whenever a collision occurs.

• I created the animators for each enemy, Some, such as the Qrabz were really easy, as the Qrabz only has a single animation that loops over and over again. Other enemies, such as the Stalwart, required much more complex animation controllers, as they had as many as three different animations. In those cases, I had to create specialized scripts to act a middleman between the movement/attack scripts and the animation controller. These were very complex to write, and often involved parsing through and making modifications to scripts created by other programmers. In the end, all of the controllers were made.

Below are some images of what I did:

A bug I had to fix where the Qrabz enemy would fly, seemingly randomly, into the terrain and behave abnormally.

A view of the sounds that I integrated into wwise. All of these sounds can now be heard in game.

A view of the Stalwart animation controller. A script was additionally created to trigger all of the transitions based on the stalwart’s movement script.