Literally every time I've set out to make a game, I've let perfectionism get in the way. Some examples:

- Spending all my time thinking about how to support 10 different resolutions

- Coming up with the perfect framework for managing state

- Working on silly menu systems and other UI elements

- Finding the perfect map builder and obsessing over data representations

- Tweaking an entity component system to death

- Etc

Next time I set out to make something, I'm not going to worry too much about the code. If the idea has merit, I'll refactor it later if I need to.

Summary--It's really easy to let details get in the way of ideas.

I think a lot of it is what types of games or genres you're interested in. Certain games / genres of games work better as small games than others.

Like I've worked on a lot of small games (https://vgel.itch.io), some better, some worse, but I've never tried, e.g., an FPSRPG or a Dwarf Fortress-esque simRTS. The process of "stripping down" those genres to be feasible as a small game fundamentally transforms them into something else. When you rip the complex skill tree out of an FPSRPG to simplify it, it becomes a different kind of game! And some people just don't like that—they only want the complex game. They didn't like early Minecraft, they only like Minecraft now, after 10+ years of development gave tons of interlocking features and mechanics. And that's... what it is. It makes me a little sad, but I don't think those people will be very happy as solo indie devs (unless they have the superhuman willpower to push through years of development on a single game without enjoying the early stages or the tight feedback loop of improvement you get by releasing smaller games).

I've tried to sell this vision to people before, maybe not as eloquently as OP, showed them Itch.io and some of my favorite games on there, and... they just didn't care. It didn't interest them at all. Other people got the appeal immediately. It just seems to come down to personal taste.

"I can tell you “scope small uwu”, but if you don’t believe small games can be good in the first place, all you’ll hear is a homework assignment you have to do before you can make the games you really care about."

This is both an important insight and excellent writing.

Something I've struggled with and have seen often is engineer-types drawn to game development who lose themselves in code, tech, and getting it "just right." It's super important to be clear about _why_ you makes games. If it's just to blow steam after a long day slinging JavaScript or to dabble with new technology be honest about it -- you'll spare yourself pain later. If you really want to _make_ games remember the aphorism, "real artists ship."

On the subject of scope, I think it's helpful to remember the Mythical Man Month. If the game you're cribbing took four experts two years to create, that's eight person-years. Can one person hope to make something of that scale? There are examples, but few have that level of resolve.

Don't hand wave away things by saying "modern game engines." People were brilliant back then, and expectations were lower in some respects.

I made a pretty cool semi-idle game recently, in the spirit of Progress Quest. It's called "Console Quest" and runs from the terminal.

It's a simple RPG where your characters fights monsters and completes quest achievements without your input, but you get randomized chances to visit the merchant or medic, which largely determines your fate. It seems simple at first but it's harder than it seems as the game moves on.

https://github.com/donuts-are-good/consolequest

I made it just for fun one night, and found it strangely addictive all on my own while testing because I'd want to keep playing even after verifying the thing I was testing.

P.s. my high score is 356 days in game. not sure it's possible to get higher, you get wiped out quick.

It'd be my pleasure if anybody wants to play :)

My partner and I are developing a very-high level 3D dialect of Logo. It makes 3D game development MUCH easier because you can code from the perspective of turtles in 3D space.

I've had a lot of fun developing a bunch of different games in it, and as more features / keywords are added, I get to write even more games! It's been a blast. We recently added physics capabilities to the turtles, and I'm working on using those for some new games.

I have a 13-year old guinea pig I've been teaching how to code in Logo, and she loves how much she can do in so few keywords. She's recently started competently debugging her own code and I'm proud of that.

https://turtlespaces.org (website) https://turtlespaces.org/weblogo (WASM IDE)

If you enjoy small, self-contained games, obviously check out Vampire Survivors as a recent phenom, but SokPop collective on Itch and Steam puts out a new game each month and while many of them are barely passable, some are truly great, especially Stacklands which I think is their biggest hit, but a very short/small game overall.

I think the biggest trap is that people imagine their games will be fun. And then as they build them they realize it’s not. A lot of the fun was just their fantasy.

