(РПГ) Дизайн дроп-таблицы

18

Я думаю, что этот вопрос больше относится к таким играм, как MMO и Diablo-подобные игры.

Каковы обычные конструкции для реализации перетаскиваемой таблицы, когда монстр может отбрасывать различные типы предметов в зависимости от процента? Я предполагаю, что самый простой способ - это иметь словарь «процентного веса» для типов элементов, но его сложно расширить, если мы хотим ввести новые типы элементов (например, когда расширение D2 включает в себя руны и элементы нового класса)

Extrakun
источник
4
Почему сложно расширять процентные словари при добавлении новых предметов? Я имею в виду, что если вам не нужно, чтобы все проценты составляли сумму в 100% (и это только в том случае, если вы хотите, чтобы монстр всегда бросал один предмет, что довольно странно для меня), я не вижу проблема.
n0rd
1
Скажите Орк => {'кинжал', 'меч' 'броня'}, и у меня есть новый тип предмета, скажем руна; Мне придется обновить все словари, связанные с каждым типом монстров напрямую. Конечно, это еще один слой косвенности, который не может решить. Итак, вопрос в том, как выглядит этот слой?
Extrakun
Я не уверен, почему вы думаете, что обновление словаря сложно. В Python расширение одного словаря новыми значениями выполняется, например, одним методом. Не могли бы вы уточнить, где, по вашему мнению, сложность?
Kylotan
2
Extrakun, если вы посмотрите на мой ответ ниже, есть ответ на ваш вопрос «еще одного уровня косвенности». Вместо того, чтобы рассматривать капли как плоскую таблицу, вы можете построить их из вложенных выражений. Если вы разрешаете именованные макросы (то есть функции), вы можете повторно использовать фрагменты отбрасываемой таблицы в разных объектах.
Великолепно
2
Вы только что наткнулись на «подвох» разработки игр. Конечно, вы можете сделать игру за два дня, но затем наступает пять лет добавления контента. И добавление контента - это размол. ШЛИФОВАЛЬНЫЕ.
Тор Валамо

Ответы:

22

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

Простая капля выглядит так:

1-10 copper coin

В нем просто говорится, что случайное количество медных монет должно быть от 1 до 10. Все становится более гибким, когда вы добавляете ветви:

one of
    turquoise stone (50%)
    onyx stone (25%)
    malachite stone (15%)
    jade stone (10%)

«Один из» выбирает одну из своих дочерних ветвей на основе заданных вероятностей, а затем оценивает это. Капли могут уронить более одного предмета:

any of
    turquoise stone (50%)
    onyx stone (25%)
    malachite stone (15%)
    jade stone (10%)

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

Поскольку они могут быть сложными, это также позволяет вам определять именованные макросы, по существу функции, которые расширяют выражение ветвления и могут быть повторно использованы в нескольких отбрасываниях. Таким образом, если, например, у всех дварфов выпадет один и тот же вид добычи, вы можете создать для этого один макрос и использовать его для всех типов монстров вместо копирования и вставки огромных дроп-таблиц.

Пример падения одного монстра :

:: ancient dragon
    glyph   = D
    groups  = dragon
    drops
        (coins)
        2-3(1:8) one of
            (any-weapon)
            (any-armor)

Здесь (coins), (any-weapon)и (any-armor)все макро - вызовы:

(any-armor)
    one of
        (shield)
        (helm)
        (boots)
        (gloves)
        (cloak)
        (robe)
        (soft-armor)
        (hard-armor)

который в свою очередь называет такие вещи, как:

(cloak)
    one near level
        cloak (10)
        velvet cloak (20)
        fur-lined cloak (50)

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

Как и все системы, управляемые данными, вы можете ошеломить себя, создав непостижимо сложные капли, но это отвечает моим целям:

  1. Уметь указывать, какие вещи полностью исключены из кода.
  2. Простая реализация основной системы в коде.
  3. Уметь настраивать, какие именно монстры выпадают, чтобы игрок мог проводить целевое исследование. («Мне нужно ожерелье. Я буду искать гномов, потому что они склонны их бросать».)

Код C #, который реализует это здесь .

необычайно щедрый
источник
Это одна реализация, которую я не видел раньше. Благодарность!
Extrakun
12

В Stendhal наши лут-таблицы являются списками. Каждая запись содержит название предмета, минимальное и максимальное количество и вероятность. Внутренняя структура очень похожа на то, что мы показываем на веб-странице существа .

Для нас важно, чтобы игровые дизайнеры, которые хорошо знают мир, могли определять такие вещи. То есть без понимания сложной логики на уровне программного кода. Таким образом, у нас нет определений существ и предметов в программном коде, но мы перенесли их в файлы .xml, такие как elves.xml или club.xml . У нас есть графический редактор для них, но большинство разработчиков игр напрямую изменяют файл .xml.

Чтобы сделать существ и предметы легко расширяемыми, мы используем систему строительных блоков: не существует класса программ для «эльфов» или «лучников эльфов». Но есть ряд классов, связанных с поведением, таких как «трус», «патруль», «агрессивный», «лучник», «целитель». Дизайнеры могут определять новые существа, выбирая такое поведение без написания программного кода: например, чтобы создать «эльфа-лучника», нарисуйте эльфа-спрайта с луком и определите его как «наступательный», «лучник». Затем определите уровень и подобные атрибуты и добавьте несколько эльфийских предметов в таблицу добычи.

Для элементов у нас аналогичный подход, но в настоящее время он ограничен одним поведением: дизайнер может добавить новый элемент и определить поведение, такое как «ConsumableItem», «KeyItem» или «AttackItem», «Spell», «Scroll» без необходимость программирования логики.

Хендрик Бруммерманн
источник
8

В настольных играх D & D существует концепция типов добычи. Большинство монстров выпадают из одной или нескольких таблиц, и эти таблицы будут тем, что вы обновите в своем расширении. Монстры по-прежнему будут отбрасывать «65% обычных, 10% драгоценных камней, 15% художественных, 10% инструментов», но вы обновите то, что было в каждой из этих таблиц.

Например, самоцветы содержат слоты со случайными диапазонами, которые возвращают «1 самоцвет (25%) 2 самоцвета (50%) 5 самоцветов (75%) 100 самоцветов». и когда вы хотите добавить специальные камни рун, обновите таблицу на «1 драгоценный камень (25%) 2 драгоценных камня (50%) 5 драгоценных камней (75%) 100 драгоценных камней (95%) 1 рунический камень».

Но, с другой стороны, если у вас уже есть процентное взвешивание, почему бы просто не обновить все таблицы монстров в вашем расширении? Конечно, такие таблицы имеют небольшую полезную нагрузку по сравнению с текстурами и сетками. Кроме того, вам не нужно поддерживать процентное соотношение до 100, это всего лишь предположение, с которого вы начали, и вы можете подсчитать реальную сумму до генерации случайного значения. Если веса добавить до 120, то просто сгенерируйте значение 1-120 вместо 1-100.

Ричард Фабиан
источник
3

На первый взгляд это похоже на проблему «взвешенного случайного отбора».

Алгоритм определения случайных событий

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

Даже если вы предпочитаете использовать проценты - это та же система, только масштабированная до 100, - вы переоцениваете, насколько сложно добавлять вещи. Если у вас есть 100%, а затем добавьте 20% в расширении, просто разделите все значения на (120/100), и вы вернетесь к общему значению 100%.

Kylotan
источник