...
Browse GamesSteam news
Full Steam announcements and update articles for this title.
v1.0.7 is now available and includes plenty of changes. While most of these will be hard to spot, there is one big feature I'm very excited to share:
The Powerline to the Professor kiosks that you'll find throughout Slumberland provide tutorial tips and helpful hints about some of Slumberland's bigger secrets. But for those of you trying to find every last secret hidden in Slumberland, you'd probably appreciate a little more help. With this update, once you've completed the true ending to the game's story, you'll find a new option when visiting Powerline kiosks. For 50 candy, you can use Game Genius™, which will add an indicator to your map somewhere in Slumberland where there's a secret you haven't yet found. The indicator is easy to spot, so you can't miss it, and you can have as many active at a time as you can afford to purchase. This feature will be disabled if you don't have 50 candy, or if you've already discovered every secret area in Slumberland.
I hope this helps everyone push through to 100% completion and collecting all of the game's achievements!
But of course that's not all that's in this update. You may have noticed that, despite being relatively the same size, this particular update is quite large. That's because there have been some pretty big under-the-hood changes:
With this update, the game is moving from Unity 2022.3 to Unity 6.4. This is quite a big jump that resulted in lots of changes (such as moving over to using Render Graph for the dynamic fluid simulation effects used throughout the game), but the only thing that you should notice is the removal of the Unity splash screen on launch (this was previously a requirement that has since been removed).
Unity's Addressables System manages how the game content gets bundled up and loaded into memory at runtime. While working on the game's Switch port, I discovered some big flaws in how things were structured. This overhaul is what contributed the most to the large update size (changing any addressable bundle requires that bundle to be re-downloaded, and they basically all had changes), but it results in much lower memory being used by the game. If you already had plenty of memory, you likely didn't notice this, but there are hardware scenarios where this will result in big performance improvements.
Before unlocking Game Genius™, the Professor will now also be better at giving you tips to help you finish the true ending to the game if you're having trouble finding where to go after defeating the final boss
The Blue Moon to the right of the bed found west of the Great Mushroom Tree has been made easier to collect (it was missing Silas' tag and the one-tile wide entrance was unnecessarily difficult to enter, so it was made two-tiles wide)
Fixed Flip often not showing up to chat with Nemo after starting on the Photo Hunt adventure, or to remind Nemo to grab the camera before setting out
Various tweaks to the world to help smooth out awkward camera corner transitions
Fix for dialogue not working when you start a game in Nemo's bedroom and try to read the Kickstarter backer plaque
Moved the option to view the credits to the "Extras" section of the menu
Added the full version (including patch/revision number) to the "Support & URLs" section of the menu
Fixed the URL for bug reports to point to the public Discord channel rather than the private playtesting channel
Improved the blur effect used for the pause menu background to be resolution independent (it's using a reference resolution of 1920x1080, so if you were already playing in 1080p, you shouldn't see a difference)
Removed the anti-aliasing setting and leave AA disabled, except during the wake up animation which does use 3D geometry for the shattering effect
Add a velocity emitter to Nemo in the Music Player so you'll see the "Space Fluid" effect when playing relevant songs
Change all sound effects to load in the background and preload the data (should result in less stuttering)
Change all music to Streaming playback mode with a more optimized sample rate
Various minor bug fixes and probably some stuff I forgot to include in this list because it was a big one
Okay, I think that's everything for now. I've been making great progress recently addressing traversal stutters, so keep an eye out for another update coming soon which should make playing on the Steam Deck much more pleasant. Thanks for reading, Sleepyheads!
-Dave
I just wanted to share some updates in case you haven't been following the patch notes. The two major features that were missing at launch are now available: the in-game Music Player and Achievements! There have also been loads of smaller bug fixes, performance improvements, and other helpful quality of life tweaks throughout the last few patches, and more are on the way.
Both of the above-mentioned features will respect the progress you've already made with the game, so you can hop right in and listen to any of the Music Tracks you've already collected throughout Slumberland, and your achievements will be logged as soon as you load up your save file.
In the near future I will mostly be focused on performance optimizations and bug fixes to make sure everything is all lined up for the Switch port, but I also have some more post-launch features I am planning to introduce, so stay tuned! Thanks for reading, Sleepyheads.
-Dave
Yes. If you played during Steam Next Fest, that build is fairly similar to what we’re releasing today and those save files will work fine. There have been some minor changes (items moved around, dialogue changed, etc.), but you shouldn’t have any issues taking that save and continuing on from there.
If you played a version of the demo older than this recent Steam Next Demo, you will have the option to go ahead and try to use your existing save slot, but I highly recommend just deleting your old save and starting a new one in this case. Both because you’ll want a refresher on what you were doing exactly, but also because a lot might have changed since you last played and it might cause weirdness in your save file.
Steam Achievements are coming! And don’t feel the need to wait, your progress is all being stored in your save file, so when the Steam Achievements get implemented, your progress with them will be registered. I hope to get these all wrapped up very soon, but I didn’t want to rush it for launch. I’m not an achievement hunter myself, so I’ve been trying to get as much insight from others as possible to make sure the achievements are a fun and worthwhile addition to the game that will help give you a reason to dive back into the game for more after finishing the main story.
First off, if you’re finding these, nice work! These tend to be hidden fairly well throughout Slumberland, so you’ll need to be keeping a close eye out for secrets to find them. The bad news is, the in-game music player isn’t quite ready yet. This was something I was hoping to get in for launch, so I went ahead and made sure all the cassettes were in place in the world, but I need just a bit more time before I get the music player in the game. Expect this in an update very soon and when it’s live, you’ll be able to listen to any of the Music Tracks you’ve already collected. Sorry for the delay on that.
The 10% launch discount will last for 7 days. The demo will also stay up during this period, but if you’re interested in checking out the game, please do so this week because I will also probably be taking the demo down at the end of the first week. As I continue to update and patch the game, keeping the demo up to date is no small task for a single person. So please play and consider purchasing Little Nemo sometime this week!
I know most of you reading likely won't be attending GDC since it is an industry event, but if you are there, please make sure to stop and say hi if you spot me! It would be really cool to meet anyone that's backed the game or even just enjoyed playing the demo in Steam Next Fest.
The goal of attending this is just to kind of get myself out into the game dev scene. I’ve been pretty heads down just working on Little Nemo for many years now, but once I wrap it up later this year, I’ll be trying to figure out what’s next for me and for DIE SOFT. This isn’t super relevant to Little Nemo, but I just wanted to share this because it’s all part of game dev I suppose, and I like sharing a peek behind the curtain.
Little Nemo is officially in Steam Next Fest with a freshly updated demo, so come check it out. If you've played the demo before, you might notice a few new features and systems that weren't there before. For those of you that like a good challenge, when choosing the "Challenging" difficulty, you'll be able to Rank Up if you fill up your Moon Meter without getting hit. See if you can beat the first boss while at Max Rank!
And for those that want a slightly more easy-going experience, the "Comfortable" difficulty setting (still working on the exact naming for that mode) disables the Rank Up mode entirely so you don't have to worry about the game dynamically increasing in difficulty, and you'll also be able to withstand twice as many hits.
There's some new characters and interactions in here as well: Flip now provides you with a Magic 8 Ball so you two can stay in touch at all times, and you'll also spot some Hotline booths, the "Powerline to the Professor", where you can get in-game tips from the Professor.
Please give it a spin and let me know what you think!
So in this update, what I want to talk about is the process of getting the sound effects created and implemented in the game. But before I get into that process, it would probably help for me to give some context about the systems I’ve designed for the sound in the game.
The sound effects (represented in this editor view above by the white icons) on camera will be at full volume, while the one just off camera on the right will be quieter and panned slightly to the right ear.
Voice Sound Effects The sound channel for the voices has a lot more filters available to tweak. But rather than being location specific, these get tweaked based on whoever is currently speaking. Each actor has a defined voice, which is a combination of audio clips (one for each letter) and parameters for the channel’s filters.Interface and Ambient The interface and ambient audio channels are a bit simpler as these don’t need any type of filtering or spatial considerations. These sound effects just get slotted in pretty simply. And for clarity, ambient audio is the stuff you probably don’t even know is there: the very gentle sound of wind in the Dreamswept Plains, the gentle trickling of water from nearby fountains in the Palace exteriors, the distant din of car and foot traffic in Nightlight City.Okay, so with that context set, what does the process actually look like?Here’s a pic of the most recent doc I sent to Jonathan that we’ve been working from
Making the Clips From here, Jonathan will create sound effects for each specific item I have called out, usually with several different versions to try out. Usually at least one of these will be perfect, but if not, I can mark it in our shared document that it needs further revisions. I can’t say too much about his process in this step, but if anyone is interested to know more please let me know in the comments and I can talk to him and get more details about how the .wav files actually get made.Implementing in Unity When I’m testing out new sound effects, ideally it’s a simple use case of “this sound fires whenever this thing happens”. Those are typically very easy to implement, and it looks something like this:Bring one or more .wav files into Unity as Audio Clip assets.
Create a Sound Effect asset, which uses those Audio Clips. If there are multiple clips, it’s typically something like footsteps which want several variations so that we can randomly select one each time the sound effect is used. This Sound Effect asset is important because, not only can a sound require multiple Audio Clips, but it also has associated data such as the playback volume.
And finally there’s the triggering of that Sound Effect in one of our few most common ways: include it in a effect prefab (these are our effects which are generally used for effects that have some visual element), or include it in an object’s sound effect collection to be referenced from that object’s Animator.
While you can't hear the humming in this screenshot, you might be able to tell that the contrast is increased due to Nemo being so close to the Oblivion.
Looping Audio More Generally Looping audio in other scenarios has important considerations about when and how it starts and stops. For simple audio loops, the Sound Effect has a “Should Loop” property you can check. That loop will continue until told to stop or the entity responsible for emitting it is gone. But loops suddenly starting at full volume, and then later abruptly ending, tend to sound bad. So in a lot of cases we use a custom subclass of the SoundEffect which is a FadeInOutLoopingSoundEffect (it does what it sounds like it does). I used this very recently while working with Jonathan’s sound effects for the Crystal Cruncher boss’ idling engine noise. The sound effect is fairly loud and helps communicate which sub-phase you are in (is the core vulnerable or not) based on whether or not it’s running. But if we just stop the sound without fading it out (even very briefly) it’s very jarring.Surface Effects Another common need is a sound when something collides with a floor or a wall. This gets a bit more generally into our Surface Effects systems, which also includes visual effects like having different bits of grass, snow, or dust kick up when walking on a surface, but without going into those details, we can simply hook into that system to specify that some objects should make sounds when making horizontal and/or vertical collisions. A good example of this is the breakable gems which appear in the Palace. In an effort to communicate that they can and should be shattered, they make a crystalline sound whenever bouncing off a floor or wall.Here's another in-editor screenshot in which you can see the gem emitting a sound effect right where it's hit the wall.
There are probably some other minor variations of how the diegetic sound effects get implemented, but I think that helps give a sense of how much their implementation can vary. The sound effects used for interface elements, ambient sounds, and the voices are all much more straight-forward. Interface sounds are typically immediate and momentary, ambient sounds are just looped with the volume attenuated based on how much screen space that type of environment takes up, and voice sound effects are all implemented in the same way so that I can just slot new clips in for new voices.But hopefully that helps paint a picture for the general workflow and process that goes into getting sound effects into Little Nemo! Let me know what you thought of this deep dive. Did I go into enough detail, too much detail, not touch on a particular aspect you’re more curious about? These are fun to dig into so I’m happy to share more details!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…
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. (And I apologize for the quality of the gifs below, but I'm limited with what I can use for inline animations here on Steam)
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.
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.
Thank you for reading and following along. Please leave a comment and let me know if there are aspects of the game you'd like to hear about next month! Until then, Sleepyheads!
-Dave
I know we’ve already looked at the enemies in 🎃Haunted Hollow🎃, but seeing as today is Halloween, I figured we should definitely take another look at this domain. There are some spoilers in here, so if you're trying to go into the game blind you'll want to pass on this one.
I’ve covered a bit about this domain’s Guardian and quest in the past, but I wanted to dig in a bit more about how this all works. But first, meet Alex, the domain’s Guardian:
Alex is seemingly the only Guardian that hasn’t lost control of his domain. He still has his scepter and has not been transformed. But that doesn’t mean your job is done because Alex asks you to do something for him before he’ll help you recall your core memory of Haunted Hollow. Specifically, you’ll need to bring Alex game cartridges for his Super Dreamstation 32 video game console. These are some retro games that his dad really likes, so he's curious to try them out.
By the time you reach Alex, you may have already encountered one or more of these cartridges out in your travels because they are located throughout Slumberland. Once you’ve met Alex, you’ll be able to carry these back to him, but it’s a bit trickier than you might think. When you’re holding something in your hands, you’re unable to do things like dangle from monkey bars, use your pogo stick, or attack enemies with your yo-yo. Making it back to Alex from wherever you find these is a bit of an adventure unto itself for each one and will require some deliberate pathfinding on your part.
So rather than battling a boss here, you’ll instead have a long-running quest. You could go ahead and try to get started on it right away (Alex will point you towards the one cartridge location he knows of from the start) or just keep track of cartridges as you find them. They’ll be marked on your map once you spot them, so you can always come back to grab them later. I hope this is a nice change of pace from a boss fight, and that you’ll explore Haunted Hollow for ideal routes back to Alex while carrying a cartridge.
Once you’ve brought Alex enough cartridges such that he helps you push back the Oblivion, he’ll also offer to sell you some new pajamas, the Ghoulish PJs 💀. With these spooky PJs, you’ll fit right in at Haunted Hollow. Here’s a quick look at how they work currently:
And the in-game description:
These PJs were once worn by a lucid dreamer and allow you to ride the line between being awake and asleep. Buff - Unawake You do not suffer any damage from enemies, but hazards always wake you up in a single hit.
I made these pretty strong for the first pass, and the reaction was about as expected (playtesters that got these PJs usually responded with something along the lines of “wow, these seem busted!”). So from here I think I do need to tone these down to bring them more in line with other PJs. While I think the one-hit wake-up from hazards is very punishing (maybe more so than players realize at first), I don’t want these to even feel broken. While it’s fun to abuse mechanics and for players to try to “break” the game, if you have one set of PJs that players think is way better than the others, it just removes the decision about which PJs to wear, and the goal is for the players “load out” (PJs and Little Buddy) to always be something they should be considering. So we need a fair balance of pros and cons with this ability.
And here's some changes I’m thinking of making to this:
You'll still actually get hit by enemies (and thus knockback and hit-stun), you just won't receive any damage from those hits.
Projectiles get treated as hazards and can also one-shot you.
I’ll test these approaches out and maybe it just needs one or the other, or maybe it needs both. We’ll see how it goes in the next round of playtesting!
The last thing I’ll dig into here that’s kind of cool about Haunted Hollow is how the lighting in the game works, because there are a lot of dark areas in Haunted Hollow. If it gets completely dark, you won’t see anything except outlines of your character and enemies.
This of course makes it very difficult to navigate, so you’re gonna want some light. There are sometimes lanterns strewn about to help you see, and there’s even some enemies that emit light, though you’ll have to avoid destroying them if you want them to keep lighting everything up for you.
But probably what you’ll need to do most of the time is carry a jack-o-lantern around with you. These are a great source of light and allow you to see to navigate through the dark areas, but as we mentioned above with the cartridges, not having your hands free can be a problem. And besides, what if you’re trying to carry a video game cartridge through Haunted Hollow to Alex? In that case you’d definitely benefit from having a Little Buddy that can help you see in the dark, so make sure to explore Slumberland and keep an eye out for clues!
So what do you think of Haunted Hollow? Did you enjoy this domain-specific overview? Please let me know in the comments below! As a big fan of all things Halloween, I always knew from the get-go that Little Nemo was gonna have to include a Halloween-themed dream domain so it's fun to get to show it off a bit ahead of release. 🎃
Everyone seemed to enjoy seeing more about the behind-the-scenes process stuff I shared in last month’s making an enemy update. So I thought I would continue with something similar this month and show what goes into making a pair of Nemo’s pajamas.
In Little Nemo and the Guardians of Slumberland, PJs are one of the major upgrade items you can find or purchase throughout Slumberland. Each pair is unique and provides a passive buff as well as a new color scheme for Nemo. You can swap out which PJs you have equipped at any dresser (so when you’re back in your bedroom is a great time to reevaluate which PJs you should be wearing).
In terms of the power level of the buff the pajamas provide, the goal is for all PJs to feel equally useful and balanced, while ensuring each buff is completely distinct from any other. And in terms of how I think about the PJ buffs in terms of how they compare to other major upgrade items, it’s something like this:
Toys grant entirely new abilities that are transformative and affect combat and traversability. Used as a gating mechanic.
Little Buddies are much less powerful abilities, but should be very unique abilities unlike any others you have. No parts of the map should be gated by having these, but some areas or lore might be soft-gated by them.
PJs are like Little Buddies in that they are not transformative the way Toys are, but unlike Buddies, their buffs should enhance some existing ability you already have in some worthwhile way.
Okay, so with that context in mind, let’s talk about how I create a specific pair of PJs. Specifically, we’ll go through the process I went through in making the Dino PJs.
I want each Guardian to have a pair of PJs that matches them, and since there is a Dinosaur-themed Guardian, that means we will have the opportunity to get some Dino PJs at some point in the game. So the first thing to do is to pin down a visual identity for these PJs…
PJs take advantage of the dynamic sprite re-coloring system I’ve built for Little Nemo (read more about that here), so we need to come up with a palette that somewhat matches Gertie’s look.
Since Gertie is herself using the dynamic sprite coloring system, let’s first just see what happens if Nemo simply uses Gertie’s color scheme when wearing the Dino PJs.
Nemo simply using Gertie's color scheme directly with no modifications. Not quite right.
Okay, that doesn’t work because we’re using Gertie’s skin tone and the hair color is a bit dark and desaturated, but the color of the pajamas is a good start. So we’ll make a new Gradient Map based on that as a starting point and start making some adjustments.
A color scheme is a series of gradients that our shader uses to re-color the sprite as needed.
Something we’ll need to keep in mind during this part of design is we want each pair of PJs to be very visually distinct. Since I know Nemo will also have access to Frog PJs, and I expect these two to both be primarily green, then I might bring those PJs up as well and do some side-by-sides to make sure they’re sufficiently different from one another.
A side-by-side of the Frog PJs next to the Dino PJs so I can make sure they feel visually distinct enough despite both being primarily green.
And after we’ve got something that looks nice, we’ll also just make sure that we still like it in a variety of lighting conditions. And if that all looks good, we’ve got the look down!
And here's how the PJs are looking in a variety of lighting and background contexts.
Now I need to design a buff for these PJs. I have a PJ doc with all the PJs in there that have already been designed, so I can go in there and see where there’s room for a new ability buff. Some PJs will buff Nemo’s innate abilities (for example, Nemo can of course innately collect candy by walking over it, but the Sweet Tooth PJs allow candy to be pulled towards Nemo from a distance) and some will buff the abilities gained from new Toys (the Yo-Yo Master PJs for instance will allow you hold the attack button down to keep your yo-yo out when you attack).
So while working on the Dino PJs, one of the abilities that had no buff was the Bubble Wand. This toy grants you the ability to create a protective bubble around yourself which will protect you for one hit. Since you can’t move at all while bubbled, there’s some room to make this even more powerful for players that like strong defensive options.
Meanwhile, there was another thought that had been bouncing around my brain at some point, which was a) how much I like the Tanooki suit’s ability that allows Mario to turn into a statue in Super Mario Bros. 3 and b) how that is actually a lot like the Bubble Wand’s ability. So with these things in mind, I decided a good ability for the Dino PJs would be to upgrade your Bubble Wand ability with the ability to turn into a statue, making you completely impervious to enemy attacks (instead of just a single attack). That kind of ability buff feels in line with the level of power that other PJs have and also is just kind of a fun nod to a game I love.
So now we’ve got the buff designed and we just need to actually make it all work.
So let’s get into the details of everything I need to do to make these PJs actually function. There’s a step that I already did earlier, which is to add an entry to our PajamaType enum for our Dino PJs. And when we were working on the color scheme, we also would have made sure to wire up PajamaType.Dino with the color scheme we developed.
Since this is a modification of an existing ability, we’ll need to do two things: 1) allow for the Bubble Wand to also work in such a way that it will no longer pop when hit and 2) Ensure Nemo’s Animator knows that we should be using this version of the bubble ability because we’ll need an entirely different animation (and speaking of, we’re gonna need to draw a statue sprite for this animation).
Adding this feature to the bubble ability is relatively easy: we’ll create a StatueDefense component that we can tag the player entity with when they have this buff enabled, and it will piggyback on the existing Defense logic that the Bubble Wand's default ability uses.
Here's a look at the system that piggybacks on the existing defend system and instead handles the statue logic
I only include that picture so you can see that it's not too much logic. This system is essentially just doing a few small things:
Recess the player when becoming a statue (so we appear behind enemies instead of in front as we normally do.
Remove the player's AITarget component (this will prevent enemies not just from hurting us, but from even trying to attack us)
Make the player completely invulnerable instead of relying on the ArmorBox we normally use (which would get popped if hit)
Emit an effect so that we can get some particles and a sound effect happening anytime we transform into or out of statue form.
For Nemo’s Animator, the bubble wand animation is controlled using our animationState parameter, and there is an integer value that corresponds with a defensive animation. So we’ll just add a new integer value for this buffed version of the defensive animation and make sure our animation system handles that based on the boolean we added to the Defense component above.
Nemo's Animator now just has a single new state it can enter as highlighted here. We'll enter this state anytime our animationState parameter matches the integer value that corresponds with our new statue animation.
We’re almost there! Let’s draw that Dino Statue that Nemo will turn into. This should be easy because it’s only a single frame and doesn’t need to be animated. I got João to help out and do some sketches for what this might look like first
Some very cute sketches from João depicting Nemo as a dino statue
But they weren’t quite what I was after. I really wanted some kind of a staff in Nemo’s hand too. Something about the staff that the Mario statue holds in SMB3 just sticks with me in a way that it wouldn’t feel right without something similar. Cid had the great idea to use a crossing guard sign, which is thematically fitting since the Dino PJs will be acquired in Nightlight City. So with that help from Cid and João, I came up with this sketch.
My attempt at combining the ideas I liked into one dino statue concept sketch
Since I'm happy with this one, now I’ll draw a more finalized version of the sprite, bring it into Unity and make sure those new animations for Nemo use the statue sprite. And then we have a new pair of working PJs. And here they are:
The Dino PJs in action! I'll probably continue making minor tweaks, I don't love the transformation smoke effect right now for instance, but it's all working.
And that is a full look at how I’ve made a pair of PJs for Nemo from start to finish! Getting these PJs to the player is simply a matter of drawing a dresser into the world and selecting the PajamaType.Dino enum option, or making it available by using a simple macro via the dialogue system (if we’re purchasing them from an NPC). But I won’t say too much more about that, you’ll have to find these PJs in the game yourself when you play!
Thanks so much for reading all the way down here. I'd love to get feedback on how people are liking these devlog updates and what other topics you'd like to see covered, so please leave a comment down below!
For this month’s update, I thought I’d show off the making of process in more detail. As many of you reading probably already know, despite having some very important people helping with the game, Little Nemo is mostly a solo developed title. So I want to show you what my process looks like by diving into the full end-to-end process of just a small piece of the game: developing a single new enemy. I think this will give you a good sense of how many different hats you have to wear as a solo developer for the production side of things alone, while also trying to highlight how I get help when I can.
A photo I took during the Kickstarter of me working in my office/studio
I’ll start by showing off the enemy we’re gonna be discussing, the Helmlet:
The Helmet patrolling in the test environment This is a very simple enemy that just walks back and forth and is armored from the front. It shares a color scheme with the Burrchin and Slowpoke enemies because, like them, it is designed to go in any domain. Now that you know what we’re aiming for, let’s back up and start at the beginning of this whole process.
The inception for this enemy comes from two areas. The first is that while working on level design with Rygar (who helps out a bit with boss and level design), the Raddler was identified as an enemy that is nice to place anywhere. Its simple walk-back-and-forth behavior makes it a nice and easy enemy to slot in anywhere. The Raddler was designed as an enemy for the Dreamswept Plains, and so I didn’t love putting it into other domains, but it didn’t necessarily clash, so we just started using it throughout Slumberland.
Then more recently, I was playing some Mega Man 4 and I noticed that the Shield Attacker enemies are quite fun. They are a simple back-and-forth enemy, but with the twist of being armored from the front. Even though we liked the simplicity of the Raddler, I thought we could afford to add just a bit of complexity since we already have the very simple Burrchin and Slowpoke to use for “easy” enemies.
So now we had an enemy in mind: one that simply patrols back and forth, but is armored when attacked from the front, it damages you if you touch it, and should visually fit in with Burrchin and Slowpoke. Alright, so let’s make it!
Next up I need to come up with a visual concept for this enemy. This is somewhere that I might enlist João’s help to come up with a visual concept, but in this case, I was confident in my ability to come up with something appropriate, so I worked on the visual design myself.
As I mentioned before, the Burrchin and Slowpoke are some of our other “generic” enemies designed for use in any domain. Their general visual motif is “cute but dangerous plushie”.The Burrchin and Slowpoke are enemies you'll find throughout Slumberland
So we want something like this, but it needs some kind of shielding in the front. Okay, what if it’s a mask, kind of like Mario 2’s Shy Guy or Kirby’s MetaKnight?
The Shy Guy from Mario 2 has a mask that could provide some armor perhaps?
That’s a good idea, but a mask doesn't necessarily look “shielded” enough, so we’ll just need to accentuate the mask a bit more and make it a little more shield-like. I’m thinking it should probably look more like a tower shield.
Additionally, since this enemy damages you on touch, we’d like it to have some spikes to make sure that’s immediately clear to players and they don’t think you can step on this enemy to pick it up. Luckily I have the time-lapse available for the ideation of this enemy, so you can see all the various visual ideas I tried out before I found the one I really liked:Me scribbling down different ideas until I found something I was happy with
So that leaves us with a design that looks something like this:
The initial sketch that I was happy with for Helmlet
It’s around this time that I also start coming up with a name for the enemy. I’m generally aiming for something cute, fun, and which includes some kind of pun or reference to the enemy’s function or inspiration. I settled on “Helmlet” as the helmet part of the name communicates the enemy’s armor, and the “-let” part of the name helps make it sound like a small and cute name.
So there we have it. Okay on to the next step!This step is actually quite a bit slower and more work-intensive than you might realize, so I’m gonna break it down quite a bit. For this step, I’m primarily working on my iPad and an Apple Pencil, before bringing everything back to the PC to get imported into the Unity project.
First we need to sketch out the motion for our walk cycle. Luckily in this case, we only have to worry about the walk cycle, and a frame or two for turning around. I’ll often start these out by just drawing in the keyframes I want to hit, so I’ll have a choppy version of the animation to get the general idea of what I’m after.
Just a few keyframes to convey Helmet's waddle
After I’ve identified the keyframes for an animation I think will look good, I render the rest of the details. The first step to that is tweening the animation with a target typically of 15fps (we’ll use 30fps as needed if it’s something that needs more motion detail or clarity and moves quickly, or go down to 10 or even 7.5fps for animations that have very little motion. And we also make sure this is all at the target resolution (typically 256 pixels per unit, with standard enemy size being roughly 1x1 units).
All of the inked drawings for Helmlet's walk cycle
You’re probably thinking, why would you draw this 14 separate times? That seems like overkill, especially since most frames are so similar, and you’d be right. But something I strive for with Little Nemo is making sure not only that it is hand-drawn, but that it feels hand-drawn. And getting the feel involves re-drawing the sprite so you get those subtle differences in each frame that cause a so-called “boil” in the animation and help the animated elements in the game really pop and come alive. The minor details such as the texture of the inking come through really nicely when the game is running at 4K resolution.
All 14 inked sprites in sequence
Now for all of the details that go into each frame. I probably don’t need to talk too much about these, so I’ll just share a timelapse of each step being added to the sprite sheet.
A time-lapse of how the sprite sheet looks as we add details from each step
The way the colors cover up all of the details probably seems kind of weird, but that’s because we’re making two different textures that are combined using a shader so that we can dynamically re-color the sprites. This is all just custom rendering tech I’ve developed for the game, and if you wanna learn more about it, I wrote it up in detail way back during the game’s Kickstarter campaign in this post here: Little Nemo Art Pipeline.
And again, we’ve selected a simple example here, so the only other animation we have is a two-frame turnaround animation, but we will also do this step for any other animations the enemy needs.Next up, we’ll export the drawings from Procreate as PSDs (Photoshop's file format). I recently set up a local NAS server (essentially an in-home cloud solution) for DIE SOFT, which helps make this process faster and easier than using google drive since it’s all over local network instead of over the internet (these PSDs can sometimes get quite large). So these PSDs go onto the NAS and then I can access them from my PC. I use Photoshop to export sprite sheets for the animations, and then import them into Unity and get them sliced up into individual sprites.
Slicing up the sprite sheet in Unity
I could have just not mentioned this step because it seems self-evident that this would need to happen, but it’s worth calling it out because even with the various automation steps involved to make this relatively fast and easy, these are the sorts of tasks that can easily eat up loads of time unexpectedly when you’re doing even the most simple tasks yourself.
Now that we’ve got the sprites in there, we need to get them moving around on screen and behaving as expected. Since we’ve got a simple case, this step once again is very simple. The enemy AI is not a particularly strong part of my Nemo codebase, but it is robust enough that I can easily build out an enemy like this. In fact, I already have an enemy archetype for it I call “Simple Patrol” which adds the MoveForward, TurnaroundAtWall, TurnaroundAtHazard, and TurnaroundAtLedge traits, which is all this needs to do what we want it to.
So we’ll create a prefab for it which is a variant of our standard enemy base, we add the SimplePatrol behaviour, add an ArmorBox to it (so it can block hits from the front), add a hitbox to it (so that it hurts us if we touch it), and then fiddle with all the parameters such as its walk speed until we’re happy with it.Here's the Helmlet's prefab. Lots of components, but many of them are from the base enemy prefab
Even with this simplest of enemy types, this step manages to take a good amount of time. There’s often a lot more fiddling than I anticipate going in. For instance, with this enemy, I needed to fiddle with my armor logic because even if you hit the enemy from behind, if your weapon overlapped the armorbox, the attack would get blocked.
We have a functional prefab for the enemy at this point, and if Little Nemo were built using Unity scenes, we would just be placing the prefab directly into scenes. But Slumberland is built out of Rooms encoded into JSON files and authored using the Nemo Maker tool I’ve built. If you wanna see a little more about this, I talked about it in an earlier Kickstarter update. But that means I have one last abstraction step: bring this prefab into Nemo Maker so I can place it into the world.
This involves just making a prefab swatch, and putting it into the appropriate palette (in this case the shared palette since this can be used in any domain).Helmlet's Nemo Maker swatch
Much like the importing of the sprites into Unity, this is the sort of task I could ignore while sharing my process, but I think that would be doing you a disservice in terms of trying to show you what actually happens here. Also this is also one of those menial tasks that quickly adds up.
This enemy doesn’t need any custom sound effects, but if it did, those needs would get jotted down into a doc where I’m tracking sound effects for Jonathan Baken to work on when he does his next pass on SFX for the game. There’s a whole process for getting those imported and utilized in the game that looks a bit like what we looked at here and definitely takes a bit of time. If anyone is interested, I could do a similar look at that process next.
This enemy also doesn’t really have any narrative implications. If it did, I would probably try to chat with Cid about it during the design phase to make sure it fits into Slumberland’s narrative appropriately.And of course this enemy doesn’t have any musical requirements, so Peter Berkman’s contributions to the game’s soundtrack aren’t relevant to what I’ve walked you through here.I just wanted to get this step in to point out where other contributors are typically involved in the process even though they weren’t in this particular example.So now we’ve got this new enemy, available to use in Nemo Maker and you got to follow along for the whole process.
Using Nemo Maker to place the newly made Helmlet into the world to test it out
Please leave some comments down below and let me know what you thought of all of this and what you’d like to see for next month’s developer update! I hope this gives a little more insight into how all of this is made, and what an endeavor it is! 😅 Thanks for reading, and I'll catch you all in the next update at the end of September. -Dave
One of the most fun things to work on when I’m doing level design, is hiding secrets in the game. I thought I would take some time to talk about how I approach designing them, as well as the bigger picture systems in place to help ensure they’re a fun aspect of the game.
Don’t worry too much about spoilers here, I’m not sharing anything that you wouldn’t have already encountered in the demo portion of the game.
The Internal Logic of Secrets 🔎
One thing I try to be cognizant of is the “hit every wall” problem that can arise in games with secret rooms hidden behind walls. In my opinion, a good secret is found because the player notices something, or can just feel that there’s a secret there. So my goal is to help players understand that the secrets aren’t just random breakable walls and that there is an underlying logic to them, or at the very least there are hints. So the best way I can help the player find secrets is to give them the right clues and to craft the secrets in a sensible way and help them understand that they should be “keeping an eye out” for secrets rather than just assuming they could be anywhere. If a player is just using the yo-yo on every wall to test it, then that’s a failure on my part (and besides, secrets should have varying methods of being hidden).
So with that general philosophy explained, here are some of the ways I try to help create a consistent internal logic for the secrets:
Universal Hints: This is something that isn’t actually implemented yet, so it’s not in the demo, but there will be a subtle visual indicator somewhere nearby every secret. You won’t know what it is the first time you see it, but after enough exposure, the hope is you’ll learn to understand it indicates that there’s a secret nearby. Once you know that, you’ll then need to have a keen eye to spot these indicators, and then also from there deduce a) where exactly is this secret and how does it function, and b) is this even something I can get yet or does it perhaps require a toy I don’t yet have.
Geographic Hints: These are, I think, the more important and subtle clues that players will (often perhaps subconsciously) notice and think “is there a secret here?” This can be a conspicuous shape of the terrain that begs questions, or can be subtle hints from the tiling system that imply the existence, or lack thereof, of tiles on the other side of what appears to be a solid wall.
Unique Hints: These kinds of hints will be dependent on the context. These are generally bespoke things that are designed to draw your attention or show you something in a relatively “innocent” way so as not to be too obvious.
Map Hints: Because the world is built up of screen-sized chunks, sometimes there are conspicuous “holes” in the map, and those will often contain secret rooms. This is something I’ve always loved since playing the original The Legend of Zelda which used this hint technique, and then was later also used by The Binding of Isaac.
I want to show off the geographic hints and unique hints by showing how I designed what is arguably the first secret in the game. Technically, it’s more like the fourth or fifth secret you encounter, but this is what players will likely think is the first secret and it’s one that I’m going out of my way to help players find (I would say probably more than half of players that I watch play are able to spot it, which is a good range I think).
The wall on the right here can be walked through to find a secret room. The first clue is that some of the tiles have stones in them. Why are there stones there and not in the tiles above them? I don’t expect players to already innately understand how the tiling rules in this domain work, but it should feel off. Specifically what’s happening is that there are no tiles to the right where the blue arrows are, which causes the tiling rules to use the tile with stones on it. Above where you see the red arrow, there are tiles to the right, so the standard filler tile is used. This is one of the ways in which I’ll try to give geographic hints.
The next hint you’ll get when you pluck these candy out of the ground:
When Nemo plucks this, the candy will scatter about, and some of it will wind up behind the wall. Most players will either a) see what has happened and realize something is funky, or b) just instinctually chase the candy into the wall. This is an example of a unique hint where I’ve specifically designed the room to give you the hint when you pluck this grass.
Fun side-note: I’ve watched many players chase candy into the wall, and then immediately come right back out and not even notice that they walked into the wall a bit. It’s subtler than you’d think for plenty of players.
The candy going behind the wall is the thing that is supposed to make the secret very clear, but the hope is that players will internalize some of the subtler details about this secret encounter so they start to learn this logic of the world’s secrets.
And just on the other side of the wall of this same room, we actually have a very similar secret, but this time it’s a bit tricker.
Do you see it? Most players that find that first secret seem to notice this and will attempt to walk through the wall. But you can’t actually get this secret yet. I wanted this wall to stand out as suspicious, so hopefully it’s in the back of the players mind. In the screen above, we later learn how the Yo-Yo can break some blocks, perhaps that could also be useful down here… 🤔
As you explore more of the map, you might also notice that this chunk to the left forms a suspicious hole in the map. That is one of the more subtle hints that will hopefully remind you to come back to this later on in your adventure.
Gotta Catch ‘Em All
One standard feature of metroidvania games is completion percentage. This is just a way to let the player know “yup, you found every secret in the game.” Maybe it’s tied to map exploration percentage, or item collection percentage, or some combination of both, but either way, plenty of players will feel compelled to find everything. And since you want the secrets sufficiently hidden so that they feel rewarding to find, you risk making the chase for 100% feeling annoying or even impossible.
So with that in mind, there is a Little Buddy in the game called B.O.B. It’s a little robot that will alert you to any nearby secrets you haven’t already found. You won’t be able to get it until fairly late in the game, and you’ll need to go out of your way to do so, but if you do, you’ll have a Little Buddy that helps you hunt down secrets that you missed earlier.
B.O.B. represents kind of the final big hint the game offers. He will essentially mimic the universal hints that you’ll learn to spot in the game, but without risking being so subtle as to be missed.
Where to Put Secrets 📌
Another major aspect of the secrets to touch on is simply how to decide where they go. There are cases where I have a very specific item I want a player to find at a particular time and place. Oddly enough, these tend to be both the easiest to find secrets (the room mentioned above, finding your first Little Buddy, etc.), as well as the most difficult to find (secrets left behind for speed running and/or subsequent runs that are intended to be as difficult to find as possible). But in most cases, I’m simply designing a room/platforming challenge, and I'll realize a fun way to incorporate a secret into what I’ve built. Often in these cases, I’ll just create an empty secret room with the intention of later deciding what kind of reward will be in there. These tend to just be single chunk, dead-end rooms rather than elaborate shortcuts. I’ll typically populate them with a collectible like a Blue Moon, a Lucky Coin Shard, a Music Track, etc.
A Miserable Pile of Secrets 🍷
Ultimately I want the world of Slumberland to feel filled to the brim with secrets, but they also need to be sufficiently engaging and hinted at to different degrees so that players feel like they can always come back to an area later on and find plenty more secrets within. I’m pretty happy with the amount and quality of secrets in there now, but I will probably keep adding and refining these right up until the game ships.
Okay, that's it for now on this topic, but if you’d like to hear more about this or any specific topics, leave a comment below, or find me in the Discord server! Thanks for reading! -Dave
About
This page aggregates Steam news feeds, patch notes, and developer announcements for Little Nemo and the Guardians of Slumberland, sourced from official Steam community posts.
Major updates, balance changes, and seasonal events often correlate with player-count spikes — cross-reference announcements here with the live charts on the main Little Nemo and the Guardians of Slumberland statistics page.
Articles link back to Steam for full changelogs. SteamScope refreshes news entries as new posts are published to the game's Steam hub.