Dartiora | Jamesharris615

Game System Designer

Dartiora: Land of Ley

Dartiora: Land of Ley was a proof of concept and a mini full game for players to explore. The game takes place in the village of Sefer, where you, a hired spell blade by the Dartioran Municipality, is requested to deal with both the physical problems of the region, and the ley caused problems as well. As you dig deeper in the ley problems of the region, you learn you aren't the 1st spell blade, you are the 60th. Explore the Mistveil dungeon and remove the region of its problem, craft weapons, powerful imbued runes, and deity blessed talismans to learn new skills to take on the cursed ley of the land.

I created the artwork, the programming, and all design components for the game. Mixamo supplied the animations. All the world design and the models for all the artwork, the UI, and the iconography was created by hand in either photoshop or Maya.

Commented Gameplay Video

Software

Tools Used: Unreal Engine 4, Maya, Photoshop, Mixamo (Animations)

Anchor 1

Process: Design

Initially, the game was planned to be a small level area with minimal components, but then evolved into different pieces, which brought new mechanics along. Crafting and NPC communication was important for quests, and required for some. As the spell blade is just another number to the villagers of Sefer, they don't talk too kindly to the player. All of this created the feeling of the village so that the player would feel as if it is just a job. I first built the main character to house the animations and that allowed me to create the initial sword mechanics. When creating the sword mechanics, I wanted to base them around faster attacking for the main character, since he isn't a heavy attack user as a spell blade. After the sword was done, the next was to add the magic attacks, hence spell blade. I created three different attacks, that needed to be combo'd into in order to activate the magic strikes. The first was a shield, it is placed up by holding right click, which is the universal magic button. This counters heavy attacks and reduces the damage that you take from physical strikes, while nullifying magic strikes. The second magic attack was a basic knock back of all nearby enemies, allowing for a quick disengage. The last magic attack is a bolt strike that is a basic magic launch. All of this was thought through for the character so that he could feel quick and responsive. Below is the original drawn map used, marking main ore/wood locations.

The sword magic also needed some form of mobility. This came in the process of a two step blink. Throwing the sword away and vanishing it was the start of the blink. This meant that the user also could not use sword strikes until he finishes the teleport. The magic strikes can still be used, as not to completely nullify the playstyle. Clicking, as if it was an attack, blinks you onto the targeted enemy. This results in strong mechanics for dodging and maneuvering around the battlefield. The other mobility option comes after the third strike, instead of using magic, the character teleports backwards. This was implemented as a form of reset for the character and giving some space for going in to the fight and out of it.

The next pieces added to the player were the bow skills and uses. The bow offers another playstyle and to poke the enemy from a distance. As the player was almost mainly melee, giving some range, while not making it too strong, was the reason behind it. It also gives the main character a much stronger silhouette to be easily identifiable and memorable. Initially, the bow or the sword had to be equipped, meaning that the character had to choose, during the equip screen, what they wanted to use before an fight. After some testing, users wanted to be able to have both options at all points in time. I combined the bow and the sword into a single character and that was much better from a player perspective then. The skills had a lot of different options for the bow user, mainly that bow is focused around some repositioning of the enemies. There skills let them pull, push, and have a heavy striking blow that pushes some enemies backwards.

The enemies came next. Working on the enemies was pretty quick and basic, as having the bandits be more melee heavy, and the slimes be more ranged heavy, splitting the playstyles relatively evenly. As some playtest went on with the bandits, having some form of hit stun was important. It gave weight to the players attacks and helped to ground them more in reality. This led to the stagger bar being created. Bandits can not be staggered more than 3 times in a row, with a bow shot being able to reset that. If they go over three staggers, they then lash out and fight back heavily and stronger. This was decided so that brute force players needed a little more skill in their teleports, and strategist players were rewarded by using their skill in timing.
All of those pieces combined created a more dynamic playstyle that the players really enjoyed working around. Enemies also had counters built into their gameplay. The Greatsword Bandit has a strong overhead attack, this can be countered with the players magic shield. Learning the enemies and the gameplay is key for the dungeons, so giving these options in the overworld helped player retention.

