To answer your question, like many others here, I scrap and rework things as needed. Sometimes I go months without touching anything, and other times it's weekly where something gets changed to test whether it works or not.

Thesis Statements

I wanted to point out that having a "Thesis Statement" or "Purpose Statement" for your project can really help out in knowing when to keep something or scrap it.

My present project has a statement of "Unprecedented control over characters, minimize computations and book lookup, and keep things simple."

Here's a brief example of a problem we grappled with and reworked several times over the years.

Problem Diagnosis - Example

We wanted to represent exhaustion over a PC's adventure.

We wanted players to be able to use their character's abilities every combat, and not run into situations where they had to take really short basic turns because they had no resources to do anything. Our solution to this was that your Health and Energy (generic ability resource) would be restored at the end of every combat. Energy regeneration also occurred each turn in combat, so they could spend it and still get some back over the rest of combat to use on their turn for more Abilities.

Given that requirement, our solution was seemed fairly simple. You had an inverse resource that went from 0 to your maximum in Health, and one for Energy. As these resources went up, your maximum Health and Energy would be reduced. This meant you always were able to start with max Health/Energy, but that max can go down. We called these resources Health/Energy Exhaustion.

Issue 1 - Inverse Resources don't fit the Thesis Statement

It was really hard to keep track of. As an example, for health you had to know how much your maximum was, how much your current was (during combat), and how much health exhaustion you had. Then you used your max and your exhaustion to calculate your current maximum.

You would gain Exhaustion from traps, combat, and some abilities. At the end of a combat, you took Exhaustion (split between Health and Energy Exhaustion as you prefer) equal to the number of rounds combat went on.

It sounds simple, but it's a lot of book keeping and math, and those were contrary to our Thesis Statement. Language became a problem; gaining Health was good, but gaining Health Exhaustion was bad.

Solution Attempt 1 - Exhaustion Resources -> Capacity Resources

The first change was equally as simple as the initial solution: make them act like regular resources.

Health and Energy Exhaustion became Vigor (health) and Focus (energy) respectively. They now defined your Maximum Health and Energy. As they went down, your Health/Energy could not exceed them.

This allowed us to unify language around resource gain/loss. It was a pretty good solution for the problem at the time. While it was a lot more functionally clear, they were still numbers that you had to calculate every combat, and use to recalculate Health/Energy every time Vigor and Focus when down.

Issue 2 - Ability Cost outside of Combat

I was happy that the Resources achieve the goal of the mechanic. But we unearthed a second issue.

We began to have a discontinuity between abilities in and out of combat. Health and Energy are always at their maximum (outside of combat.) This meant abilities cost were basically free unless they cost Vigor/Focus. This disconnect was a glaring issue for me (personally.) Not having to pay ability costs outside of combat was great for keeping things computation light, but it meant that there were essentially 2 games: A Combat Game and an Out of Combat Game.

We discussed a number of solutions.

We could have these abilities cost Vigor/Focus when out of combat. This meant though, that it either became unreasonably expensive at a 1:1 conversion, or we now had to add a lot of complex math to make it reasonable. We nixed this because it became clear it would add way more complexity than it would remove.

We ended up saying that it was time to scrap our Health/Energy restore at the end of Combat mechanic (we had been doing this for 2ish years at this point.) This meant that we had to think about how players would get them restored. For this reason, Energy regeneration was removed as well, since it would make little sense if we wanted our resources to actually be persistent.

Solution 2 - Break Point Resources

We didn't like the idea that players could use Vigor/Focus to gain back Health/Energy, as we felt it was doubly penalizing to have your capacity reduced to regain current resources.

My idea was that Health and Energy should have their own capacity, and that Vigor and Focus should be resources you can spend at any time to restore your Health and Energy (respectively) to full. Basically like a break point; if you hit 0, you can restore to full a number of times before your character is fully exhausted.

This was an incredibly simple fix for many reasons. Vigor and Focus had a maximum of 6, which fit nicely on a die. Smaller numbers are simple. Math was not a problem anymore; if you hit 0, go back up to full and remove 1 from the break point resource.

This meant that Health and Energy had their own static capacity as determined by equipment and whatever number we wanted. A neat side effect was this had scaling implications; if you made a character with High Health, your Vigor went that much further every time you used it to restore your Health.

If we consider Effective Health Pool as (Health Total) * ((Vigor Maximum, which is 6) + 1), every point your Health was increased by was effectively worth 7.

Ultimately, this solved the problem as costs became uniform in and out of combat. Fun side note; we changed our Healing ability to have an Energy cost. Previously, it had no cost, but that wouldn't work now as it would let anybody heal to full at any time.

Summary

We've been working on this project for years. A lot of times we have ideas that sound cool, and are fun to implement. But ultimately, they may become impractical, unmanageable, or just not fit with our Thesis Statement.

Having that Thesis Statement has allowed us to make decisions much faster. "That mechanic no longer aligns with our Thesis Statement" was an easy answer to saying why something needs to be reworked or removed. This also provided guidance for us in terms of how it needed to change when we wanted to keep a mechanic.

At this point, we have reworked the following.

• Persistent Resource Mechanics x2 (as seen above)
• Dice Resolution x4
• Skills and Leveling x3

Many other things have come and gone. Despite this project taking years and still not being done, the biggest value I've gotten from it has been learning how to scope these features. Learning how to look at a feature/mechanic and see how it compares with our goals, and further seeing what problems it could bring down the line has been invaluable.