December DevLog | Game Development Summary

Welcome back to another devlog summary – and happy holidays! We hope you all had a nice and relaxing break. In honour of the New Year, we thought we’d do another wrap-up of all our work this month. We know that 2020 is going to be a huge year for Depths of Erendorn, and we can’t wait to see what it has in store for us – but for now, here’s a glimpse into the past!

3D Character Modelling

We worked on a lot of different things in the 3D modelling department in December. From finishing up the Frost Dwarf Guards to changing our entire UV unwrapping process, saying our Character Artist has been productive is an understatement!

Modelling Dwarven Guards

As we mentioned in our last devlog summary, we started this month by finishing off the sculpt for our Frost Dwarf Guards! These are hardy enemies in Depths of Erendorn whose small stature is quite misleading – so bear that in mind for when the game is launched!

The most fun part about modelling these NPCs was designing the horns for the helmet, which our Character Artist had a lot of fun experimenting with. Once a design for the horns had been finalised, we moved on to the fur pelt, an item donned by many of our previous classes of Frost Dwarves. To speed things up, our Artist actually duplicated the fur collar a few times before manipulating its overall shape. 

Then, after retopologising and unwrapping everything, we could begin texturing:

• Metallic texturing was added to the helmet and, for the High Guard variation of this model, to the studded cuffs that are seen around the boot.
• Before starting on the cape, a few colour tests were carried out so that we could find the best colour for it. In the end, we chose a dark, warm brown colour to complement the tunic. 

Finally, the fur pelt was projection painted with the same fur texture that is used on our Glacial Boar model. This is something we do with every Frost Dwarf character, since their lore dictates that this race relies on the Glacial Boar for many aspects of its survival. From clothing and food to labour intensive tasks, we really wanted to imply how much Frost Dwarves rely on the Glacial Boar – and we think that incorporating the Boar’s fur texture into their fur pelts is a nice little easter egg for this! 

• 

• 

Modelling Civilians and Merchants 

With the Frost Dwarves modelled and out of the way, our Character Artist began work on the Human Civilian and Merchant classes. Players will come across these NPCs as they explore settlements and wander through Erendorn, and will even be able to trade with some of them.

These characters are really defined by their clothing and accessories, so it was important for us to reflect their lifestyle in their overall design. The Merchants, for example, are quite nomadic individuals who can be distinguished by the mass of collected items that they carry on their travels. Therefore, we included a vast range of accessories in their design, including:

• A large backpack, the insides of which were also modelled in case we ever need it as a prop. 
• A rolled-up blanket and pots and pans, as an indication of their nomadic lifestyle.
• A few potion bottles, to signify the kind of special items that these characters carry. 
• A sack where the Merchant could keep their gold coin, or other collectible items.

Furthermore, we want our Merchants to have some variation between them when they come to be implemented into the game. To do this, our Character Artist modelled the clothing pieces in a  way that would allow them to be part of our future customisation system. While players won’t be able to customise NPCs, it will allow us to have some randomly generated designs for the Merchants so that they don’t all look the same.

UV Unwrapping Process

Whilst everything was being retopologised for our Civilian and Merchant, our Character Artist took the time to actually change the UV unwrapping process for characters’ clothes and equipment. They did this for one main reason:

• We are planning for many characters in Depths of Erendorn to be customisable in the future, meaning that players have the option to change clothes, armour, facial features, etc.
• To accommodate this, our Artist has created characters so that they can be broken up into modular pieces that, during the customisation process, can then be swapped out for other pieces.
• The biggest hurdle when doing this was figuring out how to group clothes/equipment and UVs/textures together in a way that was efficient at run-time but still kept a high level of quality.

In the past, our Character Artist had tried to group together the UVs of pieces in keeping with what ‘series’ they would be a part of. For example, the Frost Dwarf Guard equipment is all grouped together in a single UV. However, this method could cause a few issues, the most prominent being that it sacrifices efficiency at run-time. This is because, due to the customisation system we’ll be introducing, it will behave as if the player is wearing equipment from various different ‘series,’ resulting in a large number of textures that need to be called.

Another issue often found came in the form of editing existing equipment UVs and textures. Any time something has needed editing in the past, the entire outfit’s UVs would need to be carefully edited to avoid issues such as texture overlap, which would often increase the amount of time spent on making minor changes – and, when it gets to crunch-time, this is an area we’d prefer to have streamlined!

Luckily for us, our Character Artist has found that the solution to these issues is to change how UVs are approached for equipment pieces:

• Equipment UVs will now be based on the ‘customisation slot’ rather than the specific ‘series’ that the equipment would usually be a part of.
• This means that equipment will no longer be grouped together. Instead, only pieces that share a customisation slot will share a UV tile.
• Once in the engine, we can resize and compile these into single UV tiles for a faster, more efficient performance.

Through all of this, we will be making the textures as modular as the meshes they are attached to. This way, we will not only have increased efficiency at run-time, but we will also have streamlined what was previously a rather awkward process.

Animation

Our Animator spent this month by continuing to transfer and update characters’ animations from the old rigging system to the new unique rig we created in October. This was done for many character classes within the Human race, like the Knight, though we also gave some TLC to the Earthen Dwarf. Some of the animations worked on included:

• Walk Cycles;
• Two Basic Attacks;
• Basic Idle and Combat Idle;
• Punch, Drink and Death Animations;
• Idle with One-Handed Weapon Equipped;
• Idle with Two-Handed Weapon Equipped;
• Equipment of One and Two-Handed Weapons

In addition, our Animator also created a new spellcaster pose and ranger pose, which were added to the Human combat idle – and, since we now use the same base rig for all bipedal characters, we were able to test these on different classes of characters within the Human race such as the Mage and Bandit. We also updated the ‘equip’ animation of two-handed weapons, like the sword, mace and axe, before testing these updates out on the Human Knight by having them perform a basic attack using one of these two-handed weapons. 

Once we had updated the respective animations and skin weights, we exported the main unique rig that all bipedal characters will use in the engine. The rig for the Human and Dwarf classes was then exported, along with a set of animations for both character races. After this, our Animator:

• Baked each animation onto the rig.
• Deleted unnecessary animation keys, like static and redundant keys.
• They then finally exported everything as an FBX.

The next step is to import these characters and animations into the engine so that we can test them all out to make sure that the animations perform well with the main rig. We will eventually be doing this with all bipedal characters in the game so that they all make use of and function well with the unique rig we’ve been creating over the last few months. 

• 

• 

Environment Art

In last month’s devlog summary, we started building a Cave Dungeon test scene inside Unreal so that we could begin developing the underground world of Erendorn. Continuing on with this work, we decided to introduce a few new things in order to push the dungeon to the next level:

• A modular pillar spline system was implemented, enabling us to create many different versions of pillars for our dungeon. 
• Clusters of glowing mushrooms were also added in order to bring a fantastical element to this otherwise ominous atmosphere. 
• The glow effect of these mushrooms was also improved so that it interpolates between two emissive colours, adding a much more ethereal look. 
• The water spline system we introduced last month was also improved so that it refracts light from submerged objects, making it much more realistic.
• Two species of bioluminescent plants were brought into the Cave Dungeon for added points of interest, as well as to push the fantasy element even further.
• Local particle fog effects were added to the scene to make it more eerie, and the lighting was also changed so that the dungeon would appear less warm.
• Cave doors were created and implemented, alongside some bone pile decals so that we can give the subtle implication that this is a dangerous, sinister place. 

The most exciting change made to our Cave Dungeon test scene came in the form of some brand new crystals! If you’re an OG, you may remember from our older devlogs that we used crystals throughout our dungeons. Since switching game engines, and since revamping our environment overall, we decided it was time to create a new crystal material that was more transparent, refractive and realistic. 

To do this:

• We created two variant crystal Blueprints.
• Each of these contained light sources of their own.
• This gave a unique quality to every crystal. 

In the future, more Blueprints will be made so that we can diversify our crystal family and really have some fun. Improving our crystal was a really exciting project because the type of lighting they lend to our environment is essential in producing the eerie, yet fantastical atmosphere we’re aiming for with our dungeons. 

• 

• 

• 

• 

Visual FX

We polished off a lot of VFX this month. Not only were the effects for Heaving Blow and Drain Life completed, two generic spells and skills also received some visual TLC. Lightning Bolt, a spell that deals Lightning Damage and stuns enemies, had a few tweaks made to it; and Headbutt, a skill that deals Physical Damage, was also finalised. 

New and improved buff effects were also created for:

