Don’t keep thinking of solutions!

(Originally penned Dec 2016)

There's many solutions to every problem, and this is especially true of programming.
One of the biggest things that used to slow me down (still does, actually) when I work on games was the idea that I had to consider every solution to every problem I encountered. This is primarily an issue that will come up towards the beginning of a project when you're thinking about your engine loop, or how you're going to structure your database, or what classes are going to inherit from which other classes, and so on.
I'm not saying you shouldn't plan ahead for this stuff, but that first, gut instinct, "this will work" solution you had in your head? It will probably do everything you need it to, and with some refining along the way, it will probably also handle all the weird case scenarios you run into later on.

Planning ahead is still key. Map out your solution on paper and try to come up with things that might break it. Make sure it'll hold water before you try to pour the game in. But don't keep thinking of solutions once you're done. You do this probably WAY WAY more than you think you do.

Would it be more performance-friendly to rewrite the whole thing using C++ 11's std::whatever the hell structure you've never really worked with before but people on the internet keep talking about it?
Probably a little.
Would it be more dynamic to split this one function into a few more modular functions that specific classes are granted access to?
Like, maybe.

There are always a hundred solutions you can come up with, which each have their own pros and cons lists. The trick is though that they're all solutions, and you're only going to use one. You're never going to be the best programmer in the world and neither am I. No matter how good your solution is, there's always going to be someone who could theoretically look and say "oh my god, i can't believe you did blah this way, don't you realise it would have been way better to do blah that way for blah reason?". That person could be you, looking at your own source code 10 years down the line. But not if you spend that next 10 years writing and rewriting and planning and replanning the same game back-end because you keep thinking of other solutions that would, on the front-end, do more or less the exact same thing as the first idea you had.

Previous
Previous

Game length, and, I guess, price?