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

Wrought – Pt 2

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

A large issue I had noticed with the Wrought enemies, was that in order to aim towards the player, the entire gameobject would rotate in the direction of the player. Therefore, its sprite would also rotate towards the player; which needed to be fixed immediately.

The process I chose to fix this issue, was to use a child object which would rotate independently of the parent object that would have the Sprite Renderer and Animator components. This child object would act as the sprite renderer and would rotate in the opposite direction of the parent object, effectively counteracting the rotation and causing the Wrought’s sprite to appear as if it weren’t rotating at all.

Furthermore there would also be a second child object that would act as a hitbox:
To allow the child object to deal damage to the player, I wrote a simple script that would check if any collisions were from the player.

If the player was the other object in the collision, it would call the TakeDamage() method in the player’s PlayerHealth script and cause the player to take one HP of damage.

Bug fixing

When creating a separate child object for the sprite renderer, it cause a lot of unintended issues with the physics of the game. As the parent object would act as the hitbox, its has a RigidBody2D component to allow it to collide with walls and stalagmite obstacles in the dungeons. However, the child object containing the sprite renderer didn’t have one. This would cause the parent object and the child object to misalign whenever a collision would take place.

To fix this, I gave the child object a RigidBody2D component and altered its mass for collisions.

The invisible Wroughts issue, however, was a much easier fix. Simply going into the Wrought prefab’s sprite renderer component and changing its Order in Layer to be higher than the Dungeon’s floors made it visibly in the Dungeon.


This bug was caused by values that weren’t being set, specifically the Velocity X and Velocity Y values, as these values were being used by the animator in Unity to decide what walking and attacking animation to play for the Wrought.

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