Я атакую его снова и мне норм

На эту мысль меня натолкнуло размышление Konstructor на тему схематичности игровой механики и интерпретации всех действий посредством нескольких игромеханических опций: imaginaria.ru/p/hexxen-1730-perevod-i-mnenie.html. Отчасти, мои собственные измышления тоже послужили катализатором.

А что, если единственный тип действий игрока на любые заявки — это атака?!

Под атакой я понимаю действие, результат которого — уменьшение у цели каких-то параметров или счетчиков. И эти самые счетчики не ограничиваются только хитпойнтами, но и всем другим, что может быть посчитано. Бои, внимательность и скрытность, всякие паркуры, ТДО, дипломатия, сверхспособности, крафт, пилотирование техники и дергание связей в организациях и кругах знакомств — это атаки и защиты от них. Ударил кого-то — снял хиты, договорился или запугал — снял решительность, прыгнул через забор — снял метры в высоту, купил или сделал сам — нанес урон своему кошельку, ресурсам и настойчивости продавца, скрылся в темноте — продамажил внимательность цели (или наоборот), обратился к союзникам — исчерпал их кредит доверия и пр. Всякие маневры и состояния тоже могут быть выражены счетчиками (чтобы встать с земли, нужно продамажить рейтинг «поваливания» до нуля).

Как думаете, взлетит? Что интересного можно еще из такой системы извлечь? Насколько абстрактной можно сделать такую механику, чтобы не погрязнуть в адовых списках и примерах каждой конкретной вещи?

29 комментариев

avatar
Звучит как Кортекс+, в котором ты можешь уменьшать значение кубов мастера.
avatar
*Ариклус атакует предположение о сложнореализуемости данной идеи*

В принципе в некоторых системах атака — не сильно отличается от обычного действия (нет отдельного броска урона), так что можно заявить что любая атака — действие или что любое действие — атака.
Например в МТ урон определяется количеством успехов на атаке. Также есть длительные действия, где надо накидать Х успехов, в то время как броски жрут драгоценное время или ограниченое число попыток (примерно как и в бою).
Обычную проверку где достаточно одного успеха можно рассматривать как атаку по однохитовому «противнику».
Комментарий отредактирован 2017-01-26 17:54:07 пользователем ariklus
avatar
В понедельник Blades in the Dark поступают в продажу, если чо.
avatar
Blades in the Dark
Это часом не та игра, где колода карт на руке обозначает и скрытность, и живучесть, и еще какие-то параметры?
avatar
Нет, совсем не та.
avatar
Это вы про project: dark говорите. И она еще не скоро выйдет.
avatar
Вообще, это ничто иное, как ресурс менеджмент, только перевёрнутый вверх ногами. Пессимистичный, так сказать.
Концепция может быть вполне интересной: решение проблем становится вопросом понижения определённых параметров до определённого уровня. Обычно, правда, делают обмен очков характеристик, нудаладно. Буду следить за развитием.
  • CY
  • +4
avatar
Если отвлечься от звучания слов «атака» и «счетчики», то традиционные системы именно так и делают. Только «атака» называется, например, «проверкой скилла», а «счетчики» принимают только значения «успех/провал». Небинарные счетчики стоит вводить лишь там, где промежуточные значения для чего-то нужны. Потраченные на 20% ресурсы партии имеют смысл, перепрыгнутая на 20% пропасть — не имеет.

