I've been working on a falling-block puzzle game for a few years now, and the hardest part of it is actually the menus. You'd think the actual game itself would be the big challenge, but no. I don't want just any old menu system: I want the perfect interface; something for the first-time user just much as it was for grizzled 20-year tournament-grinding veteran. 1 to 4 players need to be able to play however they individually want, with as few necessary inputs as possible.

For the most part, I actually did it! When it came time to start tidying up and getting the final bits of functionality, I started to freeze. Something just wasn't adding up, and it was keeping me from making progress. How will the program determines which user is which between sessions? The Redot engine doesn't expose any truly unique device IDs, so I can't apply any saved configurations automatically. If I want to allow users to save quick-deploy pre-saved configurations, how many more components am I going to need to build? Being able to handle input from gamepads, a keyboard, and a mouse—all the while allowing other players to continue their own toggling and configuring—requires a virtual keyboard and a data-navigation system at least: that's when I called it on development entirely.

Why, why, why couldn't I make a system that's lightning quick and endlessly robust?

Can’t Go Anywhere From Everywhere

Every game of old has a serious set of starting parameters. The number of controllers, what kind of controllers, and how they are ordered are all built into a game console. PC games presume there's only the keyboard and mouse being used, or have a very strict rules and presumptions about how gamepads will be used. In both environments, user profiles are saved externally and injected into the game at launch. The fastest application flows cut off options before the first process is even executed.

What I was trying to do was account for each and every conceivable niche corner case and contort the program around them, instead of funneling users from those corners into a single procedure. Imagine if analysis paralysis was explicitly stated as a step in development: that's what I did. By trying to everything at once, I ended up with nothing at the end.

It's clear to me now that I have to decide a few things outright for the game to get even close to my original (vague, blurry, amorphous) vision. I'd already been building up that understanding: mouse input isn't configurable at all, and can be used to override and reset any settings applied by a gamepad or keyboard. Turns out that I need to go a little further!

Options

I can do a few things from here:

1. Dedicate the game to a platform with its own input-manager
2. Create a system for user-profiles that must first be navigated with universal default settings
3. Employ an add-on that exposed unique device IDs to Redot, and save configurations according to those IDs

All 3 of those options are far more work than I want to commit to. The easiest thing to do would require slightly more work from a user, but less work from me: create a "tournament mode" where users are all given default controls initially and can easily reconfigure whatever they need to. This explicit mode would use all of the tools I've already built. I'd be 95% done with functional development as opposed to 40%. Any setting where players would be swapped out frequently and arbitrarily would rely on tournament mode. Without that very distinct environment to factor in, more focused screens can be comfortably developed.

Casual play can lean back into a broader net of assumptions and be perfectly happy. A single anonymous profile saved for start-up can be manipulated freely. A slightly bulkier flow built around external user IDs could maybe be applied? Ah; there's not enough pressure in what will likely be the most common use-case to worry about what could be done as I'm writing the article talking about it!

Conclusion

• Set explicit parameters for an endeavor, when you start.
• Don't do too much all at the same time.
• Be willing to section off complexities into their own modules.

A game that frankly could have been online and playable in eight months is somewhere into the 2-3 year mark, all because I wasn't able to keep myself on a very clear and specific track. I turned the easy part of making a game that most people just sleepwalk their way through into a massive mountain of a hurdle by not saying "no" to any theoretical complication that I could fearfully dream up.

Keep your work simple and direct, and you'll be able to make it quickly. A wrong path can be corrected when the path itself is clearly marked.

An imperfect something will always be better than a heap of perfect nothing.