You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Multiple servers hosting thousands of players rely on upstream to provide a fast, safe, and accurate base on which to build and contribute back. As such, incoming code must demonstrate these traits. We enforce a base level of automated checking using CI, but this can't extend to actual game content.
There are two situations we're trying to avoid:
Someone implements a feature but it's incomplete. It seems complete and/or it isn't popular, so it is never caught, addressed, and finished. Unless there's a complete and exhaustive audit this discrepancy will never be caught.
Someone implements a feature but it's incomplete. It is popular and it sticks out by providing a bad experience, or introduces a "loot pinata" or similar exploit. This often results in maintainers having to rush to disable it or to swarm and fix it after the original author has disappeared.
The solution we've come up with here is to mark incomplete content (but still retail-accurate for what has been submitted) as experimental in some way, giving operators the choice of whether or not they want to use it. We have been considering if it's then worth it to disable loot and gil drops from mobs in experimental content, how we can make this a consistent system across different content types, and how to signal to players that the content they're engaging in is experimental and as such might be unbeatable, broken, provide no challenge, or not drop any loot.
The actual implementation of this system is ongoing.
I'm generally quite taken with incomplete work being switched off and hidden behind settings. See: Chocobo Raising, Monstrosity, Synergy, AMAN Trove, etc.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Introduction
Multiple servers hosting thousands of players rely on upstream to provide a fast, safe, and accurate base on which to build and contribute back. As such, incoming code must demonstrate these traits. We enforce a base level of automated checking using CI, but this can't extend to actual game content.
There are two situations we're trying to avoid:
The solution we've come up with here is to mark incomplete content (but still retail-accurate for what has been submitted) as
experimental
in some way, giving operators the choice of whether or not they want to use it. We have been considering if it's then worth it to disable loot and gil drops from mobs in experimental content, how we can make this a consistent system across different content types, and how to signal to players that the content they're engaging in is experimental and as such might be unbeatable, broken, provide no challenge, or not drop any loot.The actual implementation of this system is ongoing.
PRs:
experimental
flag #6304Since this is quite a contested topic I've locked the issue right away. If you want to talk about it or offer up ideas please open a discussion.
The text was updated successfully, but these errors were encountered: