Skip to content

E-Jay Tripoli

A documentation of my work for Year 2 – Studying Games Design and Art at the University of Southampton

Menu
  • Lament
    • Development
      • Procedural Room Generation
        • PRG – Pt 1
        • PRG – Pt 2
        • PRG – Pt 3
        • PRG – Pt 4
        • PRG – Pt 5
      • Dungeon
        • Stalagmites
        • Pitfalls
        • Health Potion
        • Dungeon Bug Fixing
      • Player
        • Player – Pt 1
        • Player – Pt 2
        • Player – Pt 3
        • Player – Pt 4
        • Player – Pt 5
      • UI/HUD
        • Start Menu – Pt 1
        • General UI
        • Skill Tree – Pt 1
        • Skill Tree – Pt 2
        • Skill Tree – Pt 3
        • Skill Tree – Pt 4
        • Skill Tree – Pt 5
        • Skill Tree – Pt 6
      • Enemies
        • Whispers – Pt 1
        • Whispers – Pt 2
        • Wrought – Pt 1
        • Wrought – Pt 2
        • Boss
      • Scenes
        • Tutorial
        • Hub
        • Depression Gate
        • Gateway Scenes
    • Logs
      • Initial Plan
      • Teamwork
        • GitHub
        • Discord
      • Weekly Logs
        • User Analysis
        • Accessibility
        • Testing
        • Marketing
        • Formative Feedback
      • Playtests
        • Playtest 1
        • Playtest 2
        • Playtest 3
      • Showcase Event
      • Post-Project Reflection
    • Research
      • Understanding Learning Outcomes
      • Understanding my role
      • Researching Tools
      • Researching Pipelines
      • GDD Breakdown
      • Researching Procedural Generation
      • Existing Games
  • Arcadia GDD
    • Weekly Logs
      • Week 1 – What is a GDD?
      • Week 2 – Game Worlds
      • Week 3 – Concept Art
      • Week 4 – Character Design
      • Week 5 – Narratives
      • Week 6 – Gameplay and Game Systems
      • Week 7 – Feedback week
      • Week 8 – Audio
    • Research
      • Analysing Existing Games
      • Genre Research
      • Research into Psychological Abuse
      • Character Research/Moodboards
      • Environment/Map Research
      • Researching Medieval Knights
      • Researching Enemies
      • UI Research
    • Ideation & Development
      • Initial Development
        • The Essential Experience
        • Initial Game Ideas
        • Choosing a Game Genre
        • Choosing the Game’s Title
      • Game Play
        • Gameplay Loops
        • Mechanics/Tech
      • Story/Narrative
        • Twine
        • Summary of Narrative and Story
      • Game Art
    • GDD
      • Game Overview
      • Game’s Vision
        • Game Pillars
        • Project Focuses
      • Gameplay
        • Mechanics
        • Skills
        • Enemy Behaviour
      • Story & Narrative
        • Twine Prototype
        • Story
        • Narrative
      • Character & NPC Profiles
      • Map/ Level Design
      • UI & HUD
        • Creating the logo
      • Prototype/ Proof of Concept
      • Sound
      • Target Audience
      • Controls & Platform Specs
Menu

PRG – Pt 4

Posted on March 1, 2025May 9, 2025 by et4g23

Now that the Procedural Room Generation was in a working state, I had to consider how the player would be able to move through and interact with it.

Camera System

When the player moves throughout the dungeons, they need to be able to see the rooms that they are in, in its entirety. Therefore, every time the player enters a room, the camera must lock on to the entire room for two key reasons:
– The player isn’t blind-sided by any attacks that are out of their vision
– Unnecessary space isn’t being taken up in the players’ view

Go to 6:23 to see an example of the room transition

To do this, I needed a way for the game to recognise whenever the player entered a room. So I created an invisible gameobject with a Box Collider 2D; called it a ‘RoomManager’ and added it to every room prefab, to check if the player had entered that room. Then, once the player had entered that room, I needed to find a way for the camera to centre on that room, for whenever the player was colliding with the ‘RoomManager’ game object.

The default camera system in Unity isn’t great, so I downloaded a built-in camera system form the Unity Package Manager called ‘Cinemachine’. Cinemachine allowed me to intuitively create a system for the camera movement between rooms within the dungeon. I then created a Virtual 2D Camera using Cinemachine and implemented one in each room prefab (Ensuring the camera encapsulated the entire room and only the entire room).

Then, on the ‘RoomManager’ gameobject, I added a ‘RoomCameraSwitch’ script that would essentially swap which VirtualCamera was being used depending on what room the player was in. This was done using the ‘Priority’ integer in the ‘CinemachineVirtualCamera’ component, how the ‘Priority’ int would work is that whatever Virtual Camera had the highest priority int value would be the camera that the game would follow. I had set a Virtual Camera to follow the player and gave it a ‘Priority’ value of 9, and made all of the room prefabs’ Virtual Cameras have a priority of 5. However, whenever the player would enter a room, the ‘Priority’ value of the Virtual Camera of that room would be increased to 10, causing the game to use that room’s camera instead of the player follow camera. Lastly, whenever the player would leave the room (stop colliding with that room’s ‘RoomManager’ gameobject) that room’s Virtual Camera’s Priority value would fall back down to its default value of 5.
The following is the ‘RoomCameraSwitch’ script that is on the ‘RoomManager’ gameobject:

Collisions

In order for the walls to prevent the player from leaving the room before the room was completed, I had to add a Box Collider 2D component to them.

Most importantly, I made sure the ‘Is Trigger’ box was NOT ticked. This would have turned the component into a trigger instead of a collider, allowing the player to completely phase through walls.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

©2025 E-Jay Tripoli | Built using WordPress and Responsive Blogily theme by Superb