Greetings, BANJOS is returning with a final update to our game! The main changes we made were implementing the rest of the UI, adding the endgame state of the game, and fixing sound issues. Let’s overview the entire game!

Story and Gameplay

Since the first two weeks were remote, the FIGJAM board was very helpful for putting down a lot of ideas and images. The main themes that we gravitated toward were: technology, nature, and robots. After a lot of brainstorming, our narrative began with variants reaching “the core” and the creator trying to stop them. The variants would have an isometric view, while the creator has a bird’s eye view. However, this idea was pretty vague, and difficult to figure out interesting game mechanics. Our biggest breakthrough was deciding that the robots could be soldering robots and the map as a big circuit board. It was much easier to figure out character designs, map designs, and also sound designs. Many of our initial gameplay ideas were based on using different electrical components to redirect electricity: resistors, capacitors, diodes, and LEDs. We also wanted to try different tools for soldering, like the wick for desoldering and a hot air gun. In order to streamline the game due to the time constraint, we kept soldering, resistors, switches, capacitors, and LEDs.

We struggled with getting networking and unity working in the early stages. So we didn’t plan out the creator’s gameplay until the later stages. Instead, we focused a lot on the variant’s gameplay and making sure their mechanics were working. If we were to do this again, we would do more paper prototyping to explore different game mechanics. 

Visual Development and Character Design

At first, the visual development was generic dark forests and a concept of the core. After we figured out the circuit board and soldering theme, it was easier to create concept art for the map and characters. The characters were initially going to be 2D animated, but then it was switched to 3D. It took a bit of time to set up the models, but it paid off in the end because the characters matched the environments well and it was easy to iterate upon. If we were to do this again, we would not hesitate to start on the 3D models.

Map Design and Level Design

The most important part of map design and level design is how to relate them to our gameplay and concept. At first, we intend to divide the game into two phases with one as the tutorial and skill-build phase and another as the main phase. But we focus on the main phase because of the limitation of time. We base our game map on the combination of the forest and the circuit board. The circuit board expresses our narrative and concept and the forest offers an environment concept for our gameplay. 

In early map design, we used a layout of the circuit-board-style with the forest and the core. Then we tried to add some simple puzzles. The original puzzles consist of lights, resistors, and switches which composed our game map for the Alpha. After that, we discussed how to make them more interesting according to our asymmetric gameplay. We decided to make LED light as the components to control the view which meant both sides needed it to gain advantages. It was viewed as the most important interactive element on the map and a way to achieve a dynamic balance between both sides. More detailed and specific mechanics and relevant components were added to the level including the container for recharging, the gates for entering the core, and so on. 

After the basic frame formed, we spent some time adjusting the light setting. We developed a color scheme of purple and yellow to fit the sneak vibe and our UI design. During this process, we tried different ways for light settings and finally used point lights, material emission, and post-processing to realize the expected visual effects. 

The most important and difficult parts of the process are not about technical problems (there are but not very very difficult). They should be:

• Relevance to the gameplay: we need to develop our map based on our core gameplay and make all the elements form a system around the core mechanics. In our map: 1) the relationship between the lights and the different view angles mechanics; 2）the relationship between the other components and the soldering mechanics; 3) the relationship between the forest and the sneak mechanics.
• Visual consistency to the art concept, UI, and character design: consistency is critical for the players to view the map and the level as a part of the whole game. In the process, we spent some time adjusting color, material, lighting, and shading to make it look nice. Getting all the artists on the same page is important.

Take-way: if more time is allowed, we may:

• Add some details into the environment for liveness and appeal 
• Trees with different heights on different scales show distance to the core and make the difficulty different during the process of  getting close to the core
• Refine the visual effect after all the functionality implementation and debugging 

Programming

