• 0 Posts
  • 18 Comments
Joined 1 year ago
cake
Cake day: July 11th, 2023

help-circle

  • I think we don’t actually disagree and I was just not precise enough in my original post.

    What I described above applies to abilities that are relevant in combat and any other type of encounter that the respective system mechanically treats as a conflict similar to combat. That absolutely does not mean other abilities should not exist, just that they should not be practically usable during an ongoing combat-like short term conflict.

    Also: Abilities that are useful in short term combat-like conflicts and abilities that are not should not compete for mechanical resources of any kind, that is never fun.






  • Most abilities should be either “per round/turn” or “per encounter”.

    Abilities that are too powerful for that should either not exist or require significant preparation (enough for the opposition to have a chance to discover and interrupt it).

    Abilities that fall in the second category should automatically come with a less powerful variant in the first category.

    Maybe as a middle ground some player abilities could use the “roll for recharge” mechanic from powerful monster abilities.




  • I agree with the general sentiment that there are limits to what should be possible even with the rule of cool.

    In this specific case we don’t even need to go into the territory of undefined stuff that the DM decides on the fly, the rules as written already explicitly say “You create up to 10 gallons of clean water within range in an open container.”







  • About comments:

    Please please please, do not always write comments. Try to write code that does not need comments whenever possible. Proper variable, class and method names go a long way. If you think a block of code needs a comment, turn it into a method and give it a proper name instead.

    Comments should be a last resort for cases where making the code self explanatory is not possible, and those should be rare.

    About optimization:

    Optimal code is code that fulfills it’s purpose without observable issues.

    If you try to make something faster without any prior complaints or measurements indicating that it being slow is an actual issue, you are not optimizing, you are just engaging in mental masturbation.