Hey everyone! Welcome to the 9th week of game development. Last week was the ‘Audio Sprint’ in which I took care of the audio aspects of the game. The sprint also marked the finish of the 4-week cycle of releasing a build, but I didn’t make a build. I don’t have much at this point for someone to play and test, but I am going to target the next cycle for a proper build.
TLDR:
- I collected a bunch of sound effects for the new mechanics I added last time.
- I came up with a new data manager for audio to maintain the library of different sound effects and refactored the code to manage them better and trigger the sound effects easier.
- I modeled a new test environment in Blender to test visual styles.
- Finally, I added some secondary animation to enemies when they die and coins when they get collected.
So let’s begin.
Collecting Sound Effects
Finding good sound effects for your game takes time. You’ll have to go through hundreds of sound files just to find a dozen right ones. For the most part, you won’t even get the sounds you were looking for. You’ll have to create them.
I didn’t want to spend time on that just yet. Currently, my focus is to get a placeholder sound effect as quickly as possible, code it in the game, and let it be until other moving parts of the development settle down.
I have already mentioned the tool called Soundly. I used it to quickly gather a bunch of sound effects and made it work in the game. It saved me a lot of my time.
Of course, now the problem is that all the audio will be temporary, and at some point, I’ll have to replace all of them. That could result in a new kind of challenge.
Sound library
My first approach was to let individual gameobjects be responsible for carrying their sound files and play them. It made sense because each gameobject will be self-reliant, and it won’t have to look for another script in the scene to find the right audio clip or to play them.
The problem with the above approach would be that when I want to replace all the sounds, it will be tedious to go into individual gameobjects and look for the audio clips they are carrying. The chances of missing a gameobject increase with this approach, and making changes to the sound files, replacing them, and all other edits will take unnecessarily long.
So, I switched to maintaining one audio library source in the form of a scriptable object. In hindsight, this seems the obvious way to go, but as I have been made aware by many people, I am dumb.
Since it is a scriptable object, the individual gameobjects can still run independently without looking for any other script in the scene. When it’s time to replace the sound effects, I can change them in the scriptable object alone.
Testing visual style
I spent some time modeling another test environment in Blender. I modeled a bunch of grasses to figure out which would look good from the isometric pov. What I found is that having a gradient in the grass helps.
But there are a lot of things to figure out here.
- Should I paint textures, or should I use a limited palette of flat colors and gradients?
- Should the overall environment be simplistic or detailed?
- Can I even achieve the paint-like feeling?
One thing is for sure — I have to load this environment in Unity and test there. That’s the final destination the models will go in. So it’s best to try different things and judge all that in there.
My task will focus on it during the next visual sprint, which is two weeks away.
Some more animation
I had programmed some mechanics earlier, which required some attention. I introduced enemies, but when they died, they simply vanished. Also, when the player collected coins, they just disappeared.
I had plans to have a more elaborate animation for them with particle effects and whatnot, but I wanted something quick to be implemented now. It was important because animation plays a crucial part in providing player feedback. Without that, the game mechanic feels limp, and it doesn’t feel right during playtesting.
So I quickly applied some particle effects to the enemy when it died and had the coin flip up when it was collected.
Next step
The goal is to finish prototyping the combat mechanic. That’s one thing that requires lots of testing even to decide how it’s going to be. So I’ll make a combat arena with testable levels. It will require
- Auto enemy spawn
- Loading different maps
- Have a combat manager which controls the win/lose states, resources, and how hard the level is going to be
- Bonus — make it all endless and randomly generated. I don’t intend to have randomly generated levels, but it can help to test different scenarios quickly.
That is all for this week. See you next time.
I wish you very well!
Originally published at https://www.theearlyowl.com on October 18, 2021.
