Sprint #4: "Municipal mandate means miscellaneous milestones."
June 24th, 2018
A couple of months ago, I was given my very first jury duty summons, scheduled for June 19th. I was gainfully employed and not particularly aware that I'd soon be quitting that job and dedicating my summer to Ensue so, at the time, it didn't seem so undesirable. As we stand in reality, though, I'm receiving no paycheck for my gamedev efforts at the moment and, as such, I was more than a little nervous of actually being selected to a jury. Even though, regardless, I still wouldn't be getting a paycheck, it seemed like it'd be a particularly big waste of valuable time. (It also gave me good reason to imagine how terrifying that type of feeling would be for someone who hasn't been an overpaid software engineer for more than a decade, somebody whose life could be materially affected by carrying out their civic duty.) Given the uncertainty, I planned this sprint to have a bit of a this-and-that type of flavor to it, all aimed towards finally offering Ensue up to this week's r/gamedev Feedback Friday thread. As it happened, there were no jury trials scheduled for this past Tuesday, which meant that my "service" had been completed. I look forward to saying the same for this game someday.
Feedback Friday, for real
I know it doesn't seem like it should require much work to post, "Hey, check out my game. Here's a link. Thanks." on the internet but I'm trying to be a bit more rigorous than that. From a marketing perspective, I wanted to have a few outlets ready to be followed and liked and joined and all that stuff that I wrote about last week. From a development perspective, though, I still needed to get the prototype into more reasonable "stranger shape". For instance, I'd so far given pretty much zero consideration to having all sorts of debug controls on the screen but, when a stranger is messing around with Ensue, I don't want it to seem like those buttons are part of the experience. I'd also been doing the overwhelming amount of my testing with my SNES controller and so gamepad controls have been the default. A stranger, though, is almost surely only going to bother with the keyboard, especially in a "Feedback Friday" context, so it was clear that I needed to be sure to make the keyboard the default. To that end, I also needed to add a little dialog box with the controls. I also needed to not start on a basically blank level. I also needed to take a look at the order all of the levels were in to make sure they made sense. It all adds up.
Thankfully, our favorite software developer was able to trimuph in the face of adversity and, yes, in fact, make his first Feedback Friday post, officially letting randoms in on the secret for the first time. Feedback has been pretty consistent with what I've been told so far. In fact, u/Chukobyte (whose Serenade of the Sirens game is pretty fun) summed it up wonderfully in just three sentences: "I think the controls felt smooth. I think an indication that you could do wall jumping would be helpful. I made it to the third area but I'm not sure how to get past it." People, generally, have been getting tripped up (regretfully, no pun intended) on learning how to triple jump, which is required to clear the third area to which u/Chukobyte refers. It's clear to me that it's not clear to players that the triple jump is a game mechanic that needs mastery, so I'll certainly need to do a better job of teaching it.
Additionally, even though u/Chukobyte isn't able to discover the triple jump, they do discover the wall jump, which it's not my intention to reveal until the fourth area. I've seen this before while watching over other players' shoulders and it's a big problem: they end up thinking the wall jump is the solution to the puzzle and they just need to figure out how to correctly use it. All of a sudden, their mindset has been shifted from exploration into execution and, unfortunately, they're trying to execute the wrong thing. This type of feedback is awesome to have because it helps me see where my level design is falling short. In this specific case, maybe I need to hold off on introducing walls (and, by extension, wall jumps) until after the player has become fundamentally comfortable with the other jumping mechanics. At the least, the triple jump (and probably the single and double jumps) need to be taught without walls, which too often seem to be leading the player in the wrong direction.
Workflow matters
Also included in this sprint were a bunch of Storybook-related issues, most of them boring tweaks like "Storybook tags should be editable" that don't really bear mentioning. One thing that I've specifically been doing with Storybook is making sure it's usable from a mobile device. I know from experience that there will be times when I'll have ideas for Ensue but I'm not around my computer or notebook to jot them down. By making sure Storybook is pretty much always available to me, I don't have much excuse to not be adding things as I think of them.
What's even more boring than the Storybook tweaks I worked on was the process of backfilling the database so it represents the current state of the project. It was truly mind-numbing to go through my notebook and try to parse whether something should be made into a real story or not and then to spend some of that time adding things that had already been done, purely for record-keeping purposes. That compulsive instinct to have Everything Even Remotely Related to Ensue represented in Storybook was hitting me hard and I decided to, at the very least, cut it off at four weeks ago. That served as a reminder, though, that this project is older than that.
Background on Ensue
In fact, development on Ensue began in October 2016. The first time I made a commit to my repository with something vaguely "playable", things looked pretty, uh, plain.
About a week later, I'd introduced the notion of ground, level exits, and even a couple of enemies, along with adding a splash of color.
A month after that, I'd played around with sizing (a lot) and made some basic tile artwork that, somewhat embarrassingly, still shows up in the prototype today.
So, in my first cycle of development, I spent nearly six full months working on the game, making my final commit on March 20th, 2017, with things looking pretty much like they do today.
Obviously, not much of that six months (nor of the most recent seventh month) was spent on artwork. Besides that I'm hardly anything of an artist, the vast majority of that time was spent on the engine and game mechanics. It's very much within my personality to want to write every line of code for a project (hence why I made my own website and my own bug database instead of just installing existing products) and this video game lark was no different. I saw it as an opportunity to learn about why existing engines--things like Unity, Unreal, Godot, and even LÖVE--are so helpful to developers.
It certainly becomes apparent when you find yourself writing collision detection code and continually learning that you're off by one pixel or your mathematical understanding of a physical situation isn't quite right or you just don't even get the concept of subpixels (I mean, how can a subpixel even possibly be a thing?). It's not an exaggeration to say that you can spend days trying to debug literal edge cases with your collision detection and--at least I think--a pre-rolled engine will have already handled a lot of that brand of frustration. They also give you a nice library of common game design objects so you don't have to implement your own, for instance, state machine class (not that it's super difficult).
Closing thoughts
As the developer, it's tempting to look at some of those screenshots and get a little discouraged that maybe Ensue hasn't come very far in the time I've spent working on it but what those screenshots don't show is the gameplay. A lot of time has been spent experimenting with magic numbers (e.g. gravity, terminal velocity, number of frames that you should be allowed to spend jumping) to get to the point where I open Ensue up to the public and people say things like "the controls felt smooth." That's an immensely satisfying thing to reflect on, even if, on the whole, we're still just moving boxes around the screen.
Next sprint
In Sprint #5, I'm going to get back to the game itself and implement some mechanics that I've wanted for a while. The main one to look for in the next build is a switch, i.e. something that you interact with to make something else on the screen happen. I think that'll open up a lot of new gameplay possibilities. There are a few other things I have in mind as well and, having zero days of vacation and zero days in court planned for the week, I'm hopeful that I'll get to all of them.