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.
Step 1: Design
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!
Step 2: Visual Design
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!
Step 3: Sprite Animations
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.
Sub-step 1: Finding the motion
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
Sub-step 2: Tweening and Inking
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
Sub-step 3: Shading, details, and coloring
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.
Step 4: Importing Sprites into Unity
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.
Step 5: Scripting Enemy Behavior
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.
Step 6: Make it Authorable
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.
Step 7: The Steps We Skipped
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.
And We’re Done!
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