October DevLog | Game Development Summary

October has come to an end, and with that we hail in our latest monthly devlog installment! Remember to follow us on Twitter, Instagram and Reddit for daily updates on Depths of Erendorn – but for now, let’s get into what our team have been up to this month.

3D Character Modelling 

In last month’s devlog summary, we took you through how we created our mighty Slayer class for the Daggerclaw Harpies. Well, with the sculpt for this enemy out of the way, we could begin working on a new class within the Daggerclaw Harpy race: the Wanderers. 

With the conflict between their King and Queen reaching a head, the main settlement of the Daggerclaw Harpies is rife with tension and division. Disillusioned by their rulers’ lack of direction, Wanderers are those who choose to leave the main settlement, driven by fantasies of discovering the legendary wonders offered by the far reaches of Erendorn. To reflect this nomadic lifestyle, we added an array of details to the Wanderer sculpt:

• A rolled-up blanket was added to their belongings.
• We gave them a bigger bag where they can keep all of their trinkets and troves, as well as survival tools.
• We showed paper scrolls poking out of their bag, indicating an array of elusive documents.
• The belt was made to look somewhat armoured to show that even these Harpies are always ready to fight.

We could then move on to retopologising everything and baking all the maps, which brought our Wanderer model up-to-date with the Slayer model. With both sculpts ready and raring to go, we thought we’d bring a little life to them with some texture. Starting with the base mesh for the body, we paid particular attention to feather density and how the feathers would wrap around the different contours of the body:

• We used a tiling feather pattern that we created last month to create the feathers on the Harpy.
• To make the feathers appear like they were conforming to the curves of the body, we used spherical mapping, which also helped to achieve a more varied feather density.
• However, the feather density was still a little too consistent even after this step, so we decided to split the body into separate “areas” so that each part would appear a little more varied.

The next important thing to do was to finalise the masking so that the feathers would overlap at the join areas. We could then start adding some colour to the body:

• The feathers were given a warm, golden colour to reflect the majesty of these creatures.
• Green/blue undertones were also added to the skin so that it complemented the feathers without blending in with them.

With the texture for the base mesh complete, we moved onto texturing the various clothes and items of each Harpy class. We wanted the Slayers to have justice done to their elite rank within the Daggerclaw Harpy army, so we immediately knew that we needed a rich and regal colour scheme. 

This idea was manifested in the combination of a deep crimson underskirt, a dark green tabard and an even darker green sash. We thought this complementary colour pallet gave our Harpy Slayer an important, elite appearance, without making them seem royal. We pushed this noble air a bit more by adding a ruby red headpiece, fine metallic detailing around the edges of the tabard as well as an aged-gold crest.

We actually decided to use the same colour scheme for the Harpy Wanderers, using a deep crimson for their skirt and sash and a dark green for their rolled-up blanket. This created some coherency between the two classes – and all Daggerclaw Harpies have an air of importance about them, so replicating this rich colour scheme was an added bonus!

For the details, we:

• Added a deep brown, leather texture to the satchel and waist armour.
• Added bronze detailing to the waist armour, as well as to the belt buckles.
• Made the paper scrolls that Wanderers carry appear old, worn and distressed.

And that brought an end to the Daggerclaw Harpies – but not to our modelling work! Next on the list was resculpting perhaps one of our most recognisable, iconic playable characters from Depths of Erendorn: the Parakaw. If you don’t know what we’re talking about, then you definitely need to join us on social media! 

Recreating our Parakaw is very much a future-proofing measure. When we first made the Parakaw a few years ago, no details had been ironed out about how a character customisation system might work in the game, meaning that we never made a proper base mesh for the Parakaw. Instead, we only focussed on creating the sculpt armature. This missing base mesh has become much more of a high priority issue since our Animator has moved onto a different workflow where they animate characters without their equipment on – so it was about time we fixed it!

After we sculpted the base mesh we continued working on the Parakaw by:

• Placing feathers onto the wings using an insert mesh brush, which saved us some time.
• Adjusting the proportions to ensure that the Parakaw appeared a little shorter.
• Retopologising and unwrapping the entire base mesh.
• Baking the high poly mesh to a low poly mesh to ensure better topology and a lower polycount.

After finishing the Parakaw’s base mesh, we could move on to texturing. We started by setting up a feather pattern that was used across the entire body. To get the pattern flowing nicely, the chest was split up into left and right segments. While doing this, we actually found that the height map was making the feathers look too harsh, so we decided to add a slight blur in order to make them appear more fluffy! In fact, we may do this for the Daggerclaw Harpies at some point, since they look a bit stone-like in comparison.

We will be replacing the original Parakaw model with this new one once it is all finished. Hopefully there won’t be too much rework needed in order to make the existing clothes fit the new model, but it might be trickier than we think so we’re going to have to see how that one goes!

• 

• 

• 

Switching Game Engines

You’ll remember from a previous devlog that we’ve decided to switch game engines. This decision was made due to the fact that our current game engine was hindering our development in a number of ways. If you’d like to know more about what went into this decision, then head over to a previous devlog where we talk all about it. 

After a lot of research and even more tests, we’ve decided to continue building Depths of Erendorn with Unreal Engine. There are a number of reasons that brought us to this conclusion:

• UE4 fits all of our requirements, from better terrain systems to advanced rendering systems.
• UE4 offers great graphics, allowing us to really push the artwork in the game to the next level.
• UE4 is very well documented, unlike our previous game engine where the documentation was a bit unreliable.
• UE4 also provides a lot of integrated tools, as well as having a lot of compatibility with external tools.

Now that the switch is underway, every department is spending some time getting to grips with Unreal. We’ve already started creating new animations, environment scenes and visual effects in UE4, and the results we’re getting are incredibly promising! We can’t wait to see Depths of Erendorn come to life in a totally new way, so make sure you join us over on Twitter, Instagram, Facebook or Reddit to stay in the loop!

Animation

This month, we have had huge success with regard to optimising our workflow in the animation department. Our Animator spent a lot of time researching and playing around with unique rigs for use with our characters. We have decided to do this so that a single rig can be used for every class of character within a given race. This will mean two things:

• Character generation in the game will be faster because fewer rigs should help to reduce the FPS hit when several characters are on screen.
• It will also optimise our workflow by eliminating the need to create a different rig for every character. Instead, a single rig will be produced for use with multiple characters. 

With all that in mind, this month our Animator created a main rig that will fit every class of character within the Human race, from Knights and Sorceresses to Bandits and Beastmasters. We’re able to do this because the main rig can be altered according to each character. For example, to create a unique rig for all of our Elven characters, like the Storm Elves and Twilight Elves, we simply adjusted this main rig before skinning the respectful base meshes and clothing to it. 

We also tested this unique rig out on a couple of different characters:

• Dwarves: more significant adjustments had to be made in order to make the main rig fit the proportions of our Earthen Dwarves and Frost Dwarves.
• Watertarg: the characteristic features of this character, like its ears, were important to add to the main rig, as well as a new set of clothing joints.

To test the rigs, we imported all of the above characters into an Unreal test scene that our Animator created. We then tested all of their walk cycle animations alongside each other. Doing this is important because it allows us to check the deformation on the mesh for all the different characters, as well as all the different classes of characters within a race – in the same way that a Watertarg may deform differently to a Mage, the Mage may also deform differently from a Knight, for example.

Another way we tested the functionality of this unique rig was by importing one attack animation for the Dwarf and one for the Watertarg onto these characters. Both seemed to perform well, and after this both of the animations and rigs were sent to our VFX Artist so that some fancy weapon trails could be added to their weapons – so keep reading to check those out!

Once we had successfully created a single, main rig that could be used to create multiple characters with, our Animator began looking at all of our bipedal character concepts to see what features our main rig should have. With this in mind, more features have been added to the main rig, including bones for the:

• Coat
• Tail
• Wings
• 3 toes
• Back clothing

Now, the main rig – with all of its bone features that suit all bipedal characters (even Lionmen!) – should be able to be used in the engine. The main success to point out here was that all of these character races mentioned today are sharing one, unique rig. Although this rig was adjusted to each race respectively, we view it as a success that we’ll at least be able to use a single rig for each character race in the game.

Environment Art

When we transitioned over to UE4, we thought it would be a good idea to create an environment test scene where we could experiment with creating the viridescent and lush overgrowth that we envision in Erendorn’s wilds. A lot of work has gone into these test scenes to ensure that they are as interesting, diverse and realistic as possible:

• Several variations of pine trees have been created and implemented into the environment. These pine trees have also been through multiple iterations to get them to where they are now:
  • Improvements were made to their leaf cards, increasing leaf density while reducing the overall polycount.
  • The leaf shader was also improved, allowing us to depict richer colours and more realistic lighting.
  • We made changes to the Leaf Master Material so that we could get more variation between all the trees.
  • A Bark Master Material was created to allow for colour adjustments, as well as normal map adjustments.

