If the video can not be played for some reasons, please visit the following link:

https://drive.google.com/file/d/1vkLkpot9gfwAr89js7cmC1ycleFSGkHl/view?usp=sharing

Want to know more about the game? Please have a look at our project video!

If the video can not be played for some reasons, please visit the following link:

https://drive.google.com/file/d/1d-xkqQsHgCWAWiaPPu9GMWpY_ejqkiaC/view?usp=sharing

We are still making some final adjustment to the game. The download link will be updated here soon.

After having an overview of the game, let’s see the new changes spiral made in the last week to polish the final build.

New Changes in Week 13

Programming

In our last week of the semester our team’s programming had one focus and one focus only: polish. We ran full tests many times each meeting to maximize the probability that our last presentation went completely smoothly and could effectively showcase everything we had been working on over the last 14 weeks. 

Audio Implementation

The biggest source of issues was audio this week since we didn’t get to actually implementing our audio assets until the last few weeks, so these elements were the most under cooked and needed the most fleshing out. The networking element made implementing the sounds particularly non-trivial, especially with FMOD. We had dynamic sounds designed for the background music but unfortunately couldn’t get the audio parameters to work. 

UI

Since the last blog post, I worked primarily on implementing the UI for the tutorial into the game, as well as polishing the existing start menu. I tried to be as faithful to the design drafts as possible, since they were very excellently made.

Most of the heavy lifting was just making a tutorial menu script to handle interactions between the different panels, and hooking up the tutorial to the existing NetworkMenu script. Had I more time, I would have thrown in a tweening library and animated the menu to be more vibrant (ie animating the parasites to bounce up and down, having better fade in fade out options for the menus and panels, etc.)

Audio

The final rush from beta to final focused heavily on implementing existing assets as well as fixing and refining our existing work. In our beta there were still many sounds that were not yet hooked up to the unity project, so getting those in there was one of our first priorities.

We went through many cycles of putting in audio, then testing, finding bugs, and starting over again. This was also done alongside all the non-audio programming as well, meaning it was harder to find time to work on specific sound errors. During this process of implementation, we were also creating a few new sound assets for the human tasks which the player completes in order to win the game. There are a total of six tasks scattered throughout the ship, and we decided that each should have its own unique sound effects. This not only adds some audio feedback for the player completing the tasks, but also acts as a hint for any parasite that hears a task being completed nearby. 

The six tasks are: repair fuse box, repair ventilation, submit lab sample, redirect power, start power core, and start escape pod. These tasks are only completed by each player a maximum of one time, therefore the sounds were not randomized in any way and will sound the exact same each time. Not only does this save time on the asset creation side, but it also adds some consistency to the player experience as a parasite can learn what certain tasks sound like and use them to track where the human is. 

Art

UI

The UI in the game was keeping updating in the last week. We finished the start, ending screens, designed for the tutorials. Also, we refined the task list to be a call out list that does not take much screen space.

Lighting

At the final stage, we adjusted the lighting of the level. Spot lights were added to emphasize task related objects, and the lightness increased the visibility for players to navigate in the level.

Summary & Reflection

It is the time to celebrate the result, and also the time to look back and reflect on what we did. Our team members have some words to say.

Thomas

Programmer & 3D Artist

For 3D art, my main task was designing and modeling the level itself. I deliberately designed each component of the level to fit in a 20×20 unit grid and kept each doorway geometrically identical, which allowed us later in development to move the components around and reconnect pieces like legos without any gaps. This definitely helped in the design phase of the main level’s development. The only downside to this strategy was the level looking fairly uniform which made it hard to navigate for new players. I think if I had more time and a second try I would try to make multiple prefab variants out of each repetitive component (especially the hallways) which had more small details like vents and pipes which could differentiate them. The lighting and extra effects like posters helped with this but it could have been much better. 

For programming, the main difficulty was maintaining state across the network. If we had each computer in the game perfectly sync their memory state, this game would be game-jam level in complexity, but having to sync state across the network added a huge amount of difficulty. In particular, having a complex gameobject which could be possessed and unpossessed by multiple players was quite complicated to engineer. The strategy which helped us keep tech debt down was tying state updates into as few RPC calls as possible, even if it was at the cost of performance. For example I had an “UpdateOwnership” function inside the HumanController script which would act as a state reducer: check if the human was meant to be controlled by the local player, and depending on that update the state of the entire entity (toggle camera, audio listener, etc). Any time we added a new feature to the Human we would add its proper behavior to that one function. If we ever ran into trouble with portions of the human code not reacting to possession properly, we could just call that function in a few more places (at one point it was even in update but we removed that) and it would usually resolve the problem, which saved a lot of debugging time. The main source of real issues came from poor documentation or even bugs in unity’s Netcode for GameObjects, which was the networking library we were using. Unfortunately the library is fairly new and esoteric edge cases and I even had to change and debug portions of the library itself to get the behavior we needed. Overall I am still glad I used it since I know how to wrangle it now. I suspect it will be the future of unity networking, and I plan on using it in future multiplayer projects. 

