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

Pitfalls

Posted on May 9, 2025May 10, 2025 by et4g23

Another obstacle in the dungeons for the player to avoid, our idea is that they will deal a large amount of damage to the player if they were to fall into them, and then respawn the player in the room after they had fallen.

The PitFall scripts starts with references to a Transform component called playerRespawn, which is where the player will respawn upon falling into the pitfall and a reference to an int damage = 2; , the amount of damage that will be dealt to the player if they fall into the pitfall.

This Pitfall game object also has a BoxCollider2D component which is set to trigger. Which is used in the OnTriggerEnter2D() method to check if what has collided with the pitfall is the player. If it is the player, it will cause the player to take 2 HP of damage and prevent them from moving or attacking.
Then a Fall() coroutine is called which waits for 1 second (For a future fall animation to play), then takes the player to the playerRespawn transform and then re-allows the player to move and attack.

After implementing the Pitfall, we decided to allow thew player to dash over them, documented in this Development Post.

Updating the Pitfall

After the playtest, we had a lot of feedback concerning the pitfall. Players felt it was much too buggy to have the respawn point be a static point on in the room as opposed to it being that last area in the room the player stood on before falling into the pitfall. Furthermore, enemies were still active as the player went through the motions of falling into the pitfall and respawning – allowing them, on occasion, to deal damage to the player without the player being able to do anything.

These were two large issues with the pitfall, however, instead of fixing the issues directly, we felt it was best to redesign the pitfall entirely. This was due to my lack of Unity and C# experience up to this point, despite being the group’s primary programmer and we felt this would save us a lot of time

Ultimately, we decided to change the pitfall into an obstacle that doesn’t do damage but merely as a ‘wall’ type collider that the player can only move through by dashing. This would be a lot easier to implement and would work similarly to other existing 2D roguelike games (such as The Binding of Isaac).

To prevent the player from walking through Pitfalls, I gave them a BoxCollider2D component. However, the player would still need to be able to dash through them. In order to do this, I created a new Layer called “PlayerCanDashOver” and assigned it to the pitfall prefab. Then, in the Dash() method in the player’s PlayerControllerNew script, I used the Physics2D.IgnoreLayerCollision function and inputted the players’ layer and the pitfall’s layer. This would prevent the player’s Collider component and the pitfall’s Collider component from colliding during the player’s dash.

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