• Impair: Commonly used by characters like the Earthen Dwarf, Human Knight, Watertarg and Twilight Elf Assassin, this generic skill allows players to choose and literally impair an adjacent enemy, reducing their Movement Speed for one whole turn. 
• Cripple: This is a generic spell that actually causes a targeting enemy to lose some Strength, making them easier to attack by weakening them.
• Fast Healing: Another generic spell used by the above characters as well as the Forest Druid, Zentragal and Parakaw, using this allows to player to gain some Health Regeneration for that turn.
• Restraint: Utilised by the Knight and Twilight Elf Assassin, Restraint makes it so that any remaining Energy from the current turn is added to the player’s Energy Regeneration in the next turn. We decided to show this as a luminous ring of amber light that spreads from the centre, eventually breaks apart and dissolves.
• Rage: Used by the Earthen Dwarf, Rage increases a player’s Ability Power and Strength for one turn, as well as increasing their Maximum Energy for the rest of the dungeon they find themselves in. This is an awesome skill, so to balance it out we made it so that the Energy gained from Rage can only be obtained twice. Rage was shown as a red shockwave that bursts out and around the character, with anticipatory smoke and trailing particles to imply its power – though it’s still very much a work-in-progress at this point!

We then started working on Spike, which can be used by the Parakaw and Zentragal to deal Arcane Damage to opponents – though using this spell comes at a risk as there is a 10% chance it will hit you! As well as this, a quick effect was made for a counter attack. Our VFX Artist actually took inspiration from the Pokemon ‘protect/detect’ skill by using a little glint that appears when a player has successfully countered an attack. 

Our Visual Effects Artist also began working on the VFX for Ice Storm, a generic spell that deals a significant amount of Frost Damage to enemies within a 6×6 area. But it doesn’t stop there – enemies affected by Ice Storm also lose a small amount of Movement for one turn, giving the players an extra advantage in battle. 

To do justice to this awesome spell, our Artist created luminous shards that rain downwards, colliding with the floor before before ‘dying’ one by one. This was a big improvement from the original test, which had them simply phasing through the floor. An AOE circle was also added around where the shards impact the ground, giving it an extra bit of detail. 

• 

• 

• 

Programming

Even more work was carried out on level generation this week. Rules can now have input to make the system more flexible – this will open it up to future modification with more interesting generation patterns. Further to this, many improvements were made to level generation this week:

• Level generation now includes doors.
• Room events are now re-implemented into level generation.
• We refactored the way that the server handles room data in the level generation. 
• Doors now store spawn locations. This information was originally missing from the serialisation function.

Our Programmers also managed to improve performance with pathfinding by making it so that each tile in a room now has its walkable neighbours pre-calculated. Improvements were then made to the Set Piece system for the room builder. By adding the capability for doors and other gameplay necessities, it allows us to include any number of additional environmental objects we might need when setting a room up for gameplay. It also allows us to disperse them dynamically across the generation map. 

In addition to this:

• Rotational data is now recorded for Set Pieces.
• Enemies and loot were added back into level generation.
• Tile types and behaviour for door and spawn tiles were added.
• Adjustments were made to how spawn locations are recorded.
• The server can now rotate a Set Piece depending on what area of the level it lands in.
• We also added flood fill to the room builder in order to remove any unwalkable spaces.

All of this continues our efforts towards level generation, which our Programmers have been working tirelessly on for the last couple of months. But we didn’t only work on level generation in December:

• We added a base character class and created placeholder character classes for playable characters and NPCs. 
• Gameplay classes were added for Tiles, Rooms and the Room Manager, which will be used with the room builder class. These classes and functions will form the core of the data representation of the level in the client.
• The ability for set pieces to be designed using our UI was added, allows us to generate information about potential spawn locations. 
• Using this tool, our artists will be able to create grid representations of complex, authored set piece objects This grid representation will then be exported for use on the server. This system allows us to have beautiful authored set pieces embedded into our levels, which are procedural. 

Our Programmers also spent some time setting up core gameplay elements, like creating a system for storing and referencing character assets and associated data. Other gameplay elements added this month include the ability to spawn and pool character blueprints, as well as the introduction of class character model swapping to the character selection and character creation menus. 

Before this, all we had in terms of gameplay was data from the server. After all of the above work, we now have in-engine classes that can hold and do things with that data, so we’re pleased to see it all come together in this way.

The last bit of work our Programmers cracked on with before the Christmas break was a bit of bug fixing, so that they could have some peace of mind over the holidays:

• Door-spawning locations were fixed.
• Fixed a bug related to the placement of Set Pieces, which prevented them from spawning.
• The Set Piece object structure was changed, and Set Piece objects were then recreated.
• The outer-edge of a room that is generating is now surrounded by a wall whilst it is generating.
• This outer-edge is also no longer changed or affected by the Cellular Automata steps.

• 

• 

With all of this work boxed off, we have a nice, steady foundation to start the New Year with – so we’re eager to see how it will evolve over the coming months! We’ve already kicked off 2020 with a brand new VFX and a freshly textured set of models, so come and check those out with us in our first weekly devlog of 2020!