Sprint #5: "Switching contexts."
July 1st, 2018
I've spent the bulk of the past two sprints working on things that are wholly separate from Ensue itself. The RDG website, for instance, or its Twitter account, or the shiny new Facebook page, or Storybook, which is how I'm tracking all of my project issues. The work I've dedicated directly towards Ensue has been strictly aimed at getting it into stranger-shape, so I could present it to the public for feedback. This week, I wanted to get back into the weeds and make some progress on a game mechanic wishlist I've had in my brain for some time.
Spikes aren't just for floors anymore
Although I have a lot of skepticism for where spikes will eventually fit into the bigger Ensue picture, they sure are fun to play with. Is any game mechanic as universally and unmistakably understood by video game players than the humble spike? "I am sharp, I am pointy, and I am almost certainly going to hurt you, if not altogether kill you. Avoid me." Michael "Kayin" O'Reilly's I Wanna Be the Guy: The Movie: The Game took "spikeplay" to an extreme and practically established a genre, the game's release spawning literally hundreds of spin-offs.
Generally speaking, spikes serve to either force the player to use a particular type of movement to avoid them or punish the player making a mistake (in many cases, both). Often, removing the spikes from a level would render it trivial for the player to complete. Consider this level anchored in the Ensue universe.
Clearly, whoever created this level wants the player to prove that they know how to chain some wall jumps together. There's no penalty for failure that's relevant to the state of the game itself, that is, there's no way to die or even get hurt when the player is unable to execute the jumps as intended.
Here's what happens when the layout of the level is kept the same but some floor spikes are placed in very particular spots.
Now, in addition to proving her skill with the wall jump mechanic, the player must prove that she can execute them precisely. The spikes near the top of the screen force her to make sure she gets a tall wall jump off in order to clear them and, even then, her task is still not done. She must finally figure out how to avoid the spikes that she's imminently falling toward. Within Ensue, you can either execute two more wall jumps (off the rightmost wall and the left wall, respectively) or produce some well-timed movement while falling and safely land on the final platform. Regardless of which strategy she goes with, the floor spikes have clearly intensified the situation.
Of course, this is an obvious concept to anybody who's ever played a platformer before. I bring it up, though, to establish that, until this sprint, floor spikes were all I had to work with in Ensue. In that particular level, there aren't even many more places that you could put floor spikes, really only on the runway that precedes the initial jump. In Sprint #5, I was finally able to implement a few new toys: spikes that can also live on walls and on the ceiling. Here's what that level looks like now.
These new spikes don't influence the action to nearly the same extent that the first spikes did but they do ask a couple more things from the player. Firstly, they require that the player begin this entire sequence with a triple jump because, although you can get over the lowest set of spikes with a normal jump, the ensuing wall jump won't have enough height to protect you from the second set of spikes you'll encounter. Secondly, they demand ever more precision from the player's choreography through the level as she's no longer afforded as much freedom in working her way up the tower. She can't, for instance, just maintain her height by wall jumping indefinitely during the initial climb.
A side-effect of this is that the level sort of gives away how it wants to be beaten. The spikes are set up in such a way that the player just looks at the layout and understands that she can probably only beat the stage with one particular set of movements. This isn't outwardly a good or bad thing but, as I delve into level design and draw from my influences, I'm going to need a clear idea of where I want to go with the challenge. So far, my short levels have been very much in the "precision platforming" style where I don't really offer more than one way to get somewhere.
One of the cool things about Super Mario 64, to use an example of a game I'm very familiar with, is that there are very often multiple ways to get somewhere. Typically, there's the "long way", where you're mostly just walking to your destination, and the "cool way", where you chain together certain movements (like triple jumps and wall jumps) that give you just enough speed or height or both to get you where you want to go. Maybe that type of freedom is easier to grant in a three-dimensional world but it's an interesting thing to keep in mind as I progress with Ensue.
Spikes need periodic breaks, too
Having rambled about level design "theory" for a few paragraphs, let's get back to the matter at hand. In addition to letting spikes be placed in all four orientations, I was able to implement a timer that allows spikes to cycle between being retracted and extended. The influence this has on gameplay is obvious: the player must now deal with uncertainty surrounding spikes. The cycle interval never changes, so it's up to the player to get a feel for when she can safely land on what will soon be a deadly surface. It adds an extra layer of timing-based challenge to a level like this that, without spikes at all, would only ask the player to execute a triple jump.
At the moment, retractable spikes are all based on the same timer and have the same hard-coded interval but I'm certainly interested in giving myself more freedom with those things going forward. It'd be great to be able to play with spikes that retract at different times and different cycles.
Switching things up
The last major mechanic I was able to implement was a switch. In Ensue, a switch is a region of the screen that, when the hero stands inside it, triggers something else to happen. Implementation-wise, this uses the classic Observer pattern, with switches being the subjects and other things (for now, just platforms, but there's no reason other stuff couldn't do the same) are the observers. Whenever the hero is standing (or not) in a switch's region, it lets all of its observers know about that. The observers then do whatever they want to with that information.
It's really fun to envision the possibilities going forward, especially when you consider that switches don't necessarily have to be shown to the player. An invisible region that activates or deactivates enemies could be a thing, for instance. Switches that can be triggered by enemies passing through them can start helping me explore what the glove and bat are going to be used for. They also just help the world feel more alive, which, frankly, is quite a boon for a developer who spends hours a day looking at this stuff.
Wall jump iteration
Finally, after receiving quite a bit of feedback from people last weekend, I decided to give wall jumps a serious look. The general thought seemed to be that wall jumps needed to be a little more lenient. Too many people were trying to execute a wall jump and failing, almost universally because their instinct was to press the direction that they wanted to be going post-wall-jump before actually pressing the jump button. This resulted in an awful lot of these types of clips.
This happens because, when the player presses left to change direction, she's immediately moving the hero away from the wall. In specific terms, the hero's rightmost side is no longer at a y-coordinate that the game sees as immediately adjacent to a wall. Wall jumps are only granted if the hero is touching the wall, so when they're just a pixel or two away, you get the clip above. As the developer of this game, I've very much gotten used to just pressing jump and then, as fast as possible, pressing the direction I want the hero to go but, in observing half a dozen people play the game and reading the feedback of half a dozen others, it's abundantly clear that that breaks peoples' expectations.
I'd had a few ideas and suggestions for how to make wall jumps easier to execute. You could allow the player to stop themselves on the wall, the way Celeste does. You could make it so wall jumps were allowed as long as the hero was within a magic number of pixels of the wall. You could freeze the hero on the wall for a brief period of time, rendering their problematic button press irrelevant for that period. You could try to solve the problem visually and give clear feedback for when the hero was in a "wall jumpable" state. I ended up going with a combination of those last two things.
Now, when the hero touches a wall, the player is altogether prevented from changing their left-right orientation for ten frames. That means that they have a sixth of a second to press the jump button, regardless of what other buttons they're pressing, and be rewarded with a wall jump. I also went ahead and turned the hero a darker shade of blue whenever he's in a wall jumpable state, though I'm not really convinced it's helpful. In any case, it ends up looking like this.
The nuance might be hard to see in the video (consider playing the prototype!) but, I assure you, the wall jump feels much nicer now. For good measure, I also decided to have the wall temporarily slow your fall as you hug it, giving you a little bit more time to execute your dance through the level. I hope my players agree that it's much improved.
Closing thoughts
All in all, Sprint #5 went very well. It was a ton of fun to get back into the actual game development part of this whole thing (even though there were a handful a moments where I felt like I was just poking at big messy pile of code). I didn't even get to all the stuff I had planned, so we'll just have to wait for a future sprint to talk about the million other ideas I have.
Next sprint
I'll be going out of town again on Tuesday so it's going to be a somewhat short week. I'm still planning on getting some work done but most of the things I do are likely to be more behind-the-scenes stuff, especially Storybook-related things that the project manager part of me is starting to pine for. That said, it's going to be really hard to resist the temptation to play with all of my new toys.