This week’s game development update on Depths of Erendorn features new ambient sounds for the game’s Tavern, new VFX for skills and abilities, and some recent screenshots of the world’s environment – which is looking pretty epic if we say so ourselves! We also talk you through our process of setting up a new material customisation system for equipment, including all the challenges we faced and how we’re working around them.
Material Customisation System for Equipment
We’ll talk about the chunkiest update first! Last week, our Character Artist continued working on the material customisation system for equipment in the game. One of the features of Depths of Erendorn will be for players to have the ability to swap their equipment (in addition to customising things like clothing and armour). While we’re really excited to get this up and running, it presents quite a few challenges in regards to optimisation and production.
Features and Challenges
From the start, we’ve heavily discussed and altered the outline of what this system should be capable of according to our production limitations and scope. The aim was to find a balance that satisfies players and would be achievable given our team size. Some key features the equipment material customisation system must have are:
- 5 primary equipment slots (helmet, head, upper body, gloves and lower body)
- Some form of colour customisation specific to the equipment
- A lightweight system to account for the environment, other playable characters, and enemy characters while still retaining a high level of quality
Although these may appear to be fairly simple features, they all present challenges that we’ve had to overcome in order to create a robust system. Some of these challenges include:
Many games that allow for colour customisation achieve it through the use of greyscale base colours, which are then given colour in-engine through the shader. Mask textures are used to specify which areas to apply these colours to.
A great example of this in practice is Warframe, a game where all the characters are coloured using such a system, and where material types that the characters may wear are quite limited. Due to many of our character concepts using a mix of materials (metals, cloth, leather, etc) we would need a minimum of 2 mask textures per equipment. This could greatly compound the amount of textures an equipment set would need.
Number of total material slots per equipment set
As the player will be able to mix-and-match whatever equipment they like according to the customisation slots, we have to constantly assume a worst case scenario where all 5 slots would use different material instances. By itself, this isn’t a huge issue, but it does present some limitations as to how we could assign additional material slots per equipment piece.
As fur/hair and skin would need to be unique material slots, we would have to assume that each equipment slot would be capable of 3 material slots (3 x 4 = 20 slots) plus the material slots used for the base mesh of the head (skin and hair). That’s a total of 21 material slots in an assumed worst case scenario, which means that we would have to limit ourselves breaking up equipment meshes into additional material slots.
Number of total textures
As the game will have a wide range and variety of equipment for players to find and wear, we have to be conscious of not only how many textures each piece is loading into memory, but also how much hard drive space the game would need.
How We Approached the System
During research, we looked at a variety of existing games and how they approached their own systems for customisation, to help gain ideas for how we might approach our own. One stand-out case was Paragon, a game in which characters are fully textured in-engine through the use of carefully authored masks and material assignment through Unreal’s material layering system.
Although their approach was interesting and highly flexible, we decided against such a system due to concerns of production speed and engine limitations. As specified before, with a large amount of characters on screen, our system must be lightweight, and seeing the number of shader instructions per material was somewhat worrying for our use case!
So, based on our research, we decided to approach the system in the following ways:
- A total of 21 material slots: Although that’s quite high, we hope some stress testing will give us insight into whether we need to reduce this number or not
- Base colours: These are to use a mix of greyscale and full colour
- 1 mask texture to allow up to 3 customisable areas: These areas will correspond to the greyscale areas of the base colour to allow for the colour of those areas to be altered
- Detail normals that take advantage of the customisable areas: High frequency normal details need a large texture size in order to read well. By adding this detail in-engine, we can reduce the size of a character’s normal map more aggressively
- Experimenting with the idea of removing ambient occlusion (AO) maps: Because equipment can change, shadow information that would show interaction between these slots is fairly pointless. AO maps, however, could still provide a lot of useful shadow information, which is why this is still uncertain
Additionally, once the current prototype for the shader has been stress tested, we may look at adding the ability to non-descript add dirt/grime and wear through the shader. We’ll keep you posted on how this system turns out over the coming weeks!
The biggest update from Animation last week was the new run cycle that was created for characters holding two-handed weapons. Our Animator adjusted these for the Knight, Watertarg and Earthen Dwarf before exporting, cleaning, and adding them to the engine. Look at ’em go!
Last week, our Environment team replaced all the current wood ends for things like spiked fences with newly created wood end decals, since the original ones had a bit of a harsh seam. They’re currently applying these decals to all the old meshes – it’s taking a bit of time, as there are a lot of assets, but the upgrade is worth it!
We also created our own custom palisades and fence posts for the settlement, replacing all the old unoptimised Megascan assets – here’s a few before-and-afters of the spiked fence!
A few lighting changes were made within the world last week. As a result, we’re now using SSGI, which is slightly more expensive but well worth it for the improved rendering results!
In addition to lighting changes, we:
- Improved the sky so that we have fluffier clouds!
- Made some changes to the trees in the world to improve shadowing at distance
- Moved the starter zone area closer to the settlement and carved in some dirt roads
- Added in new foliage from Megascans and fixed RVT texture flickering
More visuals for level 2 skills were worked on by our VFX Artist last week, including:
- Clear Mind: Means that every spell you cast has a 10% chance of refunding all the Mana cost to you!
- Hardened Will: Reduces your Strength by 20% on the next turn, but gives you back 80% of that Strength reduction as Resilience for 1 turn
- Extra Energy: Allows you to gain extra Energy every 4 turns
- Inspire: Grants allies within a 5 tile radius of you extra amounts of certain Stats for 1 turn, including Reaction Time and Haste
- Jab: Deals Physical Damage to an adjacent target. If the target is a caster, it will also cause their next spell to fail!
- Mighty Strikes: Grants you extra Armour Penetration for 1 turn
- Trance: Restores a little bit of Health, and a little bit more on the next turn – if you avoid getting attacked!
Our Sound Artist spent a lot of last week recording, editing and implementing ambient sounds for the Tavern! Players will find this local pub in the game’s settlement, and will be able to have a mosey around inside. The Tavern ambience will add an extra layer of immersion to this space with the clinking of glasses, the glugging of liquids, and the bustling sounds of the regulars! Take a listen to the new SFX below while having a peek inside the Tavern:
In addition to Tavern ambience, our Sound Artist began researching and experimenting with interesting ways to use and implement sound within the game’s menus and loading screens to increase immersion. They also started working on volume boxes in-game to act as a control for exterior ambience when players are inside. The box will trigger ducking (meaning exterior sounds will be ‘ducked’ i.e. have their volume decreased) so that you have the audible experience of going from interior to exterior and vice versa.
Our Sound Artist also redesigned the wind ambience for the game’s environment. Now, instead of one track playing on a loop, there are three tracks (bass, mids and highs) that play simultaneously while modulating their pitch and volume. This makes the wind sound far more dynamic and natural:
Last week, Programming was spent on preparing the client to record gameplay, resulting in a number of bug fixes and a broad cleanup of ability templates:
- Character Outlines: Prevented toggle UI from switching the outline of dead characters
- Weapon Outlines: Applied character outlines to equipped weapons
- Ability Hit Reactions: Fixed a bug where a single enemy would react to all Damage dealt via ability
- Text Panels: Text panels that appear during gameplay now use a style consistent with the stat panel
- Ability Templates: Worked through generic and class abilities to prepare as many as possible before recording
The final steps are being taken before we’re able to flip the switch and migrate to the Golang server from PHP! So, with this in mind, the majority of last week was dedicated to the unenviable task of AI.
No, these (sadly) won’t mine us any bitcoin. Instead, we had to have a big sit down and figure out exactly how enemies will react in certain situations. Some of the questions we asked ourselves were: What do they do if a Twilight Elf Assassin they’re trying to attack goes invisible? Do they try to hide behind cover if they have spare Movement? And so on.
While the answers to these questions aren’t final, we’ve worked out what we want to happen for now and have implemented these decisions, including enemy Movement patterns and code that allow us to have different types of AI behaviour depending on what we feel suits the NPC best. For example, aggressive animals will behave differently than tactical Bandits.
This work tied in nicely with us allowing the players to also use the newly created move command, since it’s the same one the NPCs use – the only difference is that the clients choose where it takes the players as opposed to the server deciding for the NPCs.
That’s it for this week’s devlog – see you next Tuesday!