Over the course of the semester, we found many roadblocks in terms of getting certain functions of our game to work. Some features were difficult to implement, while others were quick 5-minute bug fixes. No matter the changes, though, we almost always ended up with some Git merge conflicts. While that might not have been the hardest thing to deal with, it was certainly one of the most frustrating. These conflicts were particularly bad at the beginning of the semester when the programmers were not always completely on the same page but greatly improved as time went on. Communication and better splitting up the work were very important in alleviating how many conflicts we would have to resolve. If we could change one thing from the start, it would definitely be coordinating better what changes we were making and not messing with the other programmer’s work.

At the beginning of this process, we struggled greatly with getting networking to work. We eventually settled on using Photon PUN to easily create rooms and servers, but the fundamentals of networking did not click until midway through. Because of this, we were unable to get started on implementing the main gameplay until past Alpha. We also figured out later on that having a priority list split amongst us was much easier to manage than just updating the discord. This way, we could discuss current updates and make sure all of our changes are kept with the merges. 

On top of that, we realized that either we did not implement Photon properly, or it has difficulty handling a backlog of RPC calls because the game would start to have a really bad delay, making it unplayable. This only occurred the night before the final presentation, and we have yet to discover why this happened because it would fix itself sometimes. I think if we were to redo this game and process, I would look into other methods of multiplayer, mainly Fish-net which was created by someone who also harbors a distaste for Mirror networking. 

Overall, the coding process for us was a big learning curve since both Angela and Jasper did not have extensive coding experience in Unity. However, we have learned so much about everything from organizing code all the way to making sure our scene doesn’t break.

Sound

The process for sound design was pretty simple. It was a team effort to lock down concepts and aesthetics of what the game would be, and from there I would go off and create sounds. Upload them to a google drive for the coders to implement according to my specifications.  Once we locked in an aesthetic and I was able to make some initial concepts, I was able to quickly iterate and improve on all of them. Efficiently update music and SFX according to playtests and feedback. 

It was difficult having to rely on others to do the implementation. Only having two real coders meant that sometimes the sound got pushed down the priority list. Which is understandable. But it was frustrating when sounds had been in the drive for days/weeks had still hadn’t been implemented. If I were to do things differently, I would do the implementation myself and probably use WWise. 

Overall

Everyone on the team had distinct roles and skills, so assigning tasks was straightforward. Due to conflicting schedules and for convenience, we held biweekly meetings over discord to discuss our progress and next steps. This worked out well in order to keep people updated. It would have been ideal to host meetings in person, so we could bounce ideas off of each other.

We communicated important events and reminders through group chat and then moved further discussions and links on a discord server. Hence, tasks were also put on the discord channel. However deep in game development, it was harder to keep track of what was going on. So we moved everyone’s tasks on a google doc and prioritized which ones needed to get completed.

Since both of our programmers are relatively new to Unity and multiplayer, it took a while to get a working prototype. We spent a lot of time implementing assets and making sure the game didn’t break. So we wished there was more time for us to focus on how to make the game more fun and enjoyable.

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.

Starting with what was done this last week, we had edited level 1 as well as fixing a large number of bugs that were present in levels 2 and 3.

With level 1, a more cheerful background music was added to it compared to the nature ambiance and lantern sounds heard in level 2 and the chase music in level 3. We also added a large number of dialogue events to help the characters learn the mechanic, but also to start learning the stories between the father and daughter. In the level, the daughter walks through a path to collect pine cones hoping to feed some squirrels, and the father walks through his path to shoot logs and collect a key. This key opens a gate in the clearing, and leads to the level 1 to 2 cutscene.

The level 1 to 2 cutscene was drawn out and colored, showing scenes of the daughter running ahead of the father, and then another scene of the daughter leaving her father and going through a small hole in a gate, thus separating the father and daughter and moving into level 2. There is also dialogue added in this cutscene, and shows the conflict between the daughter and father occurring. The dialogue includes the father telling the daughter they must leave the forest and go home as it is getting late, but the daughter does not want to go home. She tells her father that she does not have enough freedom, and runs away. This then leads to level 2.

