Documentation and User Guide

Eternal Echoes: Heroes of the Depths » Devlog
2025-06-01 by sammosenh
Share this post:

Documentation and User Guide

Difference in Final Game to Game Concept

Eternal Echoes: Heroes of the Depths delivers on many of the core ideas I’d envisions from the start, particularly in its strategic, turn-based combat and distinct class-based design for heroes inspired by the classic MMO holy trinity. Players control a party of four heroes; the guardian as the tank, the cleric as the healer, the mage as the debuffer, and the rogue as the damage dealer; and face off against waves of enemies drawn from a pool for each encounter. Heroes can perform basic attacks or use unique class-specific abilities, with a limited number of abilities available each turn cycle, players are encouraged to carefully weight their options and plan ahead. All this comes together in a card-based format that aims to capture some of the feel of tabletop games like Magic: The Gathering or Dungeons and Dragons.

While many of the core ideas came to fruition, some more ambitious systems planned early in development had to be cut or significantly reduced, largely due to time requirement and the complexity of core game systems. The most significant feature cut was the character progression system, through item drops, leveling, ability customistion and stat scaling to further augment the players style. Without character progression, features such as enemy scaling couldn’t be implemented, meaning the game couldn’t achieve it’s intended score-based roguelike structure loop.

Despite these omissions, I leant a lot throughout development. With the core combat and structure in place, this version servers as a strong base for implementing the systems that were left out and creating the game I originally envisioned.

Differing Features:

  • Abilities and Visuals
    • Multiple abilities for each hero
      • I realised as soon as I began implementing the first ability, which was the rogue ability, along with the whole ability management system, how complex this task actually was and how large the scope of my original vision actually was.
    • Visual effect feedback for status effects
      • This was low on my priority list and came more under polish and was therefor skipped over in favour of focusing on core system implementations, however, considering the systems I missed, this would have helped with the polish and feel of what I was able to complete in the six weeks.
  • Progression Systems
    • Character leveling system
      • I felt that setting up the ability system, which was must larger in complexity and scope that I had assumed, was a more important feature to implement, allowing the heroes to each feel unique and add to some fundamental strategy and decision making, and this was skipped over in favour of finalising the ability system. Im happy I chose to do this, as the ability system without character leveling, and therefor enemy scaling, allows for more strategy than implementing character leveling but each with character only being able to basic attack and fundamentally being the same.
    • Item drops after battles
      • This was one of the main features near the bottom of the priority list, as its inclusion would of aided character progression, but its omission did not prevent it, so was skipped over in favour of more important systems.
    • Customisation/augmentation of hero abilities
      • The complexity of implementing the default hero abilities was already at the extent of my programming capability, in some areas even exceeding it as I required the regular assistance of generative AI in this section to help me understand the logical flow of what I was trying to implement, and iron out bugs. Additionally, as only one ability was implemented, given more time, I would have spent it adding a second default ability over adding ability augmentation as the scope of ability augmentation was significantly greater.
    • Inventory system to allow item switching as new items drop
      • As item drops where never implemented, implementing an invetory system and item loadouts was obviously not going to make any sense to implement.
  • Enemy Design and Combat Scaling
    • Enemy scaling
      • Due to having no character progression that allowed heroes to get stronger as they progressed through each run, scaling enemies to also get more challenging was not going to be a smart idea as they would quickly overpower heroes and end runs early every time. However, while there could be more complex logic for enemy scaling such as scaling existing enemies by the level of the encounter or spawning enemies based off countering the most invested in hero, the means to essentially hardcode in and make new enemies that are more challenging, and assign them to later levels, all exists, and would just be a matter of creating them, and adding more levels to summon them.
    • Enemy roles and abilities
      • In theory, much of the structure to implementing this already exists, but after getting reality checked by implementing hero abilities, I skipped over this. I could have assigned existing hero abilities to enemies that suited their role, and used an ability usage system similar to with the heroes, at the start of turn cycle each enemy could roll a random number, and the highest two could use their abilities that turn cycle. Alternatively, I could have taken an easier option, and given each enemy only one action (which currently is only basic attack), and they could use only that one action, which given their roll, would be an ability that made sense, and then create enemy AI logic to target individuals that favoured it such as single target healing on low health enemies or high execute damage on low health hero targets, however, the time taken to make the heroes feel unique, took away from being able to make any of the enemies feel unique outside of different stat allocations.
    • Boss encounters
      • With no enemy roles or abilities implemented, I felt making boss encounters would not have added anything to the game. With abilities, bosses, aided by a certain selection of minions with their own abilities, could make each encounter feel unique. However, without the implementation of enemy abilities, bosses would have just been a massive stat sponges, and due to current balancing, with some heroes already being especially vulnerable, losing heroes could come down more to luck than mistakes in strategy and decision-making, so scaling attack stats was unwise, and making one enemy just take turn after turn to widdle down would likely not only have added nothing, but also taken away from the experience.
  • Roguelike Structure
    • Score system to measure performance and progressively harder levels
      • Due to no character scaling, and therefor no enemy scaling, making progressively harder levels was incredibly limited in scope, effectively impossible. Developing a scoring system off of metrics decerned by encounters that didn’t yet have my desired level of uniqueness, would have been very limited in scope and quite unrewarding. With no character progression, there is little a player could do to change their score, if character progression exited, and say, someone focused on a high-risk high-reward glass cannon build, they could feel they earn their score, however, with not character progression, there is little the player could do to change the range in which they could effect a scoring system.

