next »

[LyricalReverie]

She truly did a fantastic job with the Freedom Planet soundtrack. The "Meanie Boss" track, in particular, is a favorite of mine.

[Ninety]

Love that canyon area on the world map, some great colour choices. I also really like how that crossfaded music came together, I wouldn't have thought to use a multi-channel file.

[Ted]

Ohhh good idea using the ogg file channels in that way. And those songs by Woofle are SUPERB too <3

[Ishi]

Layered Music - Part 2

Following on from the previous post, we have a multi-channel music file and need to play it correctly in-game.

Adjusting the channel volumes during playback

I use the FMOD API for audio playback. So I'll be talking about my usage of that API specifically. I don't know what capabilities other audio systems have.

I won't discuss the work required to actually load and play the music file - so let's assume that's already working!

Our example music file has the following channels, representing 4 versions of the song, each in stereo. These are the input channels.
1. Beach (Left)
2. Beach (Right)
3. Jungle (Left)
4. Jungle (Right)
5. Underground (Left)
6. Underground (Right)
7. Plains (Left)
8. Plains (Right)

And the game outputs in stereo, so there are two output channels.
1. Left
2. Right

The function that's needed to alter which channels are heard is Channel::setMixMatrix. This allows you to freely control how much of each of the input channels is heard on each of the output channels! For example:



Applying the above mix matrix sends 1.0 (full amount) of the Beach L channel to the Left speaker output, and 1.0 of the Beach R channel to the Right speaker output. All other channels send nothing to any of the output channels. So this will sound like just the Beach version of the music is playing on its own.

For each version of the music I define one of these mixes. Mine are defined in XML as part of the data which describes all the sounds and music in the game. You can define it however you want, or hardcode it into the code, it's not important.



The above mix causes the Jungle version of the song to play.

And finally in order to fade between songs, I apply a new mix matrix every frame, where each value of the mix matrix is interpolated between the Beach mix and the Jungle mix. The mix below is 60% through the fade; so Beach has been reduced to a volume of 0.4 and Jungle has increased to a volume of 0.6.



Channel Ordering

There's one last thing to cover - a detail that I glossed over previously.

In this image in the first post I showed that when exporting the multi-channel music file from Audacity, Beach L is being put into Channel 1, Beach R is being put into Channel 2, etc.

And in the mix matrix examples above, I said that Beach L is in Channel 1, Beach R is in Channel 2, etc.

However this isn't quite correct. The channel numbering is actually different between the Audacity export and the FMOD mix matrix.

We need to look at the ogg format specification to see what the meaning of each of the channels is. We are using 8 channels which is interpreted by the format to mean the file is in 7.1 surround sound.

eight channels
the stream is 7.1 surround. channel order: front left, center, front right, side left, side right, rear left, rear right, LFE

And then we can look at the documentation for the FMOD_SPEAKER enum which reveals the order in which FMOD refers to channels.

