Behold as I pretend that I am a game developer.
When a former coworker of mine sensed that a meeting of more than two people crossed the line into not being productive for everybody, he wouldn't hesitate to remind everybody about how expensive meetings can be. If you consider the salaries of five software developers and one project manager, it doesn't take long for the company to be spending thousands of dollars on something that ultimately amounts to wasted time for everybody involved. It's a concept that's stuck with me ever since and feels especially relevant as I've been enduring a bit of a lull with Ensue development. I've spent a good amount of time trying to dissect that lull in my notebook writings that I don't care to regurgitate here (and, yeah, it isn't lost on me that the effort spent trying to figure out why I'm not as productive as I want to be could've been better spent on, you know, actually being productive) but I do want to call out a concept I learned about during this sprint and has, so far, been a huge help for my focus. I'll also go through some video game stuff that I did.
Some people reading this may know who Jason Rohrer is but I imagine most do not. Truth be told, I barely know who he is, having never played any of his games. I first came across him in the bonus footage of the excellent Indie Game: The Movie entitled Indie Game: Life After as he was working on Passage. I encourage you to look into his (extensive) game library but I bring him up because I happened to see a Gamasutra post linking to his GDC 2018 talk, "Don't Break the Chain: Maintaining Productivity on Your 19th Game".
In the talk (which, of course, is highly recommended), Rohrer analyzes his productivity habits by looking at his revision control system. After having somewhat of a mental breakdown while crunching on his newest game (One Hour One Life), during which he was failing to honor time commitments he'd made to his wife and three kids, he was led to the Pomodoro Technique, a time management method created in the '80s by Francesco Cirillo. As a quick synopsis, the Pomodoro recommends breaking your day into working periods into 25 minutes of focus on a particular task followed by a five-minute break that increases to a longer break after the fourth work period. In Rohrer's situation, he realized that two cycles of four working periods meant that he'd be spending 200 focused minutes per day on his game, which he felt was all you could particularly expect of peak performance from anybody. It also made his hours far more predictable, especially when he allowed himself to pursue those typical distractions--Discord, email, web--during the break periods and strictly not during the work periods.
The whole talk really connected with me and there's more to it than just Pomodoro but that concept was certainly my major takeaway. My prior process had been to go to a coffee shop every morning and write in my notebook until I didn't have any more to write, then go home and work until some nebulously defined time. In practice, this often meant starting work after lunch and working until about 5pm (sometimes earlier, sometimes later). When I decided to give Pomodoro a shot this past week, I decided that I'd flip it around: I'd spend two full cycles, broken up by lunch, working on the game (i.e. writing code, composing music, drawing sprites), and one half-cycle writing about what I did, what I will do tomorrow, and any other thoughts I have about things.
I'm only a handful of days into this new process and, in general, people are pretty good at sticking to new things for a short time, but I feel like it's been great for me so far. I commit myself to 200 minutes of focused work, 50 minutes of reflection on that work, and I can usually enjoy a beer while I write, which just feels a lot better than a second or third cup of coffee. I do still need to get better about knowing exactly what I'm going to be working on next (which I think will motivate me to start expanding Storybook's functionality) but so far, so good.
I had the opportunity to introduce and watch a couple of people who'd never seen Ensue play through it. It's well documented why this kind of thing is useful--you get to see what's too easy, too hard, the player's expectations, the player's decisions, etc.--but I had a somewhat new experience this time around. For a while, I've noticed that, every so often, the game will throw an error that reads TypeError: actor.state.bat is null and, unfortunately, brings the game to a screeching halt, requiring a refresh. Perhaps stupidly, I didn't consider this bug to be high priority, mainly because I wasn't really sure what was causing it, which made it feel like a very rare case. In observing the new players, though, this bug kept coming up. It's not really worth going in to what the fix was (it was literally a one-character change) but I think it's important to document that, sometimes, it's not even clear that something isn't a rare occurrence until you start seeing it affect other people. So important was this fix that I actually pushed it to production the instant it was done.
Maybe this isn't really a "tiny" thing but it's always struck me as somewhat unexpected that the hero in Ensue can bounce (and destroy) two enemies at once. Consider the following video.
It's not like it's the worst thing in the world to allow the player to kill two enemies with one set of feet but I've just never really intended for this to be the way that Ensue acts. This wasn't really a pressing issue or anything but it was staring at me in my backlog and I decided to take care of it. This type of encounter now looks like this.
A more robust solution might attempt to make it predictable which enemy you'll be attacking (it seems intuitive for that to be the one that's rendered on top of the other, unlike what happens in that video) but, for now, I think this works well enough.
Finally, the most significant thing I worked on during this sprint--taking several days to finish--was a complete genericization of the concept of platforms. Previously, I had six or seven subclasses that would inherit from a Platform class, all implementing slightly different behaviors. For this story, I wanted to put the onus much more heavily on the data to define a platform's behavior, under the assumption that every iteration of a Platform is a combination of a handful of different traits: a) how that platform gets activated; b) how that platform gets deactivated; and c) how that platform moves. Generalizing a platform's movement to be an arbitrarily defined script of coordinates allowed me to realize a feature I've wanted for quite some time: scriptable platforms. Visually, that means I can now have platforms that move like this.
All of the other types of platforms have been preserved in functionality by this one generic class that gives the data much, much more control, which will, hopefully, make it easier think of new ways for platforms to behave. I'll do my best to resist the autoscroller temptation but, I've gotta admit, in getting acquainted with level design to the extent that I have, I'm starting to see why they're so appealing to include in games.
All told, the adoption of a new productivity process and finally accomplishing something that's been on my mind for a while (and, at the same time, getting to use the word "genericization" more than anybody else in the world probably ever has), Sprint #9 went well. It seems like the expectation of "only" 25 minutes of focus at a time is much better for me and it's not even clear that I'm getting less done than I otherwise would be. I'm certainly less distracted, which is a big win no matter which way we define productivity. Again, I highly recommend watching that talk from Jason Rohrer, so much so that I'm going to link it again.
The next few weeks are filled with travel for me, starting with a trip to New York City from which I'll drive up to Quebec for a wedding and back to Seattle from which I'll drive up to Vancouver for a fantasy football draft. I've only penciled myself in for an expectation of four full working days during that time but I'll see what I can get done. I think I'm going to try to spend Sprint #10 experimenting with things, mostly tweaks to existing game mechanics that make things behave a little differently, just to see what happens. I should also probably design some more levels.