Перевод: flannan
Ссылка на оригинал перевода
Ссылка на оригинал статьи
Перевёл я, Фланнан, и считаю перевод законченным. Если вы считаете, что нужно что-то редактировать — пишите, что именно, или корректируйте прямо на Википереводах.
Хоумрулы — необходимая часть большинства игр, и нам, ведущим, часто нужно их использовать, чтобы исправить недостаток, заткнуть дыру, или удовлетворить непредвиденную потребность. Хотя многие ведущие хорошо водят, это не обязательно означает, что они хорошо модифицируют системы. Так что рассмотрите эти рекомендации, когда вводите собственные хоумрулы.
Я встречал в своей жизни ведущих, которые — как и я — любят понимать и обсуждать взаимодействие игровых механик; нырять глубоко во внутренности системы и смотреть, как она там работает. И наоборот, я играл с немалым количеством ведущих, которые мало интересуются основаниями — им просто хочется, чтобы игра работала. Оба эти подхода вполне хороши (как и все промежуточные), и я даже скажу, что вторая группа — когда использует коммерчески опубликованную игру — ожидает, что всё просто «заработает». К сожалению, как мы все знаем, так редко бывает.
Даже разработчики смертны, и подобно тому, как ни одно приключение не переживёт встречи с ИП, ни одна система не переживёт встречи с группой игроков… или с ведущим, любящим что-то поднастроить. Есть даже подмножество, которым нравится настраивать свои правила — имеют право — даже безо всякой причины. Ненавижу играть в таких играх!
Так вот, я сейчас надеваю свою шляпу разработчика игр, позвольте мне поделиться своей философией в вопросе хоумрулов или изменения систем.
* Убедитесь, что у вас есть хорошая причина. Это кажется очевидным, но если нет по-настоящему сильной причины модифицировать правила — и вы умеете предвидеть все вытекающие последствия — делайте изменения только в крайних случаях. Нередко одна «заплата» создаёт кучу новых проблем.
* По возможности отбросьте эмоции, когда продумываете изменения. Некоторые изменения рождены эмоциями, например непреклонным желанием закрыть кажущуюся «дыру», которую нашёл игрок. В самом ли деле её нужно чинить, или ты это просто ситуация, когда вам кажется, что угрожают опоре вашей власти?
* Простота лучше сложности, при прочих равных. Или, как говорят англичане, Keep It Simple, Stupid (KISS). Не пытайтесь решить вопрос тремя бросками кубов и двумя диаграммами, когда хватит одного броска. Да, возможно, придётся ради простоты от чего-то отказаться, но постарайтесь понять, служит ли каким-то образом эта сложность игре. Почти всегда, сложность не служит, она только замедляет процесс.
* Пусть ваши изменения подходят к игре. Изменение правил в Дневнике Авантюриста (Savage Worlds) скорее всего не такое сложное, как можно сделать в Ролемастере или в ДнД. ДА не любит таблицы или глубокий симуляционизм, так что ваши изменения не должны идти по этому пути.
* Будьте внутренне последовательны. Здесь я имею в виду, что при любой возможности — используйте уже существующий каркас, который у вас уже есть, а не пытайтесь создать новый. Это самая большая «ошибка», которую я видел: чудовище Франкенштейна из заплаток и исправлений, поставленных наобум, пытающихся решить одну проблему и создающих кучу новых. Вдобавок, они просто кажутся совсем не к месту. Система, может быть, не делает то, что вы от неё хотите, но скорее всего есть способ использовать существующие структуру и механику, лишь слегка подпилив, чтобы заполнить недостающее.
* Не бойтесь признать ошибку. Интеллектуальная и эмоциональная честность здесь очень важны. Признайте, что вы неправы, и стремитесь быть честным и беспристрастным. Игроки заметят, и это произведёт сильное впечатление.
* Спрашивайте чужого мнения, особенно от игроков. В лучшем случае — вы получите новые идеи, о которых не подумали, без лишних усилий со своей стороны. В худшем случае — игроки почувствуют, что включены в процесс принятия решений.
* Основывайтесь на основной механике разрешения при любой возможности, и делайте исключения только при необходимости. По сути, механика, основанная на исключениях. Это помогает избавиться от сложности и ненужного «разделения» правил.
* Я раньше это сказал, но стоит повторить: стремитесь к простоте. Никто не оценивает вас за стиль или за то, какой вы хитроумный.
Думая, какой бы взять пример, я не мог не вспомнить одну из моих любимых игр, Fading Suns (англ. Гаснущие солнца). Система Очков Победы (Victory Point System, VPS), которая там используется — не что-то примечательное. Но вполне работает. Но именно её из всей системы чаще всего меняют. Не без причин, потому что система, как она есть, имеет проблемы со внутренней последовательностью.
Например, вся игра вращается вокруг механики на d20 «киньте меньше или в точности требуемое число». Это ясно, легко понять, и механика того, насколько много вы выкинули, не переходя требуемое число (механика «Price is Right»), определяет, насколько хорошо вам удалось. А выкинуть в точности требуемое число — критический успех. Просто, не правда ли?
Только бой внезапно закладывает лихой вираж, когда, после того, как вы попали, внезапно система превращается в упражнение по подсчёту успехов. Бросаете d6-ые — это единственный момент в игре, когда нужен другой куб, чем d20 — и считайте 1-ы, 2-ки, 3-ки и 4-ки, как успехи и для повреждений и для поглощения бронёй. Каждый раз, когда я объяснял эту систему игроку, игроки находили её не менее режущей глаз, чем я когда в первый раз читал правила. На практике она тоже странная; игра немного останавливается. («Ой, подождите, мне сейчас нужно d6-ые достать...»)
Есть несколько способов подойти к этому, и не последний из них — просто использовать систему такой, какая есть. Но я тут говорю не о том, чтобы попытаться исправить то, что кажется аномалией, а подчеркнуть, что она есть, даже в RAW. Лично мне никогда не хотелось «исправить» этот аспект VPS, но многим другим хотелось.
Я не сомневаюсь, что вы дорабатывали напильником немало систем, и хотел бы услышать ваши мысли о том, как вы подходите к такой проблеме за своим столом ниже!
В комментариях к тексту упоминается, что в тяжёлых с точки зрения математики системах нужно ещё следить за балансом новых хоумрулов.
А плейтестить хоумрулы нужно во всех системах.
Ещё одна интересная мысль: записать хоумрулы, чтобы все их видели и точно знали, какие они.
И не забывать, что хоумрулы можно пересмотреть, если они неудачны.
Один из комментариев рассматривает три случая, когда хоумрулить — хорошая идея:
* Когда правила не поддерживают что-то, что вы хотите ввести. Например, создание магических предметов.
* Когда правила мешают сделать то, что вы хотите. Иногда его проще игнорировать, но иногда лучше переделать.
* Когда вы и ваши игроки симуляционисты и вы любите более сложные системы для какого-то действия. Например, более разнообразные криты в игре, где много боёв. Но только для тех действий, которые в фокусе игры!
И напоследок, один комментатор высказался за то, что жизнь коротка, и в наше время развитого геймдизайна (в противоположность диким временам АДнД) хоумрулы — напрасная трата времени.
Ссылка на оригинал перевода
Ссылка на оригинал статьи
Перевёл я, Фланнан, и считаю перевод законченным. Если вы считаете, что нужно что-то редактировать — пишите, что именно, или корректируйте прямо на Википереводах.
Хоумрулы — необходимая часть большинства игр, и нам, ведущим, часто нужно их использовать, чтобы исправить недостаток, заткнуть дыру, или удовлетворить непредвиденную потребность. Хотя многие ведущие хорошо водят, это не обязательно означает, что они хорошо модифицируют системы. Так что рассмотрите эти рекомендации, когда вводите собственные хоумрулы.
Настройки
Я встречал в своей жизни ведущих, которые — как и я — любят понимать и обсуждать взаимодействие игровых механик; нырять глубоко во внутренности системы и смотреть, как она там работает. И наоборот, я играл с немалым количеством ведущих, которые мало интересуются основаниями — им просто хочется, чтобы игра работала. Оба эти подхода вполне хороши (как и все промежуточные), и я даже скажу, что вторая группа — когда использует коммерчески опубликованную игру — ожидает, что всё просто «заработает». К сожалению, как мы все знаем, так редко бывает.
Даже разработчики смертны, и подобно тому, как ни одно приключение не переживёт встречи с ИП, ни одна система не переживёт встречи с группой игроков… или с ведущим, любящим что-то поднастроить. Есть даже подмножество, которым нравится настраивать свои правила — имеют право — даже безо всякой причины. Ненавижу играть в таких играх!
Так вот, я сейчас надеваю свою шляпу разработчика игр, позвольте мне поделиться своей философией в вопросе хоумрулов или изменения систем.
* Убедитесь, что у вас есть хорошая причина. Это кажется очевидным, но если нет по-настоящему сильной причины модифицировать правила — и вы умеете предвидеть все вытекающие последствия — делайте изменения только в крайних случаях. Нередко одна «заплата» создаёт кучу новых проблем.
* По возможности отбросьте эмоции, когда продумываете изменения. Некоторые изменения рождены эмоциями, например непреклонным желанием закрыть кажущуюся «дыру», которую нашёл игрок. В самом ли деле её нужно чинить, или ты это просто ситуация, когда вам кажется, что угрожают опоре вашей власти?
* Простота лучше сложности, при прочих равных. Или, как говорят англичане, Keep It Simple, Stupid (KISS). Не пытайтесь решить вопрос тремя бросками кубов и двумя диаграммами, когда хватит одного броска. Да, возможно, придётся ради простоты от чего-то отказаться, но постарайтесь понять, служит ли каким-то образом эта сложность игре. Почти всегда, сложность не служит, она только замедляет процесс.
* Пусть ваши изменения подходят к игре. Изменение правил в Дневнике Авантюриста (Savage Worlds) скорее всего не такое сложное, как можно сделать в Ролемастере или в ДнД. ДА не любит таблицы или глубокий симуляционизм, так что ваши изменения не должны идти по этому пути.
* Будьте внутренне последовательны. Здесь я имею в виду, что при любой возможности — используйте уже существующий каркас, который у вас уже есть, а не пытайтесь создать новый. Это самая большая «ошибка», которую я видел: чудовище Франкенштейна из заплаток и исправлений, поставленных наобум, пытающихся решить одну проблему и создающих кучу новых. Вдобавок, они просто кажутся совсем не к месту. Система, может быть, не делает то, что вы от неё хотите, но скорее всего есть способ использовать существующие структуру и механику, лишь слегка подпилив, чтобы заполнить недостающее.
* Не бойтесь признать ошибку. Интеллектуальная и эмоциональная честность здесь очень важны. Признайте, что вы неправы, и стремитесь быть честным и беспристрастным. Игроки заметят, и это произведёт сильное впечатление.
* Спрашивайте чужого мнения, особенно от игроков. В лучшем случае — вы получите новые идеи, о которых не подумали, без лишних усилий со своей стороны. В худшем случае — игроки почувствуют, что включены в процесс принятия решений.
* Основывайтесь на основной механике разрешения при любой возможности, и делайте исключения только при необходимости. По сути, механика, основанная на исключениях. Это помогает избавиться от сложности и ненужного «разделения» правил.
* Я раньше это сказал, но стоит повторить: стремитесь к простоте. Никто не оценивает вас за стиль или за то, какой вы хитроумный.
Думая, какой бы взять пример, я не мог не вспомнить одну из моих любимых игр, Fading Suns (англ. Гаснущие солнца). Система Очков Победы (Victory Point System, VPS), которая там используется — не что-то примечательное. Но вполне работает. Но именно её из всей системы чаще всего меняют. Не без причин, потому что система, как она есть, имеет проблемы со внутренней последовательностью.
Например, вся игра вращается вокруг механики на d20 «киньте меньше или в точности требуемое число». Это ясно, легко понять, и механика того, насколько много вы выкинули, не переходя требуемое число (механика «Price is Right»), определяет, насколько хорошо вам удалось. А выкинуть в точности требуемое число — критический успех. Просто, не правда ли?
Только бой внезапно закладывает лихой вираж, когда, после того, как вы попали, внезапно система превращается в упражнение по подсчёту успехов. Бросаете d6-ые — это единственный момент в игре, когда нужен другой куб, чем d20 — и считайте 1-ы, 2-ки, 3-ки и 4-ки, как успехи и для повреждений и для поглощения бронёй. Каждый раз, когда я объяснял эту систему игроку, игроки находили её не менее режущей глаз, чем я когда в первый раз читал правила. На практике она тоже странная; игра немного останавливается. («Ой, подождите, мне сейчас нужно d6-ые достать...»)
Есть несколько способов подойти к этому, и не последний из них — просто использовать систему такой, какая есть. Но я тут говорю не о том, чтобы попытаться исправить то, что кажется аномалией, а подчеркнуть, что она есть, даже в RAW. Лично мне никогда не хотелось «исправить» этот аспект VPS, но многим другим хотелось.
Я не сомневаюсь, что вы дорабатывали напильником немало систем, и хотел бы услышать ваши мысли о том, как вы подходите к такой проблеме за своим столом ниже!
Комментарии
В комментариях к тексту упоминается, что в тяжёлых с точки зрения математики системах нужно ещё следить за балансом новых хоумрулов.
А плейтестить хоумрулы нужно во всех системах.
Ещё одна интересная мысль: записать хоумрулы, чтобы все их видели и точно знали, какие они.
И не забывать, что хоумрулы можно пересмотреть, если они неудачны.
Один из комментариев рассматривает три случая, когда хоумрулить — хорошая идея:
* Когда правила не поддерживают что-то, что вы хотите ввести. Например, создание магических предметов.
* Когда правила мешают сделать то, что вы хотите. Иногда его проще игнорировать, но иногда лучше переделать.
* Когда вы и ваши игроки симуляционисты и вы любите более сложные системы для какого-то действия. Например, более разнообразные криты в игре, где много боёв. Но только для тех действий, которые в фокусе игры!
И напоследок, один комментатор высказался за то, что жизнь коротка, и в наше время развитого геймдизайна (в противоположность диким временам АДнД) хоумрулы — напрасная трата времени.
Комментариев нет:
Отправить комментарий