Testing Feedback

User Feedback

  • Enjoyment and General Impressions
    • Users generally enjoyed the experience, with most giving a solid 4 out of 5, however, some responses of 3 recorded show the range that interest in this style or specific implementation of the game. Nearly all users showed interest in seeing how the game developed further, suggesting that the core gameplay concept was solid enough to peak player interest.
  • Abilities and Clarity
    • While no users reported being complety confused by the ability system, over half said they only somewhat understand what each ability did. This suggest the functionality was intuitive enough to learn, but lacked specific clarity, implying that maybe some more visual elements (such as a the healing skill having a value next to a green healing icon), or breaking up the card into elements of; target, number of targets, damage or heal and value, then a brief ability description would have helped. Ability and basic attack targetting was well received, however, several users suggested minor improvements or changes to exiting hover interactions. Overall, this feedback shows that this area is a strong focus for improvements.
    • To improve this area in the final week of development, I resolved the issue with ability card layering and increased the hover movement distance to show the full card, allowing users to get all available information on the ability when making their decision, and not only when they are preparing to use the ability.
  • Turn System and Card Readability
    • Responses to player turn and card playability feedback was notably mixed, heavily indicating a need for more consistent visual cues for active cards. Multiple users suggested strong visual cues such as coloured borders, glowing effects, or more distinct animations for better visual indication. While feedback was mixed in playability feedback, the turn system itself received strong positive feedback, indicating that the system has a strong base and played well. Additionally, several users noted that leftover UI elements from systems not implemented, such as the experience slider, created confusion. Feedback on visual indication for this system clearly points to it requiring strong change down the line.
    • There were no changes made to the turn system indication as this week exposed a lot of bugs with the turn system itself that had to be resolved, the unused experience slider was removed from hero cards to help prevent confusion.
  • Hero Identity and Strategy
    • Almost all users reported that the heroes felt distinct in their roles, indicating that the implementation of the holy trinity combat system was strongly implemented. In terms of strategy, 6 of the 7 responses noted that they used the turn order to determine their ability usage over synergy between hero abilities. This suggest that the balance of the game for the speed-based turn system along with ability limitations encouraged players to plan ahead and make decisions on what they might need later in the encounter, as opposed to being reactionary or feeling inconsequential.
    • As this section received solid feedback, attention was directed to other areas for improvements throughout the final week of development.
  • Action Feedback
    • Feedback on action responsiveness was overwhelmingly positive, with 6 of 7 responses stating that the game provided sufficient feedback for when actions were performed. This suggest that the current implementation of hit animations, and action animations succeeded in informing the user of their completion. While this was the overall feedback, a few suggestions for improving visual indication of status effects for abilities that applied taunt and armour break were noted.
    • While feedback for this section was solid, I implemented sound cues this week for each ability and the basic attack, to further inform the player of action usage and help making them feel impactful, however, there were no changes to status effect indicators.
  • Bugs and QoL Suggestions
    • While reports of bugs were limited almost only to ones that I had mentioned prior to going into testing, one user mentioned encountering a soft-lock where the game became unresponsive after an enemy turn, requiring them to restart the game. Additionally, quality of life suggestions were limited to those already mentioned throughout the above feedback, largely pointing towards polish and interface clarity.
    • This week I believe I was able to replicate the soft-lock bug, and it happens when the cleric does, I, however, have no idea why and have therefor not implemented a fix, I've just uped the cleric health in the meantime so that they will most likely not die, while I continue to investigate the issue. Notably, the unlimited actions per turn bug has been resolved, correctly limited the users to two ability usages per turn, as they were encouraged to replicate during testing.

