Бреганов • Блог

Вариант использования Надеюсь, вы не забыли предыдущие статьи по теме создания системы. Эти статьи -- упрощённый вид создания систем. Упрощённый подход. Куда отсюда можно расти. Образ и виды зависимостей между системами. Образ ассоциаций (связей; глаголов) между выбранными сущностями (существительными) и их объектами (конкретными реализациями выбранных вами абстракций). Можно пойти дальше и углубиться в изучение крайне глубокого уровня -- влияние проверок на действия персонаж, принципы вокруг проверок, события и моменты, когда механики срабатывают. Также попытаться докопаться до конкретных реализаций конкретных механик. Для этого существует масса книг, в том числе настольные механики и блоки для строительства игр: - 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. Делаем проверку на атаку; - Что считается успехом? - Что такое провал? - Ожидаемая ли чистота успеха и провала? Отвечает ли это изначальной задумке? Закидываем в этот вариант использования разные значения для атаки, для ситуаций с противниками и смотрим на данные. Можно, разумеется, пытаться делать это не руками. Важно вытащить и пройтись по последовательности куска действий вашей игры. Да, не всей игры, а можно проверить только кусочек. Так вы поймёте, где правила могут синергировать, где рваться, где ломаться и тонко донастроить другие сущности. Оппонентов поднять по характеристикам. Атаку сделать не такой частой. Модификаторы уменьшить и упростить подсчёт, так как слишком много времени считается. Всё это можно ощутить только, если прогонять это всё через тесты и взаимодействие с другими правилами игры. Да, пускай не всей системой сразу, но частью. В идеальном случае играть в собственную игру постоянно, чтобы заодно проверить и частоту использования конкретных правил. Может быть какие-то из них вам не нужны.

Ситуация на рынке труда для специалистов Unreal Engine.

В комментариях к посту обсуждали нормальное распределение или закон Гаусса. Вот как он выражен в жизни. Украл скрин у друга.

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

"Посмотри, какую прикольную проверку придумал!" История стара как мир. В клубе Лабиринт в году так в 2003 была фраза от Gold-а -- одного из местных ведущих. На заре появления D&D 3 редакции он с сделал свой сплав "хороших решений"AD&D 2.5. Тогда было много редакционных войн по всему интернету. А фраза была простой: "Если мастер не пытался сделать собственной системы, то он не мастер". Так получилось, что мы постоянно находимся в поиске механик, правил и подходящих динамик. Нам всем вроде бы хочется сделать крутую, сильную, мощную и кричащую игру. Я не исключение. Поэтому возникает миллион самых разных домашних правил, основных, дополнений и порой "рулингов" (сию минутных правил). И каждый раз, почти каждый мастер начинал либо слишком масштабно, либо слишком мелко. И пример мелкого начала вошёл в некоторого рода мем. Новый автор правил с 2003 года каждый раз говорил, что есть классные кубики или классный способ основного броска/проверки. И почти каждый раз становилось понятно, что за этими проверками нет главного -- архитектуры, структуры и, собственно, системы. Было ясно, что такой автор думает, что словно бы и так ясно, как вести такую игру. Что принципы ведения ролевой игры обычны для всех и не имеют никакой разницы. А значит можно просто использовать набор забавных характеристик, которые кидаются точно также, как и в остальных играх и весёлую проверку. Всё. Вот такой наивный взгляд. Такие идеи преследовали не только наших авторов игры СНГ арены. Но и много авторов из-за рубежа. One-Roll Engine или (O.R.E.) движок за авторством Грега Столца про альтернативную историю с игрой под названием Godlike. Стат и навык складываются вместе -- это количество бросаемых кубиков. Всё точно также как в Storyteller/ing. А потом начинается разница. В упомянутой системе Мира тьмы нужно было просто посчитать успехи против какого-то числа, например, 6. Все кубики со значениями от 6 и выше после броска -- успех. Количество успехов -- степень успешности действия. В O.R.E. была высота и ширина проверки. Две восьмёрки запишутся как 2x8 -- ширина 2, а высота 8. Три двойки -- 3х2. И т.д. Если у игрока больше, чем 1 составной набор, то игрок сам выбирает высоту и ширину. И далее в редакциях автор играется именно с кубиками. Добавляет "Hard Dice" -- считается всегда 10. "Wiggle Dice" -- игрок сам выбирает, что показывает кубик после проверки. А потом ещё и "Expert Dice" -- игрок может просто кинуть, либо выбрать значение заранее. И только в игре Better Angels автор наконец-то меняет концепцию -- теперь навыки работают не также как в Мире тьмы. Кубики складываются из всех подходящих добродетелей и грехов. Да и дальше он больше работал именно с кубиками. А не с тем, чтобы понять, какой образ игры он хотел бы добиться. С самого начала, автор хотел зашить сразу две проверки в одну, чтобы упростить проверки. Но потом усложнил. Потом ещё раз. И на самом деле потом ещё не один раз усложнял, да так, что пришлось ограничить проверки максимумом 10 кубиков на одну проверку (потому что росли вероятности комбинаций). И кто во что был горазд. Поэтому просто "прикольная проверка" без оснований всегда говорила о том, что автор выбирает проверку просто потому что прикольно. И скорее всего там нет какой-то глубокой работы, где автор как архитектор скорее построил прикольный фасад дома-коробки без оглядки на функции этого дома. К примеру, GURPS выверяли проверку для того, чтобы подходило под "нормальное распределение". То есть, когда надо кинуть против 14 свои 3d6 кубиков игрок может даже ощутить, где он находится в этом нормальном распределении. И большая часть проверок построена таким образом, чтобы отвечать дизайн принципам системы -- Reality Check. Авторы хотели, чтобы все правила, которые можно проверить в реальности, соответствовали им.

