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.

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.

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

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

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.

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.

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.

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.

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

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

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.

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.

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

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.

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/

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

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.

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.

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

You forgot:

- Looking for the perfect domain name