The Illusion of Progress

I thought I had run out of things to talk about by this point, but of course by given how creative I am, there’s at least one more thing worth writing a blog post about.
Creativity doesn’t equal great so I’m not certain if this’ll be an interesting read, but let’s see how my blog writing can save it!

In Spirits of The Shogun when outside of fighting, the background scrolls with a parallax effect whenever the player pushes against the right boundary. When he/she stumbles upon enemies, the scrolling stops and the player is forced to fight the inbound wave of enemies. This effect is used to give the player an illusion that he really walks through a level containing a grass field and fight through waves of enemies.
What really happens is just the player making a ninja trying to exceed the right boundary and gets relocated to its horizontal position by doing so. However, a script inside each part of the background notices when this happens and tells each part to move at a speed. Each part moves at a different speed and that creates the parallax effect.

I’ve been through this briefly before in an earlier post but to new readers, when the player has traveled a certain distance (a value being reduced until 0, whenever the player pushes the right boundary) the apparent progression through the level will cease.
In the travelling phase, the right movement boundary was set on the right side, near the center of the screen. A good placement so the player wouldn’t be too near the edge when enemies appear.
However, in the fighting phase, the right boundary is set to the very right edge of the screen, meaning the player has more space to move around. That means a lot for the player since he/she has to dodge the incoming enemies and their melee/ranged attacks.

One question struck me hard though. If the traveling boundary was shorter than the fighting boundary, what happens when the player is exceeding the travelling boundary after the wave is finished?
The code would naturally make the player teleport back to the boundary, nothing wrong there. It’s just that it would certainly not look too good, and what does code know about beauty and grace?

I had to make some sort of smooth transition and that particular word gave me an instant solution. I would have the player simply slide back into place again instead of being teleported. No movement towards the right could be done while the player was sliding back. Thus no distance could be covered by exceeding the boundary and push it.
Also when the player slides back, I’d have to make the background scroll as well, to make it look like the ‘camera’ focuses back on the player, who’ll proceed through the level.
This transition had to be quick, because the player will be waiting to move again, so when the background scrolls while the player is sliding back, it will scroll much more faster.

The easiest part with that solution was to have a relaxing time with nothing more than just adjusting the speed of the player’s transition to the boundary and the speed of the background. I would have to make it look plausible too.

I don’t know if the implementation of the solution was done right, because I ended with two booleans that checked when the player pushes right. One that makes the distance left to the next battle being reduced and one that makes the background scrolling occur. I did have to split up my original boolean though, so the player couldn’t ‘cover distance’ while sliding back.

I think the special part with this is that we had no sort of camera that followed the player as he/she actually moved through a still image with occasional stand-stills as enemies appears. I don’t think that would have been the right way to create our game either. What it really is about is to create the solid experience you’d like the player to enjoy, no matter how you do it… It’s just that some ways does it better than others.

The Effect of Crossfading Soundtrack

This has been a cool addition to the game!
The soundtrack changes depending on which realm the player currently is in. If the player is in the human realm, asian instruments and taiko drums plays. If the player is in the spirit realm, the soundtrack goes all electronic and choirs are heard singing.
By the time I had to implement this dynamic effect, the gameplay themes of the game were nearly done, but still usable as they were. In fact, these uploaded tracks aren’t completed either but… time constraints.

In the human realm:

In the spirit realm:

I wish I could’ve done more before uploading them, and I most probably will.

I put these soundtracks into each of their own audio source in a game object on the scene, and assigned them to a script. I made sure the spirit version was at 0 volume, since the player would begin playing in the human realm, not the spirit realm. Now I had to make these two tracks crossfade when the player switches realms.

The script I assigned the audio sources to is named SoundManager (more appropriately named as AudioManager) and it manages the crossfade effect as well as playing sounds.
It has the boolean variable m_currentRealm that is being set to the same boolean value that decides which realm the player is in (LevelData.m_spirit). In each update, these two values are checked if they’re equal to each other and if they aren’t then it means the player is in another realm and the soundtrack needs to change.