Tester observations

  • Much of the observations I made during testing by watching the users play my game are almost a facsimile of user feedback. I observed several players struggling to initially determine which cards were active or what to do when they were playable, however, some of them mentioned that they had only briefly skimmed over my game instructions, later mentioning that the systems made more sense once they were explained to them. I also noted that players repeatedly selected and deselected ability cards or heroes during their turn, strongly supporting their feedback of presentation of ability information not being clear or accessible enough. Additionally, I also noticed a surprising number of people messing around with the experience bar ability slider, attempting to determine if it performed any action, of which they found out it didn’t, and was why I removed it this week. These observations reinforced by decision to focus on polishing visual feedback for turn playability and ability communication throughout the final week, in an effort to polish the content that already exists, over implementing new features.

Asset list

  • Abilities
    • ClericPartyHealAbility
      • Stores the cleric heal ability’s name, art, description, and heal percentage.
    • GuardianTauntAbility
      • Stores the guardian taunt ability’s name, art, and description.
    • MageDebuffAbility
      • Stores the mage debuff ability’s name, art, and description.
    • RogueDamageAbility
      • Stores the rogue damage ability’s name, art, and description.
  • Images
    • CardTemplate
    • HeroArt
      • GuardianArt
        • Used as artwork for the guardian hero in the hero and ability cards.
        • Owlcat Games. (2021). Paladin portrait. In Pathfinder: Wrath of the Righteous.
      • ClericArt
        • Used as artwork for the cleric hero in the hero and ability cards.
        • Owlcat Games. (2021). Tiefling priest portrait. In Pathfinder: Wrath of the Righteous.
      • RogueArt
        • Used as artwork for the rogue hero in the hero and ability cards.
        • Owlcat Games. (2018). Tiefling rogue portrait. In Pathfinder: Kingmaker.
      • MageArt
        • Used as artwork for the mage hero in the hero and ability cards.
        • Owlcat Games. (2018). Jaethal rogue portrait. In Pathfinder: Kingmaker.
    • EnemyArt
    • Backgrounds
  • Sounds
  • Scripts
    • Abilities
      • GuardianTauntAbility.cs
        • Implements taunt ability for the guardian, including targeting logic, animation and audio.
      • HealAbility.cs
        • Implements healing ability for the cleric, restoring health to all allies, including animation and audio.
      • MageDebuffAbility.cs
        • Implements debuff ability for the mage, reducing armour and dealing damage to multiple enemies, including animation and audio.
      • RogueAttackAbility.cs
        • Implements high-damage ability for the rogue, striking a target and adjacent enemies, including animations with clones and audio.
      • TimedEffect.cs
        • Handles abilities with a timed durating (taunt and armour break), using counters for turns.
    • Ability.cs
      • Base class for all abilities, with properties and functions for usage and checks.
    • AbilityManager.cs
      • Controls how many abilities a player can use per turn cycle.
    • AbilityCardSetup.cs
      • Handles ability card visuals, hover/select animation, interaction logic, and targeting behaviour.
    • TargetsEnemies.cs
      • For designating an ability as targeting enemies.
    • AudioManager.cs
      • Initializes and controls audio clips for all abilities and basic attack.
    • CombatManager.cs
      • Handles turn order based on speed, turn transitions, enemy AI and combatant registration.
    • Combatant.cs
      • Base class for any hero and enemies participating in combat, defining combat-related actions and data.
    • BasicAttackHandler.cs
      • Performs the movements and damage logic for basic attacks, including animation and sound.
    • BasicAttack.cs
      • Triggers a basic attack from a selected hero on an enemy target.
    • EnemyCardHover.cs
      • Manages enemy card hover scaling and click behaviour to trigger basic attacks or abilities.
    • HeroCardHoverSelect.cs
      • Manages selecting a hero for basic attack.
    • HeroCardManager.cs
      • Instantiates and animates hero ards and their associated abiltiy cards at the start of the game.
    • HeroCardSetup.cs
      • Core hero logic, initilising card visuals, stats, and handling combatant behaviour and death.
    • HeroData.cs
      • ScriptableObject storing a hero’s base stats, card art, and assigned ability.
    • HeroRuntimeData.cs
      • Holds and updates hero stats at runtime.
    • EnemyCardManager.cs
      • Instantiates and animates enemy cards at start of each level.
    • EnemyCardSetup.cs
      • Core enemy logic, initilising card visuals and stats.
    • EnemyData.cs
      • ScriptableObject storing enemy base stats and card art.
    • EnemyRuntimeData.cs
      • Holds and updates enemy stats at runtime.
    • EnemyCombatant.cs
      • Enemy version of Combatant.cs, including managing enemy targeting while obeying taunt logic.
    • HitAnimation.cs
      • Applies a shaking effect to cards when heroes or enemies take damage.
    • LevelData.cs
      • ScriptableObject that stores which enemies are present in a given level.
    • LevelManager.cs
      • Manages level progression.
    • SceneSwitcher.cs
      • Manages switching scenes.
      • Lewis, I. (N.D.). SceneSwitcher.cs. MyLO. <no-link>
  • Prefabs
    • AbilityCard
      • Used as the visual base for representation of hero abilities, including displaying the name and description of the ability.
    • EnemyCard
      • Used as the visual base for representation of enemies, including displaying the name, art, level, health, attack, armour, and speed of the enemy.
    • HeroCard
      • Used as the visual base for representation of heroes, including displaying the name, art, level, health, attack, armour, and speed of the hero.
  • ScriptableObjects
    • HeroCards
      • Guardian
        • Stores the guardian’s name, art, initial stats, and ability.
      • Cleric
        • Stores the cleric’s name, art, initial stats, and ability.
      • Mage
        • Stores the mage’s name, art, initial stats, and ability.
      • Rogue
        • Stores the rogue’s name, art, initial stats, and ability.
    • EnemyCards
      • SkeletonMage
        • Stores the skeleton mage’s name, art, and initial stats.
      • SkeletonPaladin
        • Stores the skeleton paladin’s name, art, and initial stats.
      • SkeletonSoldier
        • Stores the skeleton soldier’s name, art, and initial stats.
    • EnemyLevels
      • LevelOneOneCards
        • Specifies which enemies spawn for the first encounter of level one.
      • LevelOneTwoCards
        • Specifies which enemies spawn for the second encounter of level one.
      • LevelOneThreeCards
        • Specifies which enemies spawn for the third encounter of level one.
  • Scenes
    • EndOfGameScreen
      • Displays a victory message when all enemies have been defeated, including a restart and return to main menu button.
    • Game
      • The main game scene where the core gameplay takes place.
    • HelpScreen
      • Provides instructions for gameplay and an explanation of the games core systems.
    • MainMenu
      • The main menu of the game with background art and a title, including a help/instructions button and a start game button.

