A significant amount of my time is not even spent coding, but doing admin and spreadsheets.
But I hear you. 30 mins probably isn't enough frustration to warrant something like that. What spreadsheets? Like systemic design in spreadsheets? Or you're doing accounting?
I've seen quite a few use an OO modeling approach. That's fallen out of favor for good reason.
Another approach is Entity Component Systems. I suggest googling for one of the better blog posts on that.
Another approach is to build the equivalent of a datalog engine.
An approach I favor is to have a stack per entity, and as you parse input events things get stacked up. Then a processing pass iterates across popping things off the stack. If you know how MTG rules work it's roughly the same idea.
None of these are a panacea, because you can have logical contradictions in your ruleset that are subtle and only emerge in very niche situations.
It's definitely very difficult problem. What you suggest is similar to what I termed the datalog style. If you've ever tried to debug a prolog or datalog program, you'll know that it all being in one file is a trivial concern compared to the emergent complexity and potential for you to have misstated your logic or included contradictions.
If you have a stack per entity, like MTG, how would you find a contradicting rule?
So the stack approach essentially doesn't, because it forces a linearization. You'd have to rewind back through and see why what the system did didn't match your expectation. But at least the order is comprehensible vs some of the other approaches.
But actually in this specific case like 99% of my elemental interaction code is in the same place just as you recommend!
In this specific case the problem was entirely that I added a new rule to make ice decay into wet when it was removed, but didn't add a check to see if ice had been applied in the first place before removing it. And of course, that was all in the elemental interactions file. 28 of the 30 minutes were spent in just puzzlement why the fire wasn't applying and checking a bunch of irrelevant dead ends before I thought to check "oh obviously it's probably the elemental interaction code, go check the elemental interaction file." 2 minutes were spent fixing the actual code.
For something like status effects, I was thinking about using a datalog engine, like jasonwatkinspdx mentioned in a sibling comment. That way, you can query it for applications of status effects, instead of hunting it down in code.
That said, I never heard any game dev talking about Datalog, and was wondering if there was a reason for that--whether it's obscurity, or if it's impractical for some reason.
So a bunch of design work happens in spreadsheets, yeah, that and long form google docs. Then a lot of business and admin stuff too (if you're an independent dev which means you're making games AND running a business). Whether that's accounting or projections or any number of other sundry things.
With the problem about status effects, how is this typically implemented? Do the rules for interactions exist within the game objects themselves, as if-then-else statements? If so, I can see why that would be error prone. Even if those rules exist in abstractions like "Burnable" and "Metallic", it's still hard to see the side effects of changing or adding a single rule.
Does anyone ever implement it in a single place, where you can query for the interactions between the different status effects? That way, all the rules are in one place, and being able to query for it, the results would tell you how it came to that conclusion. If not, how come?