(RPG) Дизайн краплі столу


18

Я думаю, це питання стосується більше таких ігор, як MMO та Diablo-подібні ігри.

Які звичайні конструкції для реалізації краплі таблиці, де монстр може скидати різні типи предметів залежно від відсотка? Я думаю, найпростішим способом є створення словника "процентного зважування" до типів елементів, але це важко розширити, якщо ми хочемо ввести нові типи елементів (наприклад, коли розширення D2 включає руни та нові елементи класу)


4
Чому важко розширювати відсоткові словники при додаванні нових елементів? Я маю на увазі, якщо вам не потрібно мати всі відсотки, щоб скласти суму 100% (і це справа лише в тому випадку, якщо ви хочете, щоб монстр завжди кидав один предмет, що для мене досить дивно), я не бачу проблема.
n0rd

1
Скажи Orc => {'кинджал', 'меч' 'броня'}, і у мене новий тип предмета, скажімо, руна; Мені доведеться безпосередньо оновлювати всі словники, пов’язані з кожним типом монстра. Звичайно, це нічого іншого, який інший шар непрямості не може вирішити. Отже, питання в тому, як виглядає цей шар?
Екстракун

Я не впевнений, чому ви вважаєте, що актуалізувати словник важко. У Python, наприклад, розширення одного словника з новими значеннями здійснюється одним методом, наприклад. Не могли б ви уточнити, де, на вашу думку, складнощі?
Килотан

2
Екстракун, якщо ви подивитесь на мою відповідь нижче, є відповідь на ваше "ще один шар непрямості". Замість того, щоб розглядати краплі як плоский стіл, ви можете побудувати їх із вкладених виразів. Якщо ви дозволите іменовані макроси (тобто функції), ви можете використовувати шматки таблиці, що випадає, для різних об'єктів.
чудовий

2
Ви щойно натрапили на "улов" розвитку ігор. Звичайно, ви можете зробити гру за два дні, але потім настає п'ять років додавання контенту. А додавання вмісту - це подрібнення. ЗАГРЯЗКА.
Tor Valamo

Відповіді:


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 #, який реалізує це, тут .


Це одна реалізація, яку я раніше не бачив. Спасибі!
Екстракун

12

У Stendhal наші розграбовані таблиці - це списки. Кожен запис містить назву предмета, кількість мінімальної та максимальної кількості та ймовірність. Внутрішня структура дуже схожа на те, що ми відображаємо на веб-сторінці істоти .

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

Для того, щоб істоти та предмети легко розширювалися, ми використовуємо систему будівельних блоків: Не існує програмного класу для "ельфа" або "лучника ельфа". Але є ряд класів, пов'язаних з поведінкою, такі як "боягуз", "патруль", "агресивний", "лучник", "цілитель". Дизайнери можуть визначити, що нові істоти вибирають таку поведінку без написання програмного коду. Наприклад, щоб створити "лучник ельфа", намалюйте ельфіт-спрайт з луком і визначте його як "образливий", "стрілець". Потім визначте атрибути рівня та подібні атрибути та додайте деякі ельфійські елементи до лутової таблиці.

Для предметів у нас схожий підхід, але наразі він обмежений однією поведінкою: Дизайнер може додати новий елемент і визначити поведінку, наприклад "ConsumableItem", "KeyItem" або "AttackItem", "Spell", "Scroll" без необхідність програмування логіки.


8

У настільних іграх D&D існує концепція типів бабло. Більшість монстрів випаде з однієї або декількох таблиць, і ці таблиці будуть тим, що ви оновили б у своєму розширенні. Монстри все одно залишають "65% поширених, 10% дорогоцінних каменів, 15% мистецтва, 10% інструментів", але ви б оновили те, що було в кожній з цих таблиць.

наприклад, Gems містить слоти з випадковими діапазонами, які повертають "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%.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.