Behold as I pretend that I am a game developer.
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.
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.
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.
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.
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.
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.)
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.
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.