• Multiple variations of ferns, realistic grass clusters and other pieces of foliage were introduced to the environment test scene, bringing in lots of different textures and points of interest.
• Lighting and post-processing effects were adjusted in the test scene so that we could ensure that we got the most realistic and optimised results as possible. 
• A Rock Master Material was created in order to bring in a higher level of realism to the rocks present in our scene. 
• On the subject of rocks, triplanar detail mapping was added to the Rock Shader and we also resolved an issue that was desaturating the base colour of said rocks. 
• We also added a blend function to the Rock Master Material that will allow us to place moss on top of various objects.

• 

• 

• 

• 

After many tweaks and adjustments, our environment test scenes are looking really awesome, and we love how they are suggestive of the wild overgrowth we want Erendorn to be filled with! But this wasn’t the only bit of work we did this month. You may remember from our social media that we’ve been working on creating a character selection scene for Depths of Erendorn. The first step was to create a digital painting that would show the overall composition and design – and our talented concept artist did a great job with that!

With the painting complete, our Environment Artist could begin recreating this scene in Unreal. They started by blocking out some primary forms for the large-scale mountain terrain that appears in the character selection scene mock-up. To get a general composition of the foreground down, the set was then dressed with foliage and rocks. 

In addition to this, a basic local fog volume FX was created, and this will be used around the environment wherever it is needed. The last bit of work we got round to with this was optimising the rock master material as well as the moss propagation material function in order to improve the realism in these areas. We’re really excited to see our character selection scene come together in this way – but keep your eyes on our socials for future updates!

• 

• 

Visual FX 

The move to Unreal Engine has meant that some team members have had to familiarise themselves with new systems and adapt their work to these new systems. Our VFX Artist is no different, and this month they spent some time getting used to things in Cascade, a particle system used in Unreal. They could then begin remaking a lot of our VFX, all the while researching similar games that use UE4 to see how they’ve handled VFX. 

One thing our VFX Artist has really enjoyed about working in Unreal is how easy it is to make visual effects that are bright, glowing or shiny – but it can be easy to overuse these kind of visuals, which often leads to them becoming quite underwhelming. Our artist is ensuring that they use these effects sparingly, saving them for the moments where they will be the most impactful.

On another note, we managed to recreate a few of our spell VFX this month, including two of the Parakaw Astromancer’s class abilities: Starblast and Black Hole. We first showed off these visual fx in last month’s devlog summary, so check that out to see what they used to look like in Unity!

Another class spell we created VFX for was Thunderstorm. Also used by the Parakaw Astromancer, Thunderstorm gives each enemy in the room a 75% chance to be hit by lightning every turn for 2 turns – so it can be pretty powerful! We used a lightning material to create the VFX for this ability:

• The lightning itself is just a straight white line on a texture.
• We then used a noise texture as a scrolling mask for both the x and y axis at different speeds.
• That way, the lightning will only show up on the white areas of the mask.
• Then, with the mask moving, it will mimic lightning by creating random movements.

The colour and speed of this lightning effect can be controlled in the editor, so we should hopefully be able to use it for lots of stuff besides Thunderstorm! 

As well as doing all this, our VFX Artist also started looking into some environmental effects like fireflies, smoke and dust. We hope to use effects like these to breathe life into our environments, not only in a way that reflects realism but also in a way that captures fantasy. 

Carrying on, after our Animator sent over the rigs of the Dwarf and Watertarg, as well as their respective attack animations, our VFX Artist began setting up trail materials and systems to work with them. These kind of visual effects really bring a character’s animations to life, and multiple textures for different weapon trails were created so that we could find the VFX that brought the most justice to these characters.

After working on a bit of concept art, defining a trail type for each character, we decided to create an almost electric blue trail for the weapons, with glowing specks of light radiating from it. We then created some more buff effects in the way of pops and poofs before adding sockets to the animation skeletons so that we could easily insert the VFX. 

The result definitely brings a fantastical, yet badass element to our Dwarf and Watertarg as they swing their blades – and after our Character Artist added some textures to these models, they really started to come together!

• 

• 

Programming

Now that we have made the decision to switch our game engine to UE4, we can get back to basics! A lot of changes were made to the server this month:

