Tag Archives: Technical

DevBlog 64 / A glimpse of the water workflow

Hi there!

This week the team was grinding intensively, as we’re slowly but steadily approaching the completion of Chapter 2.

Since our animator has been with us in the office these past days, we spent plenty of time developing, polishing and implementing animations. In particular, the Elk has received quite a lot of attention, and it is feeling more alive than ever.

The artists are busy tackling the arena where the Girl will battle this Chapter’s Boss, as well as painting the texture maps for that character.
As promised before, we’re sharing our current workflow to produce the bodies of water we’ve been featuring lately in this blog.

It’s quite simple, as you can see in the following breakdown:

Small lake mesh workflow.

Shout-out to Paulo from our tech team for coming up with it in the first place. As mentioned in point f), both the ripple effect and the water surface require materials with shader work developed using Amplify Shader Editor. Here are the nodes needed for the water surface (we’ll show the ones for the ripples on a later date, since we’re still perfecting the effect!):

Water surface shader in ASE.

DevBlog 58 / The Ancestor Soldier

Leave a reply

Hi there!

This week we have finished the AI behavior of the Undead Soldier with the new animations, and started testing the group control with various enemies of this type, as well as with the big Ancestor Soldiers. The game model for the latter is already completed, as you can see in the GIF below. While exploring the battlefield area, if the player isn’t aware of the surroundings, several enemies can be triggered to attack. Mind the bodies lying around!

As always, various small bug fixes and small details were added to the code; a feature that was planned a long time ago was finally implemented – the dual weapon logic for the enemies. To put it simply, the enemies equipped with bows will now draw their swords for close combat situations, for example. Lastly, we’ve also added the Ancestor Soldier’s Mace and helmet to the game as wearable player items.

The Ancestor Soldier.

For the larger terrains we’re currently working on, the team has been trying out quick ways to achieve good results. The image below shows our simple pipeline to produce that kind of content, static environment parts. We first come up with a basic blockout of the scene, then we take it to Zbrush and refine the shapes and silhouettes, while keeping the model rough (since most details will be lost in the following step). Afterwards, the resulting mesh gets decimated, using Decimation Master. A little cleanup is often required, but after the UV’s are ready we bring the whole thing into Unity and start giving it life with Vertex Painting.

Workflow example.

DevBlog 55 / The Gate to the Battlefield

Leave a reply

Hi everyone!

In order to make it possible for us to develop interesting environmental puzzles more freely, a simple new feature was added to the Elk. Basically, the player can now command the Elk to stay in a precise location, which will be useful to overcome certain obstacles. After telling the Elk to stay put, it will start following the Girl again if she gets too far.

GET OVER HERE!!!

Meanwhile, another Ancestor Ruin has been placed in the game. This Gate marks the entrance to a very special area in this chapter, but going through it won’t be as straightforward as it might appear.

Alliance Gate.

The high poly model for the Ancestor Warrior is ready, and we’re sure these guys will prove to be quite a challenge. His weapon of choice is very menacing, and we’ll most likely show it in the next update.

High poly Undead Ancestor warrior.

We’ve also added specific idle and running animations that play whenever the Girl is adventuring with lowered stats, something that happens if she gets killed repeatedly. It was our intention to visually convey that the Girl is actually hurt and having more trouble fighting than when she is rested, and we thought a simple message prompt wouldn’t be clear enough. This is meant to work as a reminder of our “stats penalization” mechanic, so players understand why they are taking more damage from enemies and, in turn, dealing less damage to them.

Low stats run behavior.

DevBlog 51 / Performance, Performance, Performance

2 Replies

Hi everyone!

