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!

Programming

Remote Server

The remote server build and setting up remote multiplayer is working smoothly now, we no longer have to debug server issues and pretty much any iteration of the game build can get copied up to the remote server and played without issues.

Human Tasks

For alpha we wanted to build out the first major task for the human players to interact with. Building the DNA Synthesis minigame layed a lot of foundational deisgn work in terms of understanding the limitations of what we would be doing with our minigames, what is possible using the UI, and the time constraints required to make one of these.

The game is pretty simple – players must match a DNA base pair sequence to its corresponding match. There are three rounds, starting with strings of length 3 going up to 5 characters. Clicking the correct answer progresses you one stage forward, and failing sets you back to the start.

The process of building out the level progressed as such:

1. Program the base functionality of the game (generating the DNA sequences and fake solutions) (approximately 2 hours)

2. Design the prefab, with its corresponding UI elements and planned interface. (approx. 1 hour)

3. Link up the functionality to the UI, filling out the additional features that come along with linking everything up, such as failing back to the beginning, properly updating the UI, etc. (approx 3 hours)

4. Debugging (approx ?? so far another 2 hours) There are still a couple of bugs with the tasks left to iron out, which should hopefully be one time issues that don’t add development time to future tasks, but future games of roughly this level of complexity will likely take about the same amount of time (subtracting time due to increased familiarity, adding time back anyways just because game dev is hard like that) of about 5-7 hours.

Visuals

Level Assets

We added new 3d assets for the level along with some UV mapping for pretty baked global illumination.

Animations

A whole slew of new models and animations were added for the parasite and human player models.

Player Identification

Each player has an assigned color attached to their playermodel so they can be recognized at a glance – they also have usernames over their heads that match the username they chose on the main menu.

UI

This week we also did some 2D design for UI. Based on the game concept, the sci-fi style is the main direction we went for. Also, it should not be too heavy in order to fit our player characters. Geometry shapes, parallel lines and the use of 45 degree angles are the building blocks for the interface. To combine elements into UI, we play with effects like overlay, floating, repeating and transparency. The font for button and titles are futuristic.

Audio

On the audio side, this week was mainly about implementing all of the core SFX and music. Using fmod, there are slight randomizations for each of the core sounds including footsteps, various parasite impacts, and all the sounds that the parasites make when performing actions. By slightly altering the pitch, volume, or sometimes combinations of sounds, the audio of the environment as a whole will hopefully feel more alive and less predictable. We have also added an approximately 2 minute long looping soundtrack for the background of the level. Musically, it should sound mischievous and fun without being threatening. The timbres used are primarily orchestral to evoke a similar feeling to that of old cartoon animations. Synth elements are mixed in to ground these orchestral sounds into our sci-fi environment.

Programming

Bug Fixes

There were a ton of miscellaneous bugs and issues that have been fixed – the parasite jump motion and physics has been made a lot more reliable, and network issues with duplicate objects have finally been ironed out.

Win Conditions

We added a universal game-end state that is activated when all local and global conditions are fulfilled for the current human player. The UI doesn’t exist yet but now we know the system works and can start iterating on interesting tasks.

Basic Tasks – Richard

Designing the tasks for the human player to accomplish while running around the spaceship is key to making sure the player has goals they want to accomplish while they’re in the hot seat – and doing them should give the other players time to potentially hijack the player.

