Blood Feud
Written, designed, and fully scripted by Ani Manchella
Objective led game focused on making an designing an immersive story for the player. Expandable to the player for MMORPG and online gaming as well.
Gameplay Design Philosphies:
The first objective was to make sure that it accounts for performance dips. With games becoming increasingly heavy on the hardware, it was imperative to make sure that the game itself is compatible and does its best to compromise for some of the heavy calculations needed.
The mission should happen as character interactions happen. This means that the player must be able to do what they want when they want but their actions will affect the characters in some way. This was taken from games like Elden Ring, Sekiro, and Witcher 3 where the open world is entirely free for the player to explore (granted they are strong enough) but interactions and potential areas are locked behind character interactions. This means that fighting your way through the world can open up possibilities but also harm the player as well.
Design should be modular for any designer that knows Unreal Engine 5. Most assets can be edited in the editor and very little needs to be hard coded. This means that every value, with few exceptions, should be entirely based on the actor and the values the designers wish to give.
Introduce something unique, something that is rarely done in a game. This means loading in a new map, a new type of playable character, and potentialy a new mechanic. I chose a dragon for this.
Player Stats
The player obviously needs to have stats. These include things like health, magix, and arcane as the base stats. These all do different purposes. Health is the amount of damage a player can take from various actions like combat, environmental, status effects, and passive effects.
Magic refers to the amount of magic the player can cast. This would be equivalent to the FP bar of games like Elden Ring, Dark Souls, and/or spell slots in Dungeons and Dragons.
Arcane refers to the scaling of the magic. For example, if a spell does 50 physical damage and Arcane is 10, then it would be 50 * 1.1 as final calculation is (base damage + (stat level / 100)). This is a very simple scaling method and can be expanded upon grately in future.
Stats like Strength, and Dexterity all modify combat ability such as increasing base damage or increasing scaling damage respectively. The charisma stat itself modifies player favorability and allows the player to sucessfully persuade NPCs. Other stats also come into play here. If both Stength and Dexterity are high enough then the player can even intimidate the player. These options all show up in the dialogue system.
The modifier stats are attributed to things like buffs as they all modify the base stats in some way. The last is the armor class. This will add itself into the calculation into negating certain amounts of damage. This means that higher/heavier armor will protect the player more, which is quite intuitive. Armor class is not tied to the player level. Rather it is tied to the weight of the armor. This is a number from 1-20 and will negate that percent of damage.
Classically, the XP and level stats refer to the player’s level and sees if the player can level up to increase a stat.
Player Inventory
All of the player inventory and calculations are handled in the Actor Component blueprint.
This allows the inventory to be attached to any NPC and this allows things like looting mechanics, shop system, and more to be integrated easier instead of making a custom blueprint/functions/custom events for each asset.
The component shows up on the character’s blueprint as shown to the left. This means that the designer can preset the inventory with something they with. By using the map type variable to combine strings and integers, I can give each item a key and set the amount it requires. For the sake of my rememberance for quick access, I created a few variables to help me remeber the names and what all I counted in the inventory. As inventory expands, and documentation is written, items in the inventory can have their own unique key made up of letters and numbers.
This design means that adding things to the inventory should be quite simple. And it quite is. Using a blueprint interface, I can call the event “Interact” anywhere and it will add the item to the inventory. The next task is to make sure that the player can interact with a specific object.
Object Interaction
Looking at different games in the past, it was always frustrating when I, as the player, wanted to interact with something, but something else was in the way. Hence, I wanted to fix this. The obvious route for making an interaction was to do it using collision boxes. Where the player with overlap with the collision box and then the rest of the logic fires off. However, I did not want to do that. I wanted to make something that felt more intuitive. I wanted to make sure that the player will face a direction and be able to interact with the object they are facing.
To do that, I employed a simple line trace. It fires on every tick which would lessen the performance, but considering it was something very simple and easy, I figured the benefits outweighed the drawbacks. The line trace happens and if the objects implements the Interaction interface. If there are multiple interfaces that can be interacted with, then that can also be implented with switch statements to make sure the right piece of code gets fired.
After the branches, the logic goes to set the interacting actor so that the interaction UI can pop up (E to Interact). This just means that the interaction UI is already created, we are just setting the visiblity each time. This also ensures that the UI is not being set every time the line trace is fired (which is every tick).
Dialogue and Mission System
The dialogue acts almost the exact same as a behavior tree with AI enemies. The conversation starts and then the designer (me) adds a new conversation sentence or more depending on how the UI is built. Between each node is a transition node. These transitions can have any logic in them as long as the variables are properly called.
In my case, I wanted to check if the player has any of the traversable rings. These rings are important to the story as they allow the player to spend time travelling and playing as a dragon. However, any skill check can be made, like stats, inventory, or combat.
When the dialogue starts, all the booleans must be set and the current dialogue being used must also be set. This is a Dialogue Builder Object taken from the plugin found on Fab.com. These custom events sets up the UI and removes it when the dialogues are done and finished.
But we first a dialogue tree. This where I used the plugin. This plugin allows me to create the dialogue trees in a simple and modular way. It even allows me to have voice acting. Leveraging this, I was able to create a dialogue tree that is quite akin to that found in games like Baldur’s Gate 3, Witcher 3, and Elden Ring.
In creating the widget I needed to make sure that it is actually present on the screen. There were a few problems to take into consideration. I either have a limit on the amount of characters per line to prevent words going off the screen of clipping into something else, or I wrap text and dynamically change the size of the box.
I decided to do both. I put a limit on the number of words that goes into the diologue design. This meant that the designer needs to keep track of the number of characters when creating a quest system or a fun dialogue interaction. This is not an extremely hard task, so I figured the benefits outweighed the drawbacks.
As described before, doing a line trace for interactions was my smartest move, but sometimes, NPCs want to interact regardless of the player’s choice akin to real life people. For this, I had some of the NPCs interact with the player based on collision, not the line trace interaction.
Combat
The combat is not the most innovative, but it does account into something that helps it runs smoother: Performance. The game starts by having the weapon hidden from the player and when they attack it shows up. Since the game is based on the books I have published, this has a narrative reason. But this was also to take into consideration something else: I did not have traversal and idle animations for the character holding the weapon. This meant that the design needed a good reason. I had a good reason, but it must still follow the Rule of Cool. Hence, I implemented the disappearing weapon. This can be done with a VFX or not. Both work. As I am not a VFX artist, I had none to really use, but the scripting is quite simple.
The weapon traces will happen on the event tick, as it should happen, but it will only fire when the player presses the input for it and that input is situated in the comboSystem actor component. This was also done as the same comboSystem can be implemented for different enemies with the differences being their animations.
This means that the player can and will be able to do the exact same actions as the enemies. This is something I have always believed makes good believable combat akin to Sekiro where both the player and the enemy of the posture bar and unlimited magic to use (or rather combat arts).
The final combat design decisions were taken to be either styalistic or functional. Camera movement was a styalistic choice that I believed didn’t need to happen for this game just yet.
The weapon traces happen as taking two sockets from the weapon, from the crossguard to the tip of the blade. The weapon traces go between the two sockets and moves from the two of them.
The traces happen on every frame so we would have to calculate the area the sword travelled between the two frames to make sure that no enemy, another player or otherwise would escape the player. The traces will continue to fire if it collides with an actor and can be damaged. This is to ensure that the player can hit multiple actors at once. This means clearing out mob enemies will still happen and not compromise on performance.
Having these nodes for server and client will allow the game to function even if online play was implemented. This means that things like PvP or onlline co-op play will a viable function for the future. These functions also work for offline play. This means that online play is not a requirement and is fully and completely optional.
In this specific node, I just sending the damage to the server to make sure that the player is recieving all the damage necessary. The incoming damage is the final damage including all buffs, debuffs, and more that affect only the health. Any effects that harm the player’s base stats have not been passed as I designed. If they were to be implemented then it would be quite simple to just add the parameters.