The Azure Abyss, a large perforation inside the crust of the Earth tinted blue by the light from
the moon. The blue light has mutated the cave and the creatures inside it, creating twisted
monstrosities.
You are Indigo Pilfer, a scientist forced down into the abyss by his boss to find the secrets of
what lies below. Use your weapon to combine elements in order to defeat the monsters in the
abyss, your wits to get around the interwoven cave systems, and your bravery to make it to the
bottom and perhaps you'll make it out alive.
Game Source
The dialog system was designed to be designer friendly first. The system conforms
to this by allowing the designer to create dialogue trees
through blueprints in any Character blueprint as long as it has the dialog actor component
attached. This makes the system modular and able to be applied to any character or situation.
To build the dialog tree within a character's blueprint the BlueprintCallable attribute was used
on the functions that are used to build the dialog tree.
The system also allows for the designer to create
custom events that can be called from the dialog tree this is done by defining special codes
hidden in the dialogue but read by the system triggering different events such as calling custom
blueprint functions, adding items to the players inventory and setting quest flags.
The quest system was also designed to be designer friendly first. The system conforms
to this by allowing the designer to create quests very quickly and easily through blueprints.
The Quest class contained 3 main variables Goals, PreConditions and Rewards. Goals are what the
player
is aiming for to complete the quest this can include quest flags, items, or even a combination
of both.
PreConditions are what the player needs to have done before they can start the quest, this can
also include
flags, items, or even a combination of both. Rewards are what the player gets for completing the
quest, this
can, you guessed it, include items, flags, or even a combination of both.
All a designer has to do is create a new blueprint that inherits from the Quest class and
then add or replace the values contained in the blueprint that are used to build the quest. This
makes the system modular and able to be applied to any quest or situation.
To check if a quest is complete the system checks the goals and preconditions of the quest when
a new flag has been added or modified also the system also checks if a quests goals have been
met
when a new item has been added or modified. This is done by declaring events and calling the
CheckConditions function on each active quest.
The turn-based combination combat system and status system go hand in hand. The status system allows for the player to be affected by different status effects that can be applied by the player or the enemies in and out of combat. There was two different types of status effects that could be inflicted on the player, one which was turn-based and one that was using real time to tick down. The turn-based status effects could only be triggered during combat as they were based on the player's turn, while the real time status effects could be triggered at any time via the consumable jellies in the game. This affected combat as these status effects applied buffs and debuffs to the player and enemies, which could be used tactically by the player to optimise damage output or to survive longer in combat. Status effects include heal over time, thorns which damaged the enemy when they attacked the player, and a strength buff which increased the player's damage output.