А что, если единственный тип действий игрока на любые заявки — это атака?!
Рассмотри такую мысль:
Там, где есть единственный вариант действия, наличие счетчика избыточно. Там где есть счетчик, единственного варианта действия недостаточно.
avatar
Вообще да, технически, если оставить только один тип действия, то некорректно называть его «атакой», так как это предполагает наличие «не атак» среди других действий.
avatar
Действие можно и нужно называть «Атакой», ибо это точно описывает принцип работы. А ещё довольно красиво звучит: «я атакую его самолюбие!», или «я атакую внимание стражи, чтобы пробраться незамеченным». Уживание этого глагола в предложении наталкивает на особое мышление и структуру повествования.
avatar
наталкивает на особое мышление и структуру повествования
Какое именно?
avatar
Чтобы чего-то добиться, тебе надо «проатаковать» нечто, связанное с целью. Мне нравится.
avatar
Чтобы преодолеть преграду, нужно «атаковать» её и свести её к нулю. Сделать из слона муху, так сказать.
Такая игра будет не про сражение с большими боссами, а про тренировки и подбор снаряжения. Не про третью мировую, а про холодную войну. Не про секс, а про пикап.
Проиллюстрирую парочкой примеров:
Задача: незамеченным пробраться мимо стражи. Препятствие: внимание стражи. Атака игрока направлена на то, чтобы свести внимание стражи к нулю. Атакой может быть: кинуть камешек в кусты, найти обходной путь, выждать когда стражники будут невнимательными (сонными).
Задача: пересечь забор. Препятствие: его высота или прочность. Атака: придвинуть булыжник к забору чтобы сократить его высоту, пробить дыру в заборе и сократить его прочность.
avatar
Потраченные на 20% ресурсы партии имеют смысл, перепрыгнутая на 20% пропасть — не имеет.
В том же BitD любое действие может быть иметь и просто результат успех/частичный успех/провал. Счетчики «хитов» используются только для сложных/долгих действий.
avatar
Насколько абстрактной можно сделать такую механику, чтобы не погрязнуть в адовых списках и примерах каждой конкретной вещи?
Оценивать сложность задачи, числом или дайсом. Получается похоже на Кортекс, как выше уже сказали. Оставляет много простора мастерскому произволу, если числом, и всякому странному рандому, если кубиками.

При этом механика разделяется, как минимум, на одиночные «атаки» (прыжок через пропасть), «атаки» с накоплением (чиним поломку двигателя, попытки суммируются) и атаки с повторением, но без накопления (через забор можно пытаться прыгать много раз, но прыжки не суммируются).
  • R2R
  • 0
avatar
Статьи по ссылкам не читай сразу отвечай.

Для того уровня абстракции, на котором это описано — вполне нормальная ситуация свести все игровые броски к пассивным проверкам против некоторой сложности.

Другое дело, что описанного механизма категорически недостаточно, чтобы на его основе строить даже «игромеханическую подсистему», ибо основные вопросы, как минимум:
1. Когда включается требование «сделать бросок»?
2. Что (игромеханически) значит бросок: цена броска (может надо тратить фишки какие независимо от исхода?), возможные исходы и результат «вознаграждение успеха» «цена провала» каждого из них?
3. Как процессуально выглядит бросок?
4. Как интерпретируется (переводится в нарратив) результат броска?

Вот твоя система «только атака» отвечает на п.3), а многочисленные таблички, которые ты предполагаешь писать, частично на п.2).
avatar
Подход интересный, но есть одно НО, которое заодно решает вопрос с таблицами. Для такой системы нужно применять высокий уровень абстракции (или нарравтива, если хотите). Примеры, перечисленные в топике (вроде уменьшения счетчика высоты забора), это натягивание этого подхода на традиционную механику с таск-резолюшном, из-за чего она кажется похожей на обычную механику с бинарным счетчиком. Есть один тонкий момент, который отличает действие атаки, снимающей хиты, от прочих мгновенных действий — атака понижает счетчик долговременно, поэтому две последовательные одинаковые по успешности атаки добиваются большего эффекта, чем одна. Кумулятивность, так сказать. Проверка с бинарным счетчиком не обладает таким свойством — чтобы перепрыгнуть пропасть, мне нужно обнулить сразу весь счетчик за один присест, иначе все нужно начинать сначала.
Эта механика взлетает если все проверки в игре кумулятивны, скорее всего, это конфликт-резолюшн. Вместо перепрыгивания пропасти нужно проверять способность, скажем, пройти полосу препятствий, без уточнений, из чего конкретно она состоит, а счетчиком будет условная длина.
  • Rex
  • +7
avatar
В зависимости от последствий провала (после «атаки сложности») все привеённые тобой случаи можно реализовать.

Другое дело действительно зачем использовать столь высокоабстрактную механику, но это уже отдельный вопрос
avatar
Если последствием провала не станет мост из трупов над пропастью, то ты никак не перепрыгнешь через нее несколькими кумулятивными проверками.
avatar
Прыжок — атаковать пропасть (сложность проверки высчитывается отдельно).
— успех — перепрыгнул и ты на другой стороне.
— неудача — не перепрыгнул (и ты летишь в пропасть)

