Поради щодо впровадження кметової механіки MMO?

Які інструменти, шаблони чи найкращі практики ви б рекомендували застосовувати до квест-механізму, наведеному нижче перелічених вимог?

Я говорю про архітектуру програмного забезпечення (якою ти маєш бути загальною) та вибір об’єктів проводки, підписки на події та представлення умов. Відомо згадування інструментів / бібліотек, які ви успішно використовували. Редагувати: Якщо ви використовуєте сценарій, яку налаштування ви рекомендуєте?

Вимоги:

простий 2D mmo (rpg)
всі ігрові дані, включаючи квести, зберігаються у реляційній базі даних
будь-яка подія в грі може викликати новий квест для гравців або просування існуючих квестів
квест може мати довільну кількість умов, які повинні бути виконані до того, як квест буде доступний гравцям
квест може складатися з довільної кількості підквестів / кроків з довільними умовами
Квести будуть варіюватися від простих:

розмовляти з A - вбивати 5 B - розмовляти з A - постійно покращувати здоров'я
досить залученим:

використовувати предмет у зоні X - перейдіть у зону Y - бот буде нерестувати - вбивати бота, не отримавши більше 10% шкоди - предмет бота падає - забрати предмет - розблокує портал - доставить предмет у J за порталом - отримайте золото та досвід - дозволити ще раз пройти портал - заблокуйте портал для цього гравця
Екземпляри рівня - це можливість (гравці можуть виконувати певні квести в командах або ізоляцію, яка породить місце розташування саме для цих учасників)
Квести повинні бажано управляти за допомогою світового редактора без написання сценаріїв або знань про програмування ( Редагувати: не виступаючи проти сценаріїв взагалі)
Я вважаю, що C ++ є мовою реалізації

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

— jmp97
джерело

Чи є якась конкретна причина, чому ви вирішили пропустити будь-який сценарій? (наприклад, lua / gamemonkey тощо).

— Симон

Переважно через брак досвіду та через (можливо, необгрунтовані) припущення про те, як це може негативно вплинути на результативність. Також я хотів, щоб редагування світу було максимально простим. Однак я відкритий для використання сценаріїв.

— jmp97

Я погоджуюсь, що без підтримки сценаріїв буде складно додати різноманітність до квестів, не залучаючи програмістів двигуна.

— drxzcl

Мови скриптування, як правило, досить швидко, що це не проблема. Я настійно рекомендую їх використовувати. Однак, більша частина сценаріїв WoW заснована на спровокуванні заклинань та подій. "Поговоріть з A", внаслідок кулісів, A призведе до "заклинання" гравця, а квест насправді буде закодований "Це вдається, коли на плеєрі подано заклинання №55728". Тоді вам просто потрібно трохи кодування AI, щоб змусити істот робити заклинання на програвачі, і ви налаштовані.

— ZorbaTHut

Сучасні мови сценаріїв (наприклад, Lua Vm), ймовірно, досить швидкі для вас. Вони прості у використанні, прості у впровадженні, ви можете перезавантажувати сценарії під час виконання, ви можете налагоджувати та виконувати налагодження сценаріїв під час виконання, і ви можете багато разів повторювати процес створення вмісту. Я настійно пропоную заглянути в механізм сценаріїв (приклади: lua та gamemonkey) для того, щоб складати квести.

— Саймон

Відповіді:

Спочатку попередження, потім кілька порад.

Востаннє мені потрібно було реалізувати таку систему, як я не використовував двигун, призначений спочатку для MMO-подібних додатків. Система квестів, з якою вона постачалася, була спрямована на починання одного гравця, і не може бути використана.

Мені в кінцевому підсумку довелося скласти сценарії в усі об'єкти, які беруть участь у квестах, вручну, як це (псевдокод):

Lever004_on_activate() {
    if isOnQuest(player, QUEST_0012) do_something();
    if isOnQuest(player, QUEST_0015) do_something_else();
}

Це повний кошмар. Немає можливості зрозуміти, як працює квест, не перебираючи всю гру. Не роби цього.

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

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

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

— drxzcl
джерело

Але будьте попереджені, державні машини, як правило, дуже швидко перекручуються, якщо ви хочете, щоб на квестові шляхи впливали зовнішні фактори або якщо ваші квести порівняно складні. Також декілька державних машин квесту (якщо кілька квестів можуть бути активними) можуть бути кошмаром. Однак, оскільки по суті кожна програма є державним машиною, це можна зробити. Але складні проблеми залишаються складними незалежно від того, як ви їх інкапсулюєте. Хороший приклад (imo) - Oblivion, коли деякі моди не дозволяють іншим модам працювати - ваші попередні та пост-умови для станів повинні бути або досить твердими, або надзвичайно прощаючими / помилковими.

— Кай

Так, кай правильно. Просто переходьте на форуми WoW прямо зараз і читайте про людей, які скаржаться на незакінчені квести. Це відбувається постійно, навіть у вищій лізі. Дійсно все важко виправити.

— drxzcl

Наша система в основному передбачає виконання виразу (спеціальна мова міні-сценаріїв, але tcl / lua / python буде працювати так само добре, або зробити щось самостійно) кожен серверний кадр для кожного кроку місії. Це для "особистих місій", які прив'язані до конкретного гравця. Кожен піддіапазон потім є частиною FSM (машини з кінцевим станом) для самої місії (яка може бути просто підкроком іншої місії). Також є "місії на карті", які мають єдину FSM і прив'язуються до карти замість гравця (думаю, що загальнодоступні квести WAR), але підкрокопи працюють в основному так само.

На що насправді дивляться ці вирази, - це події, які транслюються системою на кшталт "NPC помер" або "взаємодія завершена". Це означає, що ви можете дещо роз'єднати різні частини, ігрові системи просто надсилають події за потребою, які сценарії місії просто слухають події і не хвилюються звідки вони беруться. Якщо ви також дотримуєтесь цього, у вас можливе взаємодія FSM зі світовою державою (показуйте цей контакт лише в стані місії X), ви можете отримати багато енергії з системи.

— кодранжер
джерело