Another type of enemy was the slime. The slime was the ley being that the mistveils created. In loose terms, they are magic balls from the dungeon. These slimes were one of two elements and can be countered with the other element, discussed later. Small slimes are common in both the dungeon and the overworld. They have three attacks with two being melee strikes and the last being some form of elemental attack. This gave some form of bonus play style to work around. Water slimes spawning making a ripple that hits twice, and the fire slimes burning a cone in front of them. The large slimes had ranged attacks when you were out of their melee strikes. Either a line attack with three fire balls and creating pools of fire that damage over time, for large fire slimes, or a cone attack of three water balls and creating pillars of ice to block movement and damage the players, for large water slimes. These can't be hit stunned, as they are magic beings and it didn't make much sense to test players.

As mentioned above, elements can counter the slimes. The player has two different elements that are available in this region of Sefer. Water and fire are the two available, hence the two craftable runes. These runes both come with the "Enchant" skill, enhancing your attacks with water or fire respectively. This is designed to help counter magic and attack the final boss a little bit easier. A rune also enabled magic for the spell blade, so without a rune, RMB magic did not work or function. This acted as a tutorial gate so that it can teach the importance of runes and the importance of crafting at the same time.

To mix up some builds, the character needed another way to differentiate themselves in a hack and slash/dungeon crawler RPG. Talismans were there to fix that. They offered a unique skill and a custom combo technique that worked from bow -> sword or vice versa. The Life Talisman's skill is an AOE damage over time bud that gains damage the more buds are nearby. This plays into a "Strategists" technique and gives them some more field play. The choice of secondary skill was a mobility and reposition after a few sword strikes, also leaving a bud. This almost made a "Class" without having to explicitly say so. The second talisman was the "Fate Talisman". This was created in opposition to the "Life Talisman". It incentivizes getting close and personal with enemies and dealing heavy damage quick. The skill was all about dealing heavy damage to execute, as if the enemy did not die within 3 seconds, they healed back that damage dealt. The talismans created two different play styles that worked in tandem with each other.

After enemies and skills were made, the random dungeon could be added. This dungeon was supposed to be a serious/end game dungeon. Passive healing, as given in the overworld, was disabled. This was a conscious choice because it forced the players to explore for healing rooms, bring a steady supply of potions, and know their combat well. The randomness ensured that if you fail once, the next layout could suit your combat style well. It was also a good source of materials, so doing small expeditions was encouraged in the long dungeon. The first iteration of the dungeon you could walk into the boss room once you found it. That let players skip the dungeon enemies and run straight to the boss which was not ideal for play time. That was when three runes needed to be activated to "unlock" the door to the boss room. As this was an end game dungeon, it was supposed to be incredibly hard, which leads to the save system. Being able to only save in town meant that you needed to be prepared for each trip you make outside the walls. All of that was intentionally done to give the player more thought to each action that he/she performs. The image below on the left is the base drawing for each room, the enemies that spawn in them, and how they connect.

Finally, the boss fight was created. As the last enemy, mainly, in the proof of concept, it was supposed to be challenging and force you to think in elements. The first phase is more of a game knowledge check rather than a DPS or timing check. The pillars spawned each have a colour. Each colour represents an element, the opposing element will break the pillar, dealing damage. Since the player would only ever have, possibly, two of the four elements, he had to try and bait the cursed into striking their own pillar. This is a knowledge test because it relies on remembering what happened to the slimes and the colours associated with them. The second phase has 4 attacks that are summoned blades, implying the boss used to be a spell blade as well, with 2 performing melee strikes and 2 performing ranged strikes. The attacks are not telegraphed; however, based on the disappearing sword, the player can determine which attack is about to be used. Having some form of telegraph gives player some form of accomplishment when they can finally learn how to dodge certain attacks. Finally, the last phase is just an all out attack where the combat skills of the player are heavily tested, he strikes with two different attacks each time, meaning the player needs to dodge and strike in time. Talismans played heavily into this last bit, as life would allow you to dodge freely and fate allowed you to execute the boss at a certain amount. The whole game has a relatively large span of time as well. While recording the video above, it took about 25 minutes to reach the boss, I didn't dive into crafting any form of weapon as well.

Anchor 2

Process: Programming

When I dived into this many mechanic based game, the first thing was to establish the base gameplay for the player. Using the process outlined above, I started with the player combat, player skills, base enemy combat, exploration, and crafting. These were the focuses of the gameplay and without those being enjoyable, the rest of the game would have faltered. Starting with the mini arena set up, the image below, on the left, shows the initial layout and player progression path. The image on the right shows some of the basic bow combat blueprints that the player also uses in the play test arena.