Я к тому, что «1 хит, победа — означает, что задача решена» частный случай варианта «несколько хитов».
avatar
Только этот «частный» случай принципиально отличается от общего. При желании все что угодно можно объявить частным случаем чего угодно, ну и что, что по дороге теряются все важные свойства? Смысла в таких логических упражнениях я не вижу.

Будь прыжок через пропасть атакой, схема выглядела бы по-другому:
Прыжок — атаковать пропасть.
— Результат броска отнимается от условной длины пропасти, причем он кумулятивен.
Успеха и провала, как таковых, в атаке нет — есть преодоление пропасти на длину, превышающую нужную, и преодоление на нулевую длину. Причем последний случай не влечет за собой мгновенной санкции, как при обычном прыжке, за провал которого меня «наказывают» падением вниз.
avatar
Подожди мне кажется в данном случае какое-то порочное мышление у тебя (*):
— выбрать конкретную реализацию механики «всё есть атака»;
— заявлять, что только твой вариант является правильным;
— если что-то работает на механике «всё есть атака», но не работает в твоей реализации — объявлять это неработающим.

Я бы шёл от другого:
1. Механика «всё есть атака» — это просто всегда одинаково регламентированное: «создание противника» и «регламентация бросков атаки до победы».
2. Рассмотреть какие типовые конфликты возникают.
3. Подумать, как именно надо реализовать механику атаки, чтобы удовлетворить пункт «2».

А то у тебя наоборот. Сначала придумал техническую реализацию, а потом возмущаешься, что не все конфликты ей решаются, не надо так.

*) я уж не говорю о фактических ошибках типа «При желании все что угодно можно объявить частным случаем чего угодно»
avatar
Ты конечно молодец, что шел от другого, а вот я иду от постановки задачи в топике. Там уже поставлена техническая реализация механики и стоит вопрос, взлетит ли. Я указываю условия, при которых взлетит. А заодно уточняю, чем собственно атака отличается от действия преодоления, как это назвали бы в фейте, и почему первое сводится ко второму только с большими и бессмысленными допущениями. Ходить от чего-то другого мне не особо интересно.
avatar
А там разьве указано (в тексте):
— А там разьве указано каким образом «получает дамаг» протоганист?

— А где «в ТЗ» запрет на пул из 1го хита?
// я не понял ты против этого пункта самого по себе или только против применения вместе с предыдущим
avatar
зачем использовать столь высокоабстрактную механику,
А почему бы и нет? :) Это широкий простор для модификаций.
avatar
Но ведь, действительно, пример «атаки высоты забора» контринтуитивный и я его скорее привел как вырожденный пример. Как сделать так, чтобы в случае такой тривиальной задачи как «оказаться по ту сторону забора» действие атаки не сводилось к «я ломаю забор и через дыру оказываюсь на огражденной территории»?
avatar
Мой вариант — отсутствие в игре таких тривиальных задач, в том и фишка. В такой игре задачи должны ставиться более масштабно и абстрактно, чтобы каждая из них могла быть представлена в виде небинарного счетчкика подверженного кумулятивному эффекту.

Другой вариант — вводить счетчик времени, когда задача сводится к успех/провал, тогда действие автоматически успешно, а проверка показывает временные затраты. Если временные затраты также не важны, действие просто успешно без бросков. Также как в нарративных системах часто рекомендуется не требовать проверок действий, если их провал не вносит в игру никаких изменений.
avatar
В сущности, большинство систем являются таковыми.
Перед тобой сложность.
Ты её атакуешь, кидая кубики.
В зависимости от того, насколько хорошо ты атаковал, решается, убита сложность или нет.
avatar
Я вот тут подумал (по результатам обсуждения с Rex):
вариантов реализации принципа «всё есть атака» — их достаточно много.

Неплохо бы сначала выписать на листочке представлять какие конфликты будут (в целом ты их уже назвал), и как будет выглядеть их игромеханическое разрешение, а уже потом выбирать техническую реализацию.

П.С.
И ещё одно (скорее как замечание на «подумать»): такая механика, если не будет существенных уточнений\добавлений, получится очень высокоабстрактной, что не всем нравится (вот для меня это худшая часть в Fate, который несмотря на это весьма мне нравится).

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.