Trekiros
commented
1 year ago My general approach is that this project's goal is to maximize how useful it is to the humans using it. The simulation's accuracy is one way we bring value to the user, but how easy the UI is to use is another way we bring value to them. And those two elements tend to conflict. That means we have to strike a balance between a simulation that is complex enough to be significantly more accurate than the ones in the Dungeon Master's Guide, and a UI that is simple enough and quick enough to use, that a Game Master would actually bother using this tool.
If we can improve the simulation's result without making the UI too tedious to use, then we should do that, always. And if we can make the UI simpler to use without affecting the simulation's results, we should do that, always. But every time someone suggests an improvement to one at the cost of the other, I am very careful about weighing the pros and cons.
Currently Casting heals, debuffs or buffs oftentimes depends on the current situation on the field. For that, I can set a trigger to cast Cure Wounds if "an ally has less than half their hit point maximum", or "there is an ally at 0 HP". I can then cast these on targets like "ally with least HP". These do not have to be the same. A friendly wizard at full HP might have less HP than the bloodied Barbarian in dire need of healing.
Proposal Broaden the available logic operators available for the user. A list of possible operators and in-depth thought process will be discussed in the comment section / attached as file. Make triggering effects and creatures available as target of an effect. This allows us to counterspell (ending the effect that triggered the action), opportunity attacks (attacking the target that moved; requires space impl.), or heal the correct target.
Alternatives For the above example, a check for relative HP is enough, but I have compiled a list of examples at the bottom, showcasing the need for additional logic.
Additional thoughts Depth I am of the opinion that good code is always as abstract and generic as possible to allow future developements to be made easily and, most important, easy to understand and implement. However, the trade-off is always the complexity of the project in ealry stages. Please comment your toughts on how narrow or wide a possible system should be. We could do everything ranging from a Node.js- or scratch- like structure allowing the user to set up everything he needs in a lot of time, to a library based approach, where the user may only specify conditions and one of a couple strategies, while the effects are implemented on the backend.
Attachments List of possible triggers, logic operators, structural proposals, a word on how refined it may be. https://docs.google.com/document/d/1_GccRf5u4DMAUD3mwbNUdySBGyzBx5LqSWAw0VRKu4g/edit?usp=sharing
Please feel free to discuss this proposal.