A coroutine function that creates the crossfade effect receives different parameters depending on what realm the player is in. A coroutine, as explained in a previous post, executes a code that runs alongside the main one, so the program doesn’t have to wait until that code has fully exectued.
The parameters given is of course the audio sources so the coroutine knows what volume of an audio source to lower and vice versa.

Before lowering and raising any volumes, a float is instantiated with a value of 0f. It acts as a counter (timeCounter).
Next, a while loop runs as long as timeCounter is not similar to the value 1f, being done with Math.Approximately(). In the beginning of this loop, the timeCounter is being added with 0.2f.  Then the volume of the audio source that fades away, gets reduced from it’s maximal value (1f) with the new value of timeCounter. After that, timeCounter gets assigned to the volume of the audio source that fades in.
A brief period of time follows by using ‘yield return’ and then the loop repeats.

When timeCounter is similar to 1f, the coroutine proceeds to assigning a couple of values. It first of all makes m_currentRealm equal to LevelData.m_spirit so the SoundManager is updated on where the player is and then it makes the boolean value m_changing go false again.
I never mentioned m_changing. All it does is making sure several coroutines doesn’t start executing. It only does that when m_currentRealm and LevelData.m_spirit is unequal and m_changing is false. If that if statement passes, m_changing goes true.

That’s what is being done when a crossfade effect occurs. I did not come up with this by myself, and searched around the web in how to create the effect. Nonetheless, I’m quite satisfied to have achieved making the soundtrack dynamic and responsive in this kind of way and it’ll surely make the game more immersive for the player!

The Complete Flow of Spirits of The Shogun

Hey guys!

A lot has been done this week. After a couple of weekly design meetings we concluded how the game flow of Spirits of The Shogun works like, and it was up to me to program the game to have the decided flow.
In Spirits of The Shogun, you begin progressing through the endless level by walking to the right. You can’t walk back from where you came from. It’s like the level progression in older Mario games.

When you have reached a certain distance, a wave of hostile enemies will appear from both sides of the screen and the player can’t proceed further. The waves are split up into smaller subwaves, for structures sake. Each subwave has an amount of enemies appearing at the same time and when all of those enemies has been defeated, a short break follows before the next subwave of enemies appear. When all of the subwaves has been cleared, the wave is finished and the player can proceed forward again until a certain distance has been traveled.

Each wave will be designed to be different of course and during gameplay, all the waves will appear in a serial order and then be repeated. There is an introductory wave when starting a new game and it is going to be designed to introduce the enemies and mechanics of Spirits of The Shogun. It is the only wave that won’t be repeated after the series of waves starts over.

I really just added the ellipses of Game Over and Menu Screen so it wouldn’t look too empty…

The gameplay was structured into separate phases. The travel and fighting phases are the only ones in the game. It’s still easier to imagine the gameplay being split up like that, especially for someone who has to program it.
Programming this kind of gameplay is about having different codes being executed depending on the current state of the gameplay.

I’m using a boolean variable to determine which state is the current and I separated the different executable codes into functions.

The code for the travelling phase runs for as long as the player has distance left to cover. Programmatically speaking, if the player pushes the right boundary of the screen (which is about half the screen in the travelling phase) then decrease a certain numeric value. If that value is equal to or under zero, then it shifts into the fighting phase by changing the boolean variable. I won’t go into detail in how the code detects when the player pushes the boundary, because it’s not relevant to the main topic of this post.
While shifting into the fighting phase, the code prepares a wave that will be spawned.

Before talking further of how I programmed the fighting phase, I have to show what the waves are made of, visually.

Ignore the name of the script. It makes sense in a particular way.