I first set up the player. Creating the combat was of upmost importance. Using the sword and animations to slash, overlaps and hits sent damage type references to enemies. This is standard but where it needed more work was the hit-stun on the enemies. Each attack applies a stacking hit stun, killing the enemy AI temporarily. This continued to add until the enemy hit count equals the current stack cap. After that, different enrage functions were triggered based on the enemy type to change up how to approach them. Enough of the enemies for now though, they can always be refined. The combo system for the player was also important. Depending on the amount of sword slashes, the RMB changed from a magic bolt to a shield, push back, teleport, and blink backwards. Based on the sword counter, it triggers the different skill functions on the player side. Below is an example of the attack function and the damage application function.

Now, attacking doesn't mean anything if the player doesn't have anything to hit with! The inventory and equipment menu read different values from a master CSV file. Each item had an ID tied to it and could have saved values in the players inventory, for enchantment, enhancement, filtering, and favoriting. Adding all of those components together created a modular inventory system where items and crafting materials could be added, buffed, and nerfed, with no additional problems. The inventory system involved reading the line of the CSV file and making a copy of it, so it could be freely modified with crafting and enchanting, close to a Skyrim like system. The images below are the item list CSV and equipment in game.

Quests and Dialogue were also handled shortly after that, to finish the prototype area. These were handled in CSV files as well with data structures to read the different styles. Quests contained the relevant information, such as rewards, giver, information, and more. This was handed off to the quest journal to read and handled in the player controller. On complete, it reads the amount of rewards, skims that many rows down, grabs the ID and amounts, then gives them to the player. Dialogue worked similarly. It reads the speaker, dialogue text, and the modifier. The modifiers, such as END, QSTART, and QEND, were used as triggers to activate the different outcomes, starting quests, ending them, or just ending the conversation.

The random dungeon was handled with a single actor placed in the center of the map. The player would spawn in a room with a UI component on the screen. This would last until the entire dungeon has spawned. As sometimes, due to RNG, the dungeon could loop back on itself and not spawn correctly, a failsafe was built in to reroll the dungeon in the case of either A) not enough room or B) the boss room didn't appear. All of this would happen on a random interval so rooms that forked could be given time to expand on each side. Once the dungeon is full, it then spawned the enemies and removed the black screen so the player can then walk around. The keys are also in randomly spawned rooms after everything appears. The door unlocks in the dungeon after using the three different runes. The dungeon also has a chance to spawn 1-2 healing rooms. These healing rooms give the player a chance to recover HP or leave the dungeon. The images below are code used to generate the dungeon, with the image on the left confirming the rooms can spawn with the one on the right being the check that all rooms exist in the dungeon.

The final boss, the Dartioran Cursed, appears at the end of the random dungeon. This boss involved three different phases that happened. The first phase involved spawning 6 pillars around him, at set locations. The pillars have an equal chance of being one of the 4 elements. If they are hit with anything it checks the incoming damage type and compares it to the current element, if it is the same, it breaks the pillar, weakening the boss. The enchant skill on the player comes into effect here, with a weapon enchanted, it changes the damage type the player is using to then give them an ability to break and attack the different pillars that have spawned. The second phase of the boss fight involved the boss summoning 4 enchanted blades to strike with. The fire and wind are both melee, with fire being an instant teleport and wind being a dash to the player. The water and Earth and ranged, with water being a ranged slice, and earth summoning runes under you. I used components that turn off and on the swords before they use an attack to give a "telegraphed" look to the strikes. Each one also has an elemental damage type to the player, so those builds that may be a little weak to one element would struggle, as it is detected on damage calc. The last phase are two elements combined into one and a last ditch attempt to attack the player. Certain counters are also built in, similar to the other enemies in the game. The AI is not a behavior tree and is instead coded into the enemy as blueprint instead. Below is an example of selecting which attack to use as the boss and an image of the boss.

The village and final map were the last things to code into the game. The NPC's use different walking AI to go to each of their locations. The cutscene to the mistveil dungeon was made with sequencer and different events connected to the visual effects. The rest of the village and the quests were implemented with the quest and dialogue system I added before. The shops and player homes were placed under the map. This meant it was a teleport instead of an open level to prevent any form of taking the player out of the game loop. The rest of the time was spent balancing the gameplay, buffing and nerfing enemies and items as need be, and adding the last of the "Main Story" into the game. All the models were made by hand as well. The image below is the dock after the post processing and the sun rays were added, alongside the misty fog.