'BB'| Da_Big_Blog (блог) | ходы игроков | 4. Концепция мастерской группы -- больше объявление, чем статья

  Концепция мастерской группы.
  Это скорее не статья, а объявление о том, что я хочу провести некий эксперимент. Я решил подробно написать, в чем он заключается и как я его вижу.





  0. ВВЕДЕНИЕ И ПОСТАНОВКА ПРОБЛЕМЫ
  Или "В чем главная проблема ДМчика?"
  На этот вопрос много ответов, и, наверное, правильность их зависит от того, кому его задают. ДнДшник даст один ответ, игрок в Мафию – другой, вархаммерщик – третий, феминистка – четвертый...
  Поэтому, чтобы своим ответом ни у кого не отбить желание читать дальше, я немного переформулирую вопрос: "В чем одна из основных проблем ДМа, мешающая ему приносить больше удовольствия игрокам?"
  Мой ответ на первый взгляд банальный – модули не доходят до конца. Мастера закрывают игры. Давайте поговорим об этом чуть подробнее.
  На ДМе огромное число самых разнообразных игр, и подавляющее большинство из них закрылось потому что мастер либо перестал постить, либо нажал на кнопку "Завершить игру" условно раньше эпилога. Да, бывают случаи, когда "все поссорились", или "слился ключевой игрок" – и это сделало продолжение модуля бессмысленным. Исключения есть. Но все же зайдите почти в любую мертвую игру – там будет несколько игроков, которые хотели продолжать. Зайдите в обсужд – там все заканчивается чаще всего либо на "мастер, ты где?", либо на "дорогие игроки, к сожалению, я заканчиваю потому что я чет перегорел/устал/потерял нить".
  Почему так происходит?
  Потому что ведение модуля – это очень сложная творческая деятельность с кучей подзадач, от разработки сюжета и придумывания сцен до обработки заявок по системе и написания художественной части постов. И обычно игра помирает по одному из трех сценариев:
  • Мастер почувствовал, что игра перестала приносить игрокам столько удовольствия, сколько в начале, мастер перестал из-за этого сам получать удовольствие и скис.
  • Игра затянулась на такое время, что у мастера что-то поменялось в жизни – нет больше сил/времени на её ведение.
  • У мастера закончились идеи, пресловутое "видение, что надо делать", и он не знает, что делать, и поэтому не делает ничего.
  Варианты разные, но суть одна – мастер не справился. Он не справился не потому что не хватило таланта. А потому что...
  Потому что делать хорошие игры от начала до конца чертовски сложно!)
  В начале-то работает дополнительная мотивация – прет идея, есть вдохновение, наработок хватает. И вполне получается волочь эту глыбу в одиночку. Но случается осечка – и дальше все сложнее. И мастер не вытягивает.

  Есть способы решить эту проблему? Конечно!
  Для начала рассмотрим базовые способы, смысл которых в целом снизить нагрузку на мастера.
  1) Камерный формат. Сольник (один проверенный игрок, который с большой вероятностью подождет/не сольется, будет поддерживать, будет всегда чувствовать себя главным героем истории и т.д.) либо ван-шот про короткую даже не историю, а сцену и т.д. Валидно? Валидно! Но не зря мастера с упорством, достойным восхищения, снова и снова замахиваются на амбициозные проекты больших модулей. Кайфа больше). Потому что драматический сюжет, в который будет интересно играть, вы в одну сцену вряд ли вхрючите).
  2) Безмастерка. Как пример – тот самый модуль-самоиграйка про вампиров. А если вы его не читали, суть в том, что: "Дорогие игроки, вот вам правила, играйте по ним сами, а я проконсультирую, если что". Ну... тоже валидно, но какбэ даже название Dungeonmaster намекает, что не для этого мы собрались. Игрокам хочется взаимодействия с живым мастером, хочется человека, который прочтет его графоманию и отреагирует на неё миром игры. Сам с собой человек может и в видео-игру поиграть.
  3) Жесткие системные игры. Мастер перекладывает главную задачу – "как сделать интересно" – на плечи коллектива, заготовившего систему. Он берет книжку, где есть готовые правила, сюжеты и техники, использует их, оставляя за собой координационную (в размере своих амбиций) и описательную (в размере своего таланта) функции, а дальше уж как игроки решат или кубы лягут. Валидно? Валидно! Это – отличный вариант! Но... "но есть нюансы" (с).
  Во-первых, мастер сильно ограничен системой (не в отношении одних только циферок, а в отношении всего), а при попытке выйти за её пределы он сталкивается всё с теми же проблемами, как если бы системы не было – ему приходится что-то придумывать и вводить самому – для этого нужен совсем другой уровень усилий/навыков/видения/литературного таланта. А иногда и с теми, которые возникают, потому что есть система – например, игроки предлагают нечто, что в ней не учтено. Эмм... что делать? То есть ок, мастер как-то впишет это в систему, но ток усилия он на это потратит дополнительные.
  Во-вторых, часто есть элементы, которые ни в какую систему не вшиты. Да, будут готовые приключения, но мало где вам объяснят, почему у вас водить их получилось неинтересно. А возможно, там просто были ключевые НПЦ, которых надо было оживить, а вы не оживили. Или что-то вроде этого.
  В-третьих, если мастер не выходит за рамки, игроки играют в большей степени с системой, чем с мастером. И как бы нуууу... возвращаемся к пункту 2). Да, кто-то любит готовые приключения, а кто-то и нет.
  В-четвертых, и, наверное, в самых главных, системы эти пишутся не под форумки, а под кабинетки. Играть вживую в бой по саваге – увлекательно и захватывающе, "быстро-весело-брутально", в формате форумной игры – в гораздо меньшей степени. Есть более удачные системы, лучше подходящие для форумов, та же ПбтА, но... но что, модули по ПбтА принципиально легче водить? Они точно так же помирают, ну, не после первого, а после второго энкаунтера. Легче, это-то правда, и костылей, подходящих форумке, там больше. Но легче – не принципиально.
  И главное – не в одной системе тут дело, а в тех элементах игры, которые в игре требуют усилий помимо системы – художке и сюжете.
  Есть и другие недостатки у этого подхода, но для краткости я их опущу.

  Какие еще способы есть? Итак, подразумевается, что модуль все же – большой, масштабный или глубокий по детализации проект, явно выходящий за пределы готового приключения. Альтернативный подход – снизить нагрузку на мастера в единицу времени. Например, как?
  4) Например, разбить большой модуль на несколько маленьких. Выдавать приключение небольшими порциями. Делать паузы.
  Отличный вариант, к которому я неоднократно призывал. Проблема в том, что все равно это очень сложно). На практике провести даже 1 законченный блок – трудная задача. К тому же это требует крутого планирования и умения мыслить наперед, чтобы из блоков потом собралась единая история. Мастер в итоге все равно оказывается перед ситуацией – "я должен решать кучу задач одновременно", просто не в течение года, а в течение, скажем, полугода.
  5) И наконец... Что если поставить на место мастера команду и разделить нагрузку между её членами?
  В зачаточном варианте это присутствует – в игру берут ассистента. Есть игры, в которых ассистент берет на себя одну или часть веток, а в остальном мастер с ним советуется. Это – вполне распространенный вариант, но по сути он большинство проблем не решает: мастер и ассистент просто реализуют вдвоем больше веток, потому что каждый ведет свою. Норм, но как бы... Просто не один мастер ведет 5 модулей, а 2 мастера ведут 3 и 2 модуля соответственно, тесно связанные между собой). На практике проблемы у таких игр, насколько я видел, абсолютно те же самые.
  Есть игры, где ассистент занимается технической частью – обсчитывает систему. И вот это уже очень близко к по-настоящему командной работе. Но и тут есть нюансы – во-первых, пойдите найдите человека, которому интересно только циферками в чужих постах заниматься. Так бывает редко, а обычно человек приходит делать боевку целиком. А боевка все же – часть остальной игры, если игра сюжетная. Система ради игры или игра ради системы? Я все же думаю, что игра ради системы – циферки влияют на сюжет, и в этом случае первому, главному мастеру, в системную часть все равно вникать придется, либо ассистенту – в мастерские задумки. В итоге подход кого-то из них все же разгрузит, но не очень сильно.
  Ну и не замечал я на самом деле, чтобы игры с ассистентами доходили до финала намного чаще. Почаще, пожалуй: двое – не один, но и не супер часто. Чаще всего либо мастер, либо ассистент все равно сливаются в какой-то момент, а потом сливается и второй номер. Как говорится, двухмоторный самолет – это 200% риска. И уж точно я видел, как такие игры буксуют и простаивают месяцами так же, как и при соло-мастерении.

  Но все же мне кажется, что именно в этом, последнем варианте зарыт просто гигантский потенциал, как сделать игры интереснее и проще для ведения.
  Почему? Да хотя бы потому, что сложные развлекательные продукты, завязанные на творчестве, к которым относятся и большие модули, да еще и с ограничением по времени – продукт группы. Да, роман можно написать в одиночку, так обычно и делают... Но роман пишется все же в своем темпе, и задачи там поуже. Писатель создает историю и облекает её в текст, но у него нет задач по взаимодействию с аудиторией, нет задач по выстраиванию геймплея, нет задач поддерживать процесс постоянно долгое время. Вернее, задачи такие есть, но они либо опциональные, либо решать их можно по очереди, а в модулях надо решать все задачи сразу. Надо выдавать конечный контент быстро – каждую неделю, ну, либо реже, но помногу.
  Думаю, ближе всего к нам будут съемки сериалов: их мало того что снимают группой, частенько сценарии к сериям пишут разные люди.
  Можно посмотреть на онлайн-проекты, где контент допиливается и издается по ходу игры: и там тоже обычно работают в команде.
  Тут логично возразить, что в таких отраслях разные задачи требуют все же разных компетенций, навыков, которыми не обладает один человек – и это правда. Но во-первых, и к нам это применимо – кто-то лучше пишет тексты, кто-то лучше придумывает сюжеты, кто-то лучше и четче циферки считает, кто-то игроков вдохновляет. Во-вторых, помимо навыков есть еще и усилия: сложно делать все одному, а еще сложнее – делать хорошо, а в длинном забеге – тем более.
  Может ли модуль делать группа? Думаю, да, пока всем её членам это интересно).
  И в групповом проекте будет еще жменя бонусов, которых соло-проект лишен:
  • Взаимная поддержка,
  • Обратная связь не от игрока, у которого своя игроцкая точка зрения, а от человека по ту же сторону сюжета, что и ты,
  • Альтернативное мнение,
  • Гораздо большая эрудиция и кругозор у команды,
  • Гораздо больше совокупный опыт,
  • Возможность посоветоваться,
  • Возможность подстраховать друг-друга, если на работе завал или ушло вдохновение.
  • Да просто ощущение, что вы не один).
  В общем, имхо, тут есть о чем задуматься... Почему мы так не делаем? Или делаем редко? А если попытаться – то как подойти к теме?

  И вот о том, как организовать команду, мастерскую группу, чтобы возникло не просто разделение обязанностей, а синергия, при которой группа будет вести модуль значительно эффективнее, чем отдельный мастер, я и хочу поговорить.
  Речь не о том, чтобы завернуть: "вот мол, как надо!" Как надо я не знаю, а то бы уже делал). Речь о том, чтобы предложить подход и посмотреть, кому он был бы интересен и с кем такую группу можно замутить. Мы не знаем оптимального способа, выработать его можно только опытным путем.
  Интересно попробовать?)





  1. ОБЩАЯ КОНЦЕПЦИЯ
  Итак, в первом приближении у нас группа людей, которая делает модуль, как общий, совместный продукт.
  Давайте представим такую группу человек из... из 3-4. Как говорили римляне, для группового проекта нужно людей не меньше, чем число муз (3), и не больше, чем число граций (9). Не уверен, что они были правы, но от чего-то отталкиваться надо, оттолкнусь от этого, тем более, что к нашим реалиям это вроде близко! Если мы говорим про стандартный модуль на 5-6 игроков, то добавив к ним 3-4 человека мастеров мы и получим как раз 8-9 душ ;).
  Вроде, все просто: команда – модуль – делают! Нет, все не просто, иначе таких групп на ДМчике было бы уже много). Все очень сложно. Есть подводные камни, причем серьезные. И мне кажется, что именно обдумав то, чем мастерение в группе отличается от мастерения в одиночку, можно понять, какой должна быть концепция мастерской группы, чтобы об эти камни не разбиться.

  1.1 Мотивация
  Во-первых, с какого перепуга они будут этим заниматься? Ну, по тем же причинам, по каким и мастерят в одиночку – им это приятно. Но в чем удовольствие?
  1) Чистый энтузиазм aka "Мне нравится идея", "Я влюблен в проект" и т.д. Отличная штука! Действительно, бывает, что сама идея ("игра про это...", скажем, "про рыцарей") захватывает так, что ты готов и хочешь хоть что-то для неё делать. Обсуждать её, придумывать, творить... Но энтузиазм проходит. На этом срезается множество обычных модулей. Идея захватывала – больше не захватывает, и часть мастеров бросает модули, а часть – продолжает вести. Кто-то продолжает. потому что верит (некоторое время), что энтузиазм вернется, кто-то – из чувства ответственности (страдает, наверное, бедолага), но кто-то – из-за других причин. Из-за каких?
  2) Интересная деятельность aka "Вдохновение". Человека прет заниматься конкретным видом деятельности, связанной с игрой. Например, писать описания природы. Или боя. Или вести боевки по Саваге. Или считать циферки в этих боевках. Проблема в том, что, во-первых, все остальное делать тоже надо, а во-вторых, за исключением редких индивидов, такая деятельность все же приедается. Люди делают перерыв, люди ищут, к чему бы еще приложить свои старания. Либо – продолжают, потому что получают за это... что?
  3) Верно, вознаграждение! И вот это, наверное, одна из самых сильных вещей, потому что вознаграждение приедается гораздо реже, чем все остальное. Вознаграждение – это реакция игроков в узком смысле и сообщества в широком.
  • Вознаграждение может быть в уважении или в похвале от игроков в околоигровом пространстве.
  • В классных постах в ответ на твои посты.
  • Вознаграждение может быть в формате плюсиков (да, многих мотивирует рейтинг, и меня, в частности, тоже, и понятно, что не ради рейтинга это все... а все же "приятно"!).
  • Вознаграждение может быть в формате ощущения непосредственной, видимой сообществу причастности к крутому проекту.
  И здесь зарыт подводный камень. В обычной игре при соло-мастеринге твое вознаграждение, в чем бы оно ни было, определяется твоими постами. Вот ровно то, что ты запостил – это и есть твоя игра. Можно сколько угодно считать боевки, обсуждать с мастером сюжет и т.д., можно уговаривать себя, что ты тут – незаменимый человек, или же выслушивать эти уговаривания от мастера, но для игроков, для форума, для сообщества, для непосредственных участников твое однозначное участие в проекте – это твои посты. Однако постит ведь кто-то один, и даже плашечка "написано в соавторстве с" – всего лишь полумера.
  Мое мнение тут (по крайней мере, лучшего решения мне в голову не пришло) – все участники проекта постят по очереди, вне зависимости от того, кто фактически написал пост. Или, как вариант – по 3/5/10 постов подярд (в зависимости от формата игры) от каждого, чтобы постоянно не путаться в порядке. 5 постов запостил один – постинг переходит к другому. 5 постов запостил другой – переход к следующему. Да, могут быть исключения, например, диалог из коротких постов, который доводит тот, кто его начал. Но в целом последовательность такая.
  Каким бы ни было вознаграждение от ведения игры – все таким образом будут делить его поровну, у всех будет желание максимизировать свой вклад, все будут работать на вознаграждение всех. Это имхо очень сильно подчеркивает, что игра – продукт общих усилий. Ты высказал идею, а её не поддержали, не приняли... пусть! Но то, что ты в команде формулируешь идеи, дает тебе право постить посты в этой игре, даже если ты сам их написал бы по-другому. Это – и твои посты.
  Без этого принципа.. Можно ли создать группу, которая будет фигачить проект месяцами, не запариваясь над тем, что вклад отдельных членов явно и намного очевиднее для игроков, чем вклад других? Наверное, можно. Однако, можно гарантировать, что люди будут выкладываться за любовь к проекту в долгом марафоне? По-моему, нет. Да, система с поочередным постингом – тоже не гарант, но она по крайней мере явно уравнивает вознаграждение.
  Конечно, вклад разных участников будет разный, и оценить, посчитать его нельзя. Но это ведь и не нужно. Мысль в том, что каждый участник мастерской группы – ключевой для проекта: без него проекта не будет или по крайней мере проект будет намного менее интересным, успешным. С этой точки зрении равное деление вознаграждения оправдано. А если участник не ключевой и без него можно обойтись, не потеряв в успехе – тогда он в команде и не нужен, верно?
  Итак, первый элемент концепции – попеременный постинг всех участников вне зависимости от того, кто написал пост.

  1.2 Принятие решений и споры
  Второй подводный камень – принятие решений. В соло-модуле проблема не стоит – все решает один мастер. В командном модуле еще как стоит: споры могут и будут возникнуть по самым разным вопросам, от сюжетных до системных.
  Я уверен, что если мастера на одной волне, они большинство споров разрешат естественным путем – кто-то уступит или будет компромисс. Но может быть так, что поспорят сильно. И добро бы в начале – в конце концов, столкнувшись с такими противоречиями, можно и разбежаться, махнув на игру рукой. Но если в середине? Или в конце? Расходиться/выходить из проекта и бросать игру? Или заранее договориться, как решать споры?
  Тут возможны разные варианты:
  1) Единоличное лидерство aka авторитет. Есть лидер проекта, за которым всегда последнее слово. Это – самый действенный, интуитивный вариант.
  • Как выбрать лидера? Голосованием – для команды из 4 человек такое себе. Просто определить человека, которому "больше всех надо"? Можно, если все единодушны в том, кто это. Кинуть д100? Меняться? Есть о чем подумать.
  • Кто бы ни был лидером, лидеру придется вникать во все (будет тормозить процесс) или отдавать решения другим. Делегирование – хорошая штука, но не всегда она сработает (об этом поговорим в следующем пункте).
  • А еще ему придется принимать решения в спорах не только исходя из видения, какой должна быть игра, но и так, чтобы никто из мастеров не заскучал. Полагаю, не один ассистент отвалился от модуля потому что у него возникло ощущение, что он "ничего не решает". Люди любят, чтобы за них решали то, в чем они не шарят, но любят и влиять на проект, которым занимаются, а не просто фигачить под чью-то указку.
  2) Разграничение зон ответственности и/или делегирование решений. Конечно же, оно будет, в любом случае – кто чем занимается, тот в том и хорошо шарит, есть экспертность. Но как универсальный инструмент разрешения споров это не очень подходит, потому что разные части игры связаны друг с другом.
  • Во-первых, разные сферы – не равноценны в отношении того, "какая игра получится". А если влиять на это человеку важно, но по другому он не может, он будет и свою часть игры (в которой он – царь и бох) вести так, чтобы она играла больше роли. Кто его остановит, если что?
  • Во-вторых... Давайте пример. Вот есть человек, который решает за сюжет. А есть человек, который решает за геймплей. Сюжетчик говорит – бой в этом месте должен быть простым. А геймплейщик лепит довольно сильного монстра, утверждая, что по его мнению, так боевка будет интереснее. Кто из них прав? Так-то оба. Формально это территория геймплея. А по смыслу? Как решить спор?
  Короче, одним разделением сфер тут не обойдешься.
  3) Коллегиальность. Участники голосуют по вопросам. Хороший вариант, но есть проблемы и у него. Во-первых, для проекта втроем это норм, для проекта вчетвером – проблему не решит, когда голоса поделятся поровну. Во-вторых, все должны въехать в проблему, чтобы проголосовать – это будет тормозить игру еще сильнее, чем в случае лидера.
  4) "Судья". Человек, который выслушивает споры и решает, кто прав, больше ничем не занимаясь или занимаясь какой-то техничкой, в которой споров точно не возникнет (скажем, вычитывает запятые). Но попробуйте найти такого, да еще и чтобы он во все въезжал, не влияя и не занимаясь лично.
  Я думаю, правильное решение – в комбинации первых трех вариантов. Есть лидер проекта, выбранный или обладающий авторитетом, с которым все согласны, которому не влом вникать в большинство аспектов (или остальным не влом пояснять их смысл), и который решает простые вопросы и споры или разграничивает сферы ответственности. Но если кто-то считает спорный вопрос критически важным – вопрос выносят на голосование. И на этом голосовании либо все голоса равны, либо голос лидера перешибается голосами всех остальных участников.
  Короче говоря, тот или иной способ разрешения споров – второй элемент концепции.

  1.3 Дублирование функций
  Любой групповой проект с разделением обязанностей имеет свой... эммм... наверное, правильно сказать flaw – течение, процесс, в котором есть этапы. Сначала вот это, потом – вот то.
  Почему эта проблема особенно остра в групповом проекте? Потому что в соло если ты не смог – это твои проблемы (ну, и еще игроков), но в групповом если затык на твоем этапе – ты держишь остальных. А у них, возможно, и вдохновение в этот момент, и просто фрустрация от того, что дело не движется.
  Жизнь такова, что мы иногда выпадаем из игр – случаются разные события, на работе завал, заболели. Это будет создавать бутылочные горлышки.
  Поэтому желательно, чтобы любая задача имела 2 исполнителей – главного и резервного, который в неё погружен. Не смог боевщик рассчитать боевку – кто-то другой делает ход за него.
  Но человек не сможет быстро подхватить функцию, в которую не вовлечен – поэтому "номер 2" должен в неё вовлекаться. Базово – "основной исполнитель" советуется с ним: отдает посты на редактуру (по форме, по содержанию), просит проверить расчеты, старается отдавать ему часть задач, когда у номера 2 есть свободное время, и т.д. Второй исполнитель может отказаться от конкретной задачи, если, например, у него сейчас нет времени или возможности, но он как минимум эту задачу получает.
  Итого, третий элемент концепции – во все или почти во все процессы вовлечено минимум 2 участника, но среди них есть основной.
  Опционально: У проекта может быть координатор, который следит за тем, кто кому какие задачи отдал, и уточняет, в каком они статусе. Самоорганизация и сознательность – это хорошо, но координация – это еще лучше. Нет, координатор не должен бегать и всех материть. Он должен исключить ситуацию, когда человек не знает, что его ждут. Или когда решил чего-то не делать, но не сказал об этом.

  1.4 "Прочие командные настройки"
  В соло-мастеринге мастер один на один с голосами в своей голове – зачем ему какие-то правила?
  Но в групповом проекте правила важны, потому что комфортная атмосфера в команде – залог стабильной деятельности.
  Правила могут включать:
  • Рамки взаимной критики. От варианта "никто никого не критикует" до варианта "допустима любая вежливая критика".
  • Нормы общения. Хотя бы просто материмся в мастерской конфе или нет?
  • Коммитменты. Понятно, что колхоз дело добровольное, и выйти из проекта может кто угодно в любой момент. Или не написать, хотя обещал. Но хорошим решением будет договориться прописать и принять приемлемые варианты, при которых то или иное действие не будет рассматриваться другими, как нарушение правил мастерской группы, или хотя бы ожидания. Например, обещаем друг другу не бросать игру, пока не решим это на общем голосовании. Или обещаем поддерживать активность хотя бы 1 раз в неделю. Или обменяться контактами (телеграмом, телефонами, соцсетями) и договориться, когда можно ими пользоваться.
  • Собственно, разделение зон ответственности, ролей. Кто чем занимается. Об этом – в следующем разделе.
  • Опционально: доп активности. Голосовые встречи раз в месяц или даже встречи в реале. Ну, понятно, тут все настраивается под группу и это больше по желанию.
  Тут я не предлагаю готовых решений – понятно, что это слишком зависит от конкретных людей и должно вырабатываться перед игрой.





  2. РАЗДЕЛЕНИЕ ЗАДАЧ В КОМАНДЕ
  Так... ну, а как должны быть разделены задачи в таком проекте?
  Основная задача мастерской группы, вы не поверите, написание постов)))). Они должны появляться). Соответственно, подзадачи должны быть направлены на то, чтобы сделать это появление более регулярным.
  Есть очевидное деление задач – "творческие и технические", игровая и художественная часть поста. Это разделение имхо слишком базовое для нашего хобби.
  Я попытаюсь предложить чуть более сложную модель, которая состоит из 7 задач на 3 уровнях.
  Исходит она из того, что придумать содержание и облечь его в форму – две разные задачи, которые эффективнее решать по очереди.

  О чем я говорю? О том, что как правило, садясь за мастер-пост, вы решаете сразу все: что написать по смыслу, какими словами это выразить, какое значение это должно бы иметь в контексте большой истории. Все эти три задачи – разные! Решать их одновременно одному человеку, да еще и быстро (а даже за неделю – это иногда быстро) – тяжело. Так чтобы и красиво было, и игроцкие посты учесть, и историю рассказывать. А еще и система там сбоку... ууу...
  Поэтому на эти составляющие, уровни, я и предлагаю разделить процесс ведения модуля.

  Уровень 1. Визионерский.
  Задача 1.1 "Генерация идей". Я сейчас говорю не только про идею модуля в целом, или повороты сюжета (хотя про них в первую очередь), а просто глобальные идеи – как должна идти игра и что в ней должно быть.
  Задача 1.2 "План". Из идей нужно отобрать стоящие, реализуемые и сочетающиеся, обработать их и выдать сторилайн, концепт, общую заготовку: как пойдет игра и что в ней будет.
  Задача 1.3 "Корректировка". Идеи идеями, а игроки что-то могут и поломать. Кто-то должен с этим взаимодействовать. Кто-то должен придумывать, как изменить под них задуманный план.

  Уровень 2. Содержательный.
  Задача 2.1 "Техническое содержание поста".
  Расчет игромеханической части, если она есть. Смысловая интерпретация "цифр" – кубы покидали – и что из этого вышло по смыслу и игромеханически?
  Задача 2.2 "Смысловое содержание поста". Кто-то должен решить, что по смыслу будет написано в художественной части поста. Продумать его структуру: тут про ситуацию, тут про пейзаж, тут подсказка игроку, тут описание проблемы, с которой он столкнулся. Понятно, что эта задача опирается на результат 2.1. А еще она очень тесно связана с 1.2 и с 1.3, но разными образами. Из 1.2 исполнитель этого уровня берет сведения, и в то же время занимается постановкой 1.3 И надо, чтобы человек, занимающийся 1.3, по ним высказался и как-то обработал.

  Уровень 3. Исполнительный.
  1) Задача 3.1 "Художественный текст" – непосредственное написание тела поста, которое прочитают игроки, и его редактура. Для короткого поста эта задача решается одновременно с 2.2: что по смыслу, то и в тексте. Но если пост побольше, если нужно, чтобы текст оброс атмосферой, сочными описаниями, деталями и фактурой, их нужно нарастить дополнительно.
  2) Задача 3.2 "Технический текст" – непосредственное написание технической части поста, которую прочитают игроки, и его проверка. Эта задача связана с 3.1, и опять же, в простых постах нормально, если их выполняет один человек – возможно, тот же, кто пишет художку. Но в больших, сложных постах, очень хорошо, если за тебя кто-то подумал, что должно быть в посте, а ты согласился с этим или не согласился.


  Как выглядит разграничение полномочий?
  Давайте условно разделим людей на:
  • "Режиссера" (пусть он же будет лидер проекта).
  • "Сценариста" (человека, отвечающего за сюжет и смысл событий).
  • "Писателя" (или, если хотите, "Оператора + Монтажера" – человека, пишущего посты, тот текст, который увидят игроки).
  • "Постановщика" (или, если хотите, "Гейм-дизайнера" – человека, отвечающего за систему и геймплей).

  И вот у нас игра.
  1) Этап 1 – до первого поста. Генерация идей (Задача 1.1). В нем участвуют все.
  2) Этап 2 – до первого поста. Фиксирование идей (Задача 1.2). В нем участвуют сценарист и режиссер. Сценарист готовит сторилайн, режиссер его комментирует/редактирует. Финальное слово базово за режиссером, а может быть решено и коллегиально. Писатель и постановщик смотрят на сюжет и прикидывают, какая понадобится система/генерация, что почитать/посмотреть для вдохновения – и тоже выносят это на обсуждение.
  2) Этап 3. Написание первого поста.
  • Используя сюжет, сценарист пишет структуру поста (Задача 2.2).
  • Постановщик, используя структуру поста, прикидывает, какие решения понадобятся в технической части (Задача 2.1).
  • Писатель пишет художественную часть по структуре (Задача 3.1), сценарист/режиссер её редактирует.
  • Постановщик пишет техническую часть поста (Задача 3.2), сценарист/режиссер её редактирует.
  • Пост.
  3) Этап N. Написание любого поста.
  • Сценарист и постановщик читают игровые посты. При необходимости (игроки что-то поменяли в сюжете) они ставят режиссеру задачу 1.3. Он решает, как быть, возможно, советуясь с ними или даже голосуя, если вопрос важный.
  • Дальше как в пункте 2).

  И подстраховочка:
  • Режиссер страхует сценариста и помогает ему. Если что, он набрасывает структуру поста за него.
  • Сценарист страхует писателя. Если что, он пишет художку за него.
  • Ну, и кто-то из них страхует постановщика, а постановщик и писатель тоже страхует кого-то. Думаю, постановщик будет хорошо страховать сценариста, а писатель – режиссера, а постановщика – режиссер и сценарист вместе. "Или как-то так" (с), уже в зависимости от конкретных людей.

  Это громоздко? Да, я думаю, это так выглядит. Но, во-первых, после притирки будет понятно, какие мелкие, тактические задачи кто решает сам, во-вторых, всегда понятно, у кого спрашивать мнения, с кем посоветоваться. Понятно, что в такой маленькой команде ты спрашиваешь совет всегда у всех). Но вопрос – от кого ты ждешь решения? И тут это будет ясно.
  Базару ноль, эта схема может потонуть в разногласиях, перекладывании задач друг на друга и "чет мне перестал нравиться этот тип", разнице в художественных стилях...
  Но также я уверен, что при некоторой "единой волне" и некоторой отладке и притирке участников она может за счет разделения задач выдать очешуительно бодрую, сильную игру – с сюжетом, системой, с темпом. Игру, которая не загнется, а дойдет до финала. И принесет кучу удовольствия и удовлетворения и игрокам, и мастерской команде.
  И да, если вам где-то к этому месту показалось, что смысл всей концепции – как заставить людей пахать забесплатно вместо того, чтобы они просто занимались любимым делом в своё удовольствие – то нет. Смысл этого всего – как сделать процесс проще для отдельных участников, дающим больше результата – и за счет этого больше удовольствия. Мой пойнт – мы раньше нарезали эти куски не совсем правильно. Используя вариант "ассистент ведет отдельные ветки", мы пытались вдвоем испечь каждый по полторта и соединить в единое целое – потому что так их режут и едят игроки. А я предлагаю, чтобы кто-то пек коржи, кто-то делал крем, а кто-то их соединял и раскладывал вишенки.




  3. РОЛИ В ГРУППОВОМ ПРОЕКТЕ ПО БЕЛБИНУ (необязательная к прочтению часть, привожу больше для разгона интереса)






  4. ИТОГО
  Для тех, кому это все показалось интересным.
  Я бы хотел попробовать такое или что-то похожее. Но, как вы понимаете, мне нужны люди. Что нам нужно для старта?
  • 3-4 человека, которым нравится идея подобной совместной работы и есть желание в неё вложиться.
  • Чтобы эти люди были друг с другом примерно на одной волне в плане норм общения, а также взгляда на то, что приносит удовольствие от игр. Взгляды могут различаться, и это даже хорошо! Но они не должны друг другу противоречить.
  • Полагаю, некое общее принятие "художественного стиля". Условно говоря, давайте так. Если вы
    - рассматриваете, как норму, темп с постом в неделю или быстрее,
    - использование системы сложнее, чем д100, но проще, чем какой-нибудь TRoS (что-то типа саваги, пбта, интерлока), при этом у вас нет аллергии на авторские системы.
    - уровень художественности постов выше, чем "ты рубанул – он упал"
    - уровень сюжетов хотя бы чуть сложнее, чем "файтер-клирик-маг-и-вор убили 10 гоблинов ради экспы", но и не в стиле "экзистенциальная сущность погрязла в трансцендентных проблемах метавселенной из-за кризиса сингулярности", то...
  то думаю, найти общий язык будет реально).

  Важная оговорка – я составил драфт концепции. Набросал на коленке некие основы. Понятно, что она нуждается в уточнении, в притирке под конкретную команду. А с чем-то вы, я уверен, поспорите! Так обсудим). Ничто тут не непреложные постулаты, все можно подвергнуть сомнению и обсудить. Но отталкиваться от чего-то надо – предлагаю отталкиваться от такого варианта.

  Еще нужна тема для небольшого модуля, подготовкой которого мы займемся. Есть пара идеек, а также с огромным интересом выслушаю ваши.

  Не предлагаю заняться этим завтра. Процесс будет долгий. Как бы мне хотелось, чтобы это было?
  • За весну соберемся и выработаем общие принципы.
  • За лето – подготовим модуль.
  • Осенью начнем.

  Хотите в таком поучаствовать? Пишите мне в личку или в обсужд этого модуля. Желательно, чтобы вы знали меня, а я – вас. А дальше разберемся.

Народ, немного задерживаюсь со стартом: желающих много, и надо разработать схему, как отобрать людей в первый проект.
Я пока работаю над этим, есть наброски, но не хочется начать для галочки). Как будет оформленная идея – создам конфу и позову всех.