Game Systems: Avoiding Post-Launch Design Pitfalls

When designing game systems, it is very important to ask yourself a question — how long will the feature exist after release? Why is it useful:
With time systems may tend to work worse, and there may be upcoming problems with scaling and iterating it.

This “sanity check” will make life much easier for you or for the people who would deal with the emerging problems in the end. 🛠

———————
🔖A little example from personal experience:
I once designed a dynamic difficulty system for PVE content and event campaigns. It was needed so that both new players and players with high-level content could play with challenge and fun, without the feeling of unfair difficulty.

To develop such a system, I relied a lot on checking on specific points of progression and content (all these – with weights) to understand how “high-end” a player is. Worked like a charm.

I thought back then:
“After two years after the release, it wouldn’t work as intended.”

Little did I know that the game would be successful and still grow during these two years. And that the person feature-owning this system will still be none other than me. 🤨

But at that moment I no longer had as much time as when I developed the feature. This ultimately became the most difficult challenge associated with this system.

———————
❓Is it worth developing such systems to be universal and flexible in order to avoid all risks in the future?

No. It may lead to over-investing in terms of resources and focus.

But it is worth checking each feature with this kind of question:
— “Will feature design create problems in the future, for example, a year, six months, or even a month after release?”

If not, everything is cool. Otherwise, it is better to change the design and deal with the most important stuff causing this. It will save a huge amount of team’s time in the future.