How to make good small games | Hacker News Reader

How to make good small games

farawaytimes.blogspot.com

261 pointspmarin90 comments

Open articleView on HN

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.

You should try making game jam games, if you haven't yet. It really teaches you to ignore things that are not absolutely essential. And all the stuff you have listed are good candidates for post-jam bugfix versions, so you don't ignore the more important things either.

Good suggestion -- there's a hard constraint (time). That becomes a forcing function for decision making.

This. The best thing about game jams is that you'll better at the next one. You'll learn to focus, not to overshoot the scope, manage your time better and do quick iterations. I've done a few on Itch and the community is really friendly, which provides enough drive for me to submit before the deadline even if the result is quite wonky. If you rate other people's games, they'll probably rate you back, which is great.

One particular game jam I recommend is Trijam [1]. It takes place every weekend, has a fixed theme and ideally you should only spend a total of 3 hours on a game which forces you to do something relatively simple.

[1] https://trijam.itch.io/

The important part to focus on here is "small". Any idea you have, shrink it. Make it 10x smaller. Create whatever that is.

It's kind of the problem with games, they consist of so many fields it's easy to think you have a "small" idea only for that idea to actually be substantial. Then, reasonably, when you want to nail the details it becomes a gigantic mountain. To me this isn't perfectionism, everyone wants to nail details, but when the scope is too large it's difficult for that to happen - hell it's difficult for that to happen on teams of tens of thousands operating as cogs dedicated to their tiny section of work!

Any one of your bullet points could have been the "small game" to demonstrate how large you're still operating.

Exactly -- if I look at how much time I put into building "frameworks", I could probably have made a dozen small scale prototypes in the same timeframe.

This happens to me with _any_ project if I don't:

- set a clear time boundary and a date, typically by estimating chunks of the work, it's better to make wrong estimations than to yak shave the crap out of something for way too long

- write down the goals and non-goals.

- make a clear, simple high-level design, including trade-offs and cutting corners to meet the goals

- implement vertically, get something going fast

Stuff like that...

Basically with an open ended, creative endeavor I absolutely need to restrict myself much as I can stomach. At least in cases where I actually _want_ to finish a project and know what its goals are. In many cases exploration and playing with code and techniques is the goal itself and that's OK.

I've been doing this a while now. I have a main foreverproject game I just toil away on for, well, forever. But I create dozens of mini games outside that foreverproject to experiment with ideas for the foreverproject.

For me the foreverproject is where I drive all that perfection energy. The surrounding games, well, they're just "experiments" and "prototypes", right? Surely prototypes don't need to be perfect ;)

Is your forever project public? Would be interesting to see what it is.

Unfortunately it isn't. I recently switched my forever project after working on the same one for a couple decades - it was a MUD (text multiplayer RPG).

The playerbase dwindled to nothing and I wanted a different challenge so I shuttered it. Over the years many people worked on it and while I'm sure they wouldn't mind if I put it up on github, I've lost contact with many of them so I don't feel right releasing it, so it's just in the bitbin of history.

Now I'm working on a 2D version of it, which adds a whole new dimension to the challenge. Once I have something more than just random prototypes I do plan on putting it up. But it's slow going - I have a job and kids, so I get about 1 hour per day to work on it.

There's so much lost that was in MUDs, including a huge amount of good, descriptive writing of vast areas. I wonder if a later iteration of the Dall-E / Midjourney / Stable generators might be able to create visuals based off of rooms descriptions.

I'm obsessed with other people's forever projects. Have you written up the "grand idea" in a blog post or anything? Love to hear more.

I'm trying to break my own BIG IDEA into manageable experiments or profitable side hustles somehow too.

I don't know if it's particularly inspired or "grand idea" - it's just a 2d multiplayer rpg, and with something like that the sky is pretty much the limit.

If I had to peg my general philosophy, which is tied to how I like to play games: it's on being open minded when it comes to strategies players can use to overcome challenges within the game, and try to codify some of that within the systems built into the game so players have options to overcome challenges in ways other than gladiatorial-like combat.

Basically, I think "exploiting" is fun, and believe it's an overused term.

This is the way to go. Just remember to market yourself by your "experiments" and "prototypes".

