Fear & Mischief

Fear and Mischief is about four children at a sleepover, who play a cursed spin the bottle type game. The game is said to summon the greatest fear of whoever it lands, but the children believe the legends to be fake.

The bottle is spun, and a shapeshifting demon is summoned, taking on the shape of a nun. It magically locks down the house and sets out to eat each of the children.

Now you and your friends will take control of the children, and will have to escape through the only way possible, sacrificing your friends.

By using the souls dropped by your friends when they die, you alone will be able to escape the mansion.

There are items scattered around in chests that can be used to sabotage the others.

3rd Person
PvP/PvE
Party Game

Info about Fear & Mischief

Project Duration: 9 weeks

Genre: Party Game

Platform: PS4

Team Size: 20

Engine: Unity

Making of Fear & Mischief

More info about Fear & Mischief

Also Fear & Mischief was part of The Rookies contest

Lead Programmer & PS4 Devkit

For Fear & Mischief I was the lead programmer and responsible for the other programmers and managing the work distribution. This included helping designers manage presentations, Trello, and other work media for the programmers.

Handing out tasks and work that was needed to be done first, also checking in on the others and helping them if needed and the last checking if features and code were up for the standard needed.

Learning the PS4 devkit and how the console handles memory, CPU, and GPU usage help me understand game optimization and I learn a few tricks to improve the fps and frame timings in-game.

Splitscreen

For fear and mischief, we needed to have a split-screen system for the cameras. At first, we wanted to be able to play 1-4 players in the game but this got cut out at the last minute due to other issues.

This forced us to lock it to 4 players but the functionality was done and that is why I am showing it here. This system also moved cameras and scaled them depending on how many players were playing the game.

This was a pretty simple system to make but we had some performance problems with our first render pipeline so to support more than two cameras without having big fps drops we needed to change render pipelines from HDPR to URP.

This improved our performance a lot but we also lost some graphical options and effects supported by the HDPR pipeline.

UI Manager

When making the functionality for the gameplay UI overall was a challenge to make it work with every player, scale, and don’t break.

We had a pretty unclear UI placement and overall functionality so it needed to be modifiable and there were many smaller and bigger improvements with the functionality and readability of the UI elements.

This forced me to create a UI manager that would take in all the actions that require UI to display and check all the players for these actions. This was also the first time I made split-screen UI so this was totally new for me.

Inventory UI

Inventory UI was something that needed to be shown all the time for the players to know what type of item they have and are using right. First, the hard part was to integrate it into the working game and make it very stable.

The game is very chaotic and even at the Beta presentation, the game was still quite unreadable so the UI needed to always be on point to guide and help the player survive.

Because the items and the overall inventory system is a big part of the game and help plan the player plan ahead, how to use the item, on who they might use the item, and so on. That is why the inventory needed to be visible, small and simple but still very functional and free of any sort of bugs so the players are never miss informed.

This was a goal of mine when programming the UI to make it very very stable and with help from the designers, I was able to get the inventory stable, readable, and functional.

Buff UI & Noise UI

The buff UI was pretty easy to implement the buff UI is very static. What I did was that I made the whole UI with separate icons and then disabled all of them.

When a player enters a buff pickup the UI Managers show the respectable buff you have active. Because the game has a very limited selection of buffs and they are permanent there was no need of initiating the UI elements in runtime.

The Noise UI was also very easy to make depending on how much speed the player had the noise UI changed.

World Space Menu

Creating the world space menu was pretty interesting for me this was my first time working with world-space UI for main menu, at first I was using the unity button system and navigation system for joysticks.

We found a problem with using this component when playing the game on the Playstation console the buttons got unselected or the wrong buttons got selected. After this bug was found I needed to scrap Unity’s navigation system and make my own, this was pretty good for us because it gave us more room for modifications.

This includes moving the camera, focusing the camera on specific world areas, disabling menus, activating menus, and button selection.

I also added a spinning bottle that looks on the button that is selected and markers that can be placed in the editor and the camera can focus on those markers or the menu specifically. We choose the markers because they made the menu feel more alive.

Crossfade Loadingscreen

The crossfade was a small addition and a very easy one but I felt like it made the game feel a lot more smooth and it added this feeling that the menu was in the same scene as the game.

This type of loading screen was made using the Async method so it was possible to be in the old scene even when loading the new one.

Page updated

Google Sites

Report abuse