next »

[Ishi]

I remember way back when you introduced the boss character (don't remember her name, but she piloted a robot), and you mentioned how she had a lot of personality unlike Leilani herself, which was certainly the case. However, those idle animations do give her a little bit of character, which I appreciate. Having bits of personality shown in sprite and art work was why I found Sonic so much more interesting than Mario back in 8 and 16 bits days.

Good to hear, thanks I won't be going all out on making Leilani too expressive, but hopefully little details like the idle anims do help to get her character across and just make her seem less blank.

Hehehe, so when can we see a title screen like this but with Leilani? 

<Sonic Mania title screen edited out because of 2-videos-per-post limit>

EDIT: although I suppose something comparable to Wario Land would be more appropriate

I loooove the Wario Land title screen

I occasionally think about the title screen, but not entirely sure what I'll settle on yet! The title screen hasn't really changed much since I first put it in, when the game used a lower resolution. So I still think of it as placeholder art.





(The way the logo falls down was directly inspired by the Wario Land title screen)

It's probably likely to focus more on the island than on Leilani, I think. Perhaps even mostly the same as it is now but with bigger art that better represents the final layout of the island.

Also shoutout to the gorgeous Yoshi's Island title screen.

[Ishi]

Audio Overhaul progress update

February 10: 0 / 142 = 0%
March 14: 67 / 162 = 41%
March 21: 91 / 177 = 51%
March 29: 105 / 179 = 58%
April 04: 126 / 183 = 68%
April 13: 163 / 191 = 85%
April 19: 194 / 194 = 100%

Yes, it's done! It feels great to finally get through this big todo list. Here's a chart to celebrate:



I now have the pleasure of feeling excited to work on the game again, a feeling that I hadn't consciously noticed had gone away. I don't recommend letting your backlog of tasks for any single area of the game from building up this much. In the future I'll try to remember this and add audio for new mechanics as I go along.

I'm now able to get back into general bug fixing and polishing to try and make a build of the game that's a good standard for giving to some playtesters. The most recent fix:

"Fix menu breaking when hitting ESC to back out of the file copy overwrite popup"

Genuinely 10x more exciting to me than the prospect of doing more audio right now

[Jimbob]

Holy mackerel, how's it going?!
It has been a while since I've checked in here, and awesome to see this at such a complete stage!

[Ishi]

Holy mackerel, how's it going?!
It has been a while since I've checked in here, and awesome to see this at such a complete stage!

Great to hear from you! I'm good, and Leilani's good In terms of the actual playable content this game isn't that complete - but the core mechanics and most of the surrounding menus and whatnot are in place at least!

[Ishi]

Aloha! I had a productive day today - the vast majority of my current bugfix / polish items list is now complete. I do still need to go back through my previous notes, as well as previous playtest feedback, to check if there's anything else worth fixing before my next playtest build.

Note that big public playtesting isn't my style, so when I talk about a playtest build, it'll be limited to a handful of people that I know. I may expand the scope of playtesting in the future, closer to game completion. However a new playtest build is still a big milestone for me to reach - the last one was in October 2018! Once the build is done I plan on making a full-level playthrough video of the Poison Pipeway level that I've previously documented the creation of on this devlog.

With that rambling done, I want to talk about a small feature that I don't think I've mentioned before, that I spent some time polishing today.

Quick Re-roll

When Leilani rolls into something - for example a breakable block or enemy - she rebounds off it. If the player holds forwards and roll, they'll eventually smash through a series of blocks:



"Quick re-roll" is an ability that Leilani has. After rebounding off something, if the player releases and represses the roll button, Leilani can boost forwards back into the roll state quicker than she would do otherwise:



This is intended as an optional mechanic that players can utilise if they want to get through an area a little more quickly. It also allows moves like smashing a block twice without touching the floor - which is useful if the block is high off the ground, for example. It hopefully just adds a bit of extra depth to Leilani's moveset.

Problems to fix with Quick Re-roll

There are a couple of problems with this mechanic that I wanted to fix today.

Firstly, consistency of performing the move. I originally intended it to be an 'expert' kind of move, so the timing was quite tight for performing the re-roll. Let's look at the numbers!



The player must release the roll button after initially hitting the wall, and then re-press the button within the 0.15s window shown above. It's possible to press the button too late, but it's also possible to press it too early.

It's easy to tell that this window is too harsh, especially because I'm the game's developer and even I can't reliably get the timing right! It feels super harsh to press the button too early and completely miss the chance to do the move.

The second problem to fix is consistency of the results of the move. The following gif shows that, depending at which point during the window the player performs the re-roll, Leilani might hit the next block or roll on top of it:



Using the move in mid-air is also a bit unpredictable - it's hard to get a sense of whether you're going to hit the next block or go underneath it:



The fix - input timings

The primary fix for both of these problems is to adjust how the input for performing the move works.

Before:


After:


The window in which the player can re-press the button to perform the move is now much bigger. Obviously this has the benefit of making the move generally easier to perform. The important change though is that the re-roll doesn't actually occur until the end of the window, regardless of exactly when the player re-presses the roll button. This has a few advantages:

• It allows me to increase the size of the window to re-press the button, but without allowing the player to press the button  really quickly and re-roll instantly after rebounding.
• It gives the move a predictable rhythm - because the time between rebound and re-roll is always the same - so it's easier to time inputs to perform the move multiple times when hitting multiple blocks in a row.
• Finally it also helps to reduce variability in the outcome of the move. When Leilani does the re-roll she'll always be the same distance away from the thing she rebounded from, so it'll be more consistent whether she hits it again or not. There are still factors like Leilani's Y position that affects this, but it's better.

Here's a gif showing improved consistency:



As you can see, interactions with the blocks on the floor are now very consistent - Leilani will always hit the next block.

When hitting blocks in mid-air, it's a little more predictable, but if Leilani is at the peak of her jump when she rebounds off a block, it's still possible to scooch up on top of it after doing the re-roll.

It's worth mentioning that at this point, I was planning on this being a desirable feature! I liked the idea of being able to gain some extra height and climb up onto a block by hitting it and re-rolling onto it. However I ended up dropping this ability after doing some experiments.

Experiments

When the re-roll happens, Leilani is sent moving forwards at her maximum horizontal roll speed. Her vertical speed is also set to a fixed value. The original value for this vertical speed was very close to zero, so she'd shoot forwards mostly horizontally (and then begin falling due to gravity). I tried out some different values for the vertical speed to see how it felt.

Upwards velocity:


Giving Leilani an upwards boost allows her to chain more block hits together, and also makes it easier to get up on top of a block. It makes the consistency of the outcome of the move even worse though, as very subtle changes in Leilani's Y position will determine if she'll clear the top of the block or not.

MORE Upwards velocity:



An even bigger upwards boost is initially kinda fun to play with - it gives Leilani a lot of power to climb over blocks. It's also quite consistent as she'll basically always get boosted over the top of the block. However, this probably isn't very useful for the majority of gameplay situations when you probably just want to smash a row of blocks rather than getting over it. It's also not very in-keeping with Leilani's usual lack of agility.

Downwards velocity:



Here, Leilani is boosted downwards into the floor when she re-rolls. I wasn't initially expecting to like this, because as I previously mentioned I was hoping for the block-climbing aspect of the move to be kept in tact - but this version of the re-roll felt the most consistent and predictable. This is the version that I ended up sticking with!

Thanks for reading

[JobLeonard]

What if the upwards/downwards velocity depends on which power-up you're having? Makes thematic sense if the bubble power-up would have some upwards velocity, for example, and the fire one feels like it should fire straight forward like a rocket

EDIT: could mean certain level set-ups can break in weird ways if you don't anticipate certain power-ups at certain times though, I guess.

[Igor Sandman]

It's always a pleasure to follow in detail the progress you make on Leilani's Island.
The multiple roll to break through rocks is a smart idea.
The gifs make me wanna play it. The game feel seems smooth!

Good luck with your "private" beta test.

[Ishi]

Thanks Igor

What if the upwards/downwards velocity depends on which power-up you're having? Makes thematic sense if the bubble power-up would have some upwards velocity, for example, and the fire one feels like it should fire straight forward like a rocket

EDIT: could mean certain level set-ups can break in weird ways if you don't anticipate certain power-ups at certain times though, I guess.

I did consider this briefly at the time. These powerups already do kinda achieve the same thing anyway using their existing effects - the floaty bubble makes it easier to climb higher with wall jumps, and the fireball smashes through blocks without rebounding. So I think it's best to keep the re-roll ability itself the same across all the powerups. Thanks for the idea though!

[Ishi]

I continued various bits of polish and bugfix work this week. Here are some examples!

Fixing robot instant-kill

Jumping on a robot like this is supposed to stun them, and then a second jump will kill them. But sometimes they would die instantly!

Before


What was happening was that the robot was in mid-air to begin with, because it had just bounced off the block in front of it. The enemy would be stunned when Leilani jumped on it. Then, upon hitting the floor, it would take damage and die - this is meant to ensure that a stunned robot enemy that's jumped on in mid air will be destroyed when it hits the floor.

I fixed it by only doing the kill-when-hitting-the-floor code if the robot was already stunned when it was last bounced on.

After


This is another instance of my input recording feature being really useful - since the timing to recreate the bug is quite precise, I could recreate the bug once and then just play it back. After implementing the fix I can still play back the same recorded inputs to check the fix worked.

Changes to roll collision interactions - reducing chaos

Before


This gif demonstates a few different rolling interactions:

• Rolling soft object hits soft object: the roll is transferred to the second object
• Two rolling soft objects hit each other: they both stop
• Rolling hard object hits hard object: they both roll
• Two rolling hard objects hit each other: they both keep rolling

What I decided to tweak is the third interaction. This is the only interaction where the number of rolling objects increases - only one was rolling before, and after, both were rolling. In a situation where there are a few enemies around, this quickly devolves into chaos as before you know it, multiple enemies are rolling around, bouncing off each other. I think interactions are good, but not if they too-easily create a chaotic situation that the player can't predict.

After


So now, in the third interaction, the roll is transferred to the second object.

Rolling objects in small spaces

Rolling a hard object into a small space makes it bounce around like so:

Before


Since the space is so small, it's pretty easy to jump on the object to stop it rolling, at which point you can grab it. However, whenever I see this situation happen during playtesting it just annoys me! Looking back through my notebook I had written this down three times without getting around to doing anything about it. I mainly find the constant thudding noise is just distracting, and it seems silly to allow the object to bounce around without achieving anything.

After


The new behaviour is to stop rolling after a few bounces, which to me looks normal enough, and prevents me getting annoyed at it. Another solution of course it to avoid this kind of situation in the level design itself - but since players can carry objects around and roll them anywhere, it's not always possible to do this.

Since the object has to bounce a few times in the small space before it stops rolling, this does still give it chance to smash nearby blocks, in which case it'll keep rolling around the same as it used to.

After


Drill robot enemy death

As shown in some of the above gifs, the drill-nosed robot counts as a 'hard' object which means it ricochets back after rolling into a wall.

This is one of the more common robot enemies, and I feel like having it ricochet back whenever it's rolled is another cause for a lot of unpredictable chaos going on in levels. Of course it's the player's choice to roll into the enemy - they could instead kill it by bouncing on it a couple of times. But I want to encourage the use of rolling into the things, not punish the player by always having the thing they rolled into bounce back at them and hurt them.

I had an idea of a different way to handle it hitting the wall:

After


I think it's kinda funny to watch, and is also consistent with another drill-themed enemy, the spinning top:

Existing behaviour


The drill bot still ricochets back if it bounces off a breakable block or something similar - but sticks into non-interactive solid walls.

After


Thanks for reading!

[Tanz0rz]

You should do a devlog on how you create the sounds for your game. I just watched your video of the factory boss fight and I really liked all your sound design!

[Citsua]

I really love this devlog. I always find myself coming here when I'm losing motivation to work. Your focus and attention to detail are inspiring!

[Ishi]

I really love this devlog. I always find myself coming here when I'm losing motivation to work. Your focus and attention to detail are inspiring!

Nice of you to say, thanks!

You should do a devlog on how you create the sounds for your game. I just watched your video of the factory boss fight and I really liked all your sound design!

That's great to hear, thanks! I'm not sure how I would approach a devlog post specifically about the creation of sounds. In this post I briefly covered which sources and tools to create sounds. Generally, I either spend a lot of time hunting through freesound.org for a sound that seems to fit, or for synthesised sounds I spend a lot of time tweaking parameters to get something that sounds about right!

Beyond that I don't really have the vocabulary to describe the kinds of sounds I want to create or how I go about creating them - as it's mostly trial and error. My editing of existing audio files is also pretty limited - the most complex thing I'll do is make a sound loop seamlessly.

If you have any ideas of what I could talk about or more specific questions about the process I'm happy to try and answer!

[Ishi]

This week I continued ticking off items on my polish/bugfix todo list. This list was mainly generated from reading feedback from previous builds, as well as ideas I had recently. I've now finished this list! This includes improvements to the rope mechanic which I'll talk about later in this post.

Self-playthrough started

I've now started doing a full playthrough of the current state of the game. The idea is to look over all of the levels and content and make a new todo list of things I want to improve.

In the past I've done this by simply playing through and making notes along the way. However this can be really disruptive to play, as constantly pausing to make a note about something is time consuming and breaks the flow of play. What I'm doing this time is recording the playthrough using OBS. I have a headset with a microphone, so I've plugged that in to do a running commentary of any issues or improvements I think of while playing. Then I can watch the video back later and actually write down the notes.

So far I've spent 1h30 on the playthrough and made 4 1/2 pages of notes in my notebook! I estimate another hour of play to finish everything that's currently in the game. 2h30 will be a pretty good amount of playtime I think, considering I can rush through most of the levels since I know them already. And there's still more content to be added!

Rope improvements

One of the game's mechanics is tightropes. I've talked about them before here and here.

The general idea of the tightropes is that you can only travel along them while rolling. If you're not rolling, you'll fall through them. They also increase the height of your jump when you jump off them thanks to their springy nature.

Here's a very old gif of them in action (2015):



Rope problems

Apart from simply being a way to incorporate some mandatory rolling into the game mechanics, the ropes were originally intended to be interesting to traverse. Their very first iteration was very strict.

If you weren't rolling when you landed on the rope then you wouldn't connect with it. Note that jumping towards the rope, then holding the roll button (which causes you to crouch in mid air) didn't count. You had to be rolling before you even made the initial jump towards the rope. This was way too harsh and I changed it so you could roll on the rope as long as you had the roll button held, even if you're not technically rolling yet.

(A side note on the subject of the difference between rolling in mid air, and crouching in mid air. Most mechanics such as skimming on water surfaces or entering boost rings are also lenient and allow you to make use of the mechanic either way. But other mechanics more directly tied to the act of rolling - such as smashing into blocks, or sliding on a wall and wall jumping, do require you to be actually rolling in mid air, so you have to plan your movements a little more carefully in those cases.)

There's another way in which the original rope implementation was very strict. Normally when rolling, if you change direction, Leilani comes out of the roll and into a skidding state, and after slowing down, starts rolling in the opposite direction. It used to be that if you tried to change direction on a rope, because Leilani stops rolling and starts skidding, she'd just drop straight through the rope as she'd no longer collide with it!

My solution to this is something I grew to feel unhappy with. Leilani would instead do a weird mid-air skid which would prevent her from falling. She could then reconnect with the rope and start moving in the other direction. This can be seen in action in this gif from a 2018 version of the game:



It's super lenient, but I think this makes the ropes less interesting than they could be. As long as you're holding the roll button, they pretty much turn into normal platforms that you don't have to put much thought into using.

Also, the level shown here was meant to be a crazy downhill ride down the rope network, more like something you'd see in a Donkey Kong Country game - but since you can turn around at any point and roll back up the ropes it loses a lot of the tension.

Changes to hopefully improve ropes

I decided to go all-out and make some bold changes, which so far I'm enjoying the results of.

Firstly: you can no longer roll uphill on ropes. You'll quickly slow down and turn back the other way. Jumping on ropes while travelling uphill also doesn't grant you the full bounce height and springs you back in the downhill direction. Note that this applies to enemies rolling on ropes too!



I think this behaviour fits, as you'd expect rolling on a tightrope to be quite a precarious situation where you don't have full control, so if a rope is placed at an angle, gravity will take over and force you downhill.

Secondly: you can no longer turn around on ropes. If you press back in the opposite direction, you'll slow down but keep travelling. In the gif below you can see Leilani slow down for some time, once she reaches the halfway point on the rope.



This gives the player a bit of control over how they traverse the rope but without giving them complete freedom. On a flat rope you can still jump up into the air, turn around, and roll the other way. But on downhill ropes the best you can do is slow yourself down.

Bonus improvement - ropes between moving platforms

I was reworking the sinking platforms level. The second part of this level made minimal use of ropes attached to sinking platforms. They weren't very interesting, partly because the rope could only be attached to a single moving/sinking platform. The rope is a single entity and could only be pinned to a single moving platform like so:


(This is one moving platform even though it's split into two parts - the left and right side can't move independently)

The natural improvement is to allow ropes to be strung between different moving platforms!



This was achieved by creating a new entity type - a rope anchor. The rope itself is pinned to the left-hand moving platform. The anchor point is pinned to the right-hand moving platform. The rope entity is linked up to the anchor, and each frame the rope's end point is changed to match the position of the anchor entity.

This can create interesting situations where the slope of the rope changes, as shown above, so you have to time when you travel across it.

Ropes between sinking platforms

Sinking platforms are just moving platforms with some extra code - so the changes above already allowed ropes to be strung between sinking platforms.

However they did need some special attention to determine when they should cause the sinking platform to sink! Normally the sinking platform sinks if there are any entities contacting it. It also sinks if there are any entities contacting other entities that are pinned to the sinking platform! So if Leilani was on a rope attached to a sinking platform, it would cause the sinking platform to sink.

This would no longer work correctly as the rope would always cause the left-hand sinking platform to sink - because that's the only sinking platform the rope is pinned to. Don't forget it's the invisible anchor entity that is pinned to the right-hand sinking platform.

The rope and rope anchor now have their own implementation of the 'how many entities are contacting me' function that all entities have. If the anchor is queried, then it just asks the rope entity for the answer. Entities on the left side of the rope affect the left-hand sinking platform and the same for the right side.



And one more hack is in there. If the gradient of the rope becomes too steep then it pretends there are entities on it, causing one of the sinking platforms to sink. This is a totally faked and hacky method of making it look like the tension in the stretched rope is pulling down the sinking platform that's higher up. It works pretty well in simple situations!

Thanks for reading!

[RealScaniX]

Wow! That's an awesome update. "The history of ropes"
It's always interesting to see the progress of a feature over such a long time and the changes that were applied to it during that time.
I think the ropes have improved a lot over time and although it seems fun to jump around on them without limits, it needs to work with the level design.

[JobLeonard]

So is it possible to

- roll on a rope attached to two out-of-sync moving platform
- jump
- unroll
- reverse direction
- do the previous three things at just the right time for the rope to change "direction" too
- land and resume rolling in the other direction

Because that would be quite the pro-gamer move

[Ishi]

So is it possible to

- roll on a rope attached to two out-of-sync moving platform
- jump
- unroll
- reverse direction
- do the previous three things at just the right time for the rope to change "direction" too
- land and resume rolling in the other direction

Because that would be quite the pro-gamer move

It certainly is! Though as shown later in the gif you can also just let the rope change your direction and gently rock Leilani to sleep.

[fall_ark]

There are so many things that I feel you HAVE to include in the inevitable trailer / store page gifs because they are so slick and smooth. Each update has like 2 or 3 candidates. I won't be able to handle NOT seeing them when the game releases...

[JobLeonard]

It certainly is! Though as shown later in the gif you can also just let the rope change your direction and gently rock Leilani to sleep.

Ah, I was under the impression (based on the description of having to time your roll) that you'd fall off the rope

[Ishi]

It certainly is! Though as shown later in the gif you can also just let the rope change your direction and gently rock Leilani to sleep.

Ah, I was under the impression (based on the description of having to time your roll) that you'd fall off the rope

Yeah, as long as you're holding the roll button you won't fall off the rope - that felt like it'd be too harsh especially above instant death pits / lava. But as with a normal stationary uphill rope, Leilani will be turned around.

[linebyline]

Does the steepness of the rope slope matter? That is, can Leilani roll up shallower slopes, or at least make it farther before she starts reversing direction, or is it strictly a matter of reversing her after a set time or distance whenever she's rolling uphill?