If you don’t know what you see here, then I’ll tell let you know that Waves is an array that consists of objects of the type custom class Wave. It is the same with Subwaves and its elements. It holds objects of the custom class Subwave. You can see what kind of properties/variables each array and element has, in the picture.
The only thing you don’t see is a hidden property of the Subwave objects, called m_cleared, which is a boolean value that turns true when all enemies are defeated. I’ll return later to why this is necessary.
Another hidden property is a Wave object called m_currentWave and it holds the wave that approaches the player.

Now when the code shifts into the fighting state, a function is being called.The function uses an incremental value to assign the required wave to m_currentWave, then increases the value so next time the function is called, the next inbound wave in the order will be assigned.
Lastly, if the incremental value exceeds the amount of elements in Waves, then it’ll be reset to 1, skipping the introductory wave which is at index 0 of Waves.

In the fighting state, an if statement checks if the wave assigned to m_currentWave isn’t the current one yet and if it ain’t then it’ll start a coroutine. The reason it has to pass an if statement is to prevent several coroutines kicking off each time the game updates.

In the coroutine, it immediately makes the wave become the current one (it is in fact a hidden value that I didn’t mention about, that turns true) so this doesn’t happen.

Ultimate Ninja Storm

Here comes the real stuff – The enemy instantiation from the waves!
I wrote a nested loop so that it would iterate through both the subwaves and the enemies that contains in each subwave.
Each iteration through the enemies of a subwave instantiates them on the scene. What happens after the loop is something more special. I have the code wait (using yield return) until the m_cleared property of the current subwave has turned true.

Let’s jump out from this coroutine and explain what will exactly happen. As I’d put it, a coroutine contains parallell code that executes alongside the main one. The program doesn’t have to wait until that code of the coroutine has been executed. That’s why I can make the code wait without stopping the whole program!
Now while that coroutine does its thing, the main code checks if the amount of enemies defeated is equal to the amount of enemies in the current subwave. Of course, that current subwave’s m_cleared property turns true and resets the killcount to 0 if it meets the required condition. It only does this when the player is fighting the enemies.
What makes m_cleared go true, though? The value that measures the amount of defeated enemies is static and is being added to whenever an enemy is hit and is dying. That happens in another script, though.

Now, in the coroutine, the code proceeds to another line of code that tells it to wait for a brief time before iterating and instantiating the enemies of the next subwave. This creates the break between subwaves and the length of this period can be adjusted from the Unity Inspector.
When all subwaves has been iterated through, the wave is finished and the coroutine finishes by resetting all the boolean values involved to false. If I didn’t do this, the wave would be completed in an instant next time it arrives. All the subwaves m_cleared would still be true! In fact, no new waves would ever arrive because the game would never return to the travelling phase. It is indeed important to make sure you clean up after you’re done, so to speak.
And lastly, it calls the function that resets the distance left to the next fight. I’ll let you in on how it looks like with code.

For the curious programmers

After this, the game returns to the travelling phase again, and so on it goes.
That’s pretty much the game flow and even though it is simple, it is still a lot to cover. It might appear to be a difficult process to implement all this and know how but everything will really work out if you break it out into smaller and smaller steps. Spend some time writing a pseudo code in Notepad and figure out what needs to be done.

What’s next for me is to improve the current enemy AI and make the gameplay music dynamic (making it sound different when shifting realms). I’m sure to have a blog about either one of them next week!

Making of The Main Theme Soundtrack

I’ve always liked to compose soundtracks for games. Since I experienced the beautiful soundtrack of Yoshi’s Island, the idea of me being the next Koji Kondo or Yoko Shimomura has enticed me! I’d like to talk more about what happened from my first experience with a good OST to now, but I’ll skip it so I don’t bore my viewers.
A great opportunity to test what I can do approached me when a lead sound designer was requested for my team. I quickly jumped at the chance to claim the role.

I think the first thing to begin with when creating a soundtrack is to create the main theme, unless you have ideas for other soundtracks that you just need to compose before you lose them (I record my voice and faintly sing what I’ve come up with, so I can compose later). All the other games has themes and it’s no exception that our game should have one too!