• We created a utility class for reading Data Tables and assigning icon IDs.
• We added a local save to remember players’ login details.
• Server Responses were standardized and all response content is now compressed.
• Disconnecting from the game server should now remove players from any non-started game lobbies.
• A server’s last message to a client with a valid request_id is now cached in case the message cannot be verified on the client and needs to be resent.
• Server responses were updated after the first implementation in order to implement response caching.
• Lobby updates sent by the server now have a disconnect flag to indicate whether the update was due to a player disconnecting.
• We changed the way commands from the client are processed by the servers so that we don’t have to use separate escaped JSON strings. 
• We added a ResendRequest Command for clients to use when we need to re-acquire a corrupted message.
• Cached responses now timeout and are deleted after a timeout period, or upon connection close.
• We continued work on simplifying and improving the game’s communication by allowing commands to pass callbacks with command requests, which ensures that the responses are dealt with correctly. 

In between all this, our programmers began the integration of Unreal’s Data Table assets, which is used or accessing ability information. This new system should prevent the need to constantly transmit data about abilities, thereby optimising our workflow. By keeping a local copy of the database tables and updating them at login, we also have the potential to be able to reduce the amount of communication required for matches to be played.

Moving on, now that we’ve switched over to UE4, our entire UI will have to be remade. While work continues on asset creation for this, like getting the artwork finalised, our programmers have been adding placeholders in order to provide a basic layout for everything. To get these bare bones down, we added placeholders for:

• The main menu.
• The inventory screen.
• The settings screen.
• The lobby browser.

Basic navigation between placeholder menu screens was also added this month. Although our UI is made up of placeholders at the moment, these will eventually be replaced with fully designed, finished assets – so we’re really excited for when we get to see it all come together!

A lot of work was carried out on character selection and creation menus this month. For starters, we added a multi-page character creation screen. This will use server calls to update the client with all available classes and learnable abilities that a player can access, depending on their progression. In addition to this:

• We implemented account character retrieval and parsing.
• We created menu widgets for the character selection screen. 
• We added character creation validation for ability loadouts and names. 

Many improvements were also made to the appearance of the character select screen and creation menus, namely to things like transition animations, the preloading of abilities, the appearance of buttons and the ordering of classes. We also set right-clicking as ‘page back’ on the creation menu and forced a character list update upon successful creation of a character. We also made a few additions in this area:

• We added a ‘last chosen account character’ to local save data.
• We added a ‘delete character’ command and confirmation.
• We added a menu to the test scene for the purposes of camera testing.

With all of this in place, the transition from the character select and creation screens is now much more refined and, to give us an idea of what these screens look like in an actual scene, our Programmers simply duplicated an environment art scene that we’ve been working on and used this as the background. This scene will act as a placeholder until our Environment Artist has finished building our character selection scene in the engine.

• 

• 

On a separate topic, a lot of work has gone into setting up the project for packaging – and with great success (after a few issues, that is). We’re now able to create builds after tracking down the source of a dependency issue, so we’re really pleased with our progress in that area. We have also created an input manager for defining and dealing with keybinds. This means that players can now rebind actions through the settings screen. New keybinds are also now added to the local save data and can be reset the same way. 

Meanwhile, a lot of time this month was spent on the lobby controller:

• A placeholder lobby screen was added.
• We also resolved a bug that kept breaking the browser. This would happen every time we updated the list after making a new lobby, so we were happy to get that sorted.
• We added a new Game Entity data structure as well as a new Lobby Data data structure to the project.
• This Game Entity class will hold character information not only for the lobby screen, but also for game scenes.

Stats and helper functions were also implemented so that we can manipulate and retrieve stat information for a Game Entity. While this is not needed for the lobby screen, it will be used extensively elsewhere in the game – like in the inventory/character information panels, as well as in the game scene itself.

Even after all of this, some work still needed to be carried out with regard to Game Entity parsing, and several changes still needed to be made to the lobby: 

• When loading into the lobby, some actions were being performed twice, which was causing some issues. This has now been resolved.
• We added some missing properties to the Game Entity class before adding parsing for these missing properties.
• Parsing of the Game Entity class was moved into a separate class, which will be used for parsing different data that is accessible everywhere. This will make it easier to maintain and use in different parts of the codebase.

With all this in mind, it is now possible to start a game once all players are ready – and certain text elements, some of which had their size increased, now also better reflect the current state of the lobby. It truly has been a colossal month for our Programmers – and the team in general! – but we’re excited to see what November has in store for us!