https://youtu.be/Z1Dapv1lFxM?si=mzVvP0NwCsA6rsEw Ого, там нашли документы полного списка параметров GURPS версии для Fallout. Кейн делится спустя столько лет!

(ч. 2 -> ч. 1) Заменить инструкции в абзаце выше на: "Довезите до аэропорта Внуково". Всё. То есть упаковать достаточно мелкие, понятные процедуры: "бросить один кубик d20", "добавить модификатор Ловкости" в понятные нам конструкции "существительных" и "глаголов", которыми они связаны: "атаковать", "отправить войска", "договориться". Всё это пока ещё не определённые конкретно правила игры на низком уровне, и не сценарии использования игры в целом. Но уже даёт первое приближение к игре. И формирует представление о том, как примерно, должны быть связаны сущности в игре. Это достаточно, чтобы уже прыгать между ещё двумя слоями понимания: "варианты использования игры игроком" и "конкретные реализации отношений между сущностями". Важная задача на текущий момент "разбить слона на части". Которые потом можно будет "скушать".

Про существительные и глаголы Я осознаю, что сейчас может быть не понятно, для чего вообще нужно на эти существительные и глаголы делить. Но я обещаю, что это важно. Чтобы было не так кисло, то вы, наверное, уже слышали, что в геймдизайне среде действия персонажа называют "глаголами". Что, собственно, игрок может в игре делать с сущностями внутри игры. Глаголы определяют то, как игрок действует, и к чему эти действия приводят. То есть глагол -- это буквально: "прыгать", "бить", "плести заклинание", "договариваться". В него вы можете пихать как крупно-масштабные вещи, так и низко-уровневые. Главное, чтобы оно умещалось в сценарий вашей работы: "отправить войска в указанный регион", "взломать замок", "указать отряду удерживать позицию". Главное, чтобы в вашем первом описанном сценарии всё вместе это имело смысл. При этом всё равно надо думать головой. Не каждое выделенное существительное -- сущность вашей игры. Некоторые из них избыточные, другие не существуют на самом деле для игровой среды, третьи являются атрибутами -- характеристики, статистика, свойства, признаки другой сущности и так далее. К примеру, "Здоровье падает до нуля". Здоровье лучше не выделять в отдельную сущность, а сделать признаком другой. При этом взять на заметку, что частота встречи этого слова уже намекает на "игровой термин" в вашей игре. И скорее всего нужно будет вписывать его в глоссарий или индекс. Поэтому уже даже просто на этой стадии можете спокойно открывать последнюю страницу вашей игры и вписывать туда технические термины с описанием того, что они значат конкретно в вашем тексте правил. Каждая игра часто переопределяет термины. Но некоторые делают это плохо. К примеру, совершают ошибку переопределять через определяемое. К примеру, "солнце" -- это солнце, которое находится в небе. В общем так делать не стоит. Старайтесь быть и однозначными. Часто в русском языке мы используем синонимы для благозвучности. А порой путаемся "в показаниях". И когда вы пишите текст того, как должна выглядеть ваша игра, может получиться, что у вас появятся: "игрок", "персонаж", "человек за столом", "следующий справа" и прочие иносказательные. При этом так повелось, что люди часто путают и говорят, что "Сделал ТэПэКа игрокам." Совершенно не значит, что он уголовник, которого надо срочно сдавать полиции. Просто надо хорошо понимать, что имелось в виду по контексту и вносить соответствующие корректировки в работе с текстом. Такие простые "слова-ловушки" могут оказаться для вас в любом месте. Может быть и обратная ситуация. Когда за одним термином на самом деле скрывается несколько разных сущностей, которые вы, может быть, делите в своей голове. Но из текста это может быть не ясно. Такое отслеживать ещё сложнее. При этом с ассоциациями глаголами всё примерно также. Нужно постоянно держать в голове целый набор смыслов по контексту, которые вы вкладывали в написанные слова. Одни и те же действия разными словами, одним словом замаскировано несколько разных, путаница в формулировках, связи, которые не выражены игровыми средствами. И многое другое. Муторно может быть, но и не сложно! Разбив "слона" (вижен игры) на части можно достаточно быстро собирать разные её элементы. И собрать даже самые большие архитектурные системы. Объектно-ориентированное мышление -- действия, приводящие, к формированию нужных абстракций, чтобы не закапываться в глубокие детали. Это словно бы не говорить вашему водителю набор инструкций вида: "Запустить двигатель, осмотреться, если нет препятствий начать движение по дороге в не заблокированной для проезда полосе, учитывая правила дорожного движения до третьего перекрёстка, произвести манёвр поворота направо, учитывая ситуацию на перекрёстке". Даже тут я скатился в абстрактные "учитывая", "ситуацию на светофоре". Но я думаю, что основная мысль ясна. (ч. 1 -> ч. 2)

