Eldritch Horror
Desgined, programmed, and Kitbashed
Quest System
Quest Management
Here is the basis of how to manage the quest progression in the editor. The number of elements for each of the arrays must be equal to the number of Mission Steps. Utilizing the tags of the actors, they must contain the Mission Name, otherwise it will not work as the Game Manager and Mission Tool will not understand what quest is for what purpose.
The Mission Dialog, MEncounter Tool, Interact Actor, and Dialog Tool do not need an actor for every element, but all of the other arrays need one to run as intended. Of course, certain parts of this quest design is not always used like waypoints or character images. However, this allows the designer to do as they need. Especially considering how any waypoint can also be set to “Hidden in Game”, this allows for greater design and extremely modular way of setting up the quest progression system.
QTE Scripting
Here is the basic scripting for creating the QTE. The QTE is called as an input that can be tied to any key in the input. For the purpose of this game, I kept it at the key for the letter E. This QTE worked by rapidly tapping it and making sure that it is working well. The actual input is coded in the player blueprint. It can be modified to fit any need and just needs to be called on any keyboard event or Enhanced Input Action.
The Game Manager blueprint allows the player to manage their quests, their stats, and check for different stats, like health, magic, death, XP, and leveling up. These mechanics must be set initially in the world. This is to make sure that the quest system gets activated and is not started from the start. This allows dynamic quests to be placed down.
This system is quite dynamic as it allows the designer to create and do whatever they need to in case they add extra mechanics like player stats, damage, or even allow the game to switch between different players in case they need to do multiple protagonists like in many AAA games such as The Last of Us Part II, Devil May Cry 5, Assassin’s Creed Syndicate and Shadows, and many more.
The mission tool blueprint allows the game to manage all the progression of a quest. In the screenshot, it can be seen how the player game will be taking on the different parts or types of quest activities. Here, we have the basic 3 types of quest progression: dialogue, interaction, and combat. After checking if each step is valid, the coe checks to see which one to fire at a time.
After each step is complete, the Custom Event node sets to finishing up each type is also present here. This allows the code to be fully integrated and set up non-quest interactions for the player. In addition, there is a boolean that is editable in the editor to check if it is for a quest/mission or not.
This means that random and scripted encounters in the open world can happen to the player at any time and can be part of the interaction system. All of these can and are set up through the editor so that is is a simple matter of dragging and dropping each actor into the open world.
Here, in the editor, a few things can and will be set. The first is making sure the dialog tool is picking the right conversation from the CSV file. Setting up the CSV file properly without spelling errors is vital to making this happen. Afterwards, the conversation steps must be the exact number as the dialogue steps in the CSV file. As these are set as an array, we are not dealing with array length, but rather array elements.
If the tool, as it is for all the others, can be for a mission or not. By default it is set to be for not a mission. If it is for a mission, the specific mission must be specified. This allows the right mission to happen for the dialogue in case multiple missions are taking place concurrently. Allow Player Control is intuititive and allows the player to run around or not. While I personally did not find a reason for the player to move around during dialogue, other designers or other games may want this feature. Others such as the No Alredy Talked Response asks if there is an already talked feature in that specific dialogue or not. When checked, the already talked feature does not fire though it is written in the CSV file.
Lastly is the approval of each dialogue is written in the CSV for which is the best response to give, which giving allows the specific NPC to behave favorably or not towards the player. Favorable or not can be written in the CSV as something extremely simple such as “friendFavorable” and can be fired with a simple if-statement. This can help for certain NPC interactions such as quest items, information, loot, and romancing options as well.
Turn-Based Combat
The combat starts with the warping of targets. This means that the player can warp to any target that is given by the editor. These can be anything that is placed in the open world. They can be empty actors, blueprints, trigger boxes, or anything else that is placed in the open world. For the sake of my clarity, I just put down empty actors and renamed them for organization purposes in the outliner. Furthermore, the warping can also be placed down for something like a boss fight, a new world to portal to, or even as a quick segway to play as another character if ever needed.
During the actual combat, the player has 4 basic options to choose from. This is easily expandable on what they can do. In addition, since they will be facing only one enemy at a time, the enemy’s health will also display. player’s turn, they will be able to choose between a number of options that will put them in different states.
To eliminate the eldritch horror from the game, the player must pass a Quick Time Event in order to get rid of the tentacles in the open world.
The dialogue is taken from a CSV file that can be edited outside the engine or in engine to create the dialogues. There are a few ways to denote this as shown in the scripting. The last node, “Get Data Table Row DialogExcelFile” takes the row name that is the character name appended with whatever the functionality of the dialogue is. In this example, it is the dialgue taken for the character when the player has finished all the conversation with them. Hence, the data taken will be from the “friend” actor. And wherever the data is taken, that character will achive that in the mission tool, the blueprint to create and manage all the missions a specific quest.
This dialogue system is not a massively expanding or branching dialogue system. However, there are certain ways to go about this. As I used a CSV file, having an extremely dynamic dialogue system akin to Baldur’s Gate 3 would not work here. But there was another way to go about this: approval.
The editor has two quest/mission oriented variables that are essential: Non Mission Combat and Mission. The boolean value determines what the mission is and the second determines for what mission. The enemy selection picks from a set of three enemy types, though more can be implemented and quite easily designed for the simplicity of the project. The delay time is set there for dramatic effect, any lag that may happen after or during calculations, and for that flow of turn based combat. Most importantly, it’s to make sure that the buttons are not spammable to any extent.
This is an unstyalized UI that was done with the basic assets given in the engine and done so to focus on design of the game, not look.
Environmental Damage
The envirnmental damage here is a depletion of health upon contact with poisonous air. The exact amount depleted can be seen with print string statments as the Main HUD has a progress bar, as oppossed to a number to show health.
In addition, to replenish heath, the key must be hit in the form of the QTE, and if done so, then the player can move on.
To account for all scenarios, if the health gets fully depleted, the game will load the most recent save, so it is imperative to save the game frequently.
C++ Programming
The basic attack here emulates a simple D100 attack, not a D10 as it’s random till 100. With the basic attack being high enough, it must pass that check. This can also be changed easily to deal with armor class as DnD’s 5th Edition rules outline and utilized in Baldur’s Gate 3. As the boolean is a simple comparative, it can be pulled from bringing a reference to the enemy in combat with and then using that armor class to set up the hit/miss skill check. Afterwards, we can use any way needed to add up all of the attack bonuses and base damage to get the finalized damage and do the final calculation to get the enemy’s final health. The scripting is simple and done so on purpose for the design of future expansion.
The defense of the player does something a little different, but can be expanded upon greatly in the end. In the current scripting, it takes the simple defense stat and multiplies it by 2 in order to defend itself. But there is usually more that defends the player with things like armor stats, armor class, weapon stats, and more. This means that the designer can just insert whatever affects defense here: stats, buffs, debuffs, and otherwise.
This is vital for when the player wants to choose between a defense strategy vs an offensive strategy. Switching between characters also does not affect this combat as only the playable character will get chosen to engage in combat while other characters do not. This helps support party system and single player/single playable character modes as well.
Here is a basic C++ calculation done through Visual Studio 2022. The calculation is done to add all the damage and multiply them with the attack bonus scaling. Input pins here will allow the player attack to be passed down from the different inputs in the turn based combat system.
