The Storm Elf Javelineer is complete, new props and cave entrances have been added to the environment, and our Drovals are sounding pretty gnarly with their new vocalisations. We're talking about it all in this week’s devlog - but before we get into it, remember to follow us on Twitter, Instagram or Reddit for daily updates on our online RPG!
3D Modelling
This week, our 3D Character Artist finished off the Storm Elf Javelineer that they were working on in the last devlog. After sculpting, retopologising and unwrapping the model, they moved onto texturing it in ZBrush:
- Dark blue, the characteristic colour of the Storm Elves, was used to texture the Javelineer.
- Silver buttons were used as a subtle piece of decoration all over the armour.
- The surface of the armour was also given a mottled texture to make it appear aged or battleworn.
The model was finished off with some placeholder hair so that we could get a complete feel for the character. We’re obsessed with the final result of the Storm Elf Javelineer, a powerful enemy in Depths of Erendorn who can hone devastating lightning magic.
Animation
Animation Controller blueprints were created this week, as well as animation blends for several of our NPCs. A few animations were then added to their respective characters in the engine, where most of our Animator’s work took place:
- The Watertarg’s Animation Controller was updated by adding a second spell state that used Cast Effect animation.
- The Lionman was reimported into the engine in order to reduce the number of materials that were originally imported.
- Materials for newly added NPCs’ SK meshes were applied, and a lot of abilities were added to the enum script.
The rat, a low-level enemy from the game, had the most work carried out on it. Our Animator exported the rat SK mesh along with its animations and added them to the engine. Animation blends were then created for the rat, as well as an Animation Controller blueprint.
Environment Art
Asset Creation
A few new urn assets were created this week and imported into a UE4 test scene. When creating these props, our Junior Environment Artist made sure to keep their lids as separate meshes. There are two reasons for this:
- It will aid in future animation, allowing us to easily open and close the urns.
- Keeping the lids as separate meshes also means we can use them on different bases and create even more urn variations.
As with the assets from our last devlog, more destroyed versions of urns and tombstones were also created. The destroyed versions were then put into blueprints with decals projecting damage onto them. This means they can be dragged into the level as one object, making for a way more efficient implementation process.
Weapons & Caves
This week, our Environment Artist rebaked some placeholder weapons from an old project. These were created a while ago, and were implemented into the engine this week to check how they looked against the new props. Swords and weapons won’t only be used by players and enemies in the game, they will also be used as set dressing pieces to bring interesting details to the environments.
In addition:
- Following from our work last week, cave rubble mounds were created and implemented.
- Similarly, 100 cave rubble rocks were also created and implemented, adding a ruinous quality to the caves.
- The cave wall material was refined so that we can add colour variance to meshes based on world position.
Moving on, cave entrances were created in Houdini and implemented into the engine. Before this, we hadn’t seen what a dungeon would look like from the outside environment, so we were really excited when this came together.
Visual FX
Our VFX Artist spent most of this week double checking abilities that had been fixed, and then testing them in different situations to make sure they were performing properly. While they found a few minor bugs, the results were, overall, really good.
Our Artist then made a note of certain effects that were too small, too big, or that spawned weirdly. We will start working on fixing these in the coming days so that as many visual effects as possible are working in the engine.
Sound Design
Now that most of the sounds have been implemented into the engine's ability system, our Sound Artist has began testing with our VFX Artist. This involves them going through all of the BPAs and checking them against our Programmers’ examples of how to fix any minor bugs. They’re making notes of anything that will require a bigger fix, but there’s quite a lot of stuff working in the engine now so it’s looking good!
At the start of the week, our Sound Artist made some vocal work for the Parakaws and the Drovals:
- Parakaws have a delayed vocal layer at a slightly different pitch playing behind the main voice. This gives an extra chorus layer and a feeling of magic, which ties in nicely with their spellcasting ways.
- Drovals are a combination of wolves, dogs and coyotes, with a vocoder played through to add some extra character to their voice. All of these layers making them sound particularly savage and unique.
We didn’t want the Drovals to sound too human, nor like just a dog. We were also concerned that they might sound too similar to the wolves from the game. But, with all the different combinations and layers of sound, our Sound Artist has managed to bring a really unique vocalisation to this enemy class.
https://doe.horus.ninja/wp-content/uploads/2020/07/Parakaw-HitReact-Mixdown.wav
These are the draft sounds for the Parakaws' hit reaction.
https://doe.horus.ninja/wp-content/uploads/2020/07/Parakaw-Attack-Mixdown.wav
These are the draft sounds for the Parakaws' attack.
https://doe.horus.ninja/wp-content/uploads/2020/07/Droval-Hit-Reaction-Mixdown.wav
These are the draft sounds for the Drovals' hit reaction.
https://doe.horus.ninja/wp-content/uploads/2020/07/Droval-Attack-Mixdown.wav
These are the draft sounds for the Drovals' attack.
Programming
This week, our Programmers added functions to create and update a Depth Map from a specific tile type. Using this, we are able to create a representation of the grid that maps out each tile as well as how deep it is in a group of tiles.
We have done one for the placement of internal walls, and now we will use it with the floor, too. This way, we can find localised centre points in different parts of the room; and, using this data, we can then inform prop placement and set dressing pieces.
Other things worked on in Programming this week include:
- Helper functions were added to retrieve the floor offset in any point of the room. Previously, it required using several blueprint nodes, whereas now just the one is required.
- Collision was turned off on the grid. This was done because of a setting that was causing our players and enemies to walk on top of the grid rather than on top of the floor.
- Several wall placement bugs that were causing small cracks and holes to appear in certain cases have been fixed.
- Some bugs with ceiling placement were also fixed. Now, there shouldn't be any holes in the ceiling and there should be fewer meshes used to create it, which should reduce the performance cost.
- A method for working through ability templates was simplified and explained to ensure that they are triggering the right assets in the correct order.
- Working with our Animator, our Programmers determined the structure and method of setting up NPC Animation Controller blueprints.
Our Programmers also made the output of our room information export easier to debug, and started on procedural light placement, as well as prop placement. For the latter, our Programmers developed a system for relating collections of props into 'Families.’ Each Prop Family can define a set of props that can be used in a variety of different ways in order to give consistency to our generated environments.
They then created a Prop Volume blueprint that takes a Prop Family and identifies its suitable locations within its boundaries where Primary Props (i.e. the largest in a Family) can spawn. After the primary props have been placed, the blueprint will then select a Secondary Prop from the Family and place them radially around the Primary. The same process occurs again with Tertiary Props.
Thanks for joining us for another devlog - see you next week!