Ориентироваться на объекты Так получилось, что мы как человеческие особи думаем абстракциями. Человек, любовь, доехать до аэропорта, купить счастье и прочие фразы имеют для человека смысл. Но не для природы. Да и смысл тоже только для человеческой особи — абстракция — не отделимая от человека. К чему так издалека? Игры — абстракции. Набор несуществующих правил, которых придерживаются и люди, а порой некоторые животные. Витают в воздухе, но не выражены формально. Но мы точно знаем, что будет весело, если мы будем придерживаться их. И, разумеется, не нарушать. Даже если такие правила не формализованы — магический круг (Хёйзинга). Для меня в какой-то мере было открытием, что музыка, а вернее, акт прослушивания музыки — игровой процесс, где есть свои правила, свои особенности, которых надо придерживаться, чтобы находиться в "магическом кругу". Настольные ролевые игры не исключение. Есть масса особенностей и поведения, которое ожидается от игроков, чтобы этот магических круг сохранялся, не рушился и, более того, был увлекательным. И мы, как человеческие особи, можем формировать и создавать такие правила, чтобы работать с динамиками отношений между игроками через сценарии вариантов использования правил вашей игры. Но их надо придумать. И с чего начать? Вот так сложно я подвожу вас к книге "Анализ и проектирование систем с использованием UML", Галиаскарова и Воробьёва. В книге они очень простым языком рассказывают, как анализировать и проектировать систему на основе одного лишь бизнес текста того, как вы представляете себе в целом игрового процесса. В книге они используют особенную программу (Visual Paradigm), но вам вообще не обязательно это делать, так как можете использовать просто текстовый файл и счётчик в рядом в этом же файле. Авторы называют процесс далее "текстуальным анализом". Напишите текстом, как вы видите игру. Что за чем следует? Как всё стартует? Для чего? (см. на скриншот для примера) Подробнее напишите — проще будет собрать первое приближение системы. С этого очень просто начать. Опишите настолько подробно, насколько это представляется. Добавьте эмоций, настроения, тона и стилистики происходящего. Как себя ощущают игроки? К чему стремятся? Как думают? Пишите так, чтобы не утонуть в деталях, но максимально подробно, насколько представляется. Далее начните с существительных. Скорее всего это разные кандидаты на "технические термины" в правилах вашей игры. И чем чаще они употребляются, тем больше шансов, что они играют у вас очень важную роль. Сделайте обобщённое описание к каждому вашему существительному по сумме найденных "вхождений" в тексте. А потом ищите связи. Удивительно, но часто они работают по глаголам. Ведь игрок может использовать жетон судьбы, а может атаковать, заканчивая ход должен назвать другого персонажа игрока или ведущего в качестве следующего ходящего и так далее. Описанные глаголы в книге называют кандидатами-ассоциаций. Далее вы можете установить факт связи. А как только два или более элемента у вас связываются друг с другом — всё — система. У вас уже будет первое приближение вашей системы. Уже будет примерно ясно, какие связи вы предусматриваете, что хотите связывать, каким образом и что для этого надо. Во многом большой опыт в универсальные игры буквально заменяет вам текст, который я пишу сейчас. Для опытных мастеров универсального толка — этот подход скорее всего ясен и понятен. Весь пост — продолжение к этому.

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