In level 2, there were no large changes made, but multiple small changes. The first change was that invisible walls were added to ensure that the father and daughter do not stray too far out of the path and become unable to finish the level. We also increased the speed of the monster,as earlier the daughter would be able to outrun the monster by a significant amount. We added more dialogue as well to further push the story between the father and daughter. Another small change involved the numpad and gate the father uses. Originally, the father would open up the numpad UI immediately after he approached the gate. Now, there is a particle system (the same as the one used for collectible items) that the father can interact with to then open up the numpad UI. Multiple bugs were fixed, such as the wolf encounter, in which the father could throw the bone before the daughter would hide from the wolf, and therefore would cause the level to not finish. Other small bugs include the father being able to shoot the logs from far away, and removing dialogue that would appear when it shouldn’t.

The level 2 to 3 cutscene had stayed the same, except for dialogue added to the cutscenes. This dialogue has the father and daughter happy to see each other, but also has dialogue where the daughter tells the father there is a monster in the woods and she hears it nearby. This then leads to level 3.

There was one large change made in level 3, in which when the daughter collects all 4 keys and interacts with the fence, the screen will now change to full screen with a background of the daughter facing the gate with the locks. The lock and keys UI then appears, and the game has a focus on the daughter, and the father player is then able to watch and support the daughter as she goes through this final task. Other small edits and bug fixes include adding invisible walls, fixing lighting issues, adding the jitter movement to the monster, as well as adding more dialogue events. The game ends once the father and daughter approach the truck, and the final cutscene plays.

Full Screen Daughter Moment in Level 3

This final cutscene wraps up the story with the father and daughter running away and entering the truck. The monster follows until they reach the edge of the forest, and then the monster turns back. The father and daughter then reconcile, and the story ends. Like all of the other cutscenes, music is also added to this one. 

Some other bugs that were fixed that do not depend on a specific level include fixing a bug regarding controller issues where the players would have to reconnect their controllers after every level. This could cause the players to switch if  they were playing the father or daughter, but has now been fixed. There was also a lot of dialogue issues that needed to be resolved, such as  the font and font size. Another dialogue issue occurred where dialogues would play at the same time and cause a jumble of letters to appear, which has now been fixed. Finally, the menu UI underwent some changes to make it more intuitive and interactive.

As a group, we had learned a number of new techniques and programs. 

Asumi, the producer, learned how to manage hers and everyone else’s time, as well as ensuring that no one was overloaded on work they had to do for the week. She also learned how to do a large number of small tasks that range from programming, animation, and design. She also learned the process and amount of work and cooperation it takes to create a game and is glad she had a wonderful team to bring this game to life. 

Gary, the artist, learned how to use After Effects and cut down on his time spent animating. He also learned to consider the character’s movements when animating. For example, using the puppet pin tool in After Effects allowed some jerkiness into the animation that felt appropriate for the monster. 

Joshua, the sound designer, learned how to use Ableton Live, Audacity and Midi keyboard to compose music and sound effects that fit the game theme, and also how to use FMOD to control music and sound effects in Unity. Joshua also helped in programming, in which he learned the syntax of C# and how to program in a more efficient way in Unity, such as using coroutine, delegate, singleton, and serialized parameters to make the code clean and efficient. He also learned some basic GLSL shader coding, and pure C# coding to implement the same shader effect, as well as learning the new input system for Unity, sprite animation, and UI. Joshua also contributed to 3D modeling, in which he learned how to use Blender and put them in Unity, and created particle systems to generate glows and fire. Regarding teamwork, he learned how to express his ideas in English as a non-English speaker, how to cooperate and understand the importance of team spirit, to trust, help, get help and learn from teammates, and to work as a team in a way more efficient way.

