Hello everyone, welcome back!

How time flies... it’s already been a little bit over a month since the Game Jam and our first version of Deathlike! We are excited to show you our progress during this last month. We’ve been working hard to implement your feedback and fix a TON of bugs as well as implementing new mechanics for player movement and game progression. We also worked on a bunch of visual stuff, balancing (which has been really difficult to do right) and a lot more, so get ready, grab a snack and let’s get started:

More Props

What’s a game about death without a graveyard? That’s right, we’ve been working on a new set of props to integrate in our levels. The idea is that these gravyard spots will function as player spawns in each stage. We thought this made sense since our player works for the God of Death. This is still a work in progress but we’d like to show you how it’s going so far.

Models in Blender

Result in game with textures and post processing

New Textures

We didn’t quite like the previous textures we were using and most of them were just randomly picked and found for free online. Textures are an important aspect for conveying appealing visuals and it’s one of the first things that pops up to the players eyes, so it’s extremely important to keep consistency in style and quality. Our previous textures didn’t have that...

Thanks to some useful tools, we managed to find a work pipeline that suits our needs! There’s an interesting and really important concept when it comes to textures which is called Texel Density (or also refered as Pixel Density). The name is self explanatory and it pretty much means how many pixels a texture has per centimeter, which can make it less or more blurry.

We found this neat Texel Density Checker tool for Blender that does the job for us. We just need to provide the texture resolution and then the tool just calculates the density!

We are pretty happy with the results and we were able to fix some of the inconsistent, ugly and boring textures we had before. We were also able to freely create some variety to the scene by painting multiple textures over certain objects, like adding moss to bricks and dirt and leaves on the ground:

In Blender

In Unity

Earlier version had less variety and less consistency

New UI

The UI is finally getting some attention as well. We included the following additions/changes:

• Reworked the layout for the altar shop (removed souls price requirement);
• Reorganized the settings UI;
• Fixed some anchoring to adapt for different resolutions;
• Added wave info in the player HUD;
• Added a useful stats UI that shows the current player stats;
• Stats also update dynamically in the UI while hovering over upgrades;
• Added settings to control bloom and flash intensity;
• And finally... no more boring placeholder boxes, we’re adding some visuals to our UI, tailored to also work with the rarity system!

New buttons and icons for the upgrades to represent different rarities

New main menu background

Altar shop rework

Before

Now

Settings for bloom and flash

Wave info

Stats UI

Stats being updated

Game Progression Balancing

As you may have noticed from the above gifs and screenshots, we have also started implementing more stats/abilities along with their respective upgrades. Our aim with these is to add more gameplay variety and player choices as well as fix some game progression issues we had earlier, particularly with the Luck and Difficulty stats we will talk about later. These are the upgrades or abilities or skills or stats (or whatever you want to call them, we don’t judge) we added:

Luck

Luck gives you... well... more luck! The name is pretty self explanatory: with more luck you get better chances to get greater and rarer upgrades. The idea is that the player will both be able to get more luck through upgrades and even more base luck each wave he wins (for example, each time the player decides to go for the next wave, the luck goes up). This way, the player gets rewarded the further he goes in the game instead of having no kind of incentive to move on.

Difficulty

Another feedback we received is that the game should get harder if you get upgrades and sacrifice yourself (makes total sense). We didn’t have that before which led to players exploit the game by getting stuck in a constant loop of sacrificing and getting upgrades in the first wave only. This allowed them to stack upgrades and get extremely stronger than their enemies. So we added a difficulty stat that goes up the more upgrades the player gets. Our aim is to provide a challenging gameplay even if the player keeps getting upgrades.

We understood that earlier versions had a huge problem with progression so we hope this can fix part of the issue along with the Luck system. We want to make it so the sacrificing option can be a hard choice for the player and not as obvious as it was before. Sacrificing and getting upgrades may not always be the best option now, so chose wisely.

And even more skills/upgrades...