A short devlog this week, ’cause the team is away during Easter. Chapter 2 is going great in terms of art, in the next devblog we will show you some cool screenshots and a glimpse of what the central hub village could look like.
Meanwhile, Andre did a complete revamp of the logic AI system. We were aware of some performance issues that were aggravated with the constant additional complexity growth of the AI. Sometimes, the best way to fix something is to scratch what you have and start again. Obviously a lot of states were recycled, but it’s a different approach in AI handling. In the gif below, using the old AI logic, we could hit an outrageous 25ms time of processing time, now it’s around 1ms. The problem used to happen if the build ran for long periods of time with various AI agents active.

Overcrowded combat – DEBUG MODE not actual gameplay.

Until next week, have a great Easter!

DevBlog 28 / GDD updates and new zone study

Leave a reply

Hi there!

This week, Amplify Creations moved to a new office, so the Decay of Logos team had the chance to improve and complete the Game Design Document of the game, and do a review of the overall production plan. Some minor plot holes were covered and the history was enriched.

Everyone helped but some other things got done obviously. André fixed some pending bugs and he’s working on improving the elk control when mounted and implementing more of Iuri’s new animations.

Pichel is finishing a very important enemy, a very peculiar boss that will have a special video preview.

Tomé did a concept study for an upcoming new zone that we are preparing.

The Rift Windmills.

DevBlog 27 / Dynamics, NPCs and facial Animations

2 Replies

Hi everyone!

André was busy adding some dynamic bones for our characters, and save a lot of time in animations. Small portions of the model like pony tails or small bags now don’t need to be animated so the animation pipeline is more straightforward.

Dynamic jiggle physics, exaggerated effect.

He also added a first version of Audio Occlusion. In practice, the sound is occluded by a low pass filter and the volume is decreased when not in sight of the audio listener. This leads to a more immersive experience, since the player will be able to notice when a sound comes from inside a building or from the outside.

Iuri this week improved the main character’s RIG, imbuing her with a lot more feeling and life. Now we feel like we’re able to convey emotions more easily, which helps a lot with storytelling.

New facial animations.

Pichel is currently working on a very important character, which we will show further down the road. He recently finished up an NPC, a prisioner, and you can check below how the model looks in-game.

Prisoner NPC.

Also check it out our newest WIP gameplay trailer:

DevBlog 23 / Responsiveness

Leave a reply

Hi everyone!

This week’s devblog will be more technical. We will talk about some tests we made on the subject of responsiveness in Decay of Logos. Although this game is not a hack’n’slash, with very tight controls in favor of gameplay, we do take this component into consideration. It has slow paced attacks, depending on weapon classes, but still we are targeting for a fast responsiveness in the controls. In the test shown below, the frame when the anticipation of the animation kicks in will be the end frame measured, and the first will be the frame after the button is pressed. The game was running at 60fps and the video recorded at 60fps. The monitor has a 6ms (Gray to Gray) response time.

You can see that after the button is pressed it takes about 4 frames for the animation to start, and about 10 frames for the actual damage to be dealt (when the trail is visible, damage can be applied). So it’s about 66ms of input lag and 166ms of delay before damage is applied.

For comparison, we measured and made exactly the same test with Dark Souls, using the same machine, with DsFix (for running at 60fps) recorded at 60fps. The results were: 3 frames for input lag, and about 18 frames for actual damage be done. It’s about 50ms of input lag and 316 ms of delay.

We choose a short sword in Dark Souls and a short sword equivalent (our Carved Sword) in Decay of Logos for a more fair comparison.

We also compared the dodge responsiveness (jump back). Again we used the same principles as above.

On Decay of Logos we get about 4 frames (66ms) again of input lag and about 16 frames (233ms). In Dark Souls we get 4 frames (66ms) of input lag and about 19 frames (316ms) until we’re able to perform the next jump.

Another way of measuring this type of things is by attaching a led light internally in the controller and putting it next to the screen for a more precise moment of the given input.

André also made changes in some transitions and blends in animation, which improved significantly the delay felt during combat.

Slowed down video.

More information about this subject, the influences of CPU Logic, Rendering and Input lag can be found here: Programming Responsiveness