The Joys of the Short Game

29 May, 2026

Good afternoon!

About a month ago, I published the game Repopulate. It took me roughly 1 month to create, and all of it was done by me. I have had very little of my own artwork in my published games up to this point; in Wrangler, it was just the environments and stat screen sprites; in Washing Machine, the HUD; in Tournament of Venus, I filled in a couple character sprites and portraits to get it done "enough" for a release (I love you Goruu). I attempted a painted style - not something I do normally - and made the game high-res for once (twice; WaMa is HD).

When I meet new people in furry circles, I inevitably bring up that I'm a game developer. On occasion, they will express their own desires to make games as well. Almost every time, they present me either a top-down design without a mechanical backbone, or a bottom-up design so sprawling it cannot possibly be done this decade. If you're an aspiring game dev, or one of these folks I've talked to, this blog post is for you specifically.

Top-Down vs Bottom-Up Design

When designing anything, be it a novel, a movie, a game, whatever, there are two schools of thought. Top-down design starts with a concept (a sex tournament), and molds the mechanics¹ around that idea (WarioWare minigames). Bottom-up design, in contrast, starts with a mechanic (gamifying sex by maintaining an arousal meter), and molds the concepts around it (a king who has to cum over and over). Obviously, the design of a particular game will never be all one or all the other, and games in particular tend to fall into a feedback loop, where mechanics can drive story beats, and vice versa. Generally, you will start with one, and its backbone will inform the rest of the game.

I am a mechanics man, and generally prefer bottom-up design to top-down. Of the four projects I've published, ToV and WaMa are top-down, whereas Wrangler and Repopulate are bottom-up. I have made a board game prototype as well that was bottom-up; it famously didn't have any context for game actions until I had dinner with one of my friends.

So Low, So High

My game design philosophy is to have at least two "modes" - the High section and the Low section. Tournament of Venus is the most obvious with this - the battles are a series of fast-paced minigames and explicit sex, while the lobby lets you go at your own pace and have conversation with the inhabitants. This design philosphy has two advantages. One, it gives the player an explicit place to stop (think Mario world maps). And two, it prevents the player from being overwhelmed by action, or bored by routine. You can have other sections of play as well, but overall they'll fit into one of these two modes, and should be bookended by the other mode.

Repopulate also has this two-mode design. The sex is the High mode, and the dialogue is the Low. It's only about 15 minutes, so the relief periods are short, but this I think adds to the way the game presents itself. The king is in way over his head, and even these little periods of respite are filled with complaining or adding on to the madness.

Pequeño

The beauty of the modern indie game is that you can have one central mechanic that you build around, develop it, and throw it out the door. Repopulate's central mechanic of each new gadget (as they're called in the code) adding diminishing arousal is not something you can build a 40-hour experience around. And that's great!

One of the pitfalls of the aspiring game developer is what a friend and I call Skyrim 2. When you see the infinite possibilities game development offers, you can't help but say "what if I made my own everygame?" You put together some characters, or mechanics, or world, and build up this system in your head that you'll make something groundbreaking, something absolutely incredible, and it's gonna make you a million billion trillion dollars.

Then you sit yourself down in front of Unity or Godot, watch a tutorial or two, and get to work. After about five hours, you realize, "oh god, this is a bottomless pit".

I am not exempt from this. When I downloaded Unity 5, I was convinced I was going to make The Next Big Thing - party-based RPGs are cool, but what about the cooldown systems from this new "Overwatch" game that just came out? Mana systems are so antiquated! I hate using Ethers!

I spent hours brute-force learning to write code. At the time I had zero artistic ability, and nothing but a scanner for scanning paper-and-sharpie drawings I had scribbled on. I even recruited someone from my high school to do some character drawings. After three or so months, I had a horrible, unbalanced, unintuitive, boring turn-based PvP game. I had my family members help test it, and it was clear even they thought it was terrible (rightfully!). I keep the battle script around as a reminder of my progress - it was a single Unity script, and all attacks were paged through using two nested switch statements. I didn't know what an Array or List was either², so I had character1, character2, character3... variables for each of the combatants. It was atrocious.