typedef enum {
  FMOD_SPEAKER_FRONT_LEFT,
  FMOD_SPEAKER_FRONT_RIGHT,
  FMOD_SPEAKER_FRONT_CENTER,
  FMOD_SPEAKER_LOW_FREQUENCY,
  FMOD_SPEAKER_SURROUND_LEFT,
  FMOD_SPEAKER_SURROUND_RIGHT,
  FMOD_SPEAKER_BACK_LEFT,
  FMOD_SPEAKER_BACK_RIGHT,

I exported Beach R in Channel 2, which in the ogg format represents the "center", which is actually Channel 3 on the FMOD side. So if I try to play the music file back I'll actually end up with a really weird combination of the left/right channels of different versions of the track playing at the same time.

I don't want to fix this by changing the way the mix matrices are laid out, because I like the mix matrices to be easy to read. So I'll fix it by exporting the file differently.

Beach L	FMOD Channel 1 ("FMOD_SPEAKER_FRONT_LEFT")	Export to Ogg Channel 1 ("front left")
Beach R	FMOD Channel 2 ("FMOD_SPEAKER_FRONT_RIGHT")	Export to Ogg Channel 3 ("front right")
Jungle L	FMOD Channel 3 ("FMOD_SPEAKER_FRONT_CENTER")	Export to Ogg Channel 2 ("center")
Jungle R	FMOD Channel 4 ("FMOD_SPEAKER_LOW_FREQUENCY")	Export to Ogg Channel 8 ("LFE")
Underground L	FMOD Channel 5 ("FMOD_SPEAKER_SURROUND_LEFT")	Export to Ogg Channel 6 ("rear left")
Underground R	FMOD Channel 6 ("FMOD_SPEAKER_SURROUND_RIGHT")	Export to Ogg Channel 7 ("rear right")
Plains L	FMOD Channel 7 ("FMOD_SPEAKER_BACK_LEFT")	Export to Ogg Channel 4 ("side left")
Plains R	FMOD Channel 8 ("FMOD_SPEAKER_BACK_RIGHT")	Export to Ogg Channel 5 ("side right")

The above mapping of the audio channels to the correct export channel looks like this in Audacity:



It's a mess but, hey, it works! I don't know if this will even be useful to anyone, but it's a look inside a small part of the game's development which is the whole point of this devlog.

The result, again

Here's the final result of this whole thing:

The final numbers displayed in the black and white text at the top of the screen - all the 1.0s and 0.0s - are the current mix matrix. You can see how the matrix changes as it fades between each version of the song.





Thanks for reading!

[Louard]

Really does sound great. And the shifting ambience from one track version to the next is perfect for the world map!

So, how are you envisioning this being used during gameplay?

[Ishi]

Really does sound great. And the shifting ambience from one track version to the next is perfect for the world map!

So, how are you envisioning this being used during gameplay?

The majority of levels won't make use of it, but I'm using it in more special cases. One example is these combat challenge levels that appear on the world map (old gif):



They have their own unique music track. Since they're combat focused, I wanted to highlight the player's damage state, so when Leilani is tiny (one hit will kill her) an extra layer of drums fades into the music to raise tension.

[TheGrandHero]

They have their own unique music track. Since they're combat focused, I wanted to highlight the player's damage state, so when Leilani is tiny (one hit will kill her) an extra layer of drums fades into the music to raise tension.

Will the boss theme(s) work the same way?

[Ishi]

Will the boss theme(s) work the same way?

Not the same as that, the boss theme has 3 different versions of increasing intensity which it progresses through during the fight as the boss goes through different attack patterns.

[Ishi]

Hello all, just a quick devlog post this week!

Underground

As seen here the core gameplay features secret areas where you see a circle cutout around Leilani which reveals what's inside. Well the world map has that too!



I didn't want to divide the world map into separate areas, so any cave / underground stuff will actually be below the surface of the island like this.

[Louard]

Those underground map bits look hot!

Also, I wasn't even aware OGG files had a multitrack format. Very cool! And, reading about your idea of adding a 'tension layer' if you will during the fight blockades made me think... Wouldn't that be a killer cool feature to have in all levels?

[Josh Bossie]

Yeah, really cool effect and good use of colors, too!

[Ishi]

And, reading about your idea of adding a 'tension layer' if you will during the fight blockades made me think... Wouldn't that be a killer cool feature to have in all levels?

It felt appropriate during a short combat-focused challenge, but I feel like adding it to every level would put too much focus on the player's state and their risk of death. I like that some of the levels have bouncy, happy music so don't want to mess with the vibe of those too much.

There's also the fact that changing music costs me money as well as time, so the music that's in the game already is unlikely to change too much

For a future game I would definitely put more thought in beforehand about whether there's a gameplay feature that could be consistently reflected in the music throughout the whole game.

[Hoj]

Hello all, just a quick devlog post this week!

Underground

As seen here the core gameplay features secret areas where you see a circle cutout around Leilani which reveals what's inside. Well the world map has that too!



I didn't want to divide the world map into separate areas, so any cave / underground stuff will actually be below the surface of the island like this.

Looks great. I like that you can see another cave entrance on the beach, makes you wonder how to get down there.

[Ishi]

End of World Map Month #2

January is over so I'm finished with working on the world map for now. It's been productive, I've got maybe 50% of the map laid out now, and have added some nice new features here and there.

Here's a sneak peek of the jungle area. Sorry for the bad gif quality, I accidentally captured the video with compression enabled.



The animated foliage adds a lot of life I think! The foliage here is all just part of a tileset, and the tiles are cycling through a 3-frame animation.

And right at the end of the month I added support for objects that are destroyed by unlocking paths. This helps to fill up the empty space where paths are going to be, so the island doesn't look really empty before you progress through it. Plus it's quite satisfying to see the blocks get destroyed.



February - Level Design month

I'm back on level design duties for a month, February is a short one but shouldn't have too many distractions for me. Hoping to make 3 good levels, plus at least a couple of the single-screen combat challenges.

[Ishi]

Spring Cliff level

I've finished the first pass on the first level of the month. It's a vertical level focused on springs.

The level is kinda sloppy at the moment, but it's just a first pass. I'll return to it with fresh eyes in the future and make improvements, and make it more interesting.

This part is quite fun, just beating up the enemies is always amusing



I altered the way that spring bouncing works: previously it would bounce Leilani to a fixed height whenever she touched it, which wasn't that interesting. Now the spring bounce works more like a standard bounce off an enemy's head. Holding jump will make Leilani bounce much higher. This helps to teach the player about holding jump to bounce off things, and also just gives a lot more control over how players decide to use the springs.

Bugs

I find that while designing levels I tend to find a lot of bugs! Whether it's due to new combinations of mechanics, or just realising that something has been broken for a while. In this case, the spring is incorrectly bouncing Leilani when she touches the side of it, which somehow results in her going way higher than she should.

[Canned Turkey]

It's looking great!
Every post showing more levels just makes me more excited to play the finished game.

[Josh Bossie]

This topic always makes me happy when I look at it. I am so absolutely in love with the SMW-style world map transitions.

How are you liking the "themed month" approach to your development? I thought of doing something similar, but I could never stay dedicated to it. I try to at least do themed weeks, but even then I'm all over the place most of the time

[Ishi]

How are you liking the "themed month" approach to your development? I thought of doing something similar, but I could never stay dedicated to it. I try to at least do themed weeks, but even then I'm all over the place most of the time

It really works for me personally. Given the amount of time I get to work on the game, spending a month on one task seems a good balance between feeling like I can focus on that area of the game, and not feeling like I'm spending *too* long on it. Placing the one month restriction on myself feels quite freeing in a way, because I don't have to worry about or feel guilty about other areas of the game. For example I could spend time on some small world map features like the destroyable blocks, without worrying about whether I would be better off working on level design or fixing bugs or something.

I do get distracted sometimes, it depends whether something grabs my attention (like how I got sidetracked with adding the gameplay recording thing a few weeks ago), but that's ok. I try to stick to the monthly plan but there's no point being hard on myself if I stray from it a bit.

[Louard]

Couldn't agree with you more about how satisfying ti looks to open up paths on the map by blowing up blocks!

But, your side roll spring bug looks more like a feature to me ^_^

PS. Watching you bounce those enemies around on the springs fill me with equal parts anticipation and jealousy!

[Ishi]

Leilani's 4th Birthday

Tomorrow marks 4 years of work on Leilani's Island! And nearly 3 years of the devlog. Thank you to everyone who has read, commented and followed my progress so far.

I always go back and view old gifs and screenshots as I like seeing how far the game has come. I posted this one last year:



This year I've recreated the area for a nice comparison!



Camera - Part 1: Setup and Horizontal Movement

Today I did some camera code that I decided I needed for the new level I'm working on. I realised that I've never talked about the game's cameras in this devlog. So, I'll do a small series of posts about how the camera works.

Setup

The normal camera in the game is locked inside rectangular areas. The old way I used to do this was by placing special tiles in the level to define the left, right, top and bottom boundaries for the camera. So placing each of these red markers defines a hard limit that spans the width/height of the level and stops the camera going past it.



Here's the same image with the camera's boundaries drawn over the top:



However, today I finally added a new way to define camera areas, that makes much better use of the capabilities of Tiled. I add a new layer called "Camera", and draw a box object in it. That's it!



This is so much easier for me to move around, and has the same effect in the game. The camera won't move past those boundaries, so only the stuff inside the screen will be visible.

(Note: Leilani is placed off the edge of the screen here; that's just how I set up the level to record a gif as I wanted Leilani to roll onto the screen during the recording. It's not normally how the game works.)

Basic Camera movement: Horizontal

Let's stick with the test level shown above as an example. The upper and lower boundaries for the camera are the same height as the game screen (15 tiles high), so the camera won't move vertically at all (except for screen shake effects which are applied afterwards). So for this post I'm just going to talk about the horizontal camera movement only.



The camera keeps pace with Leilani, there's no smoothing or lagging behind. So as Leilani moves her sprite stays fixed at a constant X co-ordinate on the screen (except when the level's boundaries . This kind of camera felt the most appropriate for the game, it's pretty slow paced and I like the camera to frame the action consistently, so most of the time it doesn't need to move around too wildly.



To help explain, an example of a game that takes the opposite approach is Cave Story . The camera in Cave Story tends to lag behind Quote and slowly catch up over time, even when Quote has already stopped moving. This works perfectly well for the game, especially as the camera shifts around based on the player's aiming so the smoothed movement is great for coping with many different situations. So I'm not criticising Cave Story's camera, my aim is just to highlight that something like camera movement should be based on what you think feels best for your game. There are lots of ways to tackle the problem!

Horizontal offset

I lied a little above when I said that Leilani's sprite stays fixed at an X co-ordinate on the screen. The camera offsets itself slightly to the left or right, depending on whether Leilani is moving left or right.





It's not a big shift but it subtly hints at which way Leilani is moving. I like how it feels, and I think the camera would feel a bit flat if Leilani was locked in the dead centre of the screen. It also helps to give the player slightly more visibility of the obstacles that are approaching.

When Leilani turns around, the camera needs to adjust its offset to move ahead of Leilani in the new direction. To keep this behaviour in-keeping with the non-laggy movement that the camera normally has, I avoided smoothly animating the camera offset as it shifts to the other side of the screen. Instead, the offset only adjusts when the camera actually moves. This gif should help to explain:



As you can see, even after Leilani has turned around, the camera offset only changes when Leilani continues moving. What I wanted to avoid was the situation where the player taps the 'left' button briefly, and it causes the camera to swing all the way over to the other side of Leilani. Instead, if the player taps 'left', the camera will barely move. So it feels neater and more in tune with the player's inputs, I think.

How the boundary works

A brief note on how the camera boundary is applied. The camera's movement as it follows Leilani, and the way it alters the offset based on the direction of the movement, is all calculated entirely independently of the camera boundary. The camera decides the position it would like to be in, and then the boundary is applied as a separate stage of the process, which clamps the camera position to within the limits of the boundary. The clamped position never feeds back into the first part of the camera calculations. This keeps the two systems nice and separate.

---

Hopefully that was interesting, and my explanations were good! Topics I'll cover in the future include Vertical camera movement, and a couple of types of cameras that are more hand-authored to fit specific levels. If you have any questions then ask away.