George, the programmer, became better at writing clean code. As Asumi and Joshua also contributed to some portions of coding, he made sure to include a lot of comments so it is easier for them to understand what is occurring. He also learned how to use Unity’s new input system. This new system was confusing if there are 2 or more controllers involved, and therefore had to learn this new system. He also created PlayerInputHandler.cs and CutsceneInputHandler.cs to interact with the PlayerInputManager.cs provided by Unity. Finally, he learned about writing shaders for Unity’s default render pipeline. He had to write a posterize post process shader and a red hue shift post process shader for this game. 

Finally, if we had more time, we would have liked to fix additional UI bugs and also add some better dialogue, as sometimes the lines do not flow best in the game and can come out strange. We would also have liked to edit the monster animation and movement to match the new animation that was created but never implemented. Another edit we would have liked to change is the level 3 camera angle, as we had tried  multiple fixes, but could not figure it out, and therefore had to leave the camera angle the way it was before. We would have also liked to optimize the code more and have the game run smoother, and create more 3D models to use in the game. We also would have liked to edit the pacing of the story, to make it feel more cohesive.

Before we sign off for the last time, we would like to show you our game trailer! We hope you enjoy!

Hellooo BANJOS is back with a few updates. Following the week before the final release, we have been making adjustments and fixing bugs.

Updated Art assets

The textures of the Variant and Creator clones have been updated in order to distinguish them better. In addition, the idle animation was edited to be more noticeable. 

The map has a gate that goes down after the variants light up all LEDs.

Fixing Bugs

Let’s speedrun some bugs that have been fixed

1. We added a boundary so the players don’t fall off the map.
2. We finally figured out how to mirror the walking animation across other players. Now you can see other players do a walking animation, instead of hovering in their position. 
3. We fixed the attack clones to have a larger range and rotate around

Screens

The title and lobby screens have been updated to use the in-game models as the background.

Sound

New sounds have been added for variants reviving other variants, clicking sounds, and the barrier exploding.

Next Steps

Our next steps include implementing the rest of the UI, fixing more bugs, and implementing the final endgame state.

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.

For level 1, we have decided to make a very short tutorial level where both players can learn the mechanics they will be using throughout the game. The goal of this first level is to open a gate that is in a clearing. The father needs to shoot down a pile of logs that are in the way and collect a key. The daughter is able to walk around and collect pinecones, as well as hide in different locations throughout the map. Once the gate is opened, the level ends which leads into level 2. This level 1 is made to have as little new material as possible, as we are nearing the end of the semester. We have no new mechanics, and will only require new music in the background of level 1, as well as an icon for the pine cones the daughter will be collecting. There is currently a composed demo of music for level 1 that will be completed soon. The majority of the work that is needed in level 1 is terrain design and laying out all of the objects. This is currently in the works, and will be completed by the end of next week. If major problems were to arise however, we do have an image of a tutorial, with what each of the buttons on the controller are used for, which can be used if level 1 cannot be completed. 

Level 1 Layout

Other time was spent making small edits and fixes to levels 2 and 3. The first edit we made involved adding textures to the dirt path and the forest ground so they can be distinguished a bit better. Also, grass was added to the forest floor on level two to help distinguish between the path and forest floor further, as the grass is more visible in the dark and can help the players determine where the path is even if their light is not shining on it. After playtesting and getting people’s thoughts on the grass, we will add it to levels 1 and 3. A different visual change we also made is with the logs the father needs to shoot in level 2, but we may also add to level 3 to increase the intensity. We made the logs look more natural and smaller, but still made sure that the father must shoot down the logs to go through the path. The destruction of the logs should also look better when compared to beta. 

Ground Texture and Grass

Another edit we made was the monster animation. We have made a change to it so it looks like it is lunging forward with irregular movement instead of constantly moving. We are still currently in the process of adding it into the game, but will be added by the end of next week. We are attempting to implement it so the speed of the monster changes at different points of the animation, so it is slower as it prepares to lurch forward, and then speeds up as it lunges.

