Description & How To Play:

This game was made for a final project for a game class at Arizona State University. As the game was geared towards the max amount of players, which is a four player lobby, it is suggested to at least play with at least a few friends. To join a lobby, the lobby must be public. If the lobby is not shown, it is suggested to make the lobby invisible then visible, and this will likely fix the problem. If not then the game will need to most likely be restarted.

The goal of the game is to purify the demon. In order to do this, the players will need to find four seals that are placed around the sanctum and destroy them. Once all four correct seals are destroyed, the demon will be purifiable. Be careful, as there are also fake seals. The only way to distinguish which ones are real, is by small differences in the pentagrams drawn on the seals. Every time a seal is destroyed, the demon will become stronger. So the closer the player(s) are to winning, the hard the game gets.

The demon’s abilities are inspired by weeping angels. When a player is caught, they are turned into stone, and can only be revived through a splash of holy water every player carries within their flasks. However, the players will only receive a limited amount of flasks. These are split between the player(s) at the beginning of the game. The development team did not have enough time to implement the texture, so currently there is no way to tell a player is dead other than calling it out. Once a player is dead, they will be able to spectate their friends if they are alive by click the left and right mouse buttons.

The primary tactic the players can use to avoid being caught is to throw holy water at the demon. This will cause the demon to be teleported to a random location on the map, however, there is a cooldown, meaning this is not a spammable mechanic. This gives a chance for the player(s) to run away, but if it is abused, the player might just find themself in a situation they did not want.

As there is only a limited amount of holy water available, if it is all consumed, the player(s) will automatically lose the game. This is because at least one holy water will be needed to purify the demon at the end of the game. So, the player(s) will need to manage their resource of Holy Water. Is it worth it to stun? Is it worth it to revive? Is it worth playing more risky or safe? The dynamic difficulty also encourages the player(s) use of holy water as the demon is more likely to catch the player.

Another tactic is for the players to be more sneaky. The demon has an easier time finding the player the more noise they give off. The demon will also be able to spot players that are in light easier. Players will also be able to hide behind objects. These tactics give the player a higher chance of avoiding being caught.

Flashlights are the primary light source in the game. The light can be accessed by pressed "1", however, they have a limited battery life, and must be recharged by picking up one of the various batteries lying around the sanctum. There are also torches and candles around the map which have limited up-time that the players can light around the map. They can be litten by pressing the global interaction button "e" while holding the lighter which is pulled out with the button "3". This makes it so that the player(s) have an easier time traversing the map with more than one lighting option, but if the game goes on for too long, the players may very well find themselves only using their lighter for the rest of the game.

There are many seals throughout the map. These seals are placed on altars. Although the altars are on set locations, the real/fake seals are randomly chosen at the beginning of the game, meaning that every play through will be different. Every seal of the game will also need player(s) to perform a ritual on the seal, forcing them to stay near the seal for a period of time. To perform the ritual, the player will need to hold the global interaction button "e" in order to perform a ritual. Each seal is a different object, but every seal will have a pentagram, with fakes having small differences in the pentagrams. If all four seals are not destroyed, the demon will not be purifiable, and when holy water is thrown at it, it will be teleported. If all seals are destroyed, then the demon will die when holy water is successfully thrown at it.

Controls:

WASD - Movement

Shift - Sprint (stamin bar can be seen up top)

CTRL - Crouch

Space - Jump

1 - Turn on/off flashlight

2 - Throw holy water (how much a player has can be seen on the bottom left)

3 - Pulls out the lighter, automatically lit (players will only be able to light candles/torches when this is pulled out)

4 - Pulls out a torch if picked up.

E - Global interaction button. Used to break seals, turn on candles/torches when the lighter is held, and picking up torches. Players will only be able to pick up another torch if the current torch has stopped burning.

M - Will pull up a map of the game's map. However, players will need to distinguish where they are on the map, so it is possible to still get lost.

ESC - Pulls up the option to leave and exit the game.

Installation:

Please extract the zip folder once downloaded, then click on the CPI211-Final, it will have a Unity logo on the file picture. Please do not delete anything within the zip file to make the game work properly.

Post Mortem:

John Satkowski - "Hello, I was the producer and designer of our game. I was responsible for managing our team, managing the game, contacting the professor / teaching assistant, creating the GDD, creating the map with the modular set that Nicole had created, the lighting for the game, creating the player and demon model / animations which I had to end up outsourcing due to time constraints, the post-processing effects of the game, alleviating rendering with things such as occlusion culling to make the game run faster, tuning design parameters of the game's mechanics, creating documents for the group such as the itch.io page, and the cover page used for the game.

I had somewhat of a bad experience with my first game class, so I had decided to take matters into my own hands and try to be a leader for a group this time. I had spent hours trying to pay attention to what people actually go to class, especially considering it was by zoom as this was during the Covid19 situation, meaning remote learning, and people who took care of their stuff such as changing their nicknames and setting a role to themselves in the discord server we had for this class. I took time doing this as I really wanted to find good groupmates and make somewhat of a real game that I'd like and be proud of. With how our university works, the game classes being a certificate program, programming focus at that, it was definitely easiest to find the programmers. I had to settle on just one artist due to this. The reason why I had no other designers was because I felt this was a job I could do myself as producers seemed to be pretty free.

What went right for me was for sure the start of the project. I was going dozens of hours dedicated into making/creating the game during the first month. The GDD alone took over 20 hours in total and was 60 page slides of PowerPoint made by Photoshop. I also spent a lot of time researching things such as the lighting of Unity and post-processing. I'm not a coder, so I tried to help out with non-code-related things. What went wrong for me was multiple things. One was that I haven't taken over a leader position for something of this scale since middle school, not to mention something more business sided. Although I think the planning / role assignment I did was generally good, there could've been definitely some tweaks which would've been a better order to tackle the development. If I was to redo anything over, it'd be to focus on the player and demon model/animations aspect first instead of focusing on it during the end of the project.

I was responsible for making the model / animations for us, but due to other classes and the design/producing side taking too much of my time, it kept getting delayed, and I had to end up opting to buy royalty / credit free high-quality character and demon model as I wanted it to look good. There were many changes to the game compared to what was put in the first GDD. This included many of the mechanics, removing a church which we were originally going to use for the spawn, changing the game from multiplayer focus to single-player focus then back to multiplayer, and some tweaks to things that were already coded out. The job allocation I kept giving to people also frequently changed, due to reasons such as getting delayed due to problems or needing to give more as some members were pretty free and some even worked more than what they were given.

The biggest problem of our game was the amount of bugs causing the game to crash that appeared during the last week of development. We had to spend many extra hours during the final week in order to prep this game to be playable enough. We also had to make some cuts to meet deadlines, such as incorporating the death/revive animation retexturing. To solve the crashing problem we had to edit much of our code, and even remove one of our mechanics of the game, which was swingable doors similar to that in Phasmophobia.

The things I learned most from working on this game were on how to manage a team, design a game better, the Unity lighting system, Post Processing, rendering alleviation, and better time management. The most important thing to me was the managing of a team, as I feel the next project I will take up will be much better due to the things I had learned from this game."

Nicole Furlage - "Hello, I was the sole artist on our team. I worked on UI, such as the main menu, won and lost screens, and in-game cursors. I also created all of the 3d models (other than the player model and demon model/animations) and particle effects used in the game, as well as all player animations in Blender.

I had never done 3d modeling prior to this class so even though the learning curve for figuring out Blender was pretty steep, I was able to create a good number of models and level-building assets for our game in a short amount of time. With the help of an animation library, I found on the Unity asset store, I was also able to create a responsive main menu.

My inexperience with Blender became an issue when it came to creating 3d animations for the player. The player had a lot of different states that required different animations. He walks, crouches, runs, and hold items in either hand. While I was able to create these in time by using references online, I only wish I could have made them smoother and more polished for the final build of the game. We had originally planned to have a different model for each of the four players, but this was changed to one model due to time constraints.

There were also a few issues importing art assets into Unity. For example, when I imported the modular set for level building into the game, it turned out that the models were scaled way bigger than any of the other assets already present in the project. Also, in 3D modeling, it is possible for some faces of a shape to be facing inward, so that Unity cannot render them properly. These issues were easily resolved by planning ahead when it came to scaling things in Blender, as well as saving and loading models into the game frequently to ensure everything looks right.

In general, I learned how to use different programs and the different tools that Unity has at its disposal to impact the look and atmosphere of a game."

Ariel Gutierrez - "Hello, I am one of the programmers of this game. I helped set up the player cameras, programmed a Phasmophobia styled door, spectator cameras, some aspects of the items (flashlight, candles, torches), some of the seal mechanics, some of the map decoration, and some odd jobs in coding to help other people in the project.

For my first-ish time working on a multiplayer game, I can say that a lot of the mechanics I implemented were able to be translated pretty well. A lot of what went wrong went into getting stuff in-game to sync up to the other players while maintaining their code optimized. For this project we used Photon and there was a limited amount of multiplayer syncing functions that we could call.

To alleviate that issue, we spent a lot of time trying to optimize our code so that these multiplayer syncing functions didn't run too much. At the end of the day, we had to cut the doors because the way I coded and optimized them was still too resource-intensive, causing the game to repeatedly crash when playing.

There were some changes that were made in the name of stability such as removing the doors, but the mechanics also went through some changes. The spectator system that I originally coded let users scroll through a series of predetermined cameras set up around the level. That was soon changed to only being able to spectate other players so that the spectator system would work in a multiplayer setting and because there wasn't a lot of time left.

I learned that making multiplayer games are an entirely different beast than making single-player games. In order to optimize code, there had to be strategic variables that would sync up to all the other players so that they could each individually handle a separate a certain operation."

Collin Spence - "Hello, I was responsible for our game's enemy AI. The enemy (demon) traverses the level while the players are looking for the seals, and can only be deterred by holy water. If the players haven't gotten all of the seals, the holy water wouldn't kill the enemy. It would just cause the enemy to teleport away and become immune to holy water temporarily. Once all the seals were found, the holy water could be used to defeat the demon.

We wanted our game to have a single enemy hunting all the players, but since the map is quite large the demon couldn't just wander. It also couldn't continuously pursue the players as it would quickly overwhelming and very difficult to win. To juggle this, the AI uses a state machine with three states: roaming, hunting, and chasing. When roaming the AI would wander the map randomly, waiting until it either hears or sees a player. If it hears a player, it will transition into the hunting state and travel toward where it thinks the player is, returning to roam if it doesn't see the player once it reaches that point. If it sees a player while roaming or hunting it will begin chasing, speeding up, and actively pursuing the player. If it loses sight of the player, it will revert to hunting and then into either roaming or chasing.

I'm very happy with how the state machine came out. With the addition of an encounter trigger, which will move the demon closer to a player if it hasn't hunted or chased for a while, the AI behaves in a way that feels fair but still frightening. The biggest issue with the AI was integrating it into a multiplayer setting. If the AI tries to run on multiple instances at the same time, it essentially breaks. So we had to get the AI to disable itself on all but one instance and then sync the other instances up with the enabled one. Unfortunately, that meant that if the enabled instance the demon would stop moving entirely, so I had to make it detect when players disconnect to make sure that it never turns off.

My biggest takeaway from this project was the importance of optimization. Since the server we're using has a relatively low cap on the number of server calls it could perform, making the AI work with as few calls as possible was very important. If there were too many calls, we consistently got crashes and disconnects."

Long Jia Lin - "Hi, I am one of the programmers on the group. For this project I worked on most of the player mechanics in the game; this includedthe ability to use flashlight, lighter, torch, throwing holy water, the player's ability to interact with the environment, the interacting buttons, and the prefab for the earlier said items. I also spent some time placing the items around the map during the end of the project to help alleviate the workload.

For this project, I was happy to see a lot of communication and participation, which makes this game project a lot more enjoyable. There was a clear leadership and role assignment which really helps the game development process simpler. I found a lot of success creating the player's action and mechanics, though some were hard to implement, I managed to get a lot of core player mechanics in before the assigned deadline, and the more we got into the project, the more familiar I got with Unity, letting me shorten my workload.

The challenges I faced were a lot of multiplayer synchronization and code organization. I got a lot of help from teammates especially for throwing the holy water. A lot of player's code has to be heavily modified in order to fit into a multiplayer situation. It was really challenging and frustrating when I was trying to synchronize the flashlight. Another mistake would be not familiarized with Photon, I believe if I knew more about Photon's utility, it could have saved me a lot of time on player synchronization.

In our game class, we also had to do three separate game jams. It had helped that we had done a multiplayer game for our final game jam, the only jam we had once we had chosen our final groups. We gained some experience on building multiplayer from previous game project with the same team during then, which definitely made the situation easier.

I learned a lot more about the Unity Engine. I definitely discovered a lot more stuff outside of the class content we had like how to create multiplayer, and the fundamental idea behind the multiplayer implementation, which made me appreciate multiplayer games a lot more!"

Scott Ogar - "Hi, I am one of the programmers and I did most of the Photon (multiplayer) setup and maintenance. I also set up the player movement and stamina system on top of also doing the lobby system. When thinking about what went right on my end, it was that we were able to sync up the players and demons, including the animations, and we were able to join and leave the rooms at will.

If it was about what went wrong... there were a lot of issues with syncing up the variables to check how many players were dead. We also had issues with too many functions being called at once, causing people to either crash or freeze which was a huge problem. To fix those problems, we made many boolean checks to make sure that certain functions (PunRPC) were only being called once. We also made more functions to force variables to go through the server so that they would be synced up between all players. Some changes that were made was spectators being able to look around because we could only have one camera in the scene and the camera not rotating well with the player that was being spectated. So that was changed.

The most I had learned from this project was about multiplayer games and how to get multiple people to sync up to each other in the same room."

Purify (My_RAMEN, indigoninja, n1ckf, S4CK, Kuu_1, Scooters) screenshots