Именно поэтому хорошо выбирать подходящую проверку под принципы, стиль, тон и идею вашей игры. Ну хорошо, пускай дорабатывать существующую проверку под принципы. Не так страшно. Важно так, чтобы каждый элемент системы давал общую синергию, которую вы как дизайнер ищите. И важно не обмануться или не обмануть как это делает в одном ужасном движке. Автор движка говорил, что сложность для проверок вообще не нужна (почему он не отказался от проверок тогда в принципе, но не суть). И при этом назначил классические целевые сложности проверок... Которые казалось бы сложностью не являются с его слов, но являются с точки зрения математики и логики. И это вело к казусам, когда "нарративная" по заверениям система давала одну и ту же сложность для убеждения стражника или друга на пороге ужасного судьбоносного выбора. То есть система полностью игнорировала остроту ставки и риска из-за этого решения. А это вело к тому, что особого смысла не было в помощи, так как это точно такой же риск со статичными сложностями как и для преодоления. И обесценке итоговых выборов. Поэтому дальнейшим шагом важно выходить на Use Cases. То есть понимание того, как вообще в принципе это всё будет работать. И проверять. А будет ли искомые сценарии давать то, что было обещано. Но никто не запрещает вам придумывать прикольные способы кидать. Просто порой было бы круто, чтобы за ними лежали классные архитектурные решения. И может быть становилось ясно, а зачем это всё. И при этом работало.