Howdy, parasites! Are you ready for the trailer of the game?
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.