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

Skill Tree – Pt 3

Posted on May 11, 2025May 11, 2025 by et4g23

Now that the Skill Tree was functional and the player is able to spend skill points upon pressing a Skill Button. I need to make the Skill Buttons actually effect the player when skills are unlocked.

In order for the SkillSO to alter the player character whenever a SkillSlot is levelled up, I created another C# script called SkillManager. This script has a reference to a SkillSO, which subscribes to the SKillSO’s OnAbilityPointSpent event, and calls the HandleAbilityPointSpent(Skillslot slot) method which inputs the SkillSlot of the SkillButton that triggered the OnAbilityPointSpent event. Then using the skillName string of the SkillSlot’s SkillSO as an input for a switch case. Then this switch case executes code depending on the case.
For example, a SkillSO with the skillName “Max Health Boost”, calls the UpdateMaxHealth() method in the PlayerStatsManager script of the PlayerStatsManager gameobject.

PlayerStatsManager gameObject

In order for the Skill Upgrades to carry over from different scenes, I created a PlayerStatsManager singleton (a singleton is a design pattern that ensures a class has only one instance, and provides a global point of access to that instance) by creating a public static PlayerStatsManager Instance. As there is only ever one instance of the PlayerStatsManager I can call the DontDestroyOnLoad() method in the Awake() method. If there is ever another PlayerStatsManager in the scene, it will check if there is another Instance of it, if there is it will destroy the newer instance of the PlayerStatsManager.

In this PlayerStatsManager script, any possible changes that could be made via the Skill Tree, such as Player Max Health, Player Terra Shard Count, Player Damage dealt etc. Therefore, any constantly changing variables, such as the playerTerraShardCount should constantly be updated as the player picks up Terra Shards. This must also be done with the player’s health every time the playerHealth script’s TakeDamage() method is called or whenever the player gains health from the Health Potion item.

Lastly, the PlayerStatsManager has a method that is called when the Max Health Upgrade skill is purchased from the skill tree, being the UpdateMaxHealth(int amount) method. Which increases the player’s maxHealth by an amount and then sets the player’s currentHealth to that new maxHealth int.

Changing the cost of skills

In the tutorial I followed, the player is only able to spend one skill point (in Lament’s case, a Terra Shard) every time they upgrade a skill, and every time they increase the skills’ level, the code for the skill is executed. Therefore, a skill that increases the player’s max health by 1 HP would be called 5 times if the skill were to cost 5 Terra Shards.

The intended way for a skill to work in Lament (According to the GDD), is that the skill would cost a certain amount of Terra Shards as a one-time purchase. If the player didn’t have enough Terra Shards as the cost of the skill, they would be unable to unlock it. If they did, the amount of Terra Shards the skill costs would be deducted from the player, and the code for that skill would be executed once.

To begin fixing this, I created a public int in the SkillSO script called totalCost. This int would be accessible to the SkillSlot and SkillTreeManager script and would be used to deduct from the player’s total Terra Shard count

Then, in the SkillSlot script, when the TryUpgradeSkill() method is called, the level of the skill is increased to its SkillSO’s totalCost int. Essentially buying it outright in one purchase.

Lastly, in the SkillTreeManager script, I altered the CheckAvailablePoints() method to check if the player had the required amount of Terra Shards to unlock the skill before the SkillSlot script called the TryUpgradeSkill() method.

I also changed the HandleAbilityPointsSpent() method to reduce the player’s Terra Shard count by the SkillSO’s totalCost int of the skill that they were purchasing.

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