Не для новичков Люблю ютубера The Primeagen — автор роликов про программирование и использование моего любимого NeoVim. Часто он разбирает в роликах статьи про редактор. И часто я смотрю их на фоне, чтобы понять философию движка. За два года использования NeoVim, я понимаю, что каждый новый день раскрывается новые и новые функции, без которых жить уже не хочется. И во многом я прикипел к собственной сборке редактора, что просто не даёт возможности мне нормально пересесть на что-то другое из официального и "большого" IDE. Меня осенило. Каждый раз новичкам в @faterpg я говорю достаточно "токсичную" вещь. Система не для новичков. И Primeagen словно бы повторяет мои слова, но в контексте NeoVim. Каждый раз ловлю себя на мысли, что отговариваю людей в чате использовать игру как первую. И уж тем более думать о том, что она достаточно простая, чтобы быстрое её понять. Особенно для закостенелых дизайнеров игр. Я часто видел, как wannabe геймдизайнеры ломали зубы об Fate в силу того, что не понимали, что стресс не работает точно также как и hit points. Не могли понять концепцию масштаба. Транзитивности правил. Релятивности механик и динамик. В том числе отсутствия "нулевого персонажа". Ещё больше голова ехала на том, что релятивность выражена листом персонажа игрока, а не эфемерным "нулевым вектором персонажа" (обычно это — обычный человек со средними статами). Или просто ломались на понимании фрактальности. Реально работе со сценами, а не всхлипываниями на бумаге "мол, говори. как двигается камера в фильмах", что только ломает игровой процесс, а не помогает ему. В силу того, что мы всё же ближе к литературному чтению, а не фильмам. Причин много. Но словно бы как в NeoVim. Если ты хочешь, чтобы инструмент был реально твоим и сформировать по-настоящему удобную среду для разработки и исполнения игры, как процесса за столом, то лучше бы инструмент был сложным. Ведь возможность глубоко настраивать инструмент — важный критерий хорошего инструмента для реально опытного ведущего. Как и для опытных разработчиков использование абсолютно непонятного визуально редактора — скорее проблема новичка, а не инструмента. NeoVim разработан с самого начала для опытных людей, которые знают, что они хотят от навигации по файлам и работы с ними. NeoVim можно сделать точной копией VS Code, но он потеряет всю свою прелесть. Точно также и с Fate можно работать как с D&D. Но в нём тогда потеряется любой смысл. Ведь лучше взять D&D. Fate на мой взгляд очень сложный, тяжёлый инструмент для НРИ, который в реальности понять и реализовать на игровой сессии могут единицы. Но один из лучших для того, чтобы можно было бы сделать почти каждую игру на этом движке своей и неповторимой. Однако, для этого надо достаточно сильно сломать "инерцию мышления" о стандартных играх, готовых правилах со вложенным нарративом, и понять, что Fate как и NeoVim не будет давать тебе готовой сборки (ну почти). Она не будет как D&D или VS Code вести тебя за ручку с миллионом предустановленных фичей. Я не могу сказать, что это хорошо или плохо. Последнее время я всё сильнее убеждаюсь, что Fate — игра не для новичков. И одному из не моих студентов даже пришлось сказать, что это не самый лучший выбор для первой настольной ролевой игры. Так как системе буквально требуется некоторый опыт в том, чтобы понимать, почему архитектурно и структурно правила сделаны такими, а не иначе. И почему авторы дают возможность пользоваться ими также как в классических/традиционных играх. Но и почему в этом нет никакого смысла.

