Little Nemo and the Guardians of Slumberland News

[p]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.
 [/p][h2]About Nemo's PJs[/h2][p]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).[/p][p]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:[/p]

• [p]Toys grant entirely new abilities that are transformative and affect combat and traversability. Used as a gating mechanic.[/p]
• [p]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.[/p]
• [p]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.[/p]

[p]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.[/p][p]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…[/p][p][/p][h2]The PJ’s Look 🎨[/h2][p]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.[/p][p]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.[/p][p][/p][p]Nemo simply using Gertie's color scheme directly with no modifications. Not quite right.[/p][p][/p][p]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.[/p][p][/p][p]A color scheme is a series of gradients that our shader uses to re-color the sprite as needed.[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p][/p][p]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![/p][p][/p][p]And here's how the PJs are looking in a variety of lighting and background contexts.[/p][p][/p][h2]The PJ’s Ability Buff 💪[/h2][p]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).[/p][p]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.[/p][p]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.[/p][p]So now we’ve got the buff designed and we just need to actually make it all work.[/p][p][/p][h2]Engineering the PJs 🛠️[/h2][p]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.[/p][p]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).[/p][p]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.[/p][p]Here's a look at the system that piggybacks on the existing defend system and instead handles the statue logic[/p][p][/p][p]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:[/p]

• [p]Recess the player when becoming a statue (so we appear behind enemies instead of in front as we normally do.[/p]
• [p]Remove the player's AITarget component (this will prevent enemies not just from hurting us, but from even trying to attack us)[/p]
• [p]Make the player completely invulnerable instead of relying on the ArmorBox we normally use (which would get popped if hit)[/p]
• [p]Emit an effect so that we can get some particles and a sound effect happening anytime we transform into or out of statue form.[/p]

[p]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.[/p][p]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.[/p][p][/p][p]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[/p][p]Some very cute sketches from João depicting Nemo as a dino statue[/p][p][/p][p]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.[/p][p][/p][p]My attempt at combining the ideas I liked into one dino statue concept sketch[/p][p][/p][p]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:[/p][p][/p][p]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.[/p][p][/p][p]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! [/p][p]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![/p]

[p]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.[/p][p][/p][p]A photo I took during the Kickstarter of me working in my office/studio[/p][p][/p][p]I’ll start by showing off the enemy we’re gonna be discussing, the Helmlet:[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p]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.[/p][p]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![/p][p][/p][p]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.[/p][p]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”.[/p][p][/p][p]The Burrchin and Slowpoke are enemies you'll find throughout Slumberland[/p][p][/p][p]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?[/p][p]The Shy Guy from Mario 2 has a mask that could provide some armor perhaps?[/p][p][/p][p]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.[/p][p]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:[/p][p][/p][p]Me scribbling down different ideas until I found something I was happy with[/p][p][/p][p]So that leaves us with a design that looks something like this:[/p][p][/p][p]The initial sketch that I was happy with for Helmlet[/p][p][/p][p]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.[/p][p]So there we have it. Okay on to the next step![/p][p][/p][p]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.[/p][p][/p][h3]Sub-step 1: Finding the motion[/h3][p]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.[/p][p][/p][p]Just a few keyframes to convey Helmet's waddle[/p][p][/p][h3]Sub-step 2: Tweening and Inking[/h3][p]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).[/p][p]All of the inked drawings for Helmlet's walk cycle[/p][p][/p][p]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.[/p][p][/p][p]All 14 inked sprites in sequence[/p][p][/p][h3]Sub-step 3: Shading, details, and coloring[/h3][p]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.[/p][p][/p][p]A time-lapse of how the sprite sheet looks as we add details from each step[/p][p][/p][p]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.[/p][p]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.[/p][p][/p][p]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.[/p][p]Slicing up the sprite sheet in Unity[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p]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.[/p][p][/p][p]Here's the Helmlet's prefab. Lots of components, but many of them are from the base enemy prefab[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p]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).[/p][p][/p][p]Helmlet's Nemo Maker swatch[/p][p][/p][p]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.[/p][p][/p][p]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.[/p][p]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.[/p][p]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.[/p][p]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.[/p][p][/p][p]So now we’ve got this new enemy, available to use in Nemo Maker and you got to follow along for the whole process.[/p][p][/p][p]Using Nemo Maker to place the newly made Helmlet into the world to test it out[/p][p][/p][p]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[/p][p][/p]

[p][/p][h3]The Secrets of Slumberland 🤫[/h3][p]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.[/p][p]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.
 [/p][p]The Internal Logic of Secrets 🔎[/p][p]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).[/p][p]So with that general philosophy explained, here are some of the ways I try to help create a consistent internal logic for the secrets:[/p]

• [p]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.[/p]
• [p]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.[/p]
• [p]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.[/p]
• [p]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.[/p]

[p]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).[/p][p][/p][p]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.[/p][p]The next hint you’ll get when you pluck these candy out of the ground:[/p][p][/p][p]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.[/p][p]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.[/p][p]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.[/p][p]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.[/p][p][/p][p]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… 🤔[/p][p]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.
 [/p][p]Gotta Catch ‘Em All [/p][p]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.[/p][p]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.[/p][p][/p][p]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.
 [/p][p]Where to Put Secrets 📌[/p][p]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.
 [/p][p]A Miserable Pile of Secrets 🍷[/p][p]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.[/p][p][/p][p]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[/p]

We just premiered our latest trailer in the MIX Summer Game Showcase and announced a limited-time public demo that is live now, and our release target of Q1 2026 on Steam. Check out the latest trailer on our Steam store page!

We're excited to announce that we'll be participating in the digital portion of this year's MIX Summer Game Showcase! We've been mostly heads down just working on the game, but now we're ready to show off as many exciting snippets of Slumberland as we could pack into 90 seconds, and it will include some exciting announcements.

You can learn more about the event on their website or head to the MIX YouTube channel on June 3rd at 9am PT / 12pm ET.