Source - Indie game development

Development Blog

[thesourcegame]

Sound Layering (Sound Design)

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. 

Now most sounds have some form of logic, they’re conditional in a sense. Stepping on concrete sounds different than landing on concrete. Landing should probably sound harder and might even have higher pitch, it might also be the case that the landing sounds come from a different array(let’s say library). Here is where the layering is coming in. While running through water I also play a watersplash sound and when coming out of the water I also play a squishy wetstep sound. This will create even more variations, since random sounds are placed over random sounds with variations in volume and pitch.

[thesourcegame]

Custom Inspectors

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. 

The old inspector for the PlayerSteps script, which was obviously way to long.

[thesourcegame]

Something else I had been working on is the overal style/mood for The Source. I’m using a Shepard tone and some slow fading inspired by the movie The Shining.

[thesourcegame]

Radio Silence, and for what reason

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.

Small preview of the Pull mechanics

[thesourcegame]

Reworked and optimized wet steps and water splashes

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.

[thesourcegame]

Something that bothered me for over a year finally fixed

Somehow the upper legs were marked sharp.

[thesourcegame]

Death mechanic revisited

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.

[thesourcegame]

Pushing mechanics revisited

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.

[thesourcegame]

Switching to a Rigidbody Player Controller

Early on I had decided using a Character Controller component for my player cotroller. Something that bothered me while programming my player contoller were the limitations regarding physics. At first I thought implementing something like pushing mechanics would be easy enough, but eventually I figured this would need loads of programming and would never the deliver satisfying results I’m looking for.

Another annoying issue I encountered was the player balancing on edges and getting stuck in certain situation. Below you can see an example of the basic gravity the Character Controller supports.The problem, even the rounded part of the Capsule Collider used by the Character Controller is considered good enough for the grounded state.

[thesourcegame]

Plants, plants, plants

Some progression on the foliage I’m working on and my pipeline. I am finally fond with the way vegetation looks in my game. I’m currently placing all the foliage manually as prefabs, tedious I know. This gives me a lot of control and makes sure it renders shadows.

This way I can also get rid of a third party asset, which I think just isn’t for my project, but will suit larger open worlds way better. Placing everything manually also was less performant than using Advanced Terrain Grass for the shadow rendering. None the less I still think this is an amazing asset for large open worlds. 

Below you can see my current foliage models. As you can see I try to use as few tri’s as possible.

Different meshes for my branches, plants and leafs.

[thesourcegame]

Performance culprit

Something I’m slowly realizing is that some effects in video games are very impactful on performance. I always took stuff like reflections, lighting and shadows for granted in video games, but I came to the conclusion that this stuff is quite impactful. Especially when you combine those effects. 

Foliage shadow, volumetric lighting, planar reflections.

One of my first blogposts was about planar reflections for water puddles. Planar Reflections is just a technique useful for achieving something like reflections. There are obviously other options like Screen Space Reflections (SSR) that are useful, but SSR isn’t very accurate and besides that only reflects whats on screen.

Another culprit I’m currently trying to tackle is shadows for the foliage I place on my terrain, which is also something that seems easy, but unfortunately isn’t. For obvious reasons foliage and grass don’t automatically render shadows. This is probably because of large open worlds with loads of grass and plants. I found an asset called Advanced Terrain Grass, which takes over the rendering of the vegetation, but this asset has its performance price tag.

Conclusion: don’t take some visual effects in videogames for granted!

[thesourcegame]

Switching to terrain

I have finally started working with the terrain tool instead of using a mesh. This ofcourse gives me the option to paint foliage on the ground instead of placing meshes all over the place, which really speeds up my workflow.

ofcourse I forgot to turn off the wind and as you can see my foliage is moving all over the place.

A huge problem I encounter with painting foliage on a terrain asset is the lack of shadows. While it clearly isn’t as impactful on the performance of the game I lose alot of fidelity and detail.

[thesourcegame]

Greebler (Github)

Found this gem on Github via the Unity3D subreddit a while ago. It’s a handy asset to place small objects like rocks and vegetation, to make levels less empty and add more realism. Was just fiddling around with some foliage and test it’s bounds. It added around 2000 plants, each 16 tris and dropped the fps from 140 in editor to around 40. Remember to remove the Greeble component and it’s trigger before pressing play. 

I also need to remember to add some (con)text to the past couple of posts. 

[thesourcegame]

Property Blocks (Shaders)

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.

Useful post about property blocks and shaders.

[thesourcegame]

CollisionEvents (Scrapped)

CollisionEvents make sure I can trigger certain things on collision. I know i want to fade out the particles when they collide with the player, so there is no fixed particle lifespan. The distance to the player had impact on the particles lifetime and this is why CollisionEvents make it possible to trigger the fade effect at the right time. 

As of now I have scrapped the particles with trails to the player for various reasons. It mainly has to do with aesthetic reasons and the performance cost. Another important factor is the controller responsiveness and the player being able to quickly absorb and abstain energysources.

[thesourcegame]

Optimizing foliage

Since I have started creating assets I have been doing a lot of research regarding asset creation. I initially created plants with 172 tris and thought that was quite a lot for an asset that is going to be placed a lot. For this reason I have started doing some research in creating foliage as lightweight as possible. A technique I found quite a lot is using 1 square polygon and use a cutout texture of i.e. a leaf.  

By UV mapping the texture tactically the fold can be in the middle of the leaf. I eventually removed the edge loop in the middle of the stem to lose another 3 tri’s per small plant.

A wireframe view of the small plant I have created, I have eventually removed the loop on the middle of the stem to save another 3 tri’s.

[thesourcegame]

Scripting particle collision

I have started doing some research on having particles fly to a target and dying. This might be an interesting visual for absorbing and abstaining an energysource. This way a particle will be sent from the player to the energysource and vice versa, to give the player visual feedback.