Acerca de

Dev Logs

Sprint one

Art, Audio, and Animation.

Reinventing What the Player Sees and How the Player Feels.

The end of one sprint and the beginning of another.

As the title states, the goal of our first sprint was to reinvent what the player sees and how the player feels. This meant recreating some of our placeholder particles, as well as updating old assets with new models, textures and sounds. Additionally, we took the time to fix old bugs that were plaguing the game from our last quarter and completely recreating the mechanic system of our enemies from the ground up.

The Barrels: Art and Tech

On our rush to Alpha and Beta, many of our art assets were created under the philosophy of get it modeled, get it textured, get it looking good, then get it into the game. We all have high standards for the work we produce, but when time is the looming factor on everyone’s minds, you just have to get it done. The good news is that now we have time, and we are going back and making sure every asset meets our tough standards

Our barrels operate as a destructible that the player interacts with all over the map. They drop sweet little goodies such as ammo and health potions, as well as letting the player feel strong by making them go *boom*. We had an annoying bug in the beginning where the slightest touch, whether it be hitting the ground, or a player or enemy hit, made it explode and drop its items. On top of this, there would be multiple of that item spawning on top of each other. So instead of getting two bullets, you get forty. That was not fun for the player, so a big tech component of our previous sprint was to completely rework the destructible system. The good news was it was a success!

Not only is our destructible system more fluid, intuitive, and polished, but our barrels received an art upgrade as well.

Our Barrels in the new destruction system:

For the new destructibles, we fractured every single one of the meshes in a program outside of Unreal. We then imported every single one of the fractured pieces into Unreal, created lines of code that would spawn them upon damage, simulated physics and applied force equal to what the character applied with the swing. Here is the code for it using Unreal’s blueprint system:

This is the damage event:

It is simple enough. Once a barrel’s health drops below zero, it will run the break event within the blueprint.

This is the code that spawns the fractured pieces.

Essentially, it gets rid of the whole mesh, it spawns all of the fractured pieces, it adds force in the direction of the player swing, and it launches all of the individual pieces. It then turns off collision so when the player steps on a piece, it doesn’t cause the player to rapidly turn or spin from the overlap.

Here are some pictures of the barrels in game:

Of course barrels aren’t the only art asset we finished and they aren’t the only destructible we have in the game. There will also be pots and crates as well as, and we have plans for many other components in our game to be mildly destructible as well.

Our Particles:

Now, let’s talk about particles. Many of our particles were placeholder assets from free packs off of the Epic Games Store. They came in handy in a pinch since none of us have a lot of experience working with particles. Thankfully we gained a new member that actually has experience in this department, and they have been dedicated to creating new particles for us.

From left to right: Swing Particle, Dash Particle, Stomp Particle

These particles will be used in conjunction with the mechanics of our character.

The Tech:

As we already talked about above, one thing we really wanted to refine was the destruction system. Having destroyed items and random pickups everywhere breaks immersion and makes the game seem really buggy. Those are both things that we do not want. So instead of using the destruction system in Unreal, our Tech Director created his own custom destruction system in the game.

From there, he revisited each and every one of our enemies and how they were programmed. We originally were using behaviour trees, of which we found were making our lives more difficult and less effective than programming the enemies ourselves. So the first thing he did was completely rid us of the behaviour trees and restart our enemy code from scratch. The good news is that this has eliminated our enemies from falling into these behavior loops they would get stuck in. No more angels rotating in circles unable to find the player or a Bouncer getting stuck in an explosion animation because the player got out of range at the right moment.

This is the overall blueprint of the base enemy. Here he programmed a mock behaviour tree using basic OOP principles that will provide all the guidelines for how the enemies will operate within the world and with the player.

On Begin play the enemies grab their starting state and begin the roaming event.

Here is the code for the roaming:

This code here sets the player as the target and allows the enemy to rotate towards the player.

This is the code for the enemy to aggro and taunt the player.

This has the enemy chasing after the player. If it is a success, the attack animation begins. If it fails, it clears the target and begins searching for another one.

This is the event run attack animation that pushes the enemy towards the player

When activated, this code clears the target.

And lastly, this is the default attack event that can be overwritten in every individual enemies code.