Dashes

Yep, you heard it! Now you can dash away from your enemies quickly repositioning yourself and avoiding threats.

Pickup Range

Now you won’t be able to pickup souls like before. You’ll have to walk near them. We did this so we could also implement a new upgrade that adds more pickup range for this purpose.

With no pickup range

With 10 pickup range

More Animations and Feedback

We also felt the game was lacking animations and things were a little too much static and lifeless so we added more animations like...

Weapon Bobbing and Camera Sway

Before it was boring and too static

Now it’s much more lively

You can also notice that we added a clearer version of the tome. Now it looks a lot sharper and less blurry.

Animation Based Attacks

We also made it so the attacks are based on animations and its speed, only triggering the shooting action in specific frames. So now the attack speed is also linked to animation speed and looks more natural.

Before, the attacks were separated from animations

Now, the shooting is based on animation events

And with faster attack speed...

The same applies for enemies and they also have a new attack animation! This also fixes an issue where enemies would start spamming bullets right away which seemed unfair and weird:

Before, enemies had no attack animation and looked more “static”:

Now, they have an animation based on their attack speed (as well as a little floating animation). We also made the projectiles bigger and the shooting speed a lot slower so they feel much more balanced:

**And the tome also has a little pickup animation!

**

Before, no pickup animation

And now

New VFX

You also may have noticed that we changed some of our VFX in the game. We also made it so we can add a pixelation effect over them by creating a simple little shader (thank you Gabriel Aguiar!).

For the more technical people out there, what this shader does is taking the UVs of a texture and snapping them to a grid so the final sampled texture looks pixelated. This is achieved by rounding the UV coordinates into whole numbers forcing nearby UVs to sample from the exact same point (for example, a UV coordinate of (4.8, 7.4) would output (5, 7)).

By multiplying and dividing by a “Bits” value, we can effectively control the intensity of the effect. It essentially controls how many pixels “wide” the effect becomes, so:

• Higher Bits = More Samples (Smoother Texture);
• Lower Bits = Fewer Samples (More Pixelated Texture)

The result (old vs new tome VFX)

And the campfire...

Now with adjustable pixelation!

Enemy Behavior and Spawning

We did some adjustments to enemy behavior and how they spawn and follow the player. We felt like the enemies were sometimes spawning a little bit too far away which could break the flow of the game by forcing the player to quickly switch from “combat mode” to searching enemies around the map.

We want to keep the fast-paced gameplay flow as much as we can and being interrupted by this can compromise the dynamic so we decided to change the spawning rules a little bit.

Previously, we were picking a random spawning point from a list of fixed spawning points placed on the level. Given the fact that our stages will be quite large and open spaces (generally), we quickly understood this was not the optimal solution, so instead, we opted on spawning the enemies around a radius from the player within a minimum and maximum distance so they don’t spawn “on the face” or too far away.

**Technical explanation incoming... **

We already briefly explained how we were doing it before... but now? Well, to put it simply, we are sampling random positions based on a minimum and maximum radius around the current player position (basically a walking circle). Inside that circle we check for valid spawning positions for enemies. For this last part, we sample a random position from the Unity’s Navmesh that is baked into the scene. This allows us to avoid expensive collision checks whenever we want to spawn enemies, since the Navmesh is already placed in valid areas in the first place!

And what’s a Navmesh? It’s essentially, as the name implies, a mesh generated on top of certain surfaces used for navigation data for our enemy AI. It simply tells them the positions that are “walkable” and that they can reach.

We also had some issues with the navmesh before, making some enemies have a brief existential crisis stopping to follow the player and shoot him. This was due to some bad geometry we had in the level that was generating a faulty navmesh. That had to be fixed so that the new spawning system would work as well.

Fixed Navmesh (blue areas are walkable by the AI)...

We also fixed a bug where enemies were endlessly following the player without stopping leading on them sticking to the exact players position, which could be quite annoying:

Now fixed...

