(Notes, draft) How I made 31 unmarked games in a month. #droqtober postmortem.

[droqen]

Making a game can be difficult, systemic games especially. Everything leaning on everything else. It's a hell of a puzzle. I liked the frankly relaxing nature of making a new game every day: throwing away the stress of "today's work must build upon yesterday's work" in favour of a structure enabling maximum freedom -- to empower myself to do "whatever I feel like" today.

I didn't stick completely to familiar genres, but I stuck to a few things that would help me stay on track and some of those things did involve sticking to some familiar spaces.
1, Every game is built in a single Godot project with all assets in its own folder (with exceptions: 12, 28, and 29 comprise the cassette player "meta" game, so they share assets). Using one engine and a clean format from the start made it possible to bundle the games together. I had folders named "1thru10," "11thru20," and "21thru30" from day one.

2, Every game is 310x130 resolution, and uses 10x10 tiles. The 'weird' resolution and tile size kept me on my toes, not relying too much on old patterns, was powerful/flexible enough to never get in my way, and finally was fixed so I never had to waste time thinking about what the right parameters were for a given game, they were already set.

3, Every game uses 4 directions and 1 button. The escape key takes you back to the menu. Same benefits as above, but also easy for the player to learn.

4, Every game has a win condition.

5. In every game you have an avatar that you directly control using the given inputs. There is a 'puzzle', as you move from game to game, of understanding the controls. Having this fixed across all games meant that it would never be much of a problem. also I just like this type of game! It lends itself to platformers often, but not always.

[droqen]

Had a conversation with Patrick of Patrick's Parabox in which I broke down my workflow - I used Godot Engine with a custom library that smooths out a lot of things for me in particular. My estimate is that it came together over the course of a year or so, bit by bit.

Specifically, some pieces that it enables:

1. Pixel art, sprite-based animation

2. Tilemap-based level design

