This week’s game devlog features a pretty creepy spider animation and, on a very different note, some of the tastiest looking food we could find in Quixel. We’re also talking you through how we’re making a smoother gameplay experience, so stick around for that if you’re interested in programming. As always, daily updates on our online RPG can be found on our Twitter, Reddit or Instagram – now let’s get into it.
Our 3D Character Artist finished sculpting the shapeshifting Zullra this week. These characters are formed from the sand, so its UVs were arranged to ensure that the cascading sand shader we created would flow well – we’ll keep you updated on how this looks once everything’s put together!
Meanwhile, the next enemy on the list was the Magmarai, and we are so stoked to finally see this awesome character come to life. Once a band of overly ambitious humans who were exiled from the Kingdom, Magmarai are creatures that have been transformed by the volcanic fires of Mount Vaznar. They have its lava flowing through their veins, and its rock plating their bodies. This gives them quite a complicated shape, so our 3D Artist used the preexisting human base mesh to speed up the workflow:
- Prominent plates of rock were added on top of various areas of the body to accentuate muscles
- These will also help to reinforce a volcanic aesthetic without straying from a human frame
- A rough stone texture was added to the plates to make them look organic and textural
The areas of the body without any plating will be where the lava runs. All of this will come to life when we get round to texturing this model, but for now here’s the concept sketch for you to salivate over.
The spider, scorpion, and wasp enemies were skinned to their rigs this week. Once their skeletal meshes were cleaned up and exported, our Animator began creating some animations for them all, starting with the spider. The way this enemy moves has been sending shivers down everyone’s spines here at Project Gamechanger, and they include the following sets:
- Idle and walk cycle
- Hit reaction and death animation
- 2 basic and 1 special attack
The death animation in particular gave us some unwanted flashbacks, so if you’re an arachnophobe, you may wanna close your eyes and scroll straight to the next section!
Creating the Game’s First Settlement
The first settlement that will appear in Depths of Erendorn was blocked out in MAYA this week. This is following last week’s initial blockout in UE4, which gave us the lay of the land, so to speak.
In MAYA, we’ve been measuring the buildings and researching some kit building methods. We also had a look into some optimisations that we’re considering making between material/texture draw calls and geometry.
We then carried on creating the assets that will appear in the settlement:
- Wood and metal materials were applied to a bunch of premade props
- UVs were then fixed so that wood grains were the right size and going in the right direction
- We modelled and textured the remaining food items that we couldn’t find on Quixel last time
- Everything was then scaled up so that it would be visible at the player’s camera distance
- Work has now started on a texture atlas for soup, stew, berries, and herbs
- Using a texture atlas will allow us to put these onto planes in pots and bowls
Moving on to the game’s outside environment, we fixed a problem that was causing the terrain material to not properly blend world offset values. In addition to this, we:
- Tweaked the tiling wood material for better use on larger structures in the world
- Updated the environment with physically accurate atmosphere and volumetric clouds
In VFX this week, we decreased the sizes of some projectile on-hit effects as they were looking a bit big in-game. Our Visual FX Artist also changed the effect for one of the game’s generic spells, Tempest, which had been set up to use the wrong effect. Tempest allows you to deal Lightning Damage to enemies in a room, and can be equipped by any of the playable characters.
This week in Programming has been spent creating a smoother experience and exploring possible improvements that could speed up the gameplay loop. There were 5 main things we did to achieve this.
- Refactoring Work
Our Programmers refactored the manager initialisation as well as how game data is applied. When joining a new game, the setup of it is handled by a group of managers that oversee different aspects of gameplay. Previously, all managers would get set up and then listen simultaneously for information to come in about the game.
This refactoring work now causes them to initialise and update in a chosen order. This means we have a better idea of how fast assets are loaded, and what part of the setup phase contributes the most to wait times.
- Staggering Enemy Movements
In order to speed up the turn-based aspect of the game, we have been exploring the staggering of enemy movements. This was one of the possible improvements that was suggested for making player and enemy turns play out in a more fluid, engaging way.
The theory is that on enemy turns, an opponent may make a move towards another tile but, instead of waiting for the movement of that enemy to finish, we allow the next enemy to begin its turn so that there is less waiting time. However, by looking at the client and server codebases, the conclusion has been reached that this method of turn-timesaving has a large probability of causing disparity between what is being displayed, and what is occurring on the server.
- Updating Movement Calculations
As a result of exploring staggered movements, it came to light that movement animations contribute somewhat to the down-time between player turns in the game. This led us to update movement calculations so that they use a character-specific speed.
Characters now have a ‘meters per second’ movement value that is used to calculate movement length. We’re hoping that makes gameplay feel more seamless by reducing the amount of waiting time.
- MoveSpeed Scaling
Another suggestion for improving movement in the game was adding MoveSpeed scaling in order to allow characters to speed up their movement over a certain distance. This means that if a move covers more than x amount of tiles, the character will be able to increase their movement speed to compensate for the distance.
- Improving Ability Templates
To make the gameplay even smoother, our Programmers also added a node to Ability Templates. This will allow abilities to perform directly based on the relationship between the caster and the target. This will mean that it will only be for abilities that can potentially target enemies and friendlies, like Test of Allegiance or Ancient Invocation:
- Test of Allegiance is a Knight ability that can either be used to restore Health to a fellow teammate, or deal Physical Damage to an enemy.
- Ancient Invocation is used by the Watertarg Excursionist and it works similarly: you can either heal a friendly target, or deal Arcane Damage to an enemy.
When we weren’t trying to create a smoother gameplay experience, we preoccupied ourselves with a few bits of important housekeeping, starting with some additions:
- An ‘Item Rarity Info’ class was added to the client. With this in place, we can now have item rarity information in the client for use in things like the UI.
- We also added a ‘Game Item Data’ class, making it possible for the client to understand what an item in the game is.
- Game Item Parsing was an addition that makes it possible for the client to take information sent from the server and turn it into an item for use in the client.
Once we have an inventory manager, Game Item Parsing will make it possible to add all the UI-related things, like items and gear, to the game. This meant that our Programmers had to start setting up the Inventory Manager Class:
- This will manage all the items on a given entity and allow us to add them back into the world
- Once complete, the next task will be to create an equipment UI and entity inspection UI
- Players will thus be able to view their equipped items, as well as their friends’ and the enemies’.
Loot selection should now also be a much faster process after the work carried out this week. This is because we have reduced the number of invalid queries the server can make for finding items to drop in our dungeons. Due to an issue with selecting loot, it was taking a long time to generate levels. By reducing the number of invalid queries, this time should be improved by as much as 400% going forward.
To top off the week, a couple of fixes were made:
- One issue was with the walls in our levels. A recent change introduced a bug that was stopping the client from correctly placing walls. This has now been corrected and our dungeons look great again.
- Another issue was with database replication, and it stopped our databases from upgrading one another. This was leading to some very confusing things happening on the server, but it has now been fixed.
That’s it for this week’s devlog – see you next Friday!