Every good rule is created for a reason, either to produce a result or solve a problem.
I consider it the designer’s responsibility to make both parts of that equation as understandable as possible, not just half of it.
I consider it the table’s responsibility to decide if those results or solutions are desirable for their game.
It is with that dynamic that the table can chose games wisely, and change them in accordance to well understood needs.
Rob,
You may need to expand on this because at the moment its not clear what your core message is (at least to me). Of course it’s entirely possible I’m just being particularly dense.
The content appears touches on both the evaluation of a hack, and the evaluation of whether a hack is needed in the first place.
I’m not too sure what you mean by both sides of the equation. Are you saying that a hack should always be presented as both a combination of rules/mechanics and a description of the problem it is intended to solve? This would seem to make a lot of sense because without knowledge of what it is supposed to solve you cannot evaluate either whether it is needed or if it is working as intended.
I would have thought the correct order to introduce a hack was:
1. Agree at the table if there is an issue, and if there is a need for a change
– Check to see if the issue you are encountering is due to a misunderstanding of the official rules or if there are any official optional rules which address your issue
2. Brainstorm ways to fix the perceived issue
3. Someone take responsibility for turning those discussions into an actual written rule
4. Playtest to see:
– Does it fix the issue / produce the expected change?
– Does fixing the issue actually improve gameplay?
– Does it introduce any unwanted consequences?
– Does it work with the table’s play style?
5. Document agreed changes.
You are correct – a hack should be made with the understanding of the rule AND of the desired effect. A lot of times when a hack goes off the rails its because there’s been a bit too much thought about the rule and too little about the result and its meaning.
That said, I would absolutely not suggest that there is one proper procedure for going about it. The model you suggest is absolutely a good one, but different tables will approach it in different ways, from the democratic to the dictatorial. Those approaches may or may not have their own problems, but those are tangential to the hack itself.
To elaborate a bit on that, it is entirely possible to have hacks stem primarily from the GM. This might be because the GM is a dictatorial jerk, or it might be because his players don’t want to worry about mechanical stuff, so he takes their input implicitly, or there may be some other dynamic. That procedural difference is much smaller than the difference of one of them being a jerk.