I spent sometime making up some basic wall panels to test that the conditions work for the human player (pardon the lighting): – After making sure that works, I moved on to more design work – the goal is for these games to be instantiable, so they have to be able to dropped into a level and work out of the box. Furthermore, – they should be simple enough that the only necessary RPC’s should be task failure/completion – if the player gets hijacked, they should be interrupted on the spot and the game/task gracefully close – they should varied enough to not get tedious. The current goal is to have a mix of more mundane tasks that might just involve standing in one spot (something like https://www.youtube.com/watch?v=yRCoQgUNTxk) survivor gameplay but for nowhere near as long), and others might be more involved, such as the minigames in Among Us or the lockpicking from the Elder Scolls games. Implementing a game inside of a game presents an interesting challenge to tackle in terms of managing game states inside of another game, but hopefully as long as we keep the games simple it shouldn’t be difficult to implement. I’m making headway into a simple DNA matching game where the player is presented with a short DNA sequence and is told to pick the right match out of 3 options right now to lay the foundation for more games in the future.

Level Components

The level components have been fully integrated into the prefab system – now all we need to do to make the level look nicer is replace the meshes on these components.

Parasite Jump UI

We have a line renderer component in the works which generates an arc which shows the player their exact trajectory they would follow with a jump in a specific direction and specific power.

Sound

Being able to properly iterate on sound has been difficult so far since the fundamental game loop has still been coming together, so this is something that will expand a lot more once we pass alpha and start much more vigorously play testing.

But in the meantime – here’s some cool background music Ian has put together

Art

We’ve integrated the latest parasite model into the game – its quite fun to see it bounce around after the jump – I’m personally really looking forward to getting a proper jumping/falling animation in for it.

Programming

Possession

This week was spent squashing some bugs that were left over from our earlier sprint to get to a playtestable state. The following describes an overview of bugs we tackled in getting possession working:

– Camera wouldn’t update/player wouldn’t move: our current implementation of the human is akin to that of a GTA5 car that the parasite players hop into – once you get in the car, you kick out anyone inside. However, this requires updating a host of parameters, such as disabling/reenabling certain scripts, making sure the camera is properly disabled so we don’t have multiple cameras per client, and reenabling turning on the proper prefab.

– One time possession bug: a bug that took me an embarrassingly long amount of time to fix. Basically, possession would work a single time and then fail – instead of slotting someone new into the mech human, it would delete the human and dump the parasite on the floor. After some misleading errors lead to thinking that it was a nasty race condition between receiving the possession message and deleting the prefab, I did the usual and placed Debug.Log everywhere, and lo and behold: [Image 2 here] We keep a dictionary with the prefab status of our players, and we never actually set the human back into a parasite when performing possession. The actual fix was a single line (the last one).

Up next is getting tasks working for the individual and global objectives. The current aim is to have one global objective and one individual objective per player lead to a win state – this should allow us to build a framework for adding future tasks and objectives, whilst also allowing us to test our win states.

Parasite Controls

We wanted the parasite to be able to walk on walls and ceilings in order to maximize their ability to hide and surprise the human player. We managed to get a system working fairly well that augments the motion of the parasite (when not physically ragdolled) to be in the tangent space of the mesh it is sitting on, letting us slide along all surfaces at all angles.

Art/Characters

Our next big step is finishing up the character models and players

We have a viewmodel (the first person perspective of the baseball bat arms and animations) and a ragdoll model for the parasite in the works, but they aren’t ready to show yet.

Level Design

We’ve added more props to the levels which by next update should let us replace our basic demo level. We have lights, terminals, and more physics props such as phones and desks.

Game Mechanics

We’ve created a generic interaction and “Win Condition” system which lets us arbitrarily place interactable tasks for the human player to complete, as well as an option to make a task “Global” or “Individual” depending on who needs to complete the task in order to win.

Parasite

The parasite controller got a UI makeover to give players feedback on their jump strength, and the network code for their physics and feedback was fully implemented.

Human

The Human also got networking fully implemented, now fully affecting the parasites physically when they hit them, as well as affecting non-player physics objects when they hit them with the bat.

Possession

Possession also need to be networked, which was done this week. The possession is now a global rpc which is triggered when the human’s face collider intersects with a parasite. This is now all hooked in with our GameManager singleton, so we can customize networked effects and announcements when a possession takes place. We have a full UI announcement system in the works to announce to players when global state changes.

Overall, tech moved forward a lot this week, but it was a lot of first drafts. We are now in a state where we can iterate and test and we have a lot of iterating and testing ahead of us.

Level Design

The basic level got a makeover this week, now featuring plug-and-play maze sections that we can use to build whatever level structure we want.

Props

We built a few basic props to place around the level to give it more interesting physics moments and liven up the otherwise blank initial design.

Characters

More progress on 3d modeling the human player, along with some mixamo work to get the rig and animation workflow started.

Design

This week we refined the details of our gameplay and decided on a solid MVP which will likely evolve over the semester.

Basic Gameplay:

The Human player, assigned at random in the beginning, has traditional First Person controls, and wields a baseball bat that they use to defend themselves from the oncoming parasites.

The Human must prevent the parasites from jumping into their broken helmet, if they fail to do so the parasite will swap roles with the Human and thus has the ability to win the game. Only the human can fulfill the win state (currently just getting to a goal position). After a swap the human has some invulnerability.

The parasite has the ability to walk on any surface and can launch themselves forward as a ragdoll in an attempt to land in the helmet.

In-Engine Work

This week we worked a lot on the basic programming structures and library which will manage game state and hopefully set a good foundation for future work and yet-to-be planned mechanics.

Dynamic Lobby

We have finished the dynamic lobby which lets players set their username and join a lobby before starting the game. This involves managing a dynamic list of joined users that is used with the game manager which assigns initial player roles.

Game Manager

The Game Manager is a core object which manages the active game state and handles things like tracking the current Human player, guaranteeing temporarily invulnerability, and deploys necessary messages to all clients.

Mockup Level

A basic mockup level with simple lighting, several spawns, and a ‘goal zone’ at the opposite end.

Human

We have a basic humanoid model and swing animation we pulled from mixamo, as well as a simple raycast which scans where the player “hit” their bat and an effect to show where the contact point is.

Parasite

We have a basic 3rd person parasite controller which enables and disables a rigidbody when they launch so they can roll around, as well as a custom camera controller so that players can maintain a view of their target regardless of their orientation. After a few seconds of little movement (they’ve physically come to rest), the controller resets back to the normal controller.

Audio

We have several basic audio effects built but yet to be implemented, here are a few samples:

Visuals

Some mockups for the final look and feel of the space facility:

A simple hallway in the facility.

Some mockups for character look and feel:

Challenges and Successes

The individual player controllers feel really good, and the basic gameplay vision is coming together.

Networking has made tough work tougher and integrating everything together for a working prototype took much longer and was less successful than expected. Thankfully its just a matter of spending more engineering time on it and so far nothing has been a roadblock.