#thesourcegame

I know, I know, I was supposed to be finishing the push and pull mechanics, but for some reason one thing led to the other and I got carried away. While thinking about the sounds the pulling should make I figured I should start experimenting with it. In the meantime I have been watching various videos about sound layering and sound design in videogames. For this reason I started working on the sound design again and specifically the players sound design i.e. steps, breathing, watersplashes and so on.

Here is a representation of what is going on when the player is running through the environment.

All the different sounds come from an array, so I have multiple variations of each sound. When stepping on concrete there are atleast 6 different sounds of a foot stepping on concrete, this is to prevent ear fatigue. Each of these sounds is picked randomly and both the volume and pitch varies += 20%. This makes it sound like each sound is unique and will prevent the sound design from sounding repetitive. 

I’ll admit, initially I thought I didn’t need Custom Inspectors and thought why would I invest time in something that doesn’t directly contribute to the game. For some time now, some script in my project have grown so much that their inspector got way too long. The PlayerSteps script is one of those scripts. It handles the different sounds of footsteps for the player and where and when to spawn wet-steps or water-splashes. This means it consists of multiple arrays and settings for each step etc.

The custom inspector, which adds tabs for the different footsteps.

Especially when tweaking volume values of the different steps while in playmode it was a huge hassle to find the right settings and for that reason I decided I should finally dive into custom inspectors and it’s uses. 

Something that really bothered me with the old wet step system was that the steps weren’t really blending with the environment. Let’s say the player has wet feet and he steps on an edge or uneven surface it would instantiate a particle system with a flat bilboarded texture that would fade out over time.

For this reason I had decided decals would be a smart way of blending those wetsteps with the environment. Something else that annoyed me was the instantiating and destroying of Particle Systems with my own “garbage collector”, which wasn’t really performant. 

For this reason Object pooling was the right solution. The steps won’t get destroyed, but reused. The cycle would go something like; move a prefab to the position of the feet, set it’s starting color (dark black) and then fade out. This way the steps are constantly reused and aniamted over and over again.

In the meanwhile I figured why not make it so that when the player only has one wet feet only let that feet place wet steps. Before I was using on trigger enter/exit to determine if a player was in a wet area and now I’m using raycasts for each feet to detect wet surfaces.

I was wondering if it is necessary to duplicate, or create instances of the  materials for my lightsources. In theory all my lightsources should be able to use the same material and only the emission value should be controlled per light source. The problem is however, that when I change the emission value of the material all objects in the scene with that material change i.e. all lightsources, and this is something I want to prevent. The other option is to create instances of the material, which cause more batches for the GPU.

The solution I found was property blocks. I have duplicated the standard Unity shader, and added a simple line of code ‘[PerRendererData]’, which will tell Unity to compile the shader in such a way that the _Emission property is to be set per renderer, instead of being shared for all renderers using the shader.

A small little update from my side and most importantly the reason why I failed to post updates on my blog. A couple of months ago I figured I needed to swap out my PlayerController from being CharacterController based to Rigidbody based. It took quite some time rewriting the different player mechanics and unfortunately without the wanted results. The initial reason was simply because I thought the game needed more physics interaction and that only a Rigidbody based PlayerController would make this possible.

Unfortunately I was terribly wrong and I stumbled from one bug into the other (Camera following physics objects, FixedUpdate vs Update and the amount of control the player has over a Rigidbody PlayerController). Going back to a CharacterController was a really hard decision, since I felt all the work was for nothing. This however was not true. I eventually managed to fix issues 

I previously had with the CharacterController component like sliding from edges and am currently reworking the pushing mechanics into a Push and Pull mechanic (This is almost done, but takes a lot of time because of the complexity and animations). None the less, I will try to maintain this blog alot more and I’m aiming for a playable first demo level around june/july.

Somehow the upper legs were marked sharp.

The initial death mechanic used a Softbody variant of the player that gets instantiated when the player died. This Softbody variant was just using some colliders for different bodyparts and Rigidbodies and configurable joints. The problem is however, since this prefab that gets instantiated is always the same, the death animation is always the same. For this reason I thought about adding the components on runtime when the player dies. This way the Rigidbodies and Configurable joints get attached live in the moment and the death animation is always dependant on the situation and the surface the player hits. 

Initially this ofcourse started with some bugs. The Configurable joints need limited motion and I needed to add force to the Rigidbodies. For convenience I randomized the force and it’s direction.

Ditching the Character Controller component means I can revisit some mechanics that I think could use some polish. One of those mechanics is the pushing mechanic. At the time I had to use constraints on the Rigidbodies to prevent unwanted behaviour. 

This means pushing stuff over edges was never going to work, since the rotation was turned off. Since the player is now also Rigidbody based working with other pushables would be alot more accessible.