Вариант использования Надеюсь, вы не забыли предыдущие статьи по теме создания системы. Эти статьи -- упрощённый вид создания систем. Упрощённый подход. Куда отсюда можно расти. Образ и виды зависимостей между системами. Образ ассоциаций (связей; глаголов) между выбранными сущностями (существительными) и их объектами (конкретными реализациями выбранных вами абстракций). Можно пойти дальше и углубиться в изучение крайне глубокого уровня -- влияние проверок на действия персонаж, принципы вокруг проверок, события и моменты, когда механики срабатывают. Также попытаться докопаться до конкретных реализаций конкретных механик. Для этого существует масса книг, в том числе настольные механики и блоки для строительства игр: - Building Blocks of Tabletop Game Design, Goeffrey Engelstein, Isaac Shalev. Второе издание есть; - Design Patterns of Successful Role-Playing Games, от 2009 года (https://legendaryquest.netfirms.com/books/RPG_Design_Patterns_9_13_09.pdf). Но как добиваться определённого настроения, стиля и тона в игре? Как это должно происходить? Каким образом? Часто разработчики приложений прибегают к так называемым "use case"-ам или вариантам использования игровых сущностей в вашей игре. Причём именно так, как вы задумали с самого начала. То есть из всех механик собрать сценарий, где все ваши сущности встречаются и проверить тестом, а добиваетесь ли вы того, чего хотите. Да, вот так просто. То есть создать персонажа по правилам вашей игры. Добавить все необходимые сущности в ваш игровой процесс. Зафиксировать это в тексте правил игры: что за чем идёт. Иными словами показать, какой вы предполагаете сценарий использования правил вашей игры для игрока. А потом пробежать по нему самостоятельно несколько раз. Получаете ли вы на выходе то, что ожидали? Частые попадания? Промахи? Страшные увечья, но редкие попадания? Борьбу за инициативу в бою, чтобы нанести удар первым, потому что удар -- смерть. Как этот вариант использования ваших правил в совокупности работает? Складывается ли он в ту историю за игровым столом, которую вы ожидали? Накидывайте сценарии на всё. Что же, у вас есть: - базовая проверка; - модификаторы в бою; - правила по складыванию модификаторов; - и другие правила. Собираем вариант использования атаки, вводим туда разные возможные и реалистичные для вашей игры данные, чтобы посмотреть, что будет происходить. 1. Выбираем цель атаки; 2. Оцениваем успешность атаки; 3. Выбираем наиболее выгодную цель: - Что такое выгодная цель в рамках вашей системы? - Какая тактика поведения от игрока здесь ожидается? - Какой выбор ставит тут игровые правила? 4. Считаем подходящие модификаторы: - Насколько долго? - Подходит ли хрон счёта? - Сильно ли сложно считать? Какие операции надо делать? Можно ли упростить не потеряв ничего в математике? 5. Делаем проверку на атаку; - Что считается успехом? - Что такое провал? - Ожидаемая ли чистота успеха и провала? Отвечает ли это изначальной задумке? Закидываем в этот вариант использования разные значения для атаки, для ситуаций с противниками и смотрим на данные. Можно, разумеется, пытаться делать это не руками. Важно вытащить и пройтись по последовательности куска действий вашей игры. Да, не всей игры, а можно проверить только кусочек. Так вы поймёте, где правила могут синергировать, где рваться, где ломаться и тонко донастроить другие сущности. Оппонентов поднять по характеристикам. Атаку сделать не такой частой. Модификаторы уменьшить и упростить подсчёт, так как слишком много времени считается. Всё это можно ощутить только, если прогонять это всё через тесты и взаимодействие с другими правилами игры. Да, пускай не всей системой сразу, но частью. В идеальном случае играть в собственную игру постоянно, чтобы заодно проверить и частоту использования конкретных правил. Может быть какие-то из них вам не нужны.