3. Pathfinding (used in games #03 and #25)

4. Simple physics (both kinematic and rigid)

There are more, but a high level of experience & familiarity with these pieces come together over and over again to enable me to put together games that I like, without reinventing the wheel -- EXCEPT those wheels I love to reinvent. I really like designing gamefeel, for example, so I don't have a re-usable platformer character controller. I tried, but discovered that I never used it because I preferred designing a new one from scratch.

[droqen]

HUGE TEXT DUMP INCOMING...

Here are the entirety of my loose notes from writing this piece, and I think the conclusion I came to is that this reads a little bit too much like a love letter to the process and not enough like a useful technical piece about what made #droqtober tick. I do get carried away, don't I?

https://eggplant.show/81-scaling-and-scoping-with-asher-vollmer-beast-breaker
[38:00] "Building a life that is sustainable and doing what we love."

The framework: from 'zero' to 'basic game' as quickly as possible
PIECES THAT WORK TOGETHER FOR PERSONAL NEEDS.
    My specific workflow:
    Pyxel Edit to design a tileset
Desire: I like doing pixel art, I like starting a project with pixel art sometimes
Godot with Navdi tools to get it working (should I link the tools?)
* Past experiment: I tried writing a template character controller but I enjoy writing that code so I never ended up using the template character controller
* Compare: The Navdi tools are for skipping over stuff I hate doing but have to do every time. Turning only a few minutes of "ugh this again" into one second of "ok done" is worth the effort.
    The turning point, the structure
Every game needed an end point, and I knew this. I didn't always have an idea of what it would be, but I had the technological signal in place, and at a certain point in each project I would look at how long I'd been working on the game and what else I wanted to do that day -- how much time I wanted to hang out with my partner, cook and eat food, chill and relax -- and made the call to switch gears. "This is fine and I've spent 2 hours on this game already, I need to start wrapping it up." The games didn't have title screens or end outros or anything, and it still generally took me an hour to wrap up all the things I'd been putting off. (Bugs, bad-feeling edge cases, testing the level design, sometimes even conceiving of and implementing a win condition. "This needs enemies, it's too easy!" "This goal is terrible! What is more fun?")

ADHD and me. 1-day attention span.
PEOPLE HAVE DIFFERENT NEEDS AND STRENGTHS. It's not always the right move to make a game in 1 day! It worked for me because I've always gravitated towards making games in 1 day. TOJam is a 3-day game jam and it's pretty much a constant that I make three games, throwing out the first two and settling on the third... but that's three games in three days, like clockwork.
You have to practice the craft to understand your relationship to it. What can you make in 1 day? What can you make in 1 week? What do you want to make, and how long does it normally take? Designing 31 games in 31 days is not a test of making as many games as possible. I could have tried to make 62 games in 31 days! But that wouldn't have worked with my learned rhythms.
By all means try making a game every day for a period of time, but if you want to take a week on a game and that feels right to you, do that. If you want to take a month, do that.

UNDERSTANDING THE DAY TO DAY PROCESS
is very important to me

DEADLINES
Missed deadlines are not "you did bad" or "now you need to catch up on this" when you're indie, accountable only to yourself. They are feedback. They are information. Yes, you should work to hit your deadlines, but you should also ask why you missed them and how you can design your deadlines to push you better in a way that makes you more comfortable but also more productive.

DROQEN WAS HERE
Doing this zine every month, building a habit...
It's relevant somehow.
(I'm late finishing this month's.)
How does artmaking fit in to my life?
    OUTLET FOR SKETCHING
OUTLET FOR NOTETAKING

Note on the style of writing: I'm writing this about myself, for myself, to myself. I write this way because I think this way, and I think this way because it's good for me: I talk to people all the time who have different perspectives on what's good for them, and I know that what's good for one person won't be good for everyone. I think in terms of designing FOR MYSELF, and sometimes it's also good for other people. So there.

DEADLINES AGAIN
Permission to stop.
Working on a project that's going to take years, how do I know when to stop working for the day? How much is enough? It's a slippery slope.



"Why don't I feel like cooking cauliflower soup today? What's wrong with me?"

I started thinking about how to better understand my own impulses and design a life around them sometime during lockdown in Toronto. It wasn't even about the work of designing games at first, it was about cooking. I had this expectation that because I was capable of doing something, that my capacity to do it was a resource I should be able to tap anytime.

I know I can cook cauliflower soup. I've done it before. And I know I can work with higher resolution sprites (for me that means 16x16 instead of 8x8, lol), I can make passable 3D games, I can write netcode, etc.

Big over-scoped projects often place too much emphasis on the end result and not enough on the process. When process is discussed in a productive light, it's often fluffy, fuzzy platitudes, dreams, aspirations: "making games should be sustainable," "we made a committment to no crunch." But nobody really talks about how to prioritize your self in work, only that you should take breaks when it gets to be too much.

Why in the hell do we let it get to be too much in the first place?
#droqtober
The topic of this article is #droqtober, my project to make a game every single day for 31 days straight. (It took a little while for people to convince me to use this name, so the first few are hashtagged #gametober or #protober. But they're part of the same project.) On midnight of the final day, I released a compilation of all of them, 31 unmarked games, for $5 on itch.io. You can get it here: https://droqen.itch.io/31-unmarked-games

When I started, I thought it was some absurd undertaking. An epic feat. I thought I was basically capable, but that I was going to put myself through hell to accomplish it. Then a week passed, and it wasn't hard at all. It was an easy, familiar rhythm to me, maybe because of decades spent making small games. More on that later, but right now it's very important to set this stage correctly:

I don't consider #droqtober a creative success because it was a struggle over which I triumphed; I consider it a success of identifying, experimenting with, and ultimately committing to a project that deeply suited my skillset, my personality, and my humanity.
sustainability
This is a word that I hear a lot. Crunch is causing massive burnout, people are dropping out of the games industry, and the solution to all this badness? Sustainability. So far it's felt like a far-off goal. It's not a strategy or a plan in itself so much as it is a cultural ambition. The solution to burnout: don't burn people out! The solution to crunch: don't crunch!

It's an important aspiration, but these answers have always felt incomplete.
first, godot
What does my process look like, and why?

I moved from Unity to Godot Engine a couple years ago for many reasons. Most of them came down to removing points of practical frustration that I had been accepting for the sake of saving myself future, theoretical frustration.

Godot Engine's benefits (mostly practical)
Lightweight, runs better on my computer
No seconds of build time after changing a script
GDScript is like Python, and I love Python
Built-in script has very nice autocomplete (I never did get VS Code working well)
Engine is easier to understand, and therefore modify* to better suit my needs
I like its Nodes better than Unity's Object/Compon
I like its Scenes better than Unity's Prefabs (at the time prefabs were very iffy. I don't know if they're fine now. I don't really think about Unity at all!)

Unity Engine's benefits (mostly future, theoretical)
More people use it so it's easier to collaborate (I wasn't collaborating much)
Capable of porting to consoles effortlessly (we'll see if I regret this one)
More people produce great resources for it (I don't use the asset store though)

.. I made it small so it doesn't totally dominate the entire page. I'm going to have to think some more about how to write the pieces that will actually be useful. Maybe some parts of this text will actually be found in the final, I don't know yet. Rough drafts! Woo!

[droqen]

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.

[droqen]

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...

Code Select Expand

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.

[droqen]

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.

[droqen]

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.

[droqen]

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.)

[droqen]

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.

[droqen]

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.

[droqen]

3

What was learned.

[droqen]

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.