Когда говорят, что нужно попробовать всё в жизни, никто и не думает о математике, алгоритмах или просто возможности сесть и порешать задачи. Даже самые простейшие задачи очень интересно «щекочат» голову. 💆‍♂️ Не знал, что есть такой emoji. Удивительный мир. Но правда нужный смайлик. А что вас развлекает, когда хочется углубиться во что-то необычное для вашего образа жизни?

В праздники снова поиграли вдвоём в Звёздные войны.

⚡️ Дорогие друзья! Мы долго держали это в секрете, но терпеть уже невозможно. Кажется... Мы... Доигрались... 🔸 И ОТКРЫВАЕМ СВОЙ КЛУБ НАСТОЛЬНЫХ РОЛЕВЫХ ИГР В САНКТ-ПЕТЕРБУРГЕ! Мы долго к этому шли. Бесконечное множество раз с грустью читали ваши вопросы: А где поиграть в НРИ в СПб? А кто научит? А кому довериться? А где найти компанию? Копили деньги, присматривали подходящую площадку, много считали - и наконец-то рады объявить, что на данный момент уже идёт ремонт в помещении, в котором и разместится уютнейшее пространство для начинающих и опытных любителей настольно-ролевых игр. ⚡️ Да, это происходит на самом деле. Совсем скоро мы распахнём двери в место, где будут рождаться легенды, рушиться планы игроков, выпадать критические двадцатки и начинаться незабываемые приключения во всех возможных и невозможных мирах. И называться это место будет 😀😀😀😀😀😀😀😀😀😀 (ну потому что реально доигрались!) Сейчас мы активно готовим пространство, поэтому понадобится ещё немного времени до полноценного открытия и всех подробностей — но работа уже кипит! ⚒️ В связи с таким грандиозным событием мы ИЩЕМ МАСТЕРОВ! Если вы из Санкт-Петербурга и у вас есть опыт ведения настольно-ролевых игр — заполняйте форму: 👉 Форма для подачи заявок мастера Мы будем внимательно изучать заявки и связываться с теми, кто нас заинтересует 💛 А ещё — подписывайтесь на соцсети нашего клуба: 👇 Telegram TikTok YouTube VK Inst Совсем скоро там появится больше контента, анонсов, расписаний и, конечно же, игр! Мы очень ждём момента, когда сможем собраться вместе, играть, знакомиться и творить. Искренне ваша, Команда LivingRoomStudio. ⚡️

