Originally Posted August 2nd 2017
It's a common scenario: a promising project grows, but then devolves into a quagmire of bugs seemingly overnight. Development progress slows, and supporters get fed up with late releases and declining content.
I want to avoid that scenario!
I'm not a professional programmer, and I'd never claim to be some kind of expert, authority, or even someone particularly good at coding. I have written plenty of code though, and I do work in IT, so I'm not completely clueless. I also happen to have a pretty good idea of what's going on with that scenario. It's a simple truth that coding practices that are workable for small projects end up being a nightmare for larger ones.
When a program is small, it's easier to remember details and variables without comments, or you can quickly take a look at another portion of the program to refresh your memory. You don't have to pay special attention to error checking, reporting, or validation. This is because the program is small enough to test fairly thoroughly yourself, and the code brief enough that you can read through it quickly to find a problem. It's not ideal, but bad coding habits won't kill a small and simple project.
People make mistakes, and I most certainly do, and that contributes to creating bugs. As the complexity and size of the code increases, it becomes easier to make mistakes and harder to find where you made them. Bad programming habits make the problem exponentially worse. I'm not saying that other game developers are bad or lazy here; often times good habits were never necessary for them before, and it can be hard to anticipate how tiny problems will snowball.
To avoid the bug quagmire, I've already been implementing several measures to prevent it, and there hasn't even been a public release yet.
Designing the structure of how things work before I start coding it
Using regular data validation methods, and making their use consistent
Avoiding hard-coding by using functions and variables to determine behavior, or using hard-coding only in universal function code (that isn't repeated, so can be easily changed).
Implementing a debug information screen so that users can provide the game state along with a bug report.
Adding error reporting code to data validation. (Info that includes the location that sent bad data!)
And plenty of other minor measures.
It's true that doing all this takes longer. It seems so much easier to just write some code and get some working content... but that comes back to haunt you in the long run. Ever seen a developer seemingly working forever on a simple addition of a new mechanic, expanding a mechanic to be less simplistic, or even just adding some new content with existing mechanics? That is NOT something that I want to see happen to Accidental Woman.