Also in level 2, edits were made involving the number pad on the gate that the father must input the code in. We modified the look of the number pad to appear older instead of very modern. Sound effects were also changed for the lock, such as hovering over a number, modifying the input, having the code inputted wrong, and the code inputted correctly. Along with the number pad edit, an edit was made to the wolf encounter so the music disappears once the wolf disappears, as previously it would play even after the event was over. 

UI Change for Number Pad

In level 3, we have made changes to the camera angle to stop the sprites from appearing like 2D objects, as well as creating a new backdrop image to show while the daughter unlocks the key. This creates two possible ways to have the daughter open the gate. The first method is what we currently have, in which the game is split screen at this point, and the daughter unlocks the locks while the father shoots away at the monster. The second method is to have the entire screen show this new backdrop image, and the screen will no longer be split screen and only show the daughter working through the locks. We will be playtesting both of these methods and determine which method players like more and move forward with that method.

Another edit made in level 3 is changing the chase music that plays in the first part of level 3 where the daughter and father attempt to escape from the monster. The pitch no longer changes as the monster approaches, and the music does not fade if the monster is too far away. Instead, the music plays continuously in the section.

Finally in level 3, we are editing the monster movement mechanic. As of now, the father shooting the monster only froze it, and would make it so the monster would always be chasing them from behind. Instead, we will now have it so when the father shoots the monster, the monster will retreat and then appear from a different direction. This will help create more intensity in the level. 

As we are nearing the end of the project, this next week will be spent working on a multitude of small fixes, instead of a few large ones. This includes fixing small bugs such as inventory icons being too small, and changing the dialogue font size in some portions. We will also finish laying out the rest of level 1, or continue with the tutorial image. We will also be coloring in the cutscenes we have previously created, and add one small one betweens level 1 and 2.

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!

It’s time for Beta In these past two weeks, BANJOS spent a lot of time implementing the gameplay changes, and UI.

Updated Art Assets

We updated the map to include 5 LED locations, fewer capacitors, and darker environment lighting. The resistor soldering points are highlighted for visibility (since the trees sometimes block the view).

In addition, the character models have been updated with a better UV texture map, and 4 more animations: rebound, fallen, revive, and idle.

Variant UI

Based on previous feedback, we focused on creating the UI. When the variant gets close to the resistor and capacitor, there is a hovering text that explains which button to press, and a loading bar animation. We also implemented the HP bar and battery. The soldering sparks have been replaced with asymmetrical star shapes.

Our current battery scaling system (This could possibly change after more playtesting)

• Soldering 2 points = 1 bar
• 5 hits = 1 bar
• Revive a player = 2 bars

The UI allows for another mechanic: charging up the battery at the capacitor. The variants need to manage their battery resources and make trips to the capacitor. 

Creator gameplay

We focused on improving the creator’s gameplay experience. We first implemented dropping clones and LED UI. The clones sent by the creator will attack variants in front of them. When the LED goes down, a button menu pops up telling the creator to fix it. From previous feedback and playtesting, we placed roaming clones that follow a randomized pathway on the map. The variants can blend amongst the crowd while the creator needs to spot them.

Some screens

We started on the UI for the title screen and character selection screen. This has not been fully implemented in the game yet.

Demo video

Next steps

Based on feedback for our Beta build, here are our priority items for the next two weeks.

1. Give the creator more control over their clones, such as the ability to move them and give them tasks (fix the LED)
2. Implement the end game state aka. Run to the core
3. Implement final UI elements, and screens
4. Adjust map, model colors, and VFX
5. Improve roaming clones and attacking clones
6. Export a Mac build

However, first large change, we have a main menu! This main menu contains a composed piece to play in the background, and we have two possible images we will continue with for the final version. Once the button is clicked, it leads to level two, and there are also sounds for when the buttons on the main menu are clicked. 

Two Options for Main Menu Art

Although when one hits play on the main menu it loads to level two, there is also a tutorial UI that was made so the players understand which buttons to press. We are hoping to make a level one eventually, but if there is no time would have to change the idea to being only a two level game, and have the tutorial be an image showing the different mechanics one can do. 

Tutorial Image

In level 2, multiple edits were made. The first large change involves the monster.  We added the walking animation for the monster, as well as changed how the monster moved. We made the monster have a jittery effect when walking, which hopefully ups its creep factor. For Alpha, we had the monster disable itself and completely disappear when the daughter hid, but now we have made it so when the daughter hides, the monster goes away. 

We also created a new cooperation task the father and daughter must do. At the start of the level, the daughter comes across her first collectable, a code. This code will later be used for the father to unlock a gate on his end. This will hopefully create more of a cooperative game feel, instead of two separate games that the two players are playing side by side. 

An inventory was also added to the game, which is used in both levels two and three, but is a larger focus in two. Now, when the daughter and father collect items, they will be able to open an inventory to see what they have collected so far. This will let the daughter to see the code again after collecting it for example. 

Inventory Open on Father’s Side

Other changes that were made include creating and adding 3D models to the game, such as a pile of logs for the father to shoot down, as well as placing other landmarks so the players understand where they are in the map. We have also fixed some dialogue bugs in which the dialogue would repeat itself, and changed the font for the dialogue. Some sounds were also changed, such as the lantern sound, the gunshot, and the wolf encounter music. The tree transparency was tweaked, and now shows the trees to be semi transparent so the daughter knows where the tree is and does not walk into an invisible tree. 

3D Model of Logs

After the father and daughter meet up in level two, it switches to a cutscene consisting of three images. These images will be paired with a dialogue the two players read. This is meant to help push the narrative of the father and daughter, as well as provide more insight into what is happening in the game. Cutscene music was also made to play in the background of the cutscene. 

One of the Cutscene Images

Once the cutscene finishes, it leads into level three, which can be thought to have two parts. Level three is different from level two in that there is no longer a split screen and instead they will work together on one screen. In the first part, the father and daughter must navigate through the forest as the monster appears from all directions. However, there have been some small tweaks since we last saw the monster in level two. Now, the monster freezes whenever it is in the daughter’s light. This is done because the father’s lantern has been broken at the start of this level, and therefore the daughter’s flashlight is all the light the two of them will have. The daughter must shine the light to determine where to go as well as stop the monster from shooting. The father on the other hand must shoot at the monster to make it run away before it attacks the father or daughter. A sound effect has been made for when the monster touches and attacks the player.

As the daughter and father work together to fight off the monster, they go into a clearing in which they find their family truck! However, it is behind a gate. This is the start to the second part of the level. The daughter’s flashlight is now out of battery and does not work, and therefore can only work off of the truck’s light. The truck’s light is different from the daughter’s in which it does not stop the monster from moving, which will make this second part harder than the first part of the level. The monster will still continue to appear at random times, but to leave and get on the truck, the daughter must now collect four different keys that are found in the clearing. These keys are then used to unlock the gate that leads to the truck. There is a matching type game the daughter must do, in which she drags the key to the lock to unlock it. She will have to match the right key to the right lock, and will need to do this four times. There are sounds that also show if the match was correct or not, and the lock and key disappear if it is a match. The key and locks can be figured out to match as they have a matching material and the keys have a base that resembles the shape of the key.

Once the daughter completes unlocking the gate, the game ends. Another cutscene plays of four images, and shows the monster turning back from the father and daughter. The father and daughter are safe, and the game ends.

Image from Cutscene

In the upcoming weeks, we will like to fix the way the inventory looks, some changes to the post processing for the light, along with possibly creating a short level one as a tutorial for the two players. We will also need to make small changes such as adding invisible walls so the players do not roam too far out of where they are supposed to go, along with increasing the speed of the monster as it is a little slow as of now. We will also have the inputting of code for the gate in level two, and the lock and keys in level three to open up after investigating it, since as of now it pops up after getting close to it.

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.