New month, new devlog! This week has been another busy one as the team ploughs ahead with the development of Depths of Erendorn. There’s even been talk of bringing a new body onboard, so we can already tell it’s going to be an exciting month! Give us a follow on Twitter, Instagram or Reddit for regular updates on our fantasy RPG – now let’s get into it.
Last week, we took you through how we sculpted three members of the Storm Elf Casters, a series of powerful enemies in the game. Well, after our 3D Artist finished retopologising and unwrapping all the meshes, they could finally begin texturing these characters:
- The characteristic blue that the Storm Elves wear was used to texture their robes.
- Since Storm Elves have a strong affinity with lightning and thunderstorms, a gradient was also added to the robes in order to mimic the look of storm clouds.
- A lightning pattern was also going to be added to the robes for extra interest, but after a few failed experiments, we eventually decided to scrap this idea.
We’re still working on getting the robes to look as interesting and elegant as possible, so in the meantime we’ve been focussing on the armour. We wanted this to look unique and fantastical, so our 3D Modeller actually decided to texture it with a metal of their own invention! This material was made to be a dark colour, with galvanised patterns and gilded edges in order to tie it in with the concept of lightning.
Another attack animation was created for the Wolvajin this week, with sound effects being used so that we could see the full effect of this enemy. Attack animations were also created for the :
Following this, all of these characters’ rigs, meshes and animations were exported. In the engine, we will continue testing them with their respective unique rig set ups.
This week, our Environment Artist formulated a plan of how to address pinching issues that were occurring with the cave walls in the dungeons. This is part of a bigger task of getting the walls in the game to look visually appealing following our Programmers’ work on implementing a wall spline system last month.
That said, our Environment Artist had a catch-up with our Programmers in order to understand the new improvements that have been made to the wall splines, which will dictate how they go about adding visual interest to them. As well as fixing pinching issues, and creating a random mesh variation blueprint like we did last week, our Environment Artist will improve the appearance of our cave walls by eventually:
- Creating more meshes and textures;
- Creating a variety of wall models to avoid repetition;
- Creating random props that will be placed at arbitrary points along the splines.
Moving on, as part of our goal to accelerate the creation and development of the environment in Depths of Erendorn, this week we have started the exciting process of hiring a new Environment Artist! After putting together a little art test for potential candidates, we were able to start surfing the internet for talented individuals whose style and experience matched our requirements, and we had a lot of luck! So keep your eyes and ears open, ‘cause we may be introducing you to a new team member very soon!
Our VFX Artist started working on the abilities for the Watertarg Excursionist this week, a playable character who belongs to one of the most ancient races in the game. Since Watertargs are amphibious, our Visual FX Artist integrated some water splashes throughout their ability effects so that they tied in with the Watertarg’s identity:
- Ancient Bolt: This ability deals Arcane Damage to an enemy while also slowing them down for 2 whole turns.
- Empowered Ancient Bolt: Not only does this upgraded ability deal more Arcane Damage than its less powerful predecessor, it also slows the enemy down for an additional 5 turns.
- Revitalise: This doubles the Watertarg’s natural Health Regeneration for 4 turns. It also allows the player to gain extra Ancient Power per turn.
- Magic Gland: This is an incredibly useful ability because it absorbs one enemy spell that the Watertarg can then use itself.
After our Visual Effects Artist created the visuals for the Zentragal’s arsenal of abilities last month, our Sound Artist decided to begin creating sounds for them, as well. Since these characters are innately cruel and deceptive, our Sound Artist wanted to get them sounding fairly dark and creepy:
- Some of the vocalisations were made to be whispery.
- A lot of reverb was added, too, which made them sound quite sinister and spidery.
However, because Zentragals are playable characters as well as enemies, our Sound Artist was careful not to make them sound too creepy as people hate spiders enough as it is – so we think we’ve hit a good middle ground!
This week in the Programming department, we fixed a rotation discrepancy between the client and the server. As a result, all entities should now face in the correct direction when they’re displayed. There were also a few upgrades and bug fixes that had to be carried out on the audio manager:
- We fixed a bug that was causing the playlist to only play the first track.
- Another bug occurred when joining old lobbies, in which the large time offset from the start of the match was causing the audio manager to make the client hang.
- More volume tracking was then added to the audio settings, and a fade out/fade in transition was also added when changing to in-dungeon music.
- New settings were then finally created for character sounds, ambient music, environmental sounds, interface sounds and dialogue.
Moving on, to avoid an initial panic when the game loads up for the first time and people try to desperately lower the volume, we have now changed the default audio to 70% on each music setting. This was following many personal experiences where this has happened with other games – so our team thought it would only be fair to learn from our collective trauma and not cause the player to suffer through trying to frantically disable the audio settings when the game loads up.
Following this, there were a few more things worked on to get audio fully up and running:
- An easier-to-use GetVolume function was added for use in various game systems that use sound. This will ensure that a player’s preferred settings are respected.
- A notification was added for when the music track changes. This will likely be disabled as a default, but for now it’s useful for our testing.
When we weren’t working on the game’s audio, our Programmers were implementing changes that will improve the testing process so that we can get to a point where Depths of Erendorn is playable for others:
- A debug UI widget was added to help debug the game and collect some stats while testing.
- A session timer has been added in order to track how long it takes us to complete dungeons when testing.
- Room information can now be logged out of the console at runtime so that we can debug the room builder and level generator.
- The seed and XP is now visible for both the dungeon and each individual room. This information makes the reporting of bugs much easier from a tester’s perspective.
Fixes to Level Generation
We spent a bit of our time focussed on resolving some issues with level generation. Set pieces were fixed, for example, along with player overlap checking code. This was following the popping up of a new bug which, in some cases, caused players and set pieces to collide with one another. This caused some set pieces to not get placed onto the map, and some player positions were even being made unselectable when joining a game.
Our Programmers fixed another issue that was causing doors to spawn outside of the playable area of the dungeon. This, in turn, caused the game to be impossible to test in certain scenarios, so we’re glad that this issue is finally resolved.
Custom Step Classes
This week, our Programmers have also been focussing on how custom steps function. They have since worked on developing a workflow of creating and applying custom steps to ability templates. With that in mind, custom step classes have been created for adding Animation, VFX and Sounds.
Custom steps serve to hold assets and details about how to execute them. For example, a custom VFX step may define what particle system to spawn, as well as to whom and where it will be applied. This is just one of the custom step classes created this week, but three were made in total:
- VFX Stepper: As we just mentioned, this allows us to trigger specific particle systems at provided locations, on provided entities and at or attached to skeletal mesh sockets.
- Sound Stepper: This allows us to trigger specific sound cues, with options of playing non-spatial UI sounds or to select a location or skeletal mesh socket to play at.
- Animation Stepper: This allows a specific animation (or a list of preferences if an animation isn’t available for a certain character) to be triggered, with the option to continue execution at a specific frame of animation.
Following this, we added an initialisation phase to these steppers so that they will make use of custom steps. Now that this is in place, any stepper has the ability to apply custom steps to its queue of steps. A proof of concept on the workflow of adding custom steppers has now been implemented on the Basic Attack Stepper. Then, in order to test the new step structure:
- Custom Animation Steppers were used for Basic Attacks and Hit Reactions.
- These animations were set on the attacker as well as the affected entity, respectively.
- A ‘generic hit’ custom VFX Stepper as well as a corresponding ‘sword clash’ custom Sound Stepper were then set to trigger between the entities.
Custom Step Factory
Our main focus for introducing this whole custom steps system is to allow other developers and team members to easily and efficiently add their respective custom step classes, or steppers to specific actions. It will also allow them to define custom step behaviour within specific abilities. To really get this system working well for everyone, it needs to be easy to use and should work dynamically – and this is where the Custom Step Factory comes in.
Since creating Ability Stepper templates will be the dev-facing aspect of this system, the process has involved breaking down all the requirements for generating and placing custom steps of each kind, and creating a workflow that allows us to understand what it is we’re asking of them. This led to the creation of a Custom Step Rule class, which allows us to define the:
- What: What asset or custom step type we want to apply.
- Where: Where to trigger this custom step.
- Who: Which entity (tile or location) we want to be the focus of the custom step.
- When: When to allow the rest of the steps to continue their execution.
Custom Step Rules are the working class that is used when defining an Ability Template. This means developers have a choice of blueprint nodes to use when modifying a Custom Step’s behaviour. Once Custom Step Rules have been defined, the specific Ability Stepper that is being initialised will search through each rule, trying to apply their criteria and spawn relevant custom steppers.
Thanks for joining us for this week’s devlog! We’ll see you all at the weekend with more updates on Depths of Erendorn.