Навіщо потрібен Nexus

Навіщо Nexus

Робити ігри складно

Роки розробки. Щоразу - винахід механік і вибудовування їх у системи. Хочеш додати голод - пишеш систему голоду. Хочеш, щоб голод спричиняв міграцію - додаєш міграцію і вибудовуєш між ними зв'язки. Хочеш, щоб міграції спричиняли війни - ще один зв'язок, ще один код, ще місяці роботи.

Кожна нова механіка множить складність. Не тому що ідея складна, а тому що розробка так влаштована: кожен зв'язок між системами - це окремий код, окреме налагодження, окрема підтримка. Чим глибший світ - тим більше зв'язків - тим складніше все утримати.

Найглибші ігри в індустрії розробляються десятиліттями. Ціна глибини світу - роки роботи.

Копіювання механік

З року в рік виходить більше відеоігор. З генеративним ШІ цей потік пришвидшиться. Гравців теж стає більше, але не так швидко. Конкуренція за кожного гравця зростає.

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

Навіть ігри-пісочниці лишаються набором окремих жорстких систем. Різноманітність - за рахунок кількості систем, а не за рахунок іншого підходу до самої архітектури.

Класичний підхід та його межі

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

Три основних підходи до розробки:

  • Експериментування, "гра мрії" - максимально оригінальні проєкти. Ризиковано, але дає шанс створити незвичайний хіт.
  • Клонування - виробництво ігор з мінімальними змінами. Найменш ризикований шлях.
  • Проміжний варіант - поєднання перевірених ідей і нових елементів. Так працює більшість розробників.

Який шлях не обирай - процес лишається еволюційним. Береш ідею, яка виглядає перспективною прямо зараз, і намагаєшся реалізувати. Підсумок заздалегідь невідомий. Навіть після успішної гри наступна фактично починається з нуля. Гроші та перевірені схеми не гарантують результат.

Але головна проблема навіть не в цьому. Класичний підхід не масштабується вглиб. Складність зростає не пропорційно кількості систем, а значно швидше - через зв'язки між ними. Тому глибокі світи на класичному підході потребують десятиліть.

Інший підхід

Я використав концепцію Ідеального Кінцевого Результату з інженерного методу ТРВЗ. Суть: успішний проєкт - не результат перебору, а результат точної постановки задачі.

Перший крок - поставити мету. Чого я хочу? Який ідеальний кінцевий результат? Чим точніша мета, тим простіше оцінювати будь-які ідеї та тренди.

Ідеальна гра як орієнтир

Ідеальну гру зазвичай описують як симуляцію, нерозрізнювану від реальності, де гравець може робити що завгодно. З цього визначення випливають вимоги:

  • Гравець може бути учасником подій або спостерігачем
  • Немає заздалегідь заданих жанрів - гра підлаштовується під запити
  • Немає поділу на одиночну та мережеву гру
  • Світ реагує природно, без скриптів. Рутинний похід до крамниці може перетворитися на пригоду.

Створити таку гру зараз неможливо. Але вона задає напрямок.

Будь-яку нову ідею чи механіку можна "приміряти" до цієї лінії. Чи лягає вона на курс, чи відводить убік, чи повертає назад. Ідеї ближче до ідеальної гри мають більший потенціал.

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

Зростаючі очікування гравців

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

Але чим більше свободи та глибини - тим складніша розробка. Найперспективніші напрямки виявляються найважчими.

Рішення: плоска складність

Я вирішив створити систему, в якій складність не зростає з кількістю механік. Як будівельні блоки: камінь, дерево, цегла. Можна побудувати замок з мільйона блоків, і сама система не ускладнюється. Блоки однакові. Правила однакові. Зростає лише кількість, не складність. Nexus застосовує той самий принцип до всіх ігрових механік.

Додавання нової механіки не повинно ускладнювати систему. Не новий код, не нова підсистема - а новий факт у тій самій плоскій структурі.

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

Формальна мова фактів масштабується без зростання складності. Десять фактів про світ і десять тисяч фактів - та сама структура, ті самі правила, той самий рушій.

Nexus будується на фактах (твердженнях про світ), а не на коді (інструкціях для комп'ютера). Факти можна додавати, прибирати, комбінувати - і світ перебудовується сам.

Чому саме так

Причинно-наслідкові ланцюжки замість скриптів. У звичайній грі "засуха → голод" - це скрипт, написаний руками. У Nexus це факти: "засуха зменшує траву", "немає трави → голод травоїдних", "голод → міграція", "міграція → зіткнення". Кожен факт простий.

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

Існуючі платформи будують світи зі скриптів і редакторів. Nexus будує світи з фактів - тверджень про те, як світ працює.

Досвід Clarus Victoria

За 13 років Clarus Victoria випустила сім ігор - від історичних стратегій Stone Age і Egypt: Old Kingdom до фентезійної RPG Next Run. Кожна покривала вузький сетинг з обмеженим набором механік. Увесь цей час гравці просили: зробіть інші епохи, зробіть Рим, Китай, Межиріччя. І справді, хотілося їх зробити.

Все йшло непогано, поки епохи були маловивченими. Але коли справа дійшла до періодів з великою кількістю джерел і механік - старі підходи перестали справлятися. На класичному підході це вже не роки розробки, а десятиліття. Тому я почав робити Nexus.

Михайло Васильєв