Moving to Unlocked Doors, Everywhere

When I started #droqtober I thought, wow, this sounds crazy. It's going to be a hellish month of being way too busy, because game jams are always way too busy. But... I think it might just be releasing games that drives me crazy, not finishing them. The entire month was -- not a breeze, but I felt at ease more often than not. I settled into a comfortable rhythm. It was like clockwork: each game took me about three hours from start to finish, though some did take longer. (Very rarely was a game finished in fewer than three hours.)

Occasionally I found myself stuck on an idea that wasn't very fun. If I caught this during the first hour, I'd generally just start over from scratch. Around the two-hour mark I would usually shift from playing around to wrapping it up. You could call it "polishing," but I'd like to be very specific. This stage involved making sure these things were all true:

- The game has an ending.
- Getting to the ending encourages you to play the game in an interesting way.
- There are no game-breaking bugs.
- There's nothing that I hate about the game. (e.g. weird visuals/composition, bad controls, unpleasant glitches, too random, too slow.)

Usually if I thought I wasn't going to be able to achieve all these, that's when I would abandon a game and start a new one. But if I hit the two-hour mark I generally would just figure it out rather than have the game consume too much of my day.

And, long-term, this was good for the health of the project. I had to make a game every day, which meant I couldn't burn myself out today -- I had to conserve my energy, my sanity, my well-being, for tomorrow. You could call this sustainability. What I learned was that I love making a game every day and that this sort of dev cycle deeply respected my skills and habits; my personality; my humanity.

I want to do it again.

3

What was learned.

So the wrapper came together on day 12, then more pieces came together near-ish to the end.

Cassette player, case customization. This was all just a thematic framing that worked with what I knew and liked, and what the nature of the games was. I had been thinking about the games as little virtual 'objects', things you might trade with people, or find in the game-world, or something like that. I hadn't decided: would you earn currency through playing the games?

The role of this framing is/was to be something I could talk about aside from the development process; is it interesting that it's a bundle of 31 games? Sure, maybe. But it's much easier for me personally to not get lost in the weeds of -- well, which game is the most interesting, which one do I talk about when I get more into detail, etc -- when there's a meta-layer, something that binds them all together. Games #12, #28, and #29 are those meta-wrapper. I talk about the desktop, the sticker sheet that you use to customize the games (this is what most people find easiest to talk about post-game, I think -- their custom cases), and the cassette player fiction.

Is this good marketing? I don't know. Maybe. But it eases my poor tired game dev soul. I don't fret about what to talk about because the structure of the game is built around what is, to me, the easiest and most pleasant talking point.

It's a game about playing 31 unmarked games.

Before I started, I had made the decision to not release the games as I went along. I hadn't decided whether I'd charge money for them yet, but I wanted to have the option later on. Besides, I already felt as though releasing small games for free was not exactly satisfying -- it was too hard to talk about them (for reasons described above) and too hard to be rewarded for them...

Again, could I ask for money for small games? Maybe. But I'm not good at asking for donations or charging money piecemeal. It feels strange and distracting. I prefer to think about chunky transactions that have a purpose

Note for self, here, that my focus is not primarily about what works to get money or what's right... even if I feel one way or another, my focus is overwhelmingly on what I like to do. Part of liking to do something is that it works! That it interacts well with the platform. But I'm making a whole grain decision based on the entire process.

The limitations/conditions for #droqtober:

- I'm going to make a game every day for 31 days.
--- "Like #inktober but for games," I thought. So the first few are hashtagged with "#gametober", until I was persuaded by a few people to use the much better #droqtober.

- You should be able to leave a game at any time, but each game should also have a win condition. (I have had a habit of releasing win-condition-less games that I've been trying to get out of. It seemed reasonable that all the games should follow this one rule, so that I could mark games as complete) - cut this aside in the article

- The game will control using arrow keys and space (with ESC for leaving the game) - Consistent controls are nice, all my games tend to use controls like this anyway. This was not really a conscious decision; it was informed by past designs as well as just the technical implementation being consistent (NavdiPinInput, mentioned above, by default has the "dpad" variable as well as two button inputs: "a" and "b").

- The games are made of pixel art.

- The resolution of the games will be 310 x 130. 310 for the 31 days in october, 130 for the Halloween-appropriate unlucky 13 and because it's the inverse of 31. Also the ratio looks nice enough, and it's divisible by 10, which means...

- The game will be made out of pixel art and mostly 10x10 tiles and sprites. This seemed like a fun variation on my usual 8x8 sprites -- it turned out to be similar enough to still be very comfortable for me, but different enough to mix things up a little and afford me some new creative space to work in.

- The player controls a single avatar. This aligns with my tastes, maybe I can more in-depth but that's just the way it is. The arrow keys (the "dpad" inputs) always exclusively move that avatar around, though the exact implementation varies. (In some games you can't move up/down at all. In some games "up" is jump.)