I thought the main theme of Spirits of The Shogun should signify and sum up the general feel of the game – the situation that lies ahead of the player.
I first went for a calming soundtrack, since I thought it would be great to have a sort of ‘calm before the storm’ feeling.
My attempts resulted in quite generic melodies which were predictable and slow. I redid a lot of tunes until I got one certain catchy melody. However, I lost it after forgetting to save. In the end, I went freestyle without any regard of the resulting feeling the theme would produce. I went on playing chords until I felt it audibly pleasant, then I had the chords repeating with more or less additional instruments and melodies playing together.
I got a feeling of anticipation and an excitement that kept building, and I was content enough with the result.

Since I’m doing music for a traditional Japanese inspired game, it was obvious for me to use Asian instruments. I had the Koto instrument being a lead instrument because most people associate Asia with it and it worked out the best of all the other choices I had. Other instruments I had for the soundtrack was for example Pipa, Erhu and Dizi.
I had to take into account that the music during gameplay would turn electronic when switching into the spirit realm, so my theme had to convey that part of that game too. I had electronic tunes play alongside the instruments halfway through the theme, as if the player suddenly entered the spirit realm. To have a smooth transition into the electronic part, I had a electronic beat vaguely playing pretty early on.

To have a good smooth loop on the theme, I composed the theme to end up calm again towards the end. Each electronic tune are stopped to play until the Dizi is left playing, just like in the beginning. It’s not the best looping I’ve made, but it works just well.

I like how I tried to follow a direction with the soundtrack by achieving a certain feeling, but transitioned into me just doing my own thing and it still ended up quite good.

Next up is for me to create an upbeat soundtrack for the gameplay. Preferably before everyone starts to believe I really made the existing one that played during Alpha, which is actually a placeholder soundtrack from Onimusha.

Implementing Realm Switching

The Human Realm, although there are no humans here yet.

What?

The core mechanic of Spirits of The Shogun is that the player can switch between realms to defeat one type of otherwise invincible enemies at a time.
There are two different realms and each realm have two distinct types of enemies. The Human Realm have human enemies and The Spirit Realm have demon enemies.
The player is present in only one of the realms but has the ability to switch to the other. The player can only hit and defeat those enemies whom are present in the same realm as the player.
However, the enemies can harm the player from both ends of the realms.

How?

By the time I came to start implementing the realm switching mechanic, I had already figured out a pretty simple solution to it.
All that was needed was a few variables being checked if they’re equal against each other, and if they are then execute something.

I began with creating a variable inside a script on the scene, which would be easily reached by all other scripts. This variable was a boolean (can only be ‘true’ or ‘false’) named m_spirit, and would tell what realm the player was in.
Then, each type of enemies would have their own boolean variables, also called m_spirit, being set to true if they were demon enemies or vice versa.

The projectiles and the melee hitbox the player attacks with possesses also a m_spirit variable. The variables gets assigned to a value equal to the global m_spirit variable, when the objects of those variables have been instantiated.

Now, whenever the player attacks and it hits, the code checks if the spirit variables of the attack and enemy are equal. If they are, then they are in the same realm and the code for collision behavior can be executed.

I made sure that the spirit variables for the player’s attacks and the enemies were public in the code. That means non-programmers could easily edit the values directly through the Unity Inspector.

Why?

I simply found it as the fastest and easiest solution to have variables being checked if equal to each other. I didn’t want to dwell too much on other options, mostly because I couldn’t come up with anything else on second thoughts.
I could have named the global m_spirit m_globalSpirit, but it was not my biggest concern at the time.

The reason I made the spirit variables public for non-programmers to edit was so they didn’t have to delve into the code to adjust something. It’s even easier for us programmer since it’s faster to edit through the Unity Inspector.

The Spirit Realm. The dark purple shaded placeholder demon enemies belongs here.