Sprint #10: "The components of a great sprint."
August 26th, 2018
With a ton of travel and guest-entertaining planned for August, I've been trying not to stress too much over lower productivity during this sprint and last. It's really tough to maintain a work ethic when you're in a different location or when you have a guest in town. It really helps, though, when your host and your guest have just as much interest in a productive day of work as you do. As such, I was able to surprise myself and work two full days while I was in New York City and two full days (along with another half-day) while I had a guest in town back in Seattle. None of the changes I'll be talking about have been released in the prototype yet because I'm still regression testing them but I'll certainly plan on a release after the upcoming sprint.
Experimenting with jump sizing
One of the most important pieces of feedback I've gotten on Ensue so far has been that it's not really obvious when you're triple jumping, nor is it obvious that you're going any higher when you do. This got me thinking about how Super Mario 64--which has been the main inspiration for using the triple jump mechanic in the first place--solved that problem. In that game, if you're only looking at Mario's jump height, it's not necessarily clear that the single, double, and triple jumps differ at all. Instead, the game relies on animation and sound to reveal that something different is going on. Here's a GIF from the Triple Jump page on Super Mario Wiki showing the graphical flair.
As you can see, when the player correctly executes the third jump, Mario is doing somersaults through the air (while shouting "Yahoo!"), which tips off that something different is happening. That GIF isn't a perfect example of this effect because the player isn't using the full height of the single and double jump, which makes the triple jump just obviously look higher, but you get the idea. As for the double jump, although there's a different sound effect used for it, the game doesn't ever really teach the player that it gives Mario a little bit more peak height than the single jump (a tactic that SM64 speedrunners use a ton) and instead chooses to just sort of let the player figure that out as they go. To my recollection, there are hardly any spots in the game that force the player to know about the double jump where they couldn't also reasonably use the triple jump.
In any case, it's been in the back of my mind for a while that I'd like to do something to make things more obvious in Ensue and I think I'd prefer to not have to rely on sound effects--and ideally not just a paragraph of text explaining the mechanic--to do it. Thus far, the approach I've taken is turning the hero a different color whenever he jumps, yellow for a single jump, orange for a double jump, and red for a triple jump.
Generally speaking, however, players don't seem to notice the colors or, at least, don't exactly understand what they mean. That definitely has made me wonder if it's just a little too much on the screen at once and I'd be better served by just turning the hero a different color whenever the third jump is made. Purely graphical solutions feel like what I'm most interested right now but I spent a little bit of time this sprint experimenting with a mechanical alternative: greatly restricting the height of the single jump. That made the single-double-triple sequence look like this.
I haven't yet playtested this with anybody but, to my eyes, it seems a little bit more obvious that you get more height by doing more jumps in a row, especially comparing the third jump to the first. Further, in this setup, I've made the double jump gain a little bit extra height compared to the single, as opposed to the current system that has them peaking at the same height. I'm a little bit wary of making a change like this, though. Besides having to go back and make sure that all of the jumps still work in all of the levels (and, assuredly, they won't), I'm worried that I'll be creating an environment that makes it feel like you constantly have to be triple jumping everywhere. Obviously, to some extent, that's the direction I'm going with Ensue because I don't want it to be an easy game overall but I also don't want it to feel like you just can't do anything until you master the mechanics. It's a delicate balance to strike and one that I'll be looking into a lot more in the coming weeks.
Word of the week: "componentization"
Until this sprint, I've had a pretty concrete distinction that some things are Tiles and some things are Actors. The distinction has mostly been related to answering the question, "Does this thing ever move?" If it doesn't, it's a Tile; if it does, it's an Actor. (Platforms, regretfully, are their own thing. I don't know.) This means that the ball and strike entities that show up in a handful of levels have been treated as Tiles. At some point, though, this was getting to be too restrictive. In my code, a Tile must always be positioned at an x and y coordinate that's a multiple of 32, the base tile height in Ensue, while Actors can exist at any location. What if I want the player to be able to swing his bat and launch a ball (or a strike!) into the air as a projectile?
This led me to try to finally unify the two concepts through componentization, described in excellent detail by Robert Nystrom in Game Programming Patterns. To summarize, everything can be an Entity that has (or doesn't) have certain components: a graphics component if the thing needs to be drawn to the screen, a physics component if the thing needs to exist in the game's physical world, an input component if the thing needs access to the actual input the player is creating, etc. In that sense, everything then just either cares about some combination of those components or doesn't. The hero, for instance, certainly would want to be drawn to the screen, be affected by physics, and have access to the player's input. A decorative bush, however, probably wouldn't care about either physics or input. A cutscene trigger zone might only want access to the collision system so it can tell when the hero has overlapped it.
In practice, I haven't exactly eliminated the concepts of Actors and Tiles because they're still distinctly interested in different systems. I have, however, greatly DRYed out and decoupled the implementations because, now, they're not constantly having to redefine, for instance, how they get drawn to the screen. They just reference one simple method within the graphics component and then the system detects whether they even want to be drawn in the first place. Maybe I want an Actor that doesn't happen to get drawn to the screen or a Tile that doesn't have to permanently exist in one location. I now have much greater flexibility to create those things.
Aoeu
Finally--and I need to apologize in advance because, again, this isn't actually released in the prototype yet; I promise it will be there soon!--I added keyboard mappings for the Dvorak Simplified Keyboard, which is the keyboard layout I've been using for sixteen years now. Yeah, I'm one of those. Also, it's way better.
Closing thoughts
So, even though I spent just about half of my two-week sprint on the road or otherwise occupied with social obligations, I was still able to crank out some major changes that will, hopefully, be big long-term benefits to development. I certainly credit the Pomodoro technique that I wrote at length about last sprint because I feel like it's made my days so much more predictable. Really, just having any type of plan for productivity is a good thing (and I admit that I could just still be in the honeymoon phase with the shiny new process) but it's continued to be great for me.
Next sprint
I'm not sure what I'm going to focus on next sprint but I might go big on redoing the level editor. Right now, the level editor is pretty literally just a <textarea> of JSON that I make changes to when I want to move enemies to different starting positions or whatever. It could definitely be better and it will definitely need to be once I'm in a world in which everything is just an Entity object. I'm very quickly getting to that point, so maybe it's time to invest a little time in the tools. But, you know, maybe I should just make some music and art. Either or.