4/7 - 4/20: Creating the Final Build

We’ve had a lot of progress over the past two weeks. Here are the updates:

Planning and Assigning Tasks (7 Hours)

One of my priorities is planning and assigning the tasks for my pod, which includes 3 artists, 4 programmers, and 2 sound designers . The primary challenge this time was to figure out what things need tweaking and how that could be done without significantly increasing the scope of the game. I had to play the game many times just to get a good sense of all the bugs in the game. This task also involves communicating to my pod members about the bugs that we need to fix, as well as communicating with the level design pod to get a sense of what they need. Below is a look at some of the things my pod accomplished (please note that not as much content was created this sprint, as it was mostly bug fixing and polishing):

One of the pieces of feedback I got while playtesting is that the stalker felt out of place in the Windmill due to it’s primarily green color scheme. As a result, I worked with Alex Kisil and Naveen to change the color scheme to better match the stage (by switching the green to orange). This made the stalker feel much more in place with the overall stage, keeping the cohesion in tact.

Level Design reached out about a glitch where the Stalwart would fall through the floor if it fell through the floor. I assigned Matan to figure out the cause of this task, and he figured out that the issue is caused by a faulty gravity check. The stalwart no longer flies through the floor.

Here is how I broke down handing out tasks:

• All of my artists were focused on iterating on their existing animations. This meant seeing them in game and figuring out how they can look better or more in line with the rest of the game. This was a largely iterative process.

