Baldur's Gate Tech Replica
Adaptive Turn-Based Fighting System
Introduction
This is my Balders Gate 3 Replica project.
I wanted to create a unique and challenging experience that follows my primary interests in playing and developing games. The use of a turn-based fighting system and the challenge of creating a diverse set of enemies and a base script that can easily be expanded to add more abilities using the same checks as other functions.
​
Summary
Individual solo project spanning 8 weeks working 4 hours a day.​
Project made in Unreal 5
Scripting
-
Turnbased fighting system​​
-
UI Elements for turn tracking
-
Multiple enemy types
-
AI behavior
-
Quest Implementation
-
Point and click functionality​​​​
Design
-
Balance Player start stats
-
balance enemy encounters
-
Designing enemy units
-
Quest Dialogue
-
Quest Design
-
Character and Camera controls​​​​​
Turnbased fight system
Information Management
The core of the fighting system I developed required multiple different scripts to communicate and identify eachother while passing and sorting information. The first iteration of this was hastily thrown together to simply work, but not be optimised or pass along too much information just for a proof of concept. While it worked to add all combatants to a list, sort them in initiative order and let them have their turn. Because it did not pass enough information, it needed to be reworked.
Redesign
More functionality
When expanding the original design of the combat system, I needed to redesign what information was being passed between the three central blueprints. The core problem of the original design was that the world manager did not know whose turn it was, only the initiative of the next character in the turn que. For a more stable combat, the world manager needs to get the initiative and a list of fighters then sort them to be equal. This way, the world manager can tell who is the next fighter rather than each fighter being asked what initiative they have then waiting for an answer while each character keeps track of if they have had a turn or not.
In the image gallery the first image showcases how information and combat worked in the original design, the second image is the redesigned version, while the third image is the end goal of the redesign that there was not enough time to implement.
First iteration of information management flow
information management updated to include more data and streamlined for ease of use
not implemented update of intended design
First iteration of information management flow
UI
Updating Turn Tracker
With the update to the combat system, I could now identify who's turn it is easily and with this information I could add it to the UI for more player feedback during combat so the player can see the total number of enemies, and who will go in turn order. However, just having the identity information is not everything, I also needed to implement UI scripting to add the number of images equal to the number of fighters. After adding the image to the screen, they need to be sorted in initiative order, and then continually updated whenever another player ends their turn. Any enemy dying is also another update needed where the targeted enemy needs to be identified, and all other images need to move to coordinate a central location. All of this is visible inside the script window below.
Ai Behavior
AI id and custom behavior tree
A central point of the combat is how AI would behave. Outside of combat they either roam or remain stationary, and while in combat they are rather simple, always going for their base attack based on the type of enemy the player is dealing with. For ranged attackers they move away from the player to a specified distance, and then attack followed by ending their turn. While melee attackers always look to move to the player and attack. Theoreticaly any behavior I want a certain enemy to make could be implemented due to the data table that the Enemy blueprint is based on. however only a simple melee and ranged attacker is all this tech replica needed.​
Enemy Design
Crafting Enemies
To be able to create some semblance of multiple different characters in the world but avoid hundreds of enemy blueprints, I made a datatable that could hold all the standard stats from the RPG system then inside the construction script they become applied to the BP_Enemy. With the addition of UI implementation this data table could also hold the image that the UI needed to display. Using this data table I can create any amount of characters rather easily, and then the enemy blueprint can be added upon to give more behavior branches that an enum the uses to give the enemy their designated behavior. ​
Quests
Simple dialogue and triggers
What RPG is complete without a quest system? This tech replica uses a very simple quest system and it controls the dialogue that the NPC uses based on the completion of the quest. This system was very limited and not very adaptive, though it was meant to be a proof of concept and something to be further iterated upon.
All NPC have a base dialogue and a quest ID. Once a quest has been completed, all NPC get checked to see if their ID was the cleared one, and if so we change the base dialogue.
This does however mean that all quests are always active and so players can complete a quest before they accept it.
Level Design Iteration
Level Layout and Experience
At this point I had only two weeks to create a level and so I had to work fast. I began with a simple layout that should be able to showcase all the different features of the game. A village to showcase some NPC and initiate a quest, a forest for some simple combat and a cave to act as a second stage in a multi step questline. Due to the time constraint, the demo now only features one map that is easier to navigate and further iterated upon. From some feedback, I upped the amount of verticality in the level and added some loot in the level to incentivise more exploration. I still wanted to keep the level rather simple and still in a refined blockout stage, and so only rocks and trees populate the level to give a bit more depth.
First drawn scetch outlines
Building the village
The end product in acordance with my time line
First drawn scetch outlines
Reflections And Playthrough
What's Left
There is still a lot of things to upgrade and things to do diffrent.
here is a list of things to still work on or change.
-
Initiating combat need to be refined​​
-
Adding enemies to existing combat.
-
More in fight behavior for enemies
-
More Data table information to include a simpler behavior when calculating attacks
-
Further establish the quest system
-
Magical attacks
-
Physics attacks.​​​​​
This was a challenge for me to push the limits of my capacity inside of a strict time limit. A limit that got even smaller due to illness taking away 3 weeks of work. The challenge was how close can I come to Baldur's gate 3 using the knowledge I accumulated during my time at TGA under the time limit of 11 weeks. I originally thought it was going to be easy and in some matters it was while others had me needing to design in a very roundabout way and then simplifying it when the concept was proven to work. If i were to redo everything now from the ground up, not a single script would look remotely the same due to me later on realising that there are better ways of creating most of the scripts controlling everything.