I design board games and have designed 30+ (one signed so far). I've come to the following conclusion about game design: It is sometimes a freaking slog! I always tell people to work on the design (or game part) they are most excited to work on. Maintaining momentum is key in my opinion. If one design or game part is blocking, set it to the side and let your subconscious work on it while you make progress elsewhere.

There is another tenet from board game design to get the idea out of your head and onto the table. Showing designs to trusted others asap is imperative. Very much a "perfect is the enemy of good enough" situation.

A practice I find useful is to have a few projects going that are in different stages. So maybe one you're still planning/dreaming up, one in the core execution phase, and one that just needs finishing touches. That way you can switch not just between subjects but between modes of working to give your mind a chance to refresh.

If you have designed thirty, you might have some insight on a question which has vexed me: are there automated or semi-automated ways to look for "fairness" and playability and such? Any guidelines?

I ask because I have a friend with a game idea that looks fun, but it has enough tweakable parameters that I could see a poor selection leading to unbalanced games, or a clever combo being difficult to beat, and so on.

A big selling point of most games is that they're new somehow, you don't yet know how to play them. A mere possibility of analysis like this would probably constrain games to a solvable genre.

This works with patterns used to create games though. Few will play rock-paper-scissors a lot, but using it as a conflict resolution mechanic with known characteristics works great.

Ultimately, only ample real-world play-testing can answer these questions from a human perspective.

I share your concern though. You don't want to publish a game only to find, when attacked by real players in quantity, that your design is broken.

For the board game I'm working on, I've found running many simulated games with MCTS-based AI players has proved instructive in some respects. For example, balancing for turn-order fairness.

Well, balance is a very very funny thing. There are lots of board game design articles about it. A lot of designers will employ spreadsheet and Monte Carlo to achieve "balance".

The thing is that players don't want actual balance; they want to feel like it is balanced. And much more importantly, it must be FUN! If a game is too balanced it might well be boring and that is worse! My goal for balance is to try to make it so that players of equal skill and exposure to a game all have a reasonable chance of winning any game play.

I do know of some designers who start with a perfectly balanced game so they have an anchor. Then they adjust it over play-testing sessions to be more fun or create the experience they are designing for. I have a game that is Dracula vs Van Helsing in a hidden movement chase. I KNOW that Dracula has a 60/40 advantage. However, during unattended play-testing (random people are just given the game and rulebook and I'm not there), players overwhelmingly reported feeling that Van Helsing was far too strong!! Perception is everything.

As for your friend, they should look at having it played during a Protospiel or Unpub event. Some are in person but there are others online. They will get immeasurable feedback to direct their design. They are also innumerable podcasts that discuss these topic like Ludology and Discords like Building the Game and Break My Game they could join to get more feedback and advice.

As for random set ups creating unbalanced games, that can sometimes be even the desired effect. It depends a lot of the type of game, length of game and target audience. For example, Uno is completely random and unbalanced in terms of game decisions. However, the point of the game is to allow kids to beat their parents while learning matching. It is a 15 minute game so you just play again and move on with life. The memories and excitement are the desired game experience, who cares about balance?

> The thing is that players don't want actual balance; they want to feel like it is balanced. And much more importantly, it must be FUN!

I play a ton of tabletop games, and it is very obvious when a game was developed by someone who doesn't understand this fundamental truth.

> I've come to the following conclusion about game design: It is sometimes a freaking slog!

I think that's probably true of all development, be it game, software, property, whatever.

When I'm working on a game, I create an incredibly simple version and iterate from there. By simple, I mean just a box on a ground would be considered a first version. Next version, added movement. Next version, added lake etc......

I also make sure it's default live so I can get continuos external feedback as well.

You forgot:

- Looking for the perfect domain name

I notice that none of the things in your list are actually about the game. Maybe reverse the order of things and do the game bits first?

That's not perfectionism, it's failure to prioritize and manage/prevent scope creep.

Unless you already have a playable game loop that's so fun it's hard to put down, you shouldn't be going anywhere near menu systems.

You should have what's basically a rickety CLI-invoked developer mode test harness, where the binary immediately enters a playable thing. Only once that is proven as something worth putting a menu system in front of should you even think about that.

Most game ideas suck when implemented so they're a total loss, or require a lot of iterating into something entirely different from what you imagined. So the top priority should be implement the game loop of your idea, learn if it sucks ASAP, then maybe try mutate it into something a person can't easily walk away from if you sit them down in front of it, or just cut your losses and do something else entirely.

Sounds like perfectionism to me. Why do you insist it’s not? Nothing you said seems in disagreement with what he said.

That's not perfectionism, that's something else. Building out menu systems before you even have the core game loop locked down is basically like building out a house before you know on which plot of land it should be built.

But how does that make it not perfectionism? Having the wrong priorities is in no way inconsistent with perfectionism.

I also don’t think that analogy works because the things he mentioned mostly do need to be touched to develop the core game loop. The problem he has is that once he touches something he can’t leave it dirty. That’s the way in which it’s perfectionism.

> But how does that make it not perfectionism? Having the wrong priorities is in no way inconsistent with perfectionism.

It's not perfectionism because you can't even succeed at making the perfect part without more of the whole defining what perfect even looks like. The requirements evolve/emerge as the whole does.

It's just misguided premature effort, but there's a very strong force driving this mistake - it's easier and more fun to trim the sails than build the rest of the ship.

Perfectionism is inherently tied to incoherence of thought, because a thought that is perfect in design leads to a perfect resulting action, and "perfectionism" refers to someone that is not taking perfect actions. A perfectionist is often making reactive changes or additions to address specific criticisms, without demonstrating performance at developing or finishing the project as a whole.

Digital technologies are flypaper for perfectionists because they enable a lack of commitment: everything is one undo or abstraction layer away.

I agree with what you're saying, but can't resist this little niggle...

> it's easier and more fun to trim the sails than build the rest of the ship.

That depends on the personality of the dev. Some devs consider the main body of the ship to be the easier and more fun thing. (I suspect that how fun a task is is correlated with how easy it feels to do).

It's not perfectionism that prevents people from reaching what's, by reasonable standards, a finish line. It's a failure to prioritize.

It's perfectionism that prevents people from shipping what's by reasonable standards already past the finish line, because they keep redoing and polishing "good enough" things, ad infinitum.

Perfectionism can be a good thing producing exceptional quality results, provided you've prioritized appropriately and are playing "perfectionist" iterating in diminishing returns land.

With or without perfectionism, if you can't prioritize correctly, you'll likely fail to finish.

Perfectionism causes people to over-finish and endlessly defer shipping.

I think we have different understandings of perfectionism. I don’t think perfectionism means you do something perfectly. Most of the time I think it’s not being able to trade good enough for best. Often this leads to unfinished work. Perfectionism by no means only comes into play after you have something shippable - you’d likely never get that far.

Development of anything substantial is an incremental process where parts must exist in an unfinished imperfect state for a time. Managing those priorities and letting parts exist as scaffolding and/or barely working stand-ins is a core competency of our field. e.g. You're not a perfectionist when you used expensive artist-produced "perfect" stand-in art instead of programmer art, you're just incompetent and wasting resources on stuff that won't likely make it into the shipped product.

I've seen many "perfectionists" hide behind this moniker when infact they're just incompetent when it comes to prioritizing what to do, how much to do it, and in what order.

You're not a perfectionist when you spent all your time making a "perfect" ECS at the expense of actually completing a playable game, when the latter was your actual goal. You're just a failure/incompetent. But "perfectionist" certainly sounds better for the ego.

> Development of anything substantial is an incremental process where parts must exist in an unfinished imperfect state for a time.

Yes, of course. That's why not being able to leave something messy/unfinished/bad is crippling.

> I've seen many "perfectionists" hide behind this moniker when infact they're just incompetent when it comes to prioritizing what to do, how much to do it, and in what order.

As you've identified, this thing they're calling perfectionism isn't an asset. I get the sense that you think being a perfectionist is supposed to be a good thing. It's not. It's a defect.

Replying to myself as it's too late to edit.

A more succinct explanation came to mind while just doing some yard work:

We've all heard and understood the wisdom of "premature optimization is the root of all evil", right?

What's being conflated here as perfectionism is a variant of premature optimization.

Perhaps we need an idiom like "Premature polishing is the root of all unfinished games".

I have similar issues, making own game engine -> making own rendering engine -> making own scripting language -> making own OS, my desire for custom tool has grown to be a sickness, haven't actually written 1 line of gameplay code.

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.

We often revolve around the result, not the process of getting to the result. That's why many don't care.

> They didn't like early Minecraft, they only like Minecraft now, after 10+ years of development gave tons of interlocking features and mechanics.

i think you are dead wrong. there is a lot of people just using the core of the game (previous the first alpha) to build stuff and that is just fine for them. past alpha (the survival mode) up to today i do not think it changed dramatically beyond some mobs and new stuff to find… the gameplay is still the same: collect -> craft [while surviving]

Some people, yeah. But a lot of people only enjoy the game because of complex systems that were added later: redstone, slimeblock machines, building complex farms, gear progression via material and enchantment upgrades, exploring an infinite world, etc. You can go on Youtube and see people who only play those parts of the game. I think it's fair to say that they wouldn't have enjoyed, say, Indev, before those features were added. And Indev, before the infinite world, was already the culmination of 6 months of work on the game! That's pushing the definition of "small game" already, and a lot of people would still treat it as "a cool toy, but not a full game" (I played it back then and remember people talking about it as such).

redstones were introduced at the alpha version of the game. complex enough to people build small computers with it back in the days. as mob and food farms, with lots of ways to automate it with water buckets etc. enchantments are just grind. the 2 main weapons of the game, a sword and a bow were introduced at alpha stage too… and the infinite world is also an alpha thing.

sure nowadays you can build a lot of complex stuff. but i do not think Minecraft went through a metanoia. i remember tweaking with more complex systems of villagers with mods back in the alpha/beta days than when they were officially released…

maybe now Minecraft is ‘more popular’ as every kid that has access to a computer with internet probably will hear about it and play. but maybe this popularity is more about ‘we do not have much child friendly games’ than any other phenomena. + the masterpiece of gameplay which it has! after you learn how to open the inventory, hold the L.mouse to collect resources and R.mouse to place blocks… life just gets brighter *-*

You can't just toil away blindly until suddenly a complex game pops out. You need to start with the small game and add layers.

Yeah, exactly, but to enjoy the small game at that point, I think you need to have an appreciation for small games. I guess it's possible to enjoy a small game as only the core of an imagined larger game, but... it's not how I think about game development, at least.

I appreciate your advice, but from a general viewpoint, just adding layers doesn't necessarily lead to interesting complexity.

StarCraft Broodwar is an interestingly complex strategy game, not because it has a lot of layers, or even lots of things at all, but because it has a simple system of orthogonal, powerful features. It had less features and units than many of its competitors (RTS was a big genre at the time), but it found ingenuity in simplicity, minimalism. Every piece of the puzzle was to some degree relevant throughout the history of the game.

I think you are right in a general sense, but "layers" can be a misleading term here. You rather want to increase complexity and beauty by enabling manners of composition.

Another game that illustrates this is The Witness, which is probably one of the most praised puzzle games and again, is beautifully simple. In terms of layers it has pretty much exactly three: The panel puzzles, the environmental puzzles and then the visual secrets that you only see by looking at things in a certain way. But in terms of actual game mechanics there are very few things. The complexity then emerges by mere combination.

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

The other outcome of this attitude of "make small games" is everyone just makes platformers.

Don't get me wrong, a platformer is a good small game project to start with, the game can be made with a level or two in a weekend using modern tools.

But even back on the NES we had way more than just platformers.

Sure, a beat-em-up is a bit more technically challenging than a platformer but I think cloning a Turtles game from the NES era is probably a fairly reasonable "small game" too.

Or cloning an RPG, or something like Fire Emblem, or Zelda.

It's weird how everyone wants to make a metroidvania but not many Zelda-likes are out there.

> The other outcome of this attitude of "make small games" is everyone just makes platformers.

I don't think so. Remember the heyday of Flash games, Kongregate (before it was spammed by MMO clones or whatnot)? Many short & sweet games that weren't platformers. Some were puzzle-solving games, some were adventure games, some were escape-the-room, some were shooters, and yes, some were platformers.

I have the fondest memories from that era. I still remember the short and thoughtful "The Majesty of Colors".

That's true, a lot of simple physics games like launching turtles and visual novel style games.

That era was definitely defined by enthusiast creators instead of the modern indie-studio-ification of even the simplest games.

Right, lots a simple physics games, I forgot about that. Launch the turtle, destroy the castle, etc. Also some relatively interesting wargames. And some interesting experimentation.

It was a golden age of enthusiast creators indeed. Browsing random games was very interesting (of course, lots of garbage, but Sturgeon's Law applies).

Is itch.io sort of like that nowadays?

absolutely nothing has replaced Macromedia Flash. The security problems seem quaint these days (to solve). Nothing since Flash has offered the creative or the technical a comprehensive suite for both proficiencies while having an extremely low barrier to entry (barring the cost of the Macromedia IDE)

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

Sounds interesting! Do you have screenshots of what the TUI looks like anywhere?

at the top of the readme in the link there's an asciinema screencast of the gameplay

edit: https://asciinema.org/a/Iu5Vu6S2j9IAPSenvH8ZU3OX2

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.

I guess the great game developers/designers are those who can convert their imagined fantasy fun into shareable real fun through games. Not easy at all.

I imagine they just imagine fantasy fun in a more realistic way than other people. So they can iterate on it faster and reach the real thing.

At least, this is the usual theme on people that are good on anything.

This really goes for any creative endeavour -- try writing a readable novel, or create a listenable track. Creating things other people actually want is HARD.

My experience has been quite the opposite: after a while working on a game I think "is this any fun?", and turns out people likes them (even if sometimes I don't really get it).

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.

ACtually this was the link I was remembering, ignore the previous one

https://a327ex.com/posts/lessons_second_game

The SNKRX guy is a champ. Great posts, great game, opensourced the code. Real class act and top tier game designer.

I started building something from his code - https://github.com/sdwr/underlod

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

A lot of this is more or less "how to develop critical taste and apply it thoughtfully" which is no small thing and not easy to write about well for any medium.

It's extra relevant in gaming too I think. Big games are very very expensive to make, and so are conservatively modeled on what works in other mediums like movies, tv, novels. Small games are where the real exploration of the dynamics and limits of the medium happens, but is held back because gamers overall have underdeveloped taste.

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 actually think making a small game good is much harder.

"I apologize for such a long letter - I didn't have time to write a short one."

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.

Can you remember any examples of the games?

One that he iterated a lot on was a titled we called "Alan Turing and the Spiders from Mars".

It was a multiplayer game (most of his games were, because the AI is free when you can just give another player a joystick). It was a simple 2D top-down sprite-based animation with:

- A ton of robots on the screen, milling around and doing stuff.

- Up to three players controlling their own robot (with the rest being computer controlled).

- A "finder" player who controlled a cursor and got a limited number of guesses as to which robots were controlled by real people.

- The players could win by fulfilling some simple missions ("pick up the blue blocks / visit each corner of the screen"), the finder could win by identifying the players without running out of guesses.

Reminds me of a certain popular modern online game . . .

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/

wow it's been a long time since I've seen a game that seems to go so far out of its way to make itself inaccessible to users. I do get that not everyone feels like putting the work in on this stuff, but just personally, as someone who's deep in UX/UI land... man oh man oh man. like you need a level of computer fluency to even install the game, nevermind actually playing it.

props to the creator for how complicated it is, but man, just contemplating the time I would lose trying to dive into it is horrifying for me.

Notch made many small games before he did Minecraft.

Minecraft itself is a small game. It has very little depth nor complexity.

When you talk about the game as it was originally, you were right. But that was more than a decade ago.

That was when it blew up.

You're right, it was already a good game when it was rather simple.

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.

> The mechanical complexity? the graphical complexity? The volume of content?

Yes, yes and yes.

> The size on disk?

Indirectly, sometimes. Also, how polished a game is.

At the end of the day, people severely underestimate the last 10% -- which take about 3-30 times as long as the first 90% -- of creating a game. Creating a bare minimum Binding of Isaac clone can be done in 48 hours. Creating a full sized Binding of Isaac competitor will take at least a year of full time work of someone who knows what they're doing.

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!

Reply on news.ycombinator.com