Мой папа. Бреганов Аркадий Александрович. На фото ему 28. Капитан. Не смотря на то, что в жизни у нас произошло очень много всякого. И приятных вещей и не очень. Очень люблю папу. Он замечательный человек во многих отношениях. И как многие другие хотел бы всего самого хорошего для всех нас. Не знаю, могу ли я рассказывать про его героизм и подвиг. Но знайте, он был готов отдать жизнь за то, чтобы остальные жили в радости и достатке. Сейчас же он продаёт вино — занимается любимым делом. Мой дедушка Бреганов Александр Анатольевич — подполковник. И тоже Красной армии. Он же писал книги, был академиком. Большую часть жизни жил в Санкт-Петербурге. Несмотря на то, что был потомственным эстонцем. Собственно, и я теперь, и мой отец, и сестра — эстонцы. Он рассказывал, как немцы сжигали его деревню и бабушку на печке, выгоняя из их деревни. Красная армия спасла и определила судьбу моего дедушки. С ним у меня аж целых два года счастливых года жизни, когда я учился в Аэрокосмическом лицее №13 в г. Химки. Люблю это время. Мы жили маленькой семьёй: я, дедушка и бабушка. Тогда я начал активно играть в SEGA, а бабушка гонять и просить дать ей отдохнуть. Пайка, любовь к математике, алгебре и многое другое от него. Строгий, но безумно умный. С отцом они играли в Ленинградский преферанс каждое лето на даче. Дедушка настаивал, чтобы я писал стихи, но злился, когда рифмовал глаголы. Бабушка защищала. Я всегда был на прикупе и заучивал фразы: "Смотри в чужие карты, в свои всегда успеешь". Азарт накинуть отцу вистов в мизере — неописуемое. Обыграть дедушку Сашу в шахматы удалось только один раз за всю жизнь. Он резал по дереву и давал мне время рисовать вдоволь. Всегда поощрял. Раньше я так убегал от реальности. А тут просто делал это в удовольствие. Казалось бы всё говорило о том, что я должен пойти служить. Даже уехал с отцом и мамой в Пинск на службу отца и катался на огромном военном Камазе маленьким. Но левосторонний хронический отит и мама посчитали, что лучше институт. Люблю папу, люблю дедушку. Стыдно, что почти никогда не писал, не звоню. Я очень плохой в этом смысле сын. Но безумно их люблю. Мою мужскую линию семьи. Искренне. У них сложная, тяжёлая и замечательная жизнь полная не менее грустных и сложных выборов.

Друзья! И недруги. Хорошие новости! НРИ-ивенту быть! 20 ИЮНЯ, Москва, клуб D20. 50 билетов, 5 дневных и 5 вечерних групп. Уникальные сюжеты в двух королевствах мира ИМПРОДОР, простые правила, лёгкий формат, лучшие мастера, розыгрыш подарков, нри-штучек и мерча. Возможность попасть на игру ко мне и к мастеру НРИ - шоу Подземелья Чикен Карри, непобедимому абалденному самому лучшему мастеру в мире - Александру Бреганову! Подробности и ссылки на билеты в ближайшие несколько дней, пора обводить дату в календаре😉

ТЕПЕРЬ СЫГРАТЬ В ПЧК СМОЖЕТ КАЖДЫЙ! 🪑 Чикен Карри и московский клуб настольно-ролевых игр D20 объявляют открытым набор на игры во вселенной ПЧК 🎲 Вас ждут: 💛Эпические битвы и захватывающие приключения в любимой вселенной 💛Мастера с многолетним опытом проведения игр 💛Отдельные комнаты с настраиваемым освещением 💛Интерактивные столы со встроенным экраном 💛Миниатюрки 💛Бесплатный чай, кофе и печенье для каждого игрока Зовите друзей и вперед к приключениям! ✌️ Узнать подробности и записаться: https://d20-club.ru/services/d20-CK Выбрать приключение можно тут: https://d20-club.ru/schedule#PCK

Telegram doesn't show this post on the web. Open it in Telegram to see it.

Telegram doesn't show this post on the web. Open it in Telegram to see it.