Monthly Update #41 đŚ
Happy Thanksgiving, Sleepyheads! đŚ I hope all of you that celebrate were able to enjoy the holiday with friends, family, and loved ones. I took the day off and relaxed, which was very welcome because Iâve been working long hours lately to try to pack as much as I can in these last few months before the game releases. Also, because itâs perfectly topical, a fun strip from the original Little Nemo comics:
While there isnât a Turkey Kaiju in Little Nemo and the Guardians of Slumberland, there is a kaiju! If youâve been reading the spoilers, you might know who Iâm referring to, but Iâll leave it at that for those that are avoiding spoilers. But talk of kaiju does segue nicely into a topic I wanted to cover this monthâŚ
Boss Design of Little Nemo
Something I havenât talked about much yet is the boss design philosophy of Little Nemo. I want to talk a little bit about this more generally, and also focus on one of the bosses and how it executes on my design intentions for the bosses. I think we can safely take a look at the Rocktopus boss fight since this is the first boss encounter which many of you may have already played through in the demo. Also, as a little aside, this is a great example of how scope creep has affected Nemo development: before the Kickstarter, I wasnât planning on having any bosses in the game. I bring this up because I think itâs kind of relevant to the discussion for a few reasons:
- Most metroidvanias have bosses, but they also are usually more combat focused and both you and the boss tend to have large health bars. Although Nemo is a metroidvania, it plays much more like a platformer, which even when they do have bosses, they tend to be a bit different from those youâd see in a metroidvania.
- I also tend to not enjoy bosses in metroidvanias (and similarly in souls-likes) as much as others seem to. I know these are often the appeal for players of both metroidvanias and souls-likes, but for me Iâm often playing those types of games because I enjoy how the combat difficulty is overlaid and balanced with the exploration. In those contexts, bosses do provide an interesting point of danger to discourage reckless exploration, but ultimately the encounters tend to be less fun for me than simply battling enemies while exploring.
So why did I decide to introduce bosses to Nemo? Well, ultimately I decided that:
- I thought I could make bosses that I would enjoy by referencing platformers for inspiration.
- I was worried a boss-less metroidvania might simply be a non-starter for a lot of players.
So when approaching bosses, I essentially have two general models in my head: the types of bosses that are often found in metroidvanias that would not be a good fit for Nemo (weâll use the Legion boss fight in Symphony of the Night as âbadâ example of a fight that would not go well in Nemo) and boss fights that better fit a game where you can only take 3 hits before âdyingâ and which has a stronger focus on platforming (weâll use Super Mario Odysseyâs Torque Drift battle as an example of a boss battle that I think is more appropriate).
In general, Iâve found platformers like Mario and Kirby tend to have better boss examples for Nemo to reference, than most metroidvanias do. And there are a few things they tend to do which youâll notice in the Nemo bosses:
- They focus on using some new ability youâve recently gained and pushing your understanding of how to use it fully.
- They have 3 distinct phases. This allows them to become less of a slug fest, and more about learning how to defeat the boss. The boss becomes vulnerable at some point in each phase, and you perhaps only need to hit it once to move to the next phase.
- They tend to be based on some deterministic pattern. This has the (imo) downside of making the boss feel like something youâre memorizing, but when you can only take a few hits, randomly generated patterns start to feel a bit meaner.
In the Legion boss fight you need to keep whaling on the boss until you deplete the health bar, while the Torque Drift fight is about taking the platformer gameplay from the rest of the level and applying it to a boss context.
So with all of this in mind, letâs see how it applies toâŚ
The Rocktopus đިđ
When you encounter the Rocktopus, you havenât even acquired your first toy yet. The goal here is to make sure that youâve built up some understanding and expertise with Nemoâs most basic innate abilities: running, jumping, and throwing.
Nemo dodging the Rocktopusâ tentacles in the first phase of the battle
To do this, the Rocktopus sends a series of tentacle attacks your way. Each one has a bit of telegraphing (rocks shaking loose before the tentacle emerges) because ideally the player is reacting to each tentacle rather than memorizing the pattern. But all you can do right now is avoid the tentacles. The Rocktopusâ face is vulnerable at this point, but Nemo does not have any innate attack abilities except to throw something. So once the Rocktopus throws a rock at you, you finally see your opportunity to retaliate, thus ending that phase.
Nemo tossing a rock back at the Rocktopus
And thatâs the general flow of the encounter. You do this 3 times, and each time the patterns get a little more difficult to avoid. The focus here is the platforming challenge of dodging the tentacles and ensuring the player has a good sense of how to use our core mobility options before moving on.
Other Bosses đš
Iâm not going to spoil any of the other bosses here, but they all tend to follow this general blueprint of: find a fun and interesting way to force the player to express a bit of skill with the toy theyâve recently acquired in a 3-phase battle with each phase slightly building upon the difficulty.
This all ties into something that I think sets Little Nemo apart from most other metroidvanias. I tend to try to describe it as a âplatforming-centric metroidvaniaâ, but subtle distinctions in design philosophy like this are hard to convey in so few words. Ultimately, what I think this boils down to is that despite the non-linear nature of the game and the focus on exploration, in a lot of ways, Nemo has more in common with a Mario or Kirby game.
What I worked on this month đ ď¸
Okay, so that was a fun look at some of my thinking and design philosophy, but what have I been working on with the game this month?! Of course Iâve been doing lots of level design and boss polish to get things ready for some more thorough playtesting of the full game, but there are also some distinct things I worked on that are kind of exciting to share. And while Iâm not going heavy with the spoilers here, there is some stuff sprinkled throughout that some people might want to avoid if theyâre avoiding spoilers so youâve been warned:
Spoilers Ahead âđâ
Flip Phone đą
Thereâs a small thing about Little Nemo that had been slightly nagging me for a while, but hadnât ever really come to any conclusion, and thatâs the way we need to insert Flip into the world any time we want to convey some information to the player. Previously Flip was getting a bit overloaded with duties of sharing knowledge with the player, and while watching people play the demo, there was clearly a bit of Flip fatigue. Players would just stop talking to Flip because they didnât want to get too many back-to-back info dumps, but at the start of the game, thereâs a lot of info to share with the player.
The first thing I did to alleviate this was introduce another idea that had been floating around for a while, and thatâs the Powerline to the Professor Kiosks (which you can see in Monthly Update #39. This allows Flip to focus more on helping establish the general setting and narrative elements, while these kiosks can provide hints and tips about how to better use the tools available to you.
But there is still the awkwardness of needing to physically place Flip into the world for Nemo to talk to her. To help smooth out this awkwardness, we introduced an animation where Flip jumps into her 8-ball to teleport to make it clear that she has ways of getting around the world that are not available to the player. But what if we want Flip to talk to Nemo about something that happens dynamically, and possibly anywhere in the world? Iâm thinking about how something kind of like Navi from Ocarina of Time could be useful if it were perhaps a little less annoying. Some way that Flip could somewhat always be with the player. And so we arrived at the Flip Phone.
When Flip calls Nemo, the 8-ball will appear in the lower right corner of the screen accompanied by a ringtone chime
When we first meet Flip, sheâll give Nemo a matching 8-ball, which in perfect dream logic fashion can be used to communicate. Anytime Flip has something to say to the player, the 8-ball will ring and the player has the option to answer the phone to get a tip or other bit of info from Flip. For you playtesters out there, the next time you play, youâll immediately notice some conversations which previously had Flip just standing there waiting, are now replaced by phone calls. One example where I think this works much better is when you try entering an area that is a late-game domain. Flip now calls to explain why you should consider waiting to enter that domain, which I think feels a bit more natural than having her standing there waiting for you.
Revisiting the Bubble Wand đŤ§
One thing that has come up when playtesting is that players donât use the Bubble Wand very often. I should explain, I hadnât been too worried about this previously because the Bubble Wand was really designed with struggling players in mind. I wanted to give those players a button to press when they were in danger and struggling to otherwise react in time. But it became more clearly a problem as I watched players struggle through difficult areas without ever turning to the Bubble Wand to help them through it.
If even the players it is most meant to help arenât using it, then itâs not doing its job. I decided the best way to help with this would be to try to a) make the bubble wand more useful and b) just make it generally more fun to use. The Bubble Wand previously was certainly useful, but it was absolutely not fun. It has a cute animation that Iâm happy with, but when youâre holding the button, your only option for inputs is to release the button to stop being bubbled.
So to address these things, I added 2 (or I suppose 2 and a half) new features of the Bubble Wand.
- You can now press left or right to dodge in that direction while bubbling. This doesnât actually make the wand much more powerful than it was before, but it does give you some options while youâre bubbled, which I think makes it more fun and interesting. And there is a little bit of skill expression involved with this (avoiding a hit by dodging vs letting the bubble absorb the hit and get popped), but not so much more that I worry about widening the skill gap too much for this toy (which is why there is no âparryâ function of the Bubble Wand).
- When blocking a projectile with the bubble, that projectile will now get âbubbled upâ. It will still pop your bubble, but previously that projectile would continue on (which for the bouncing spores could mean it bouncing off a wall and coming back at you again), so this does make it quite a bit stronger. It essentially destroys any projectiles that you block with it (this doesnât work on every projectile, but just about any of them that you imagine could get bubbled up, can get bubbled up).
- And hereâs the âhalfâ feature I mentioned: once youâve bubbled up a projectile, you can hit it with your whip or pogo stick to shoot out a projectile of your own that will damage enemies. Itâs not especially useful, but itâs just a fun little detail that hopefully gives the player a reason to want to use Bubble Wand a little more.
Nemo using the new features of the Bubble Wand to avoid damage
Itâs pretty late in the game to be overhauling one of the toy abilities in the game, but I designed these changes in a way that it shouldnât upset the balance of any encounters too much or generally upset game balance.
Checkpoint Names đď¸
This is a relatively small detail that I had maybe considered before, but it wasnât until recently that I was sold on the idea of how much it might improve the game, and thatâs names for each checkpoint (or bed) in the game. As with the Bubble Wand changes, this may seem like a big change to be adding so late to the game, but I am somewhat proud of the fact that the Little Nemo codebase is easy enough to work in that adding a feature like this was relatively trivial and I was able to do it in a matter of hours (it did take me all day, but that was because it took some time to come up with names I liked for every single checkpoint in the game).
So where do we see these names? Whenever you touch a bed and get the âCheckpointâ announcement in the upper right of the screen it will also say the name of the checkpoint.
The name of the checkpoint appearing in the upper right of the screen when reaching a bed
But more importantly, these names will appear when youâre using the map in Nemoâs bedroom to select which bed you want to arrive at.
The names of the checkpoints will also appear on the map when weâre in Nemoâs bedroom and using the map to select which bed to arrive at in Slumberland
There are several reasons I wanted to do this, but generally my hope is that it will a) help players find the correct bed theyâre looking for (I have to remember that players wonât be as intimately familiar with the world layout as I am), and b) that this will just help give a bit of flavor and fun, whimsical detailing to the world. In some cases the names just add a bit of flavor (e.g. âHushed Highlandsâ is the upper part of the Dreamswept Plains leading to the Valley of Silence), while others might actually give some helpful details (e.g. âRoyal Icing Junctionâ is the area that connects the Gumdrop Gardens to the Palace).
Overall Iâm pretty happy with what this feature adds to the game relative to the amount of effort it took from me.
Other Miscellanea đ
And thereâs a bunch of other small things that I did this month that Iâll just rapid fire share because theyâre kind of interesting or exciting:
đ
I fixed a bug that was hidden in my chunking logic for a while. Occasionally players found scenarios where they wound up in a chunk before it was fully loaded. The chunking logic was supposed to pause the game if any chunk came on screen that wasnât ready for the player (this can happen if you move so fast that you get to a chunk before its loaded, Breath of the Wild does this for instance if you use glitches to move exceptionally fast). I figured out how and why this was happening and fixed it, so now if an unloaded chunk makes it onto the screen at all (usually itâll just be a few pixels along one edge if this does happen), the game will properly pause and wait for that chunk to fully load in before unpausing.
BEFORE FIX: Hereâs Nemo falling into a chunk that didnât finish loading in time
AFTER FIX: And with the appropriate fix here, as soon as that unloaded chunk shows up on screen (the small area in the lower right corner) we pause for a moment until it loads in
âĄ
The main way players have been able to trigger the above bug is by falling. Nemoâs terminal velocity is fairly high, so if you fall for a bit, you can get moving pretty fast and get to some chunks before theyâve had time to load in and get prepared. Your terminal velocity is a function of your gravity and your air resistance, but since I didnât want to muck about with Nemoâs gravity or air resistance values (Iâm happy with how Nemo feels to run and jump in general), I simply added a manual terminal velocity. Most of the time you wonât notice this at all, but if you fall from a great height, it does make a very noticeable difference to how fast youâll be falling.
đĄ
I hadnât been very happy with the lighting in the Valley of Silence, so I revisited them and hereâs a look at how some different room types are looking in this domain:
The default lighting option is a bit less snowy and more of a daytime lighting, while the darker, heavier snow has leaned into being a dusk setting a bit more, and the caverns are better lit now as well
đ
Thereâs something thatâs been kind of nagging at me for some time: when we pause the game to enter the pause menus or dialogue scenes, I like maintaining all of the post processing we are using except the bloom. This is because the bloom can be directly controlled by the lighting system, so different environment types might use more or less bloom. When in areas that use a lot of bloom, the pause screen could get very blown out and look pretty bad. It turned out this was an easy solution, so Iâm glad I finally sat down to address it. The pause and dialogue scenes look much nicer and more consistent across different environments.
â¸ď¸
Speaking of pausing, thereâs another pause-related thing that I had noticed when profiling the map screen performance: when you pause the game, the world of Slumberland is still all active (albeit paused) behind the UI. This means weâre making draw calls to render everything before the pause UI renders over top of it. This is about as silly and easy an optimization as you might think: I just need to disable the âworldâ of Slumberland when we pause, and so Iâve done that. One thing Iâll need to keep an eye out for is there is a quirk (Iâd call it a bug) of the Unity Animator that if you disable a GameObject, it will change what the Animator considers that objectâs default properties. There is a field on Animators to override that quirk, but itâs not enabled by default, so Iâll just have to keep an eye out for things which might now have their animators messed up due to pausing (I caught one right off the bat, but thatâs it so far).
Here in the editor view you can see the game world still visible behind our pause screen before the fix
Until Next Month đ
Thanks for reading along, Sleepyheads. Iâd love to hear what you thought about this update, and what youâd like to read about in the next few more updates weâll have before release. Weâll have one more update this year at the end of December, and then weâll be heading into Q1 2026 and thus into our potential release window! If you havenât been following too closely, we still havenât announced an exact release date, but weâre getting pretty certain about a specific date, so I might share that with all of you backers ahead of an official announcement once that fully firms up. So stay tuned, and as always, donât be afraid to hop into our Discord to hang out with me and other Sleepyheads!
-Dave