User Guide

  • Eternal Echoes: Heroes of the Depths
  • How to Play
    • Turn-based combat:
      • Heroes and enemies take their turns based on their speed stat in descending order.
      • Heroes are allowed to take one action, whether it is a basic attack or ability, per turn.
      • If two or more heroes have the same speed stat (the rogue and the mage), they can take their turn in either order.
      • If heroes and enemies share the same speed stat, the heroes will get priority over the enemies.
    • Actions
      • Basic Attack
        • Select a hero card that is currently playable (as shown by being larger than other hero cards), then hover over and select an enemy card to target.
      • Abilities
        • Heroes may use a total of two abilities per turn cycle, however, basic attacks can be used as often as desired.
        • Hover and then select the ability card below the currently playable hero card. If the ability targets an enemy (the rogue, mage, and guardian), then the selection of enemies will proceed as with the basic attack. If the ability targets allies (the cleric), then the heroes will become targetable and you can select them to use the ability.
        • Abilities are also subject to armour mitigation (excluding the heal), just as with basic attacks.


The Game Screen - the screen where the core gameplay takes place, showing both mage and rogue turn, with all hero cards, enemy cards, and ability cards spawned.


The End of Game Screen – the screen displayed over the top of the game screen when either of the end of game conditions have been met.


The Main Menu Screen – the screen that the game starts at, allowing you to either seek help through the Help/Instructions menu option, or start the game through the Start Game menu option.

The Help/Instructions Screen - the screen that opens when selecting Help/Instructions from the main menu, which displays how the game mechanics work under Turn-Based Combat, and how to use abilities or basic attack under Actions.

Files

Eternal Echoes - Heroes of the Depths.zip Play in browser
26 days ago

Eternal Echoes: Heroes of the Depths

Add Game To Collection

More posts

See all posts

Leave a comment

Log in with itch.io to leave a comment.