• Programmers were focused on fixing bugs. To help them, I made a list of all of the bugs in the game that I found (https://studio.eecs.umich.edu/confluence/display/BLUE/Enemy+Bugs) to better organize our workflow. In hindsight, I could have created a better system for fixing the bugs. This could have better utilized Jira, but I think this ended up working out relatively well in the end.

• Sound Designers wanted to create Hurt sound effects for the enemies, as they noticed that they were missing from the game. This was not something that I would have considered without their input. 4 new enemy sound effects were created, including ones for the Acrobat, Dropper, Qrabz, and Stalwart. In addition, I asked them to iterate on their sound effects. They mainly created variations of their existing sound effects to avoid ear fatigue.

Fixing Bugs (8 hours)

In addition to assigning tasks, I spent a large chunk of time fixing the bugs on the enemies. As I was the one to set all of the enemy systems up, I figured that I was the best to resolve the bugs that I may have created. Here is a list of some of the bugs I fixed:

• Enemy SFX don't work (The enemy soundbank was being destroyed, as the levels were being loaded/unloaded concurrently. We needed to make two prefabs)

• Stalwart roars in the wrong direction (This involved the complex interlocking of multiple scripts that ended with a very hacky fix)

• Stalker facing wrong direction and not on ground (This involved going into every scene and setting the scale of the stalker to -1)

• Enemies flash pink instead of white (This involved making the FlashOnHit script take in a material instead of a color to flash to)

• Stalker doesn't shoot projectiles sometimes (This was because the stalker’s projectiles were hitting the cinemachine color)

• Stalker shoots in the wrong direction (I made a check to see if the player was behind the stalker)

• The game was crashing (I made a check on the relevant scripts to see if the player was null)

Getting Feedback (2 hours)

I also spent a significant amount of time getting feedback from people about how I did this semester. Being the enemy pod lead was a very rocky journey, and I certainly could have done a lot better. This meant having a conversation with each of my pod members about how I did, what went well, and what didn’t. Among the feedback I got was:

• I need to involve more people in the integration of assets, and not just the creation of them

• I should have the sound designers determine what sound effects go into the game.

• I should utilize documentation more often, and keep it consistently updated.

• I should have my pod members communicate with each other, rather than just me, for figuring out the implementation details

• I should create more tasks for the designers on my pod.

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.

3/2 - 3/23: Scope Reductions Amist COVID-19

We’ve had quite a bit of progress over the past 3 weeks, but also quite a bit of setbacks

Plan and Assign Tasks (18 hours)

My main priority was to assign the tasks for my pod members, which includes 4 artists, 5 programmers, 3 designers, and 4 sound designers (pod members have been shifted around since my last blog post). We now had a much clearer idea of what the enemies in the game would be like, so figuring out tasks was much easier this time around. A large portion of this job was creating documentation about the enemies to keep everyone on the same page (an idea suggested to me by Logan Hughes). I created a confluence page for every enemy that looks like this:

A enemy page for the Acrobat enemy, detailing the sprite, animations, sounds, and scripts used.

In addition, I wanted an easy way to track the progress of each enemy in the game, to make it easier to assign tasks and access the overall scope. To this end, I created a “matrix” of all the enemy statuses in the game, detailing every component of the enemy that needed to be created and it’s status. It looks roughly like this:

Here’s how I broke down giving out tasks:

• I’ve been asking some artists to switch to creating animations for the enemy. This ultimately proved to be a big challenge, because not many of my artists had experience with animation. While amber’s tutorial helped significantly, each artist had a unique problem with their animations. One artist didn’t understand how to use git and unity, while another had issues with the lighting on her sprite. Through this, I helped each artist figure out their strengths and weaknesses, and I ultimately got to know them alot better.

• Programmers would create more behaviors for enemies. Because alot of the core behaviors were done, a few programmers were tasked with design or switching to another pod. There were still some components, such as the movement script for the Stalker, that needed to get done.

• Designers were focused on “fine-tuning” the enemy prefabs in the game. “This involves figuring out the right level of difficulty and the right level layouts for the enemies. You should be making or suggesting changes to make this enemy better.

• Sound Designers were focused on creating the sounds that the enemies will make in the game. For instance, the Stalwart enemy would have a really loud roar, the Stalker would have a grunt sound as it throws the projectile, etc.

Another major part of the job was planning the scope reduction of the game. Because of the outbreak of COVID-19 in Michigan, many of our pod member’s lives were upended. Many had difficulty actually getting their tasks done. As a result, Nico made the call to scale back the number of enemies significantly. At first, I didn’t like this idea, as it meant most of my member’s work would get cut. However, I eventually came to realize that it was necessary. I fought to make sure that it was a fair scope reduction. In particular, I wanted each artist, designer, programmer, and sound designer to be able to point to an enemy and say “I made that”. It was important to me that each of my members, many of whom I’ve gotten to know personally, would know that their contributions were valuable. While it was a hard fight, I was able to convince Nico and the other leads of my beliefs, and we ultimately picked 5 enemies that would be in the game. These are the Acrobat, Dropper, Qrabz, Stalker, and Stalwart.

2/17 - 3/2: Early Implementations

We have had quite a lot of progress over the past two weeks on the enemies that will be in the game. Here is what I did over the past two weeks:

Assign Tasks (14 hours)

As a pod lead, my job is to assign tasks to all my pod members, which includes 3 artists, 4 designers, 6 programmers, and 4 sound designers. As we were in the early concepting phase of the game, finding work for people to do was a challenge. Ultimately, this task, which includes creating Jira tasks, meeting with different leads, updating documentation, and checking in with pod members, took roughly 13 hours of time. Here’s how I broke it down.

• Artists would create and vectorize the various sprites for the enemies in the game. Certain enemies already had concept art, but many didn’t. For those that didn’t have any concept art, I asked the artist to first create a quick sketch of their vision before implementing it in their art program. Certain artists expressed interest in animating their sprites, so I tasked them with animating the sprites they created as well.

• Programmers would create the various behaviors of the specific enemies. Now that the enemies were actually defined, the programmers had a lot of interesting and unique work to do. Much of my work with their tasks was specifying the types of functions needed and explaining to them how their script should interface with other scripts.

• Designers were focused on “fine-tuning” the enemy prefabs in the game. “This involves figuring out the right level of difficulty and the right level layouts for the enemies. You should be making or suggesting changes to make this enemy better.

• Sound Designers were focused on creating the sounds that the enemies will make in the game. For instance, the Stalwart enemy would have a really loud roar, the Stalker would have a grunt sound as it throws the projectile, etc. Faulkner gave me the suggestion of asking them to create one sound and having them suggest other sounds. I thought this would be a good idea, as it allows them to have creative control while giving me the ability to track their progress.

Assembling Prefabs (3 hours)

To aid designers, I helped to set up the various prefabs. This was more time-consuming than I expected, as many of the scripts had strange interfacing issues. Much of this process was spent with the code rather than the Unity editor, as I had to modify scripts to fix glitches and interface errors. For instance, the EnemyGroundMovement script had an issue with collision checking that I had to solve in order to get the Gungnir enemy working. By the end, we had actual enemies in the game, which was really nice to see. Here is a link to the enemies that are in the game.

1/28-2/16: Concepting and Prototyping

Over the past few weeks, I’ve taken up the role of the pod lead for the enemies pod. This means that I help designers, artists, programmers, and audio members coordinate and communicate to create the enemies of the game. Here’s what I’ve done over the past three weeks:

Review Designs

An example of an enemy design, written by Evan Brisita

I tasked our designers with creating several enemy designs for the project. These “designs” are more like behaviors than concept art. I asked each designer to create 1 - 3 “design concepts”, documents on confluence that include the following sections:

• Movement: Describe how the enemy moves. This includes: the movement pattern, the relative speed, any states of movement, and whether the enemy is on the ground or flying.

• Attack: Describe how the enemy attacks the player. This includes: the type of attack (projectile-based vs. contact-based), the telegraphing of the attack (roughly how much time between the start of the animation and when the attack lands), how much damage is dealt, and how the player can/should dodge the attack.

• Reasoning: Describe how the enemy has a positive impact on the player’s overall experience. Enemies exist not to defeat the player but to give them mechanical challenges and encourage them to fully use the mechanics. The designers write a paragraph explaining what the goal of the enemy is and how it benefits the game.

I create the template for the enemy design. Over roughly 6 hours, I sat down with Matt Rader and Gino Bryja, senior designers on this project, to decide on the enemies we want in the game. Our discussion was focused around how the enemies will be used with the level design to create a better player experience. We narrowed the list down to 6 immediate designs and 4-5 designs that will be in the game if there is sufficient time to implement them.

Assign Tasks

A basic flowchart describing how the scripts interface with each other and how the overall enemy AI works. Created in collaboration with Max Perault.

As a pod lead, my job is to assign tasks to all my pod members, which includes 3 artists, 4 designers, 6 programmers, and 4 sound designers. As we were in the early concepting phase of the game, finding work for people to do was a challenge. Ultimately, this task, which includes creating Jira tasks, meeting with different leads, updating documentation, and checking in with pod members, took roughly 13 hours of time. Here’s how I broke it down.

• Artists would create concept art for various enemies in the game based on the description of the Abyssals and the narrative spectrum sheets. I told them to use their imaginations but to keep their work within the loose specifications. My main challenge was that artists spent too much time on one piece of concept art rather than creating a wide range of lower quality art. This was ultimately something that George and I had to clarify to the whole team.

• Designers were focused on creating design concepts for various enemies in the game, as described above. While they all had really good ideas, we ultimately had to reduce the complexity of their ideas, as we want enemies to be predictable, not necessarily intelligent.

• Programmers were focused on creating the basic scripts for the game. As shown above, our enemy system is modularized, meaning that scripts exist independently and different scripts interface with each other to create the overall AI. Since many scripts are independent, I tasked my programmers with creating scripts that I knew would be in the game. This includes: the Aggro scripts (telling enemies when and who to attack), ground and flying movement controllers, projectile movement scripts, and health scripts. My main challenge with this was that there wasn’t enough work for everyone to do, as the actual enemies hadn’t been finalized. I solved this by giving many programmers prototype tasks to do (behaviors that might be in the game) and by asking those interested to make designs.

• Sound designers were asked to make temporary sound effects for enemy deaths, footsteps, and damage. Because enemies hadn’t been finalized, there wasn’t enough interesting work for sound designers to do other than make temporary sound effects. Many sound designers mentioned having very little guidance about what they were supposed to create, which is something I’ll try to be better about in the future.

12/31-1/14: Preproduction Technologies

Over my Christmas break, I’ve been doing pre production research for the studio, figuring out new technologies and determining if they’re applicable to the studio. Here are the results of my research:

Unity Test Runner

One of the major challenges during the development of Dreamwillow was the presence of Regression Bugs. Regression bugs occur during the middle of development and break systems that were previously working. Dealing with these kinds of bugs took up a significant amount of development time that could have been used to implement other features. As a result, I began to look into technology that can eliminate these types of bugs.

Fortunately, Unity offers Unity Test Runner, an interface to create and administer Unit Tests fairly quickly. For instance, say we had an XP system in our game where a UnityEvent is called every time the character levels up. We can create a unit test to check if this event is being triggered. The test passes if the event is triggered and it fails if the event isn’t triggered.

Why does this system help save time? Suppose someone changed the code to accidently prevent the event from being called. As a result, vital game functions, such as scripts that display a “leveled up“ screen, were broken. Simply pressing a few buttons would show that the UnityEvent was broken, thus taking a few minutes instead of an hour to fix.

However, there are a few downsides to using Unity Test Runner:

• Unity Test Runner is complex to set up, due to the assembly files and .dll files involved.

• These tests can only tell you if the code is broken, not if the code is working, so this doesn’t eliminate bug testing.

• Requires a large investment in the short-term, making prototypes and early builds much harder to set up.

For all these downsides, I estimated that we would end up saving a lot of time by reducing regression bugs.

Game Foundations

One of the technologies I was asked to research about for the studio is “Game Foundations”, a Unity preview package. It’s purpose is to implement the systems that can take developers time, including inventory, stats systems, currency managers, and save systems. It allows developers the ability to focus on creating unique aspects of their game, rather than the general systems that many games think. Our producer thought it could be useful, so I looked into it.

As I began working with Game Foundations, I realized that this system poses inherent risk if we choose to use this. There are several things that can’t be done with the Game Foundations, such as Item Descriptions and adding enums (and other data types) to items. If we needed those functionalities from the system, we would have to implement it ourselves using their framework, which can be very difficult. Attempting to work with a system you don’t understand can be significantly more challenging than simply writing that system from scratch. As a result, I made the recommendation to not use Game Foundations.

Save System

The ability to save your game has transformed the way games are developed. Whil