I’m interested in the policy position which defines boundaries and expectations for competitive play (as distinct from Terms of Service, which apply to all players).
That is, for the purposes of competitive play:
what are the role and responsibilities of the players vs governing authority (EHG)
are EHG employees or other special groups, such as Community Testers, permitted to engage in competitive play
does EHG categorise and track bugs and exploits separately and are there relevant subcategories
are remedial or punitive actions bracketed and do they apply to use of of bugs and exploits equally
are and when would actions be applied retroactively
how are identified problematic bugs or exploits going to be communicated to players
will there be a process for players to report identified issues (not other players) separate to the existing processes
will there be a process for challenging decisions
This isn’t an exhaustive list, but I’m sure it gives you a better idea where I’m coming from.
For what it is worth, I’m explicitly not talking about balance issues.
PPS. The policy position may well be “refer to ToS”. Whether I agree that is a sensible position or not is a completely separate issue
Absolutely agree. Parallel development is vital to a project success when large teams are involved. And as I said, this feature will be a welcome addition to the game for the player base that enjoys them.
My issue is that parallel development also means that there are teams that can be “flexed” off their initial goals and reassigned to priority tasks. And ladders should not be a priority task given the state of the game. If the only addition to the conversation is on the lines of “…why ladders?” then its beyond obvious that the feature doesn’t really apply to you and it’s fine to ignore/pass it by. But honest and open critique of a games direction/focus/methodology shouldn’t be ignored. The idea of blind fan-boy/girl-ing will get everyone nowhere with the exact same amount of added unneeded stress as blind complaints.
The replies concerning the functionality and concerns about the addition are great. Those should be considered in future iterations of the feature down the road. But ignoring concerns and lambasting the feature based on flawed presumptions and poor personal reception should be ignored.