Ian

Audio Artist & QA

For our game I was the designated sound designer, encompassing both sound effects as well as music. For the music I tried to evoke the feeling of cartoons from the 1950s – 60s, by using primarily orchestral sounds with emphasis on woodwind instruments such as oboe, bassoon, and clarinet. The winds were supported by pizzicato low strings to make sure that there were no sustained notes, this kept the music always feeling bouncy. The only held notes were sul ponticello (bowed near the bridge) violin tremolo in order to add an aspect of suspense to the music. This backbone of orchestral sounds was then mixed with some synths (set with high gliss time between notes) to add in the vintage sci-fi feeling as our game takes place in a spaceship with aliens. 

The sound effects were mostly non-stylized as I felt that the music conveyed enough of the cartoony nature that we needed. The few exceptions to this were the possession sound, which ended up being a very cartoon-like popping sound, and the parasite’s voices. These voices were done by recording myself making various grunts and laughs, then pitching them up by about 8-10 semitones, and finally running them through a grain delay effect. This effect was set to chop up the sound into little pieces and make each piece a bit higher than the last, giving the voices an alien-like rising echo effect. These parasite voices were then used when a parasite did a successful possession or whenever they jumped, just to give them a little more personality because I thought they were really cute.

I had a great time working on this project as it really took me out of my comfort zone musically. I normally like to write very dramatic or tragic orchestral music, so being able to write something fun and bouncy was quite the change. I think overall the music worked well, except for the adaptive system which we couldn’t quite get working in the end. The plan was for the music to evolve along with the game state through changing FMOD parameters. However we weren’t able to debug this system in time for the final. Luckily I still got to showcase a bit of the “rush music” in our trailer. On the topic of FMOD, I’m very glad to have gotten the opportunity to learn it over the semester. For a few years now, it has been a goal of mine to use it on a larger project and I think by the end I got the hang of it pretty well. The main thing that I would do differently if I could would be to constantly be implementing audio from the very beginning of the process. Most of our builds didn’t have audio in them until the very end, which made it much more likely to run into bugs later in the process. 

Richard

Programmer

I worked primarily on programming, and toward the latter half of the semester, implementing UI into the game. I worked best during periods where tasks were atomic and could be done within the span of a single work session – having small and manageable tasks kept me focused during meetings and led to my greatest periods of productivity. Examples of these are shown in the mana system/pickups present in the game and the implementation of the start screen UI. Since the tasks were usually small enough to be done in a few hours, I was able to usually get a quicker turn around on those tasks and handled them on time.

Overall, I learned a lot from working on this project this semester. This might repeat my sentiments from the Post Mortem document, but I ran into a lot of difficulties with work that was ultimately cut from the game and failing to put out working code in time for implementation. This reinforced the reality that game development is never a straight shot journey, and that, more than just accepting, being communicative and clear about hardships and roadblocks along the way is key to putting out a project of this scope. This reality exponentially augments in size relative to the complexity of the game, and my experiences working on this project served to not only hone my programming skills, but my time management and communication skills, in order to be a better teammate in the future.

Hongyu

Visual Artist

This is my first game project and the first time I worked as an art designer in an interdisciplinary team. For the first few weeks I was quite confused about the workflow and how I would contribute to our project. I gradually walked into the right track when I started to draw the characters and search for people’s opinion and help. What I did not do well is I realize there are still lots of improvements I can make in the last 2 weeks and I do not have enough time to achieve them in this time. If I have more time I will reach out to my peers more often and start to work on my idea ealier.  Next time I will try to be more brave to explain and practice my idea. My first game design is not perfect but I do learn from it.

Another important lesson is teamwork. I usually work with people from design/architecture background, sometimes I take it for granted that they should have the same understanding as I have for my stuff but it is not, so communication skills are quite important. Not only the language, sometimes I find sketch / storyboard is also a very effective tool to express my ideas. 

Also next time I will spend more time discussing the initial idea, the concept and the mechanisms which I think is the part we have most of the space to make improvement.

During this semester, I questioned myself several times, but thanks to Tom and my teammates, they kept encouraging me to keep it up.

Jiaqi

Producer

It is a wonderful experience to work with my team on a game development project! Every time when I editing the blogs, I am proud of the progress we made. I appreciate my teammates bearing with me in the past 14 weeks.

It is my first game project, and it is interesting to be a producer while I am still learning about game development.

After the alpha, we made changes on people’s roles and responsibilities. As the producer, I was working on workload balance across the team. I thought it is helpful to have team meetings as well as short talks with each teammate. What is special about our team is that some of us are very knowledgeable about the process of design development, while others may even don’t know their skillset can be applied into the game. It is important to get out everyone’s concerns and visions and find chances of communication between group members to make the whole process smoother.

We sometimes met problems with time management and meeting the expectations of weekly goals, but it is better in the last week after we make the tasks more digestible.

With the knowledge of game development I have now, there are a few of things to think about if we start from the beginning again: the task tracking and management tools we use, how to organize team meetings and team communication, and team decision making.

The experience of being in the position of managing a team is definitely meaningful to me. People have different expectations, work styles and knowledge, and it needs thoughtful working process design to help these people be a “team” and be efficient, happy and successful as a whole.

Programming

Network stability

This week was a lot of networking and server stability work. We transitioned from the outdated UNet transport protocol to the newer UTP which helped with getting clearer error messages particularly when connecting to addresses which had no server listening.

Art

UI

This week, we worked on updating the UI for the main menu and overhauling the UI for the game. The design mockups below are the intended designs for the UI. If time permits, I’ll look into adding a tweening library and animating some of the parasite figures to be more playful.

Level: Lighting

This week, we light up the whole level and use color and spot light to emphasize the difference of rooms and highlight task related objects.

This adjustment in lighting adds more effect of shadows and aims to help the players to navigate though the level.

Audio

This week much of the focus was on polishing existing mechanics and working on UI. To that end the main task for audio was to create unique sounds for each of the tasks that the human needs to complete in order to win the game. These, along with additional UI sounds, are all just simple one shots that can be played so creation and implementation is fairly simple.

The more elusive goal of this week is to work on balancing our current audio and debugging any sound issues that may occur. The audio balancing is done using the real-time mastering feature of FMOD, where each sound event can be edited in the FMOD editor while unity is running the build. This allows sounds to be adjusted in real time while playing, making quick fixes to the audio balance very easy.

Programming

Tasks

This week required writing the code for visualizing and implementing the new tasks decided on for the final version of the game. We have two types of tasks: 

Pickup tasks, where players must pick up an object and place it in a certain location. These tasks were harder to implement since the object needed to visually appear in the hand of the human for both the human player and the other players, so some delicate network programming needed to be done to make sure everything worked correctly even across possessions.

Hold tasks, where players must interact with an object for an extended period of time. These were simple enough to implement using our existing interaction system.

Both tasks were implemented with their own components which integrated with our universal interaction and win condition system. 

Visualizations

In order to help players navigate the tasks I used Quick Outline from the asset store which puts a solid outline around the mesh of its gameobject. These outlines toggle depending on the state of the task, for example the place where players must insert the objects for hold tasks glow only when the player is holding the necessary object. 

These helped a lot with player confusion and eliminated any need for a minimap or complex visual navigation system. 

UI

A visual task list was also implemented which shows which win conditions are fulfilled for each player. Tasks start as red and turn green as they are fulfilled. Once all tasks are fulfilled, the win screen appears which provides a button that takes the player back to the main menu. 

Bug Fixes

Heaps of bugs and networking race conditions were also resolved this week. We no longer run into any issues with parasite and player movement and their animations are also networked correctly. A change in the official network animator was required which allowed non-server clients to influence the animation state. 

Audio

Let’s listen to two new music made for the ending of the game!

Programming

This week, we worked on developing a set of abilities for the parasites to use, based on a new mana system. The current planned abilities  The parasites will be limited in their capacity to use their abilities, and the aim is to have environmental pickups spread across the map in order to disincentivize the parasites from simply pursuing the human player throughout the whole game.

Changes to the codebase included increasing the abstraction of the ability system, in order to have more reusable code components that interface with the UI and mana system.  Displayed below is a screenshot of the mana system and current ability parameters visible within the editor – the aim is to make sure that the ability system allows us to rapidly prototype for balance by allowing us to fine tune cool downs, durations, and mana costs without having to significantly much around in the code.

Due to the hectic nature of the last week, progress was slower than anticipated. Looking ahead, the aim is to finish implementing these abilities alongside the camera changes from last week by Tuesday and, moving into the next week, integrate the ability system with the HUD in order to start displaying information to the users in a more visually appealing manner.

Audio

This week focused on finishing the music system used in our game. A triggerable ‘rush state’ music has been finished for when one of the players is nearing completion of all of their tasks. The rush state music stays in effect permanently after one player gets a certain number of tasks done, regardless of whether they currently control the human or not. When the player close to completion is in the human the music adapts to add a ticking clock sound to further heighten the sense of urgency that should be felt by all the players at this point.

Due to the transition into the rush state including an increase in tempo it was a bit difficult to make the beats line up well in FMOD. To solve this we separated the short 2 bar transition into its own audio file that triggers once before starting the rush loop. Our next challenge is creating a satisfying ending that can trigger from anywhere within the rush loop music. This is made especially difficult due to the music modulating through many different tonalities making it difficult to find a smooth harmonic transition that works from any point in the music. One possible solution to this would be to create multiple endings in different keys that can trigger depending on where in the loop the music currently is.

There has also been work done this week on UI sounds such as sounds for our new cool down systems as well as standard menu button press sounds.

Art

Level Design

This week my primary focus was finishing the level design and improving the final visual style for the environment. 

New Rooms

Our level as of last week was very hard to navigate since every single corridor and intersection looked the exact same – I changed that this week by adding in 4 new rooms which should break up the monotony of the level and make it easier to memorize, navigate, and simply make the game more fun.

Our four rooms are:

• The Control Room

• The Lab

The lab will also serve as the new spawn point for all parasites, since they all broke out of the vials in the lab.

• The Power Room

• And finally a blank room that appears twice to bookend the other corners of the map

Props

I also built several props we will sprinkle around the map to give it more detail and easier to differentiate various areas.

Art Style

This week we modify the whole color code and art style, make it more sci-fi and more interesting, especially make characters more prominent. We also come up with a guideline for the art stuff to make sure all the new components will follow the same style.

Animation

We figured out possible animation for the characters, although they may not be added into our final version of game, I believe it could bring more interesting interaction for the players.

Character

We modified the human characters to make it match the style of the parasites, and since we reorganized our storyline, I differential the human character by adding some details on the character.

Programming

Bug Fixes

Written by Thomas

The first half of the week I focused on addressing the bugs and lack of polish that we ran into during alpha affecting the parasite controller and game state. There were several issues where information was not properly being communicated over the network, in particular the task completion (and thus the win state) and animation state for the human player was only replicating to the server. Some of those issues had to do with not fully understanding the networking library and some were just straightforward bugs in my code, but they are all addressed now.

Another annoying bug was a camera issue when the human player would run too close to the wall and could see past the environment mesh, giving them a view of the skybox and the entire level from the outside. This was fixed by simply reducing the near clipping plane for the main human player camera.

The biggest set of bugs came from the parasite controller. We took a step back and reassessed the design of the parasite controller and decided the cost of allowing the player to run across the walls and ceilings was too great for the gameplay it added. I rebuilt the controller so that now the parasite will simply stick to any surface it touches that isn’t the ground plane, and we are planning a “grab” feature which will require the player to pass a skill check (by pressing a key right before they hit the surface) to successfully attach to a surface. Now we no longer run into issues with the parasite passing through the environment collider or flying around when touching a corner or weird angle.

Viewmodel

Written by Thomas

So far the human player has had to deal with looking from inside their own body, which is not a fantastic experience. So I modeled a set of astronaut hands and some basic idle animations to give them something better to look at. 

In addition to the basic idle animation, there is a script attached to the viewmodel which will make it bob and move with mouse and WASD movement, so it isn’t just hard locked to the camera.

Cinemachine Human and Parasite Changes

Written by Richard

Since the majority of the players in a lobby would be parasites, I worked on making sure piloting them would feel as intuitive as possible. Since the human player and the parasites would have different point of views, I decided to use Cinemachine in order to be able to set up different virtual cameras, and have them blend between each other during cutscenes (such as possession).

Getting the parasite camera feeling nice took a lot of fiddling with numbers, including a 20 minute stretch where I was trying to get the camera to not follow the parasite directly (Cinemachine is a little finicky, especially with a target this small).

Final adjustments to the camera rig values, plus some Perlin noise on the middle rig to simulate a moving camera gives us this as the current camera view for the Parasites (some fiddling with camera sensitivity still required):

As for the human, since they are in a FPS POV, their changes aren’t as drastic – for now, I set their culling mask to ignore their own model until we add in the view model for their hands:

Blending between parasite and human cameras during possession and cleaning up the parasite camera movement during their jumps and the like is up next.

Audio

Written by Ian

This week the main focus of audio development has been the expansion of our current music system.

Our previous plan for the “rush state” music was for it to act as a oneshot audio that would correctly end with the end of the level. After further considering the win conditions of the game, we instead decided it would be more appropriate to write the music as a loop. This way it can trigger when a player is nearing completion of their tasks and not rely on a set level timer countdown. We plan to write a separate “ending” oneshot that can be triggered to conclude the rush state music when the game ends.

Art

Written by Jiaqi

Based on the feedback we received from Alpha, we are preparing for coming changes on Art of the game that aims to keep the style of character, level design and UI consistent, which communicates with the players about the theme of the game.

We are looking for inspiration in several topics:

• How to make the environment more distinguishable and interesting
• Interactable objects for Human tasks and Parasite mana/energy system
• Add more rooms for players to explore
• Color code of the game
• UI elements for Human and Parasite in gameplay

We believe a bunch of new changes will happen next week! Come back to our blog and check them out!