2

I knew from the start that these games were going to run out of the same executable. I like making small games, but I never know what to say about them individually. Consider one of my favourite, shortest games, I can't carry all these ducks! There's not much I can say about it without spoiling it, and though that's something I love about it, it's also quite inconvenient when I'm trying to share it with people. For a free 10-second game I can say, "it's free and ten seconds long" and that's usually enough, combined with a little social pressure, to get someone to at least consider it.

But my ultimate goal is not to design games that find their way into people's lives by virtue of promising not to inconvenience them too much. I'd like to make a sustainable living doing what I love, and asking for money is fundamentally inconvenient for others.

So, there are two games: there's the game you play in all its beautiful detail, and then there's the 'platonic' game, the imaginary simplified one you imagine before, during, and afterward.

I have a very personal attachment to every single one of the 31 games I made. There's a particular strategy that works for me when I'm playing the one about a haunted mansion -- Louija has to be positioned about a ghost's height below the ghost to have a chance at hitting them with the lollipop. One of the games has a normal ending, a false secret ending, and then the REAL, even more secret, secret ending. I love the pixel art in so many places for personal, silly reasons.

There are so many details that I couldn't possibly talk about all of them, and that's alright. You might discover them by playing the game, but even then I wouldn't expect anyone to develop the same relationship I have to these 31 games that I do. I'm not bitter about that, but what I do hate is the feeling that I have NOTHING to talk about as a result: that the work is a big collection of small details, none more important than the others, and that to talk about the game I must simply arbitrarily choose a detail out of the infinite sea of equally beloved details to share.

So, the wrapper serves the purpose of acting as the pretty face that's small enough to hold in your head but big enough to talk about.

In short, navdi2 saves me from doing things I don't like to do but which I found myself doing the same way every time. Along with this, I submitted a little: if I didn't like doing something I accepted the constraint that I would be doing it the same way every time instead of designing a slightly more beautiful bespoke solution. (NavdiBitsySprite has no support for defining duration of individual frames.)

These have all become sort of a part of my style and I like them, but they are nevertheless constraints.

This is not a magic bullet. There's still lots of hard work and messy code. But it lets me keep it to solving more interesting problems I've never faced before.

Also, habits: I'm familiar with certain moderately-complex problems and I let myself solve them in ways I've solved them before, re-using techniques which take advantage of Godot's built-in features (examples: pathfinding, or line of sight). Often I remember these because I thought about including my solution in navdi2 but dismissed them as too rare or too necessarily project-specific for librarying them to have any value.

1

navdi2 is my personal library for smoothing off the pointy edges of my workflow in Godot. Some examples of things included:

- a child of Godot's built-in Sprite node called "NavdiBitsySprite", inspired by the simple workflow of animated sprites in Bitsy. You give it a spritesheet and an array of frames, and in-editor it loops through those frames. It's not the most beautiful solution and often my animations don't run smoothly together and need a bit more massaging, but it means I can get something animated in my game in no time at all.

- a node called NavdiSettings that defines all the project settings exactly how I like them, with inspector input boxes for things I often need changing like game size.

Here's an example of something I DIDN'T put in the library even though I need one in every game I make: a 2D character controller.

I tried, but quickly realized it's a part of the process I don't mind redoing over and over again. Actually coding a character controller is one of my favourite parts of the process.

I do have NavdiPinInput for turning the arrow key inputs into a simple variable called "dpad" because in the process of writing character controllers I do get annoyed always having to convert Boolean inputs into a float with a line like...

dpad.x = 0
if Input.get_action_pressed("left"): dpad.x -= 1
if Input.get_action_pressed("right"): dpad.x += 1

It's only three lines of code but it's literally always the same. Coming up with the NavdiPinInput node saves me a tiny amount of thinking and rewriting in every project I ever make now,

Exactly what you consider repetitive and what you enjoy doing is quite personal, and nuanced. The code for navdi2 is nothing complicated but it came together in tiny pieces across 2 years: I could not have conceived of and written it from scratch. Rather, each time I finished a project or wrote a nice chunk of code I looked back on my messy code (which normally and commonly remains messy through all phases of development through to release) for things that I did which looked potentially re-usable. Then I'd polish them up for re-use, and continue iterating anytime they hit a snag in future projects.

3 parts

What is Navdi2? How and why did I build it?

Clever wrapper: the art form of titles and game releases.

What was learned.

I long forgot about this talk.

https://www.youtube.com/watch?v=stxVBJem3Rs

I'll grab the quote from it sometime but wanted to leave it here. He says something similar: about just not doing the things you don't want to do if you want to have a long-surviving practice. Something about "wearing you down to a NUB" after 40 years.

You want sustainability? Do what you love.

This isn't "Do what you love and you'll never work another day in your life." It's work. But it's not gonna kill you

Right, but... the ubersimplified takeaways version isn't why I asked the question in the first place. I wanted to get the temperature of what people think works. I guess my conclusion is: wow everyone is pretty different! I need to paint with a broad stroke to see if there's some undercurrent about what people agree on.

Motivation is important.

People are very good at procrastinating - VERY good at it. It's a hard lesson people need to learn. Short projects help you skip past that: a small project has less places to hide.

Hmm so conclusion: Finish things. But not because "finishing things is a skill." It's not. Finishing things is a goal, an accomplishment, perhaps a habit; anyway IN ORDER TO ACHIEVE IT YOU MUST DEVELOP A TECHNIQUE. But everyone will use different techniques. This is why I don't think it's a skill. It's too... big.

Takeaways, ubersimplified, but in conflict

1. Ask something between:
1a. Will I be able to work on this until it's finished?
 -VS-
1b. Will I want to work on this until it's finished?

2. Solve the biggest problems first. Don't procrastinate. Common forms of procrastination: solving smaller problems; or ruminating on "how to best solve this problem" forever.

droqen's takeaways

*** Be careful about falling into traps that let you off the hook for solving fundamental problems. e.g. If something is NOT FUN, making it MORE ATTRACTIVE or MORE RESPONSIVE (i.e. "Polishing" it) is not (generally speaking) going to make it fun. To solve a problem, solve the problem.

*** Don't ruminate on best solutions when you could just be working on solving the problem.

*** Follow your own energy. What does that look like in detail? Don't use tools you don't like. Extrapolating on that: Don't do tasks you don't like, and don't do them in ways you don't like to do them. Solve the problems you like to solve. Solve them in the ways you'd like to solve them.

*** Look ahead (this requires experience) to determine how much 'motivation' you have for a project. !!!

*** Look ahead (this requires experience) to determine how realistic a project's scope is. !!!

(!!!) Dig way deeper into these two. What makes a project realistic/likely? What makes motivation tick? This is extremely core to the whole thing. It's also extremely difficult to get specific about.

"At worst, [polish is] aesthetic minutiae that only the creator cares about."

"focus on a [bigger] game [..] anything smaller I make isn't nearly as fun. the bigger one already is, just needs content" - how do you know? what content? 'content' as shortcut word as if the problem has been identified.

"following my own energy. I used to think many parts of the process had to be pushed through, but that was me doing it in a way I didn't like."

- intuitive motivation - just a feel for the ideas that have promise as a larger project, and which seem possible.
'motivation to have it wrapped up into a complete experience'
'i want to turn this into several levels and have people play it'
which ideas are 'likely' and 'exciting'?


inverse answers came more easily. red flags: what NOT to commit to

- "Minigames" was just a trap to let me off the hook for designing the core gameplay right away (don't procrastinate fundamental problems.)
- Stop ranking (ruminating), "just do it already"
- "following my own energy."
- Don't use tools I don't like
- Don't polish something that's not fun
 *** I asked more about this one. "If something shines with a rough prototype, you've got something that is going to glisten when polished. That benchmark is entirely subjective // Polish is best when it reinforces design signalling or affordances. At worst, it's aesthetic minutiae that only the creator cares about."

quotes from responses to these 2 tweets and privately
tweet 1
tweet 2