The Bouncer:

The first enemy that was reworked was our Bouncer. The Bouncer is a floating eyeball that explodes when it gets into close proximity to the player.

Bouncer Blueprint:

Bouncer Explosion Event

The Cherub:

The Cherub is our smallest enemy in the game. The Wisp spawns them from the houses and will continue to spawn them until it is defeated. They deal physical based damage by biting and scratching at the player and will often use swarm tactics to attack. They have low health and damage, but their danger comes from their numbers and speed of attacks.

Cherub Blueprint:

Cherub Damage Event PT.1

Cherub Damage Event PT.2

The Wisp

The Wisp is a long range based enemy that spawns Cherubs from the buildings around them at a rate of one per 3 seconds for every Wisp in combat. Their long range attack is a projectile that does damage to the player on overlap.

Wisp Blueprint

So, the spawn function works by having a sphere collision around the Wisp.

When one of the house blueprints overlaps this sphere, it activates this code within the Wisp:

Which then activates this code within our BP_House_Base:

BP_House_Base Start Spawn Stop Events.png

This starts the spawn timer, allows the enemies to spawn from their class, then stops the spawn when the spawn timer expires. When the wisp is destroyed and the collision disappears, it then calls this code to disable the spawning.

What we are working on now:

In addition to finishing one sprint, we have started another one as well. Our new sprint has a lot of focus on creating new animation using the root motion function built into Unreal. This will give our animator more freedom to create dynamic animations for our player and all of our enemies. In addition we are looking to create some new assets for the game. These include new gates, shingles, ornaments and benches to be placed into our environment.

Sprint 1

Sprint Two

Rough Draft Trailer Video:

Here is our new (Rough Draft) Trailer for our game! Please feel free to take a look and leave any feedback!

https://drive.google.com/file/d/1LZ0Yyo9TQqX3Mao3IxjKJn5kOOAA9vMS/view?usp=sharing

Our Website

Here is the link to our website: https://caliwagco.wixsite.com/heavensshore

We have been looking to revamp our internet presence, and the first step in that is creating a website. Here are a few screenshots of the new site, where we post concept art for the game, host our blog and devlog, features for our game, our narrative for Heaven’s Shore, a team page for everyone that works on the game, as well as the game itself!

Animation:

This sprint has been a big one for reworking the animations for the player, as well as for our main boss. We have begun to experiment with root motion as a way of animating our character. This would open up a lot of avenues for creativity for our animator, as well as add a nice polish to our character. Here is the documentation for it from Unreal if anyone wants to check it out: https://docs.unrealengine.com/4.26/en-US/AnimatingObjects/SkeletalMeshAnimation/RootMotion/

Originally, we were using an animation blueprint and a variety of montages to animate our character. It was successful for the most part, it just lacked refinement. This was our old animation blueprint:

Our Old Attack Animation without Root Motion:

Our New Attack with Root Motion:

Notice how the Capsule moves with the animation. And how the player doesn’t teleport back to where the animation started once it is finished. This will allow our player to move more freely around and not glitch through any walls since the capsule component will always be on him.

Art:

With a new sprint comes a new art update for our environment. Here are a few object we have been working on for the past couple of weeks.

Stalls:

Canopies:

Wall:

Lightning Bolt Particle:

Sprint 2

Sprint 3

Sprint Three

QA:

In an effort to decrease the overall size of our game and increase the game’s performance and efficiency , we have decided to revisit every single one of our assets in the game. Our goal was to optimize geometry, reduce poly count, make more efficient wireframes, U.V.’s, and to generally look for bad geometry that is causing Unreal to struggle.

We have yet to measure the efficiency of our game before this QA phase and after, but when we have some data to show, I will post it within this Devlog or the next one.

Adding every single picture of evern new mesh, wireframe, and U.V. would make this post 50+ pages long, so I opted to place them all into a google drive document you can access here:

https://drive.google.com/drive/folders/17Od9CAGQsZibWxajnxSVvi7j_whsG9zF?usp=sharing

Everything is named so feel free to go and take a look!

Art Bible:

We have placed three of our team members towards the Art Bible and I am happy to say that it is complete! The link if here if you want to view it:

Particles:

Explosion:

Cloud: