Sprint #12: "Leveling up."
September 23rd, 2018
I never owned a Wii U and was never particularly close to buying one but there was this one particular game that made me at least think about it more seriously: Super Mario Maker. I still kind of regret not acting on that impulse. Besides that I think I'd have loved playing through the nigh-endless selection of challenges, I think it would've been really nice to just get some experience created my own levels with a professionally produced level editor. I've been doing a ton of on-the-fly learning about level design during this development process and I don't have much to draw from in my past. It felt like a good time to focus on that aspect of the game, so I dedicated the bulk of the last two weeks towards iterating on and creating new, more fully formed levels for Ensue.
Please give me your email address
Before I get there, though, it should certainly be noted that I also set up a mailing list for Rain Delay Games. I'm not going to go too far into the details here but, upon realizing that I'd have to deal with the task of configuring sendmail if I wanted to run my own email list, I threw up my arms and checked out MailChimp. Turns out, they have a free plan that you only have to pay for once you reach either 2,000 subscribers or 12,000 emails sent in a month. I don't really plan on sending out six monthly newsletters so, yeah, I think that will work fine for me.
I'm still very much thinking about what benefits I'll offer to newsletter subscribers but, for now, I'll at least actively let you know about new devlog posts. That's something, right? Going forward, I think I'll probably offer links to the unstable release of Ensue, i.e. whatever the latest state of the code is, which is not necessarily the same as what's linked to as the Ensue prototype.
Structured level design
I don't want to go any further without mentioning something that's been an incredible resource for me these last two weeks: Reverse Design: Super Mario World. This is just one of six (!) books in which Patrick Holleman tries to reverse engineer the level design process that went in to some of the most revered video games in history. In the case of Super Mario World, Holleman ends up finding certain things that come up over and over again: challenges, cadences, and skill themes. I'm still working my way through the book but the idea of establishing, from a top-down perspective, the intensity of the challenges in the level, the cadence at which they're presented to the player, and the skills you want the player to prove they have has been quite a boon.
In Super Mario World, Holleman finds, a frequent type of level is one that first establishes one skill theme by starting with something easy and iterating on it, then establishes a different skill theme in the same way, and then finishes the level by exploring what happens when you combine the two. This insight motivated me to take a look at "1-1: Make Eggs, Throw Eggs" in Yoshi's Island to get a feel for how they did things in that game. It was actually quite surprising to me how many of the basic mechanics must be employed to exit the very first level, pretty much everything besides fluttering and ground pounding. My main takeaway--which I feel like I already innately knew--was that one level design philosophy doesn't fit all.
So, I did what I've often done while making this game: I looked to baseball. When a prospective baseball player is being scouted, his abilities are summarized in a single number that falls, amusingly, between 20 and 80. You can quickly find some in-depth explanations of the scale--which actually ends up being very reasonable--but, to be sure, it's not like a scout just sort of comes up with the final grade. Instead, the scout must just sort of come up with a projection for, say, how many home runs they think the player could hit in the bigs, and certain ranges correspond with certain numbers. There are also objective measures for things like how fast the player can throw the ball. After evaluating a handful of dimensions for every player (whether hitter or pitcher), it all gets combined into a number between 20 and 80 that's evenly divisible by 5.
I've decided to use this scale for my own purposes. Every level in Ensue will carry somewhere between 20 and 80 points of challenges and every challenge will be rated between 2 and 8. In other words, if the first level is rated at a 20, the individual challenges that it contains will sum to 20. I'm not sure if this is the right pacing but, for now, I've decided that every world will end harder than it starts, every world will start easier than the previous world ended, and every world will start harder than the previous world began. I like the idea of giving the player a bit of a challenge reprieve as they progress and become more familiar with the game's mechanics.
Difficulty rating difficulty
It's actually kind of hard to determine how tough any individual challenge is, though, or even what counts as a challenge. Is this a challenge?
In an untimed game, there's no penalty for missing this jump and, let's be honest, here in 2018, it's not like pressing a button to jump is really a mechanic that the player needs to have some breakthrough to discover. Maybe this could be considered a "challenge" in the first level but not in the last, when we'd expect the player to have perfected a penalty-free jump. After you open that can of worms, though, how should triple jumps be treated?
The only way you can reach this platform is with a decently timed triple jump. It's pretty clear that a triple jump should always be considered a "challenge" because it requires three timed inputs, at its most generous, and may require specific movements as well. As the game progresses, though, timing those inputs is going to come much more naturally to the player. This particular triple jump may rate as a 4 in World 2 but could only nominally be considered a 2 in World 8.
It's pretty clear that there are several dimensions you have to consider to decide how hard a challenge is. The four I've come up with are: number of inputs (how many buttons the player must press), timing window (how much time the player has to execute the inputs), penalty upon failure (what happens to the player when they fail to execute those inputs), and solution obviousness (how obvious it is to the player what they even need to do). In practice, I've been trying to view every challenge I come up with through those four lenses. As I get further into the game, though, I'll likely need a fifth meta-lens, sort of a "wild card" rating, that accounts for how expert I expect the player to be at that point.
Requiring a mechanic
The final component of my top-down level design philosophy is deciding which mechanics I want to establish in which levels. If I want to require the player to do something, I use the language "introduce" in reference to that mechanic. If I want to "hint" at something, I'll add a little optional area the player can get to by exploring the inputs a little bit. If I want to raise the difficulty, I'll "iterate" on a particular challenge. Having these basic skill themes in sentence form, combined with a budget of challenge points that I'm not allowed to exceed, has been very useful in making what I think are three very reasonable-feeling levels.
Show us something already!
Those three levels are available to play right now. They're the first three levels that you'll encounter and they represent what I think could very reasonably be considered the first three levels of Ensue. The fourth one, though, is a tower concept level that is very difficult. If you're able to beat it, I'll consider you to have pretty decently mastered the Ensue movement mechanics. (I'm still somewhat inconsistent while playing it.)
Closing thoughts
So, after a sprint chock-full of level design, I've ended up trying to figure out how I want to get back to level design going forward. I'm considering spending a couple of days on it every sprint but, more realistically, I think I'll just spend time on it when it feels like I should spend time on it. In practice, that probably means once a month or so. Ideally, the code would get to the point where it's clear that all that remains is several tons of artwork, music composition, and level design, but even that feels pretty far away right now. I'm making progress, though.
Next sprint
In the next sprint, I'm going to be trying out a few new mechanics, fixing a few bugs, and trying to come up with a more realized version of the HUD that shows you your balls, strikes, and outs. It'll be a pretty free-form sprint that touches a lot of different systems but, overall, I think it'll tighten up the game considerably.
Sprint #11: "Asset management is key."
September 9th, 2018
Have you ever noticed how hard it is to do something you're bad at? In my speedrun days, it was always really easy to lose time while practicing a game by just playing portions that I had already, more or less, mastered. It's fun to feel like you've gotten good at something so practicing it is just you constantly giving yourself a reminder of same. It's much less fun to spend time on something that you haven't yet mastered, flailing and making mistakes along the way. I bring this up because, as one could probably guess (if I haven't explicitly said it before), my pedigree is much more code than art or music and, as a result, I've noticed that I've been neglecting my asset duties. For this sprint, I decided to force myself to work only on assets, the things that get me out of my comfort zone.
Putting a face on the enemy
The most obvious pieces of artwork still missing from Ensue has been the enemies. If nothing else, I wanted to be sure to make a first pass at what enemies in this game could look like. In addition to making me think a bit more about the greater context of what's going on in the game, some type of basic sprite/animation work would just go a long way towards making this feel ever more like a real video game. Here's what I came up with.
So, yeah, this is what a Pacer (which is a very, very secret internal code name) looks like. Obviously, it's a little baseball that, I think, works quite well with the greater game. (The goofy idea that a strike zone's enemies are baseballs resonates well with my brain.) As I was working on this sprite, though, I really enjoyed that the laces of a baseball can sort of substitute for expression by simulating a brow and a mouth. I had a very similar reaction when I first started working on the hero's sprite. The whole notion of deriving human-like expression from inanimate and/or imaginary objects is exciting to me and, I imagine, will be somewhat of a theme going forward.
I have several other enemies besides the Pacer, though, so I couldn't quite stop there. I ended up with four different variations of the baseball sprite for the Pacer, Hopper, Jumper, and Sitter, respectively shown here.
In no way am I going to say that I'm a great animator or pixel artist or whatever but I will happily mention that the life these sprites have breathed into the game has been great for morale. It's so much fun to experience visual changes with something you're working on and a huge bonus when you feel like they work well. As development continues, I'll probably be experimenting with different colors for the enemies and I surely don't want every single one to be some version of a baseball. For now, though, I think this is a great start.
A different kind of scalability
Did you happen to notice the hero in that little video? The hero got a little bit of an overhaul during this sprint because of what I've decided was a scaling issue. Let's take a moment to recall what the basic hero sprite used to look like.
Actually, I ended up moving his feet over to the left one pixel but, whatever, that's close enough. This is what the hero looks like now.
So, what happened? Even though the colors are obviously pretty different, the main thing that changed was the scaling. The hero had previously been drawn as a 10x16 sprite that was scaled up by a factor of three to be 30x48. That means that, for instance, the hero's outline was three pixels wide. That gave it a look that I thought was cool but had an unfortunate problem being compatible with enemies.
Until this sprint, enemies had been universally represented as 32x32 boxes with no artwork. Once I started working on more sprites, it became clear that I was going to have to make a decision: did I want to keep working with deliberately-small canvases and scale them up or did I want to just try render sprites pixel-for-pixel? Given how little of an artist I am, it seemed like the simpler decision was to go with small canvases and scale up.
The number 32, however, isn't evenly divisible by 3, which meant that I couldn't work on any size canvas and scale it up at exactly the same factor as I'd scaled the hero. Put a different way, if I didn't change something, the hero was going to look very different from enemies, as if his pixels were bigger (because they were). I had a couple of options.
The first option was to maintain the 3x scaling and choose an eventual sprite size that was evenly divisible by 3 in both dimensions, maybe 33x33. Then, I could work on an 11x11 canvas but still have my enemy sprites look like they were created with the same constraints that the hero's sprite was. 11x11 just felt too small, though, and there was a little bit of a mental block being so close to 32x32 (32 being a power of two, which means that computer nerds are in love with it) but not quite being there. If I wanted a bigger base canvas, that would mean that the resultant sprite would get much bigger. A 16x16 base canvas turns into a 48x48 sprite, which means that I now have to reconsider the general scale of things that happen in my levels. I didn't want any part of this can of worms.
So, the other option, was to change the scaling factor across all entities. A fun thing about the number 2 is that half of all integers are evenly divisible by it so, you know, that seemed like a natural choice. No matter what canvas size I wanted, I would always be just one pixel away from having something that would scale up nicely by a factor of 2. For enemies, I could immediately start using a base canvas of 16x16 and easily scale up to 32x32. For the hero, though, I had to go back and redo a bunch of things.
I still wanted the hero, once you're actually playing the game, to be on that 30x48 order of size, which immediately suggests a 15x24 base canvas size. I ended up using 14x24 because having that even number of pixels on the x-axis just ended up making a few things easier and more symmetrical. What I also got, though, was a higher resolution to play with. The original 10x16 base canvas only gives me 160 pixels that I can use but 14x24 gives me 336, over double! That's why the new hero appears more detailed--especially around the feet--than the old.
It took me quite some time to redo the hero's feet in a way that I was satisfied with and I'm still getting adjusted to seeing the sleeker version in the actual game but I think it's, overall, a very positive change. Certainly, in the longer term, it's going to be much easier to deal with a scaling factor of 2 (or something that's a power of 2) than it would have been to insist on using a factor of 3. All of these subtleties were things that I've had in the back of my mind for some time now but focusing on assets for a couple of weeks is what finally made me confront them.
Taking the lead
Art isn't the only thing that's gotten neglected, though. Music, also, has been something I've willfully ignored for most of the summer. So, to reset you, I've been using the excellent MilkyTracker to track what elementary music ideas I have. I know that I want a final Ensue product to have a soundtrack that evokes the era of classic video games, which makes a tracker the perfect tool to use.
They don't tell you, though, that you have to either create your own samples or go find them yourself. Being the extremely stubborn, independent-to-a-fault personality that I am, I'm insisting on creating all of my own samples. This sometimes means, quite literally, drawing with my mouse the waveform that I want synthesized. Thankfully, there are some very good tutorials out there that help newbies like me a ton to figure out just, for instance, what a bass drum's wave looks like and how it's different from a crash cymbal's.
Without going too deep into the details (which I wouldn't be doing justice, believe me), I spent a bit of time trying to clean up and otherwise improve the samples that I've been using for songs, now armed with more knowledge about the wave shape I should be interested in. I also wanted to track an iteration on the boss music concept that I previewed back in Sprint #2, ideally coming up with a lead part and just more fully fleshing it out. Here's what I came up with.
When you compare it to the old version, it's obviously much further along but, I've got to say, coming up with that lead part was a huge challenge for me. This whole process has taught me that I really don't think in leads or, if I do, I tend to assign them to the bass instead of a higher-pitched instrument. For the most part, the lead in this tune just explores arpeggios. Although that's a tried and true way to get some good-sounding notes down, I feel like it's, overall, rather simple and it sort of paints the song into a corner. Put a different way, I feel like the lead ends up sounding samey. Don't get me wrong, though. I like it. Now, if I could only find some bosses to give the music to...
Closing thoughts
Overall, it was a really productive sprint on a couple of portions of the game that it's really easy for me to ignore for long periods of time. I've already linked a couple of the sample tutorials I used for the music but, in the pixel art realm, a lot of really helpful resources were found by just searching for "pixel art shading" and clicking a bunch of stuff. If I were to recommend two specific links, Derek Yu's pixel art tutorial and Luke Oliveem's coloring and shading tutorial would be them.
Finally, Sprint #11 served as a huge reminder that visual changes impact my perception of the project disproportiately more than any other types of changes, certainly way more than just making something more efficient in code. It's very clear to me why so-called solo game developers often end up contracting out the media work: much as they hate to admit it, a successful game needs to look and sound good much more than it needs to perform good. So to speak.
Next sprint
As has become an RDG tradition, the content of the next sprint is a bit up in the air but I've decided that I'm definitely going to come out of it having a mechanism for all of you--yes, you!--to sign up for an on-some-heretofore-unknown-time-interval newsletter. It seems like a mailing list is a very cheap way to help foster my lackluster marketing efforts and, having a mainly-web background, it shouldn't take very long for me to rig that up. As far as the rest of the sprint goes, I'm leaning towards spending some very good time on level design, so I'm hopeful that I'll have some new, or at least more polished, challenges to present next time.