When I talk to aspiring game developers, I tell them this story. I tell them that I don't want anyone else to go through what I did. But I warn them - you can't watch an hour-long YouTube video and pop out the other end a competent programmer. The hard truth is, programming is a skill in the same vein as woodworking. You will fuck up your first few attempts, probably catastrophically so - and that's fine!

Keep It Simple, Stupid

When you learn woodworking, you usually make something small - a birdhouse, a table, whatever. The point is to get you used to the tools and understanding how the materials interact with each other. You should see game dev the exact same way. You shouldn't make your first game a massive, multiplayer, multi-class RPG. Make Mario. Make Space Invaders. Make a Pokemon-inspired battle system and then hack together a mission select³.

It's okay for your first published game to be small and simple. You should make a tiny little thing that you alone can bring from concept to published. Making attempts at a big system and failing over and over does help you learn, yes, but having something that's largely unimpressive but complete will do so much for you. Anyone can make a birdhouse, sure, but if you put it up, you'll still get some sparrows in it.

The advantage of software is that it's soft - you can build on top of it later. Instead of combining Cooking Mama with Silent Hill, make a little game where you serve ice cream to increasingly hornily dressed customers. And who knows, maybe your little ice cream game will inspire you to fold in some other mechanics you didn't think about before. Maybe this ice cream game can have minigames for each step of the assembly process, or the customers can have a Papers Please style storyline.

The point in all this is to make something so tiny that you can fit it in the palm of your hand. If I did Repopulate three years ago when I first started, it would've taken me at least three months. Publishing Wrangler required me to touch a ton of Godot systems and concepts, and by the end, I was falling apart. I honestly really regret having Wrangler be my first published project, because it was way more work than I anticipated. And even worse, the version of Wrangler you can play today is about 1/10 of what I had planned for it. I fell for the big game meme too - there was gonna be a whole open world, with towns, quests, NPCs, and 50 creatures, minimum! Once I actually got into it, though, I quickly scrapped all of that, and stuck with the mission select and six creatures. Even that took nine months⁴.

Make Mario! Make a horny game that has a new or weird idea, plays around with it for 15-30 minutes, and then exits! Knowing from the very start what the finished game will look like - and I mean the whole thing can fit in your head - then you're gonna learn a lot.

Game dev is not easy, and is insanely time-consuming. Assets in particular always take longer than you expect. But when you keep your scope small and your design simple, you have something you can publish and be proud of. Go out there and start creating!

P.S. - regrets.txt

A final note for you - it is imperative that you reflect on your project after it's published. Take your own experience plus that of your players into account. You don't have to make these public, but it is good to know them. It's critically important that you don't do this until a sufficient amount of time has passed from launch. Here's my postmortem of Repopulate, about a month after publishing.

Negatives:

• I wish I had hired an artist to do the intro and outro comics I had planned. I knew from the start I would not be motivated to make them, and yet, kept pretending that it would magically come to me.
• The dialogue was pretty mediocre, but that makes sense, because it was the very last thing I did.
• I think the cutout animation looks ugly.
• I should've redrawn the Subjects' vagina to look more like a humanoid one, instead of essentially a pool floatie.

Positives:

• Reception was really good.
• I think sex-as-a-mechanic was represented well by these systems.
• I did all the artwork myself, and did not crash over the art workload.
• Nobody complained about andromorph characters!
• Knowing ahead of time exactly what mood I wanted to evoke made design easy.
• Designing about ten gadgets allowed me to throw away overcomplicated ones without worry.
• All the gadgets were immediately intuitive to players - testers knew right away how to use them.
• I got to be funny!
• The differing personalities of the king and Qi came through in dialogue.
• I learned how to do a painted style, and genuinely really enjoyed painting things, like the king's cock, the rug, and the tiles.
• I was able to make a lot of different-enough Subjects with a low amount of unique assets.
• I used gdscript for an entire project, which allowed a web version, which absolutely increased player count.

Notes