Also relevant: https://a327ex.com/posts/snkrx_log

The developer talks specifically about choosing a small scope for a game, and clearly spends a lot of time thinking strategically about being an indie dev.

I feel like this advice applies to a lot more projects than just video games.

I thought this was a good write up on why to make a small game and how to conceptualize your process, and some technical advice. I was sorta hoping it would be more “I’ve accepted I want to make a small game. How do I make a good game?” As someone who likes the idea of making small games, I don’t know the discipline and I know there must be. Writing excellent software has a variety of specific ways of thinking about software and it’s implementation, how to organize ideas, what parts to not forget to plan our carefully up front and what to discover in the doing, etc.

I truly do believe that small games can be good. I know plenty of small games and pretty much the only games I have really loved in the last few years are small. But I don't agree with "A game's quality is independent from its scale". I actually think making a small game good is much harder. If you have fewer dials to tweak, it's harder to come up with a configuration you haven't seen a dozen times already. Especially not one that works. Most of the ideas that I want to work on are larger games, because I don't have any ideas for small games that I imagine to be good. I wish I had them. I have made a bunch of games and also many game jam games (i.e. smaller games - maybe 15+? - see here: https://theshoemaker.de/projects), but I think none of them are actually good. Nothing like the tiny games other people have made, that I adore. That is a level of mastery I have simply not reached (yet?). Of course I am aware that I can just try more things, because the stakes are lower, but you need a critical amount of falling-in-love with an idea to even start and all the ideas I do fall in love with are for larger games.

I had a housemate who could make a cool game in an afternoon. He was a bottomless well of interesting ideas. He works in finance now :-)

Anyway, his games were horrible messes of magical Peek and Poke statements in Atari BASIC. But . . . they were FUN. And they took a couple of hours to write.

An excellent game where the designer/programmer doesn't let things get in the way of building is Aurora 4x [1] (not really a small game anymore). Only runs on windows, doesn't even have modifiable window sizes. For users that have period separators instead of commas a bunch of the text is cut off. It's a fantastic game that is purely what the creator wants and plays and is nothing more, and it has a great community behind it. It is purely a work of passion by the creator.

[1] https://aurora2.pentarch.org/

Notch made many small games before he did Minecraft.

For small games I really think it's easier to just use C++/SDL or whatever language and framework one is familiar with and go from there. A simple 2D RPG might be the most one can complete in a reasonable amount of time (say a few months) but once you have an engine you can "reproduce" quickly.

I spent hundreds of hours as a kid building small games like this with Klik n Play, then Klick and Create, which turned into The Games Factory and now lives on as Clickteam Fusion! It had a simple image editor and event based programming system that was accessible to a kid and still pretty sophisticated. Huge influence on my later programming career. https://en.wikipedia.org/wiki/Clickteam

I can say my game(s): https://wdpauly.medium.com/trade-economy-and-supply-3a9eff92... fall into the scope creep issue, but at the same time the complexity and scale is what makes it so interesting. If you enjoy tech/programming then making something addictive and fun may not be the point so much as the mental simulation you get from the project as a whole.

What makes a game “big” or “small” in this case?

I’m wondering, because I was going through my steam library after reading this, just looking at the games I play and trying to fit them into “small” and “big” and while many seemed obvious, many were also hard to tell.

Is it the size/scale of the development (i.e. indie vs AAA)? The mechanical complexity? the graphical complexity? The volume of content? The size on disk? maybe some combination or something else entirely.

I think it's useful to aim for learning. I built a small game that runs on Android, Android TV, and Linux just to get more C++ exposure. I'm not sure if it's "good", but it's definitely small. And good enough that my child actually wants to play it, and even better, suggests improvements.

I wouldn't call Umineko a small game by any means. It is very good.

Unless screenshots were just for conveying the satisfaction point.

> I don’t make any money doing it, so if that’s your goal then this piece probably won’t be that useful to you.

Hobbyists unite!

Very well written. I really dig this. Thanks!