And more small adjustments/fixes!

We’ve also been adjusting some small things here and there to make the game feel more natural and impactful (some of the things based on your feedback as well!):

No more lame jumps (and better gravity)!

We adjusted the player jump to be more impactful and we also made the gravity more intense to avoid making the game feel “floaty”:

Now...

We also fixed crouching so the player can’t uncrouch under objects and clip through them:

Clipping through objects

Not anymore!

We have improved the walking audio loop so its speed is now dynamically changed based on the players current movement speed.

Before, the walking loop was always the same

And now it’s dynamic

We fixed an issue with certain audio being muted when A LOT of audios were playing at the same time. (Basically, Unity limiting audio per frame).

WARNING! A LOT OF NOISE

Previously, the audio was getting muted

But now it’s fixed (careful it’s really loud)

Talking about spamming projectiles...

Object Pooling

Games like Deathlike can scale up to stages where things start getting too chaotic and where there are a lot of stuff spawning simultaneously. First thing that comes to mind are projectiles, as we’ve seen earlier. The player and enemies can end up spawning hundreds of projectiles and objects per second which can stress out the PC. The tasks of spawning and destroying objects can end up consuming a lot of processing power due to something called Garbage Collection, something that Unity has.

So Garbage Collection is actually important. It’s basically the process of freeing up memory previously allocated for certain objects that, if not deallocated, can cause serious memory leaks and compromise the games performance. It’s like whenever you study for your exam only to remember the answers for the day and then completely forgetting almost half of it right away (don’t lie, we all did that... right?). Garbage Collection is doing the same thing, except doing it too often slows the whole game down.

That’s where Object Pooling comes in. So what is it? Essentially, with object pooling, we are not really destroying the projectiles and ALWAYS creating new ones. We actually deactivate them whenever we don’t need them anymore and putting them into a sort of “Waiting Room”. This creates a queue of inactive objects. We can later reuse them by grabing one of them from the queue and reactivating them instead of creating new ones.

This saves up a lot of processing time as we don’t build up as much “garbage” for the Garbage Collector as if we were constantly destroying and respawning them again.

**Muffling Music **

Now the music gets muffled whenever the player opens the pause or any other menu:

Altar Menu Bugfix

Previously, there was a bug that activated the spawn menu at the same time as the altar menu and allowed the player to unpause the game while still in the altar menu. This was due to some unclean code we had before that’s now more neatly organized and cleaned.

Bugged Altar Menu

Now Fixed!

Centralized Systems

And last but not least, we also refactored and cleaned the majority of our code by using a more centralized method where all the more generalized logic is handled in specific managers. This allows us to have better readable code and have things more neatly organized so that the configuration and setup doesn’t take as long (or so that we don’t have to search for certain things all over the place).

We have also packed up all the important data and placed them inside their respective Scriptable Objects (which are pretty much objects that function as databases to save/load the global game related data, player data and enemy data).

Wrapping Up and Conclusions

Phew! That took forever! But ye, that’s it for this first **HUGE **Devlog. We’re really impressed if you read everything until now! But really, thank you all sooooo much for sticking through this lengthy update and being interested in our games development!

We’ll be doing this more frequently now that we have pretty much everything setup accordingly and we’re smooth sailing after extensive hours of bug fixing and organizing code. We already have most of our work pipeline defined so it’s just a matter of continuing the development now.

First weeks were a little more about exploring what techniques to use and learning about new things, but now that we have most of that out of the way, we can focus on communication and development!

Annnd.... what’s next?

We’re planning on adding new enemies, stats/abilities and other surprises we don’t want to spoil you with right now for the next weeks. Expect to get these devlogs every 2 weeks from now on as it will allow us to make much shorter posts and update ya’ll more frequently.

Again, thank you all so much and we’d really appreciate all the feedback you can give! See ya in a few weeks and meanwhile, I’ll leave you with a little sneak peak of this little dude:

Get Deathlike