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 2

Posted on February 28, 2025May 9, 2025 by et4g23

After fixing a few bugs to finish of week 1, there were still issues with the procedural room generation. Most importantly, the fact rooms were able to block off other rooms. However, in order to fix this, I needed to figure out why the bug was occurring in the first place.

Understanding the Issue

Upon further analysis, I realised that every time a room was blocked by another, the room that was instantiated first (1) is always the room that blocks the room that was instantiated after it (2) – therefore the room that was instantiated after (2) is always the room that is being blocked.

This is because, between the two rooms (1 & 2), the room that was instantiated last (2) was unaware of the room that was instantiated first (1) and therefore wouldn’t know that it (2) shouldn’t instantiate a room with a door leading towards that room (1).

Bug Fixing

In order to fix this, I created a new gameobject called a ‘RespawnPoint’ (Blue) that acted very similarly to the ‘SpawnPoint’ (Red) gameobject. But it would act as a way for diagonal rooms to communicate with each other, even if they weren’t horizontally or vertically next to each other. The way that they functioned was:

  • They were located on each wall of the room prefab that didn’t have a doorway
  • They had a ‘closingDirection’ that dictated where the newly instantiated room shouldn’t have a doorway
  • If they collided with another RespawnPoint they would both destroy eachother (And instantiate an ‘Annihilator’ gameobject that would destroy other RespawnPoints)

But the most important part of their functionality was that whenever they would collide with a SpawnPoint gameobject, the SpawnPoint gameobject would be destroyed, but the RespawnPoint object would access its openingDirection int. Combined with its own closingDirection int and the SpawnPoint’s openingDirection int; the RespawnPoint could then choose more specific rooms to instantiate that would have the correct closing direction and opening directions. However, more specific arrays would need to be added into the RoomTemplates script in order for this to work.
The script for the RespawnPoint gameobjects:

This was the addition to the ‘RoomTemplates’ script, these new arrays would allow for more specificity for RespawnPoint gameobjects to spawn rooms with specific closingDirections and openingDirections. The naming convention I created was ‘yes_no_rooms’.

The ‘yes_’ meant that the room required an opening in that direction. For example, a ‘yesTno_Room’ would require a room that had an opening upwards (To the Top of it – hence T)

The ‘no_’ meant that the room required a closing in that direction. So, a ‘yes_noBRoom’ would require a room that had a closing downwards (Towards the Bottom of the room – hence B)

Therefore, the ‘yesTnoBRooms’ array would contain any room that had an opening upwards but a closing downwards, etc.

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