Универсальные системы в целом учат довольно многому в геймдизайне. Как собирать игры, в которые будет потом интересно играть. Но что самое важно, собирать именно ваши игры. Игры, которые вы сами захотите играть. И чем дольше и больше играешь, тем лучше понимаешь, что и какой группе дать в рамках правил и динамик, чтобы им было хорошо. При этом можешь составить примерный набор правил, который им понравится и подойдёт. Опыт в таком деле даст собрать вам три разных игры для трёх разных групп в одном даже сеттинге на универсальной системе, в которой вы достаточно уверенно себя чувствуете, и получить хорошие игры. Да что уж там, одной и той же группе в рамках разных выбранных правил и действий игроков будет интересно сыграть в одной системе GURPS. Словно бы разные взгляды на одно и то же. Ответ на вопрос, как поженить системное мышление и настольные ролевые игры пришёл не так давно из программирования. Объективно-ориентированный анализ. За сложным названием скрывается очень просто процесс формирования системы на определённом уровне. Разумеется нет нужды писать текст, но обычно в программировании просят текст бизнес решения своими словами, где описывается процесс использования программы пользователем. Обычным русским языком. Без сложностей. Далее программист пробегается по тексту, порой даже используя специальную программу, которая подчёркивает существительные и глаголы. Так разработчик выделяет кандидатов на первые классы (самые частые и важные существительные), а методы -- глаголы. В итоге получает первое приближение системы без подробностей того, как работает система как таковая. Далее придумывает архитектуру и структуру классов, чтобы сформировать систему. Проводят связи между классами и зависимости между ними. Что-то модифицирует, чтобы проще и эффективнее было реализовать в рамках его выбранного языка. Если ему всё нравится, то наступает момент реализации конкретных методов, обмена информацией, переменных, где они лежат и куда проходят. То есть формируется целый набор решений того, как, к примеру, в бизнес плане приложения для подбора кофе выбор сорта кофе встретился 20 раз, а чашка 12. Поэтому можно сделать *Чашку* отдельным классом, добавить в неё структуру данных *Наполнение*. А *Наполнение* не сортированным списком конкретных *Ингредиентов*. А как это относится к НРИ? Да, собранные за вас игры часто уже обладают архитектурой и систему оттачивают. Именно поэтому полезно порой обратиться к играм, где авторы не знали, во что конкретное вы будете играть, но дали вам инструменты для, собственно, сборки самостоятельного продукта для стола: Fuzion, FUDGE, GURPS, True20, Past/Future/Presend d20, Alternity, Fate и многие другие модульные игры. И сначала надо понять и разобраться, а как ты видишь игру, что она из себя представляет -- вижен. Что вы будете конкретного делать за игровым столом. Как и каким образом планируете решать поставленные проблемы. Какие для этого будут инструменты. И это буквально объективно-ориентированный анализ. Выделение сущностей из вашей игры: существительные -- в акторы, глаголы -- в методы и правила. Не забудьте провести между ними связи, чаще всего в готовых универсальных играх они уже будут. И voi a la. У вас имеется каркас игрового процесса. Если вам интересна эта тема, откликайтесь как-нибудь комментариями или лайками. Дальше я расскажу про важность составления Use Cases проверок собранных вами игровых правил, и что они должны давать (динамики). Предыдущую тему про хранение данных и записи не ставил на паузу, я кое-что хочу попробовать конкретно на материалах ПЧК, чтобы потом показать вам.