Kameran

Trailer created by Logan Young

Kameran is a first person narrative horror game following Philip as he pays a visit to his old friend and fellow archeologist Egon as his recent calls have been rather strange. Using the strange and old polaroid camera left by his friend, Philip will have to navigate and unravel what happened in Egon's home. But is he alone?

Genre: Narrative First-Person Horror

Engine: Unreal 5.0.3 -> Unreal 5.3.2, Unreal Blueprints, C++

Software Used: Jira, Github Desktop, Git LFS, Inkscape, Wondershare Filmora

Team Size: 9

Duration: Aug. 2023 - May 2024

Platform: PC (Itch.io): link to the game

*Showcased at the GDC2024 Midway Unity Post-Awards Afterparty

Postmortem

Kameran was the largest project I’ve worked on in my college career. My story is a bit different than the other team members, as I was brought in after the initial 5 months of pre-production. But in the span of 9 months, I was elevated to the lead programming position in the team and delegated coding tasks to the other programmers while taking on most of the tasks and optimizing existing systems. I assisted in the management of the group by assisting our project manager in said delegation using Jira. I also was the person who got us a guaranteed spot at Miami University’s ‘Sparkfest’ event, as well as creator of Kameran’s official IMDb page. I became the “continuity hammer” (the near equivalent would be a “Script Supervisor” in film) by making sure that ideas added to the game made sense with the game itself and that scenery between levels remained consistent. An example of this is that the Dark Room door would be opened in the tutorial, and should still be open when the player returns upstairs. I also served as the voice actor for Egon and the TV Broadcast Announcer, as well as the creator of the opening splash video and the credits video!

I learned a lot about programming with Unreal Blueprints, including the use of interfaces, using event dispatchers, and using the CommonUI Plug-in. If I were to restart this project over again, I would’ve implemented the plug-in earlier in the process, as most of the UI was already made by the time we used it. I also learned a lot about optimization, and that nothing is optimized out of the box. I found out that shadows are expensive, textures will automatically render at 4K if you let them, and to limit the amount of complex collision boxes in a level.

I had lots of fun working on this project, but we didn’t go problem free. Miscommunication, misinterpretations, and tech problems plagued the group, and 4 months of work was cut. This included the “Photo Menu” that I cover in this portfolio, and a camera ammunition system. We also ran into the obstacle of needing to upgrade versions on Unreal in order to include more members of our team. However, we managed to tighten the grip on development and become the only team of Miami University students to showcase a game at GDC 2024. And although there’s are still improvements I would make, such as implementing a full options menu, adding full controller accessibility, and adding in the photo inventory system, we call agree that we created something that we are all very proud of.

Notable Roles and Duties

UI Design:

Designed pause menu UI
Designed scrapbook menu UI
Designed audio log/notes UI
Designed all tutorial message UI

UI Programming:

Programmed pause menu
Programmed scrapbook menu
Programmed audio log/notes menus
Programmed in-game tutorial
Programmed UI pop-ups

Lead/Gameplay Programming:

Delegated programming assignments to two other programmers
Programmed the transitions of objects that are photographed
Programmed the photo object glimmer appearing and disappearing if the player is aiming the camera
Optimized code that was implemented prior to my joining, including camera functionality
Programmed the tutorial puzzle and the escape puzzle, collectible inventory, keypad functionality, and player-to-interactable interactions
Implemented gamepad functionality

Gameplay Programming

I then ran into another issue with the transition system- it only worked when the photo object model remained in place when it transitioned. When the “Fallen Shelves“ were implemented this became a problem, especially since I already created a parent class that handled the transitions for each object. My solution to this was for the system to transition between two static meshes - a tainted version and an untainted version. However there needed to be a third static mesh, a “Viewed Mesh,“ that the player saw before aiming down the viewport. So I revised the system to make every photo object have three static meshes and transition between the “Tainted Mesh“ and the “Untainted Mesh,” and that’s what creates the effect shown here!

I decided to experiment with something, and that was making objects just… appear. I fiddled with a timer that, when the time progressed, changed the material of an object to a material instance of the object that had 0.1 increased opacity compared to the previous one. With the addition of the “Viewport Aim“ mechanic, I also introduced the idea of making the “Tainted Version“ of the object visible when aiming down the viewport. This created a visual that was similar to the final product, and the team loved it! One problem though- the way how the transition system functioned was that each material had 10 individual instances, and the team started creating objects that had more than one material assigned to it. To make the system more flexible, I discovered Dynamic Material Instances that allowed me to control the opacity of each material instance without creating 10 separate material instances. It also allowed me to control the how long it took for the object to transition!

This wasn’t the only experiment I did that made it into the final product. From our playtests, most players wanted more ways to “see“ the monster. The core mechanic of the game however, was to navigate around an invisible monster. So I introduced the idea of a “glare“ coming from the monster when the player aims down the viewport. The feature wasn’t high on the priority list, but since I had extra time I decided to play around with the idea. I created a Niagara particle that mimicked a red glare, and created a system that made the glare appear for a random amount of time (within a range), and the time between it appearances was also random (also within a range). The team liked it and playtesters really enjoyed it!

Code for some of my Gameplay Programming can be found below!

Gameplay Code Snippets

Blueprint of How The Different Versions of the Photo Objects Appear and Disappear Together

Blueprint for How Photo Object Glitter Appears When Aiming

Blueprint of How the Camera Detects Photo Objects

Blueprint of How The Monster Glare Appears

UI Programming

Originally, when the player took pictures of the photo objects in the tutorial segment, the player character would immediately know the code. Players were confused by this, as there was no mention of what the order could be. To solve this, we made the tutorial into a puzzle and gave the player the opportunity to put in the code themselves. The major hurdle I ran into when implementing this however was how to inform the player if what they entered was correct or incorrect. I knew that I wanted to use colors, but I found out that my standard techniques of using Delays and Timers wouldn’t work when the game is paused. Digging into how the Engine functions, I found out that UI animations do however work under these conditions. So I made the use of UI animations for the first time by making two animations, one for a correct entry and another for an incorrect entry. The final animations are shown here with the red and green flashes!

The programming behind the Scrapbook tutorial was a fun challenge. I wanted to use a singular canvas for all of the tutorial messages for efficiency. So each version of the tutorial panel had to be tested in the UI Designer, then set using methods and variables. I did, however, use individual blur objects for each of the corresponding tutorial panels and changed their visibility based on which panel is currently being viewed. This was determined by a method that set the visibility of each of the tutorial pages, where each page had their own set method for organizational purposes. In hindsight I should’ve used the integrated Switcher panel, but you live and you learn.

Programming the Photo-View Menu is something that I’m proud of, and unfortunately it was cut. I wanted to make sure that, if a photo was changed later in development, it would be a quick and easy fix. To do this, I made the photo texture in the Photo-Viewer Menu to be set to the texture of the button representing that photo. That way the only things that would need to be changed would be the text variable for that photo’s description and the texture for the button; which allowed for some speedy changes multiple times during development.

Code for some of my UI Programming can be found below!

UI Code Snippets

Blueprint for Going Through the Tutorial Menu

Blueprint for How The First Tutorial Message Appears

Blueprint for How the UI Pop-ups are Closed

Blueprint for When The Keypad Entry in Incorrect

UI Design

The pause menu was designed with efficiency in mind, by merging both the pause menu and the inventory menus into one. The design was also built around the functionality and aesthetics of a scrapbook, which is one of the notable possessions picked up in the game. The aim was to create an immersive pause menu that differentiates itself from pause menus in other horror games.

The design had to shift during the last 4 months of development;

The “Photos“ tab originally stored the important photos that the player took, but it was unfortunately cut with the change of the camera’s functionality.

The “Notes“ tab stores all of the notes that the player collected thus far, and it’s purpose remained the same. However, it had a design change. The original “Notes“ menu looked similar to that of the “Photos Menu Mock-up,“ where the notes were separated into image blocks for the player to select, which brought up a “Note View Panel.“ At the time I found it to be inefficient, as it was difficult to add more notes with the system we had it place, and that there was a lot of empty space with the little amount of notes we had. So, I opted for a design where buttons with the titles of the notes appeared on the left side of the scrapbook, and when a button was clicked, the corresponding note would appear on the right side.

The “Entries“ tab became the “Logs“ tab. Originally, the “Entries“ tab was meant to store plot summaries. But with the need of more story-telling, the team elected to replace the player entries with audio logs from Egon, thus changing the purpose of the tab. To remain consistent, I made the design of now called “Logs“ tab the same as the “Notes“ tab, but the words of the audio log would be written on the scrapbook paper. This was to show that the “Logs“ are written transcriptions by Philip (Player character), rather than just a note that they found in the world.