Clarus Victoria

Nexus

1. Загальне

1.1. Про документ

Мета цього документа - окреслити позицію та намір Clarus Victoria щодо того, які ігри ми хочемо створювати і яким шляхом до цього йти.

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

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

Документ призначений для гравців, яким цікаве загальне бачення проєкту Nexus та напрямок роботи Clarus Victoria, а також для розробників, які бажають краще зрозуміти принципи та механіки нової системи.

1.2. Про проєкт

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

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

Nexus - це не ще один Roblox чи Garry's Mod. У більшості подібних платформ світи збирають зі скриптів і редакторів. У Nexus світи будуються на основі мови, близької до людської. З її допомогою формуються сенси, правила та наповнення. Такий підхід дає більше гнучкості та свободи у виборі того, у що і як грати.

1.3. Структура документа

Документ структуровано у вигляді нумерованих розділів для зручної навігації та обміну посиланнями.

Загальна структура включає такі розділи:

  • Розділ 1 - вступний. Містить загальну інформацію про проєкт Nexus та про цей документ.
  • Розділ 2 - описує набір ідей про те, яким може бути проєкт Nexus після його реалізації.
  • Розділ 3 - містить ідеї та підходи, що дають змогу технічно реалізувати проєкт.
  • Розділ 4 - дорожня карта: послідовність кроків, необхідних для створення проєкту.
  • Розділ 5 - виклики: ризики та обмеження проєкту, а також підходи до їх розв'язання.

Усі розділи, крім розділу 3, розраховані на широке коло читачів.

Розділ 3 більшою мірою орієнтований на фахівців та розробників ігор.

Документ має модульну структуру і може читатися вибірково, без суворого дотримання порядку розділів.

1.4. Про автора

Автор документа - Васильєв Михайло, засновник, геймдизайнер та розробник студії Clarus Victoria.

Документ відображає бачення автора і оновлюватиметься в міру розвитку проєкту.

2. Концепт ідеї

2. Концепт ідеї

2.1. Мета розділу

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

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

2.2. Початок гри

У головному меню гри представлено інтерфейс, що віддалено нагадує YouTube, але замість відеороликів тут відображаються ігрові сценарії.

Основу екрана складають блоки рекомендацій та розділ історії.

Також доступні додаткові функції: списки сценаріїв, позначених як уподобані, і тих, до яких користувач планує повернутися пізніше.

2.2.1. Створення гри через рекомендації

Якщо це ваш перший запуск, гра запропонує вам тренди у різних категоріях із різними популярними сценаріями.

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

Наприклад, якщо вам подобаються Стародавній Рим, космос і перегони, то в рекомендаціях можуть з'явитися теми:

«Імператор Траян», «Падіння Риму», «Стародавні германці», «Колонізація Марса», «Траса Монца», «Реактивні двигуни».

Ви можете обрати будь-яку тему.

2.2.2. Завантаження гри

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

Збереженнями можна ділитися з іншими гравцями.

2.2.3. Налаштування сценарію

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

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

2.2.4. Генерація гри

На основі обраного сценарію формується ігровий світ, що відповідає заданій темі.

Навіть за однакових рекомендацій початкові умови можуть різнитися, через що кожен початок відчувається унікальним.

За бажанням можна задати «сід гри», щоб відтворити схожі стартові умови при новому проходженні.

2.3. Світ

2.3.1. Правила

Універсальні правила світу — це загальний набір закономірностей, який в ідеальному образі підходить для рольових та стратегічних ігор.

Через них також можуть бути описані й інші жанри - екшен, спорт, перегони, пригоди та їхні піджанри.

Ідеться не про конкретні механіки, а про принципи, що дають змогу виразити логіку більшості ігрових світів.

2.3.2. Жанри

У грі немає жорстких жанрів, що обмежують механіки. Натомість жанри існують як модулі, які можна поєднувати та налаштовувати, подібно до конструктора.

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

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

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

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

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

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

2.3.3. Знання як основа гри

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

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

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

2.3.4. Події

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

Світ не чекає, доки ви втрутитеся й заявите про себе. Історія світу не задається наперед і не будується на скриптах. Вона складається з вашого вибору, дій інших сутностей, законів світу та випадковості. Якщо сценарій має історичну основу, події повторюються не тому, що так «запрограмовано», а тому що ті самі причини знову призводять до тих самих наслідків - як криза бронзового віку, що виникла каскадом змін, спричинених кліматом.

2.3.5. Наслідки рішень гравця

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

Чим сильніший вплив, тим масштабніші наслідки. Можна змінити русло ріки й прискорити час на століття, щоб побачити, як змінюється ландшафт. Можна здійснити подвиг, зникнути на тисячу років і повернутися в нову епоху, де ваше ім'я стало міфом.

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

2.3.6. Мотивація

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

  • Тривала відсутність поруч із коханою людиною може тяжко позначатися на стані персонажа та змінювати його рішення.
  • Фараон може наказати візирю збудувати піраміду, і для візиря це стане визначальним завданням.
  • Олені шукають їжу, розмножуються та уникають хижаків.
  • Злочинний синдикат прагне розширити вплив і захопити нові території.

2.3.7. Драматургія

У повністю симульованому світі можливі тривалі «тихі періоди». Якщо грати за фермера, можна прожити десять років без воєн, катастроф і великих змін.

Якщо мета - чесно прожити роль з усіма її порожніми днями, світ можна залишити таким, який він є.

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

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

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

2.3.8. Зміна правил гри

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

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

Можна експериментувати із самими основами та створювати світи, що суперечать звичній логіці: світи парадоксів, задзеркалля, інші всесвіти зі своїми законами фізики та устроєм реальності.

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

Зліпок поточного світу може стати основою для нової гри. Один гравець, діючи в ролі «бога», здатен створити світ, у якому житимуть інші. Це схоже на мод або редактор карти, але вбудовано в саму логіку універсальної гри.

2.4. Ігровий процес

2.4.1. Відіграш ролі

Хотіли б ви стати найбагатшою людиною?

Отримати надздібності та жити вічно?

Підкорювати космос?

Потрапити в минуле зі знаннями сьогодення?

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

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

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

2.4.2. Мета гри

Мета гри може задаватися сценарієм, вами або поєднанням того й іншого, а може бути відсутня взагалі. Вона може бути будь-якою: від повсякденного завдання до епохального звершення - отримати роботу мрії або винайти «філософський камінь».

Досягнення мети не завершує гру: світ продовжує жити, і ви можете залишатися у ньому стільки, скільки забажаєте.

2.4.3. Динамічна зміна ролі

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

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

2.4.4. Дії гравця

Доступні вам дії відповідають поточній ситуації та особливостям вашого персонажа. Вони формуються контекстом того, що відбувається, і тим, ким ви є в даний момент.

Наприклад, при пожежі зазвичай проявляються очікувані можливості: тікати, гасити вогонь, допомагати іншим. Однак ви можете вчинити інакше й, приміром, сприяти поширенню вогню.

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

2.4.5. Авто та ручне керування

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

Якщо ви обираєте роль лідера та взаємодієте з групами істот, керування сприймається не як прямий контроль, а як система прохань, наказів та очікувань.

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

2.4.6. Спостереження

Ви можете не грати напряму. Створіть цікавого персонажа, помістіть його в незвичну ситуацію, задайте бажаний рівень драматургії (див. пункт 2.3.7. Драматургія) та спостерігайте за тим, як розвиваються події.

Такий досвід може нагадувати перегляд фільму, де історія розгортається сама.

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

Цей режим підходить не лише для розваг, а й для моделювання: ви можете створити, приміром, «цивілізацію черепашок» і простежити, як вона проходить шлях від кам'яного віку до польотів у космос.

2.5. Ігрова взаємодія

2.5.1. Камера та відображення

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

Універсальна гра не прив'язана до одного способу представлення і може виглядати так, як зручніше вам у даний момент.

Навіть незряча людина зможе взаємодіяти зі світом, сприймаючи об'єкти та події через звук і опис.

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

2.5.2. Графіка та звук

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

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

У постапокаліптичному сетингу графіка та звук передають крихкість виживання, почуття втрати й рідкісну надію на новий початок.

У світі кажана простір сприймається інакше: масштаб і форма відчуваються через звук, а не через зір.

2.5.3. Карта

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

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

При наближенні проявляються деталі, при віддаленні вони зникають, поступаючись місцем крупнішим структурам і зв'язкам.

2.5.4. Час

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

Прискорення особливо доречне при грі за істот з іншим сприйняттям часу - рослини чи довгоживучі форми життя.

Час можна зупиняти, прискорювати, пропускати або повертатися назад. За бажанням можна грати в покроковому режимі, не поспішаючи з прийняттям рішень.

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

2.5.5. Гра мережею

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

2.6. Універсальність

2.6.1. Значення

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

Це можливо тому, що будь-яка гра є набором правил, а правила можуть бути описані через прості смислові твердження (триплети).

Приклади:

Dark Souls (у термінах правил):

  • Смерть -> спричиняє -> втрату_душ
  • Вогнище -> є -> точка_відродження
  • Ворог -> складність -> висока
  • Удар -> залежить_від -> витривалість

Civilization (у термінах правил):

  • Хід -> тривалість -> залежить_від_епохи
  • Місто -> виробляє -> [юніти, будівлі]
  • Перемога -> умови -> [наукова, військова, культурна]

The Sims (у термінах правил):

  • Персонаж -> потреби -> [голод, сон, соціалізація]
  • Потреба_низька -> спричиняє -> поганий_настрій
  • Дія -> задовольняє -> потребу

2.6.2. Мікси жанрів

Оскільки правила оформлюються як модулі, їх можна комбінувати. Це дає змогу збирати нові ігрові формати з уже відомих наборів правил.

Приклади:

Dark Souls + Civilization:

  • Керуєте королівством Лордран як цивілізацією.
  • Бої та зіткнення відбуваються за правилами Dark Souls (навичка, таймінг, небезпека).

The Sims + зомбі-апокаліпсис:

  • Повсякденні потреби сімів (їжа, сон, соціалізація).
  • Поверх них додаються правила виживання (укриття, зброя, небезпека).

Принцип універсальності: якщо ігрову логіку можна виразити словами, її можна реалізувати в Nexus.

2.7. Приклад

2.7.1. Ситуація у світі

Гравець - селянин Іван у селі Заріччя. Голодний, його дружина вагітна, сусід Петро загубив корову. Насувається дощ.

2.7.2. Як система це розуміє (триплети)

Всередині системи ця ситуація описана набором простих тверджень:

  • Іван -> є -> селянин
  • Іван -> голод -> 30% (або Іван -> ситість -> 30%)
  • Іван -> перебуває_в -> Заріччя
  • Мар'я -> відношення -> дружина_Івана
  • Мар'я -> вагітна -> 8_місяців
  • Корова -> належить -> Петро
  • Корова -> місцезнаходження -> ліс
  • Погода -> наближається -> дощ

Кожне твердження - атом знання. Разом вони формують поточний стан світу.

2.7.3. Як гравець це бачить

Логіка відокремлена від візуалізації та залишається незмінною.

Залежно від режиму відображення, одні й ті самі триплети показуються по-різному.

Детальніше про Мову UX у розділі 3.9.

2.7.3.1. Текстовий режим

«Ти - Іван, селянин. Живіт бурчить від голоду. Дружина Мар'я ось-ось народить. Чуєш крики сусіда - його корова втекла. На обрії дощова імла.»

2.7.3.2. Режим hex-карти з іконками

  • Тайл села з об'єктами: 🏠 (дім), 🏚️ (амбар), 💧 (струмок)
  • Персонаж: 👤 Іван [🍞30% червоний]
  • Родина: 👩 Мар'я 🤰 ~30 днів
  • Подія: 🏠 Петра 🔊, сліди 🐾🐾 -> 🌲
  • Ефект: 🌧️ наближається

2.7.3.3. 3D-режим

Повноцінне село, модель Івана тримається за живіт, Мар'я сидить біля дому, вдалині чутно крики та видно зламану огорожу, темні хмари на обрії.

2.7.4. Дія гравця

Гравець формулює намір: «Допомогти Петру знайти корову»

Ця дія перетворюється на триплети:

  • Іван -> намір -> допомогти
  • Допомогти -> кому -> Петро
  • Допомогти -> завдання -> знайти_корову

Система інтерпретує:

1. Іван може допомогти? -> Так (фізично здоровий, перебуває поруч)

2. Це потребує часу? -> Так (~1 година)

3. Це вплине на голод? -> Так (посилиться)

4. Що відбудеться? -> Пошук у лісі, ймовірність знайти корову

2.7.5. Результат

Через годину ігрового часу:

  • Корова -> місцезнаходження -> знайдена_біля_струмка
  • Іван -> голод -> 20% (посилився)
  • Петро -> ставлення_до_Івана -> вдячність +10
  • Петро -> зобов'язання -> допомогти_з_дахом

Візуально:

  • Гравець бачить анімацію повернення з коровою
  • 🍞 20% (ще червоніший)
  • Спливає сповіщення: «Петро вдячний. Обіцяв допомогти з дахом.»

2.8. Від концепції до реалізації

Розділи 2.1-2.7 описали бажаний образ Nexus з точки зору гравця: що він бачить, як взаємодіє зі світом, які можливості отримує.

Ключові принципи:

  • Будь-яку ігрову ситуацію можна описати словами.
  • Слова можна формалізувати як триплети (прості твердження).
  • Триплети можна інтерпретувати (робити висновки).
  • Результат можна візуалізувати будь-яким способом.

3. Концепт реалізації

3. Концепт реалізації

3.1. Мета розділу

Розділ присвячений ідеям про те, як проєкт Nexus може бути реалізований технічно та як він може бути влаштований зсередини.

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

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

Розділ орієнтований передусім на фахівців та розробників комп'ютерних ігор.

3.2. Гнучкий підхід

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

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

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

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

3.3. Семантична мережа

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

Триплет - це просте твердження формату «суб'єкт - предикат - об'єкт». Наприклад:

  • Яблуко - є - їстівним
  • Яблуко - має поживність - 5
  • Людина - може їсти - фрукти
  • Трава - росте - при вологості вище певного рівня
  • Олень - є - травоїдним
  • Синдикат - контролює - район міста

Через триплети може бути описано все: об'єкти, їхні властивості та стани, відносини між ними, можливі дії, ігрові правила, технології чи магія.

Це подання знань, не прив'язане до конкретної ігрової реалізації. Ідеться не просто про формат зберігання даних, а про спосіб опису сенсу світу.

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

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

3.4. Інтерпретатор

Над рівнем даних працює інтерпретатор. Він може спиратися на логічні системи (наприклад, Apache Jena) або на нейромережеві підходи.

Його завдання - обробляти триплети та виконувати логічні висновки. Наприклад:

  • Яблуко - є - фруктом
  • Людина - може їсти - фрукти
  • Висновок: людина може їсти яблука

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

У межах гри інтерпретатор використовується для наповнення світу та визначення допустимих дій. Він відповідає на запитання на кшталт:

  • Які дерева можуть рости в тропічній пустелі Аравії.
  • Які дії люди можуть здійснювати стосовно собаки в ранньому кам'яному віці та в Новий час.
  • Які об'єкти доступні сприйняттю гравця в поточний момент.

Інтерпретатор розбиває такі запитання на простіші запити до даних і зводить їх до єдиного семантичного подання, на основі якого формується відповідь.

Інтерпретатор працює з уже формалізованими запитами і не взаємодіє з природною мовою напряму.

3.5. Семантичний ECS

Щоб світ універсальної гри міг функціонувати на основі семантики, логіки та великих масивів фактів, йому потрібна архітектура, здатна описувати об'єкти та їхні властивості максимально гнучко, без жорсткого хардкоду.

Це завдання вирішує, наприклад, семантичний ECS - різновид класичного ECS, адаптований для подання знань та відносин між сутностями. У цьому контексті ECS розглядається передусім як модель даних, а не як цикл оновлення систем, і використовується як практична точка входу, а не фінальна архітектура.

В основі світу перебувають сутності: персонажі, предмети, тварини, організації, кораблі, рослини. Як і в класичному ECS, сутність сама по собі не містить логіки й даних, вона слугує ідентифікатором, до якого прив'язуються компоненти.

Ключова відмінність полягає в устрої компонентів. У традиційному ECS компонент — це структура з набором полів. У семантичному ECS замість великих компонентів використовуються компоненти-предикати: «Є», «Має», «Містить», «Може», «Належить до» тощо. Кожен такий предикат виражає один зв'язок або одне твердження про світ.

Наприклад, сутність «Яблуко» може мати компонент-предикат «Є», що вказує на сутності «Фрукт» і «Їстівне». При цьому «Їстівне» також є сутністю, що має власні властивості: «Має - Поживність», «Має - Смак». Кожен компонент-значення зберігає рівно одне значення, наприклад: «Поживність = 5», «Смак = солодкий», «Вага = 0.2».

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

Для забезпечення продуктивності використовуються кешування, індекси та механізми рівня деталізації (LOD, див. нижче).

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

3.6. Ігрові правила

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

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

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

Такий підхід частково нагадує устрій ігрових рушіїв. Наприклад, Unity Engine або Unreal Engine знімають з розробників необхідність реалізації низькорівневих функцій. Однак тут ідеться не про технічну реалізацію, а про універсальні ігрові правила. Близькі ідеї можна зустріти у настільних системах на кшталт GURPS, а також у складних пісочницях на кшталт Minecraft, Dwarf Fortress чи RimWorld, де частина правил уже має універсальний характер.

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

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

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

3.7. Абстракції та LOD

3.7.1. Обмеженість сприйняття та необхідність абстракцій

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

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

3.7.2. Масштабування часу та простору

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

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

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

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

3.7.3. Матеріалізація світу

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

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

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

Для великих часових інтервалів використовуються статистичні тенденції. Наприклад, відомо, що астероїди розміром близько кілометра стикаються із Землею приблизно раз на мільйон років. Існують моделі, що оцінюють ймовірність зникнення технологічної цивілізації в горизонті тисяч років. Ці оцінки не задають точний результат, а визначають діапазон можливих сценаріїв. Тому при переміщенні гравця вперед на тисячу років система обирає один із правдоподібних варіантів майбутнього - руїни цивілізації, сталий розвиток чи інший узгоджений сценарій.

3.7.4. Гра мережею

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

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

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

3.8. Агенти та симуляція світу

Будь-яка сутність у світі - людина, тварина, організація чи держава - розглядається як агент із власними цілями, мотивацією та станами. Агент:

  • Сприймає світ у межах своїх знань.
  • Оцінює доступні варіанти дій.
  • Приймає рішення, спираючись на свої цілі та правила світу.
  • Запускає події, що змінюють стан світу.

Світ загалом працює як багатошарова симуляція:

  • Природа змінюється під впливом клімату та доступних ресурсів.
  • Екосистеми реагують на зміни середовища.
  • Люди та суспільства відповідають на зміни природи, технологій і політики.
  • Гравець вступає в цей процес як одна із сутностей світу.

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

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

3.9. Мова UX

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

Кожен стан інтерфейсу або карти можна розглядати як запитання: «Що я бачу зараз?», а набір доступних дій - як запитання «Що я можу зробити в поточній ситуації?». Гра, аналізуючи стан світу, положення аватара гравця та передбачуваний об'єкт взаємодії, формує відповідь у вигляді нового стану світу та нового відображення інтерфейсу.

У найпростішому вигляді мова - це позначення речей, сприйнятих у світі: «дерево», «мати», «сонце».

На наступному рівні мова дає змогу описувати їхні властивості та стани: «злий чоловік», «багато зірок», «сильний лев», «300 спартанців».

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

Кожному слову або поняттю відповідає іконка.

Властивості об'єктів виражаються візуальними прийомами:

  • «Злий», «погано», «негативно» - червона підкладка іконки.
  • «Багато», «300», «мільйони», «нескінченно» - міні-піктограма множини з конкретним або абстрактним числовим значенням.
  • «Сильний», «небезпечний», «потужний», «рівень 3» - окрема міні-піктограма рівня із зазначенням значення.
  • Колір рамки може показувати належність сутності іншому гравцеві або фракції.

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

Для складніших або рідкісніших характеристик використовуються допоміжні іконки поруч з основною сутністю або вкладені всередину неї зі зменшеним масштабом.

Іконки можуть бути анімованими, додаючи додатковий шар інформації. Наприклад, при критично низькому здоров'ї серце на іконці може битися нерівно й слабко, вказуючи на небезпечний стан.

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

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

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

Сама дія формується з базової мовної конструкції.

У своїй основі ігрова мова спирається на семантичні триплети: суб'єкт - дія - об'єкт.

Приклади:

  • «Я - хочу - яблуко»
  • «Ми - оголошуємо війну - вам»
  • «Ми - атакуємо - плем'я Білого Пера»

В інтерфейсі це виглядає як вибір суб'єкта (аватар гравця чи інша сутність), виділення об'єкта та вказівка дії.

Конструкцію можна ускладнювати, додаючи модифікатори: час, прикметники, умови.

Наприклад: «Раб (суб'єкт) - будувати (предикат) - піраміду (об'єкт) - швидко (доповнення предиката)».

Модифікатор «швидко» означає застосування особливих правил: робота виконується швидше, але зростає ризик нещасних випадків або знижується якість результату.

Якщо дія спрямована не на самого аватара, а на іншого суб'єкта, вона інтерпретується як прохання або наказ.

4. Дорожня карта

4. Дорожня карта

4.1. Стратегічне бачення

Цей розділ описує план реалізації проєкту Nexus.

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

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

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

З часом такі проєкти ставатимуть складнішими та якіснішими, а один із них зрештою може перерости у повноцінний проєкт Nexus, описаний у розділі 2.

Розробка Nexus розбивається на серію етапів-проєктів.

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

Порядок етапів не є жорстко зафіксованим. Дорожня карта задає загальний напрямок розвитку проєкту, а не детальний план.

У міру розробки етапи та завдання можуть уточнюватися й доповнюватися.

4.2. Етапи

4.2.1. Етап 0. Формування розуміння універсальної гри (виконано)

Робота студії Clarus Victoria з 2013 року, випуск шести проєктів, а також багаторічні дослідження, експерименти та створення прототипів дали змогу сформувати базове розуміння того, якою може бути універсальна гра та які принципи лежать в її основі. Результатом цього етапу стало формування цього документа.

4.2.2. Етап 1. ECS та уніфікація сутностей (виконано)

  • Перевірено архітектуру ECS на базі проєкту Next Run. Сутності подані як порожні контейнери з набором компонентів, що дає змогу гнучко формувати об'єкти світу: предмети, істоти, біоми, події та ефекти.
  • Перевірено низку ідей, пов'язаних з універсальними ігровими механіками, зокрема об'єднання RPG та стратегії без жорсткого поділу.
  • Уперше для студії впроваджено та протестовано гексагональну карту, що дала змогу швидко створювати та комбінувати різні типи ігрових світів.
  • Уперше для студії додано підтримку модифікацій через Steam Workshop.

Докладніше про цей етап - у статті: https://clarusvictoria.com/blog/almost-ten-years-of-search

4.2.3. Етап 2. Геймплей реального світу (у розробці)

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

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

Особливості для реалізації:

  • Еволюція суспільств: від примітивної людини, що стоїть в одному ряду з тваринами та живе за тими самими правилами виживання, до появи перших цивілізацій.
  • Біоми та екосистеми тайлів: голод, міграції та конкуренція за ресурси. Рослини, тварини та особливості місцевості безпосередньо впливають на виживання людей.
  • Ігрові ситуації та події, що виникають як результат ігрових правил, а не наперед заданих скриптів. Наприклад, нестача ресурсів може призводити до конфліктів між групами людей та нападів хижаків.
  • Автоматизація дій юнітів або ручне керування - на вибір гравця, зокрема керування групами через загальні правила поведінки. Можливість як активної гри, так і спостереження.
  • Можливість грати як окремими персонажами, так і групами.
  • Кілька гравців на одній карті, що конкурують між собою.
  • Повернення дерева технологій, знайомого з попередніх ігор Clarus Victoria.
  • Налаштовуваний ігровий світ: розмір карти, епоха, клімат та особливості регіонів.
  • Перші версії агентної моделі.
  • Можливий сетинг світу: кам'яний та бронзовий віки.

4.2.4. Етап 3. Семантична архітектура (у планах)

Одним із ключових кроків для зниження ризиків проєкту Nexus є перехід на семантичну основу архітектури гри (див. розділи 3.3-3.5).

На цьому етапі всі системи вводяться на базовому рівні, з мінімальним функціоналом:

  • Семантичні триплети як спосіб опису сутностей в ігровому світі.
  • Інтерпретатор.
  • Перехід від класичного ECS до семантичного ECS.
  • Базові правила роботи нової архітектури.
  • Можливий сетинг світу: одна з ранніх цивілізацій.

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

4.2.5. Етап 4. Агентська модель (у планах)

На цьому етапі передбачається реалізація критичних систем, які вважаються надто ризикованими для впровадження на етапі 2. Ідеться про глибоке опрацювання суб'єктів у межах агентської моделі. Етап 2 готує для них ґрунт, але на етапі 4 агенти повноцінно реалізуються.

Архітектура гри починає підтримувати складніші процеси реального світу, що дає змогу моделювати суспільства вищого рівня складності порівняно з етапом 2.

Особливості для реалізації:

  • Повноцінна агентська модель поведінки: сутності отримують цілі, стани та мотивації.
  • Система прохань і наказів суб'єктам, де виконання не є гарантованим і залежить від поточного стану та контексту.
  • Збільшення наповненості світу, ускладнення систем та логіки об'єктів.
  • Індивідуальні інвентарі у суб'єктів, логістичні ланцюжки та система транспорту.
  • Винесення частини ігрової логіки з хардкоду в Lua для можливості створення складних модів гравцями.
  • Можливий сетинг світу: стародавній світ.

4.2.6. Етап 5. Абстракції та LOD (у планах)

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

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

Порядок реалізації етапу може бути скоригований у процесі розробки.

4.2.7. Етапи 6+. Ключові функції рушія Nexus (у планах)

Етапи 1-5 формують базовий функціонал Nexus. Починаючи з етапів 6+, розвиток проєкту зміщується у бік розширення можливостей рушія, додавання масштабованих функцій, деталей та контенту, описаних у розділах 2 та 3.

На цих етапах передбачається розвиток та впровадження таких напрямків:

  • Масштабування часу та простору, рівні деталізації та абстракції.
  • Мережева гра.
  • Генерація ігрових сценаріїв та конфігурацій.
  • Підтримка різних режимів візуалізації: від виду від першої особи до глобального масштабу.
  • Адаптивні інтерфейси та звук під різні стилі гри та рівні занурення.
  • Додаткові функції, описані у розділах 2 та 3.

4.2.8. Nexus 1.0 (у планах)

Момент виходу Nexus 1.0 визначається досягненням базової реалізації ключових ідей та функцій, описаних у розділах 2 та 3.

5. Виклики

5.1. Висока обчислювальна складність

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

Відповідь: Це розв'язується за допомогою правил абстракцій та LOD. Обраховуються лише ті сутності, з якими гравець тією чи іншою мірою взаємодіє. Детальніше див. пункт 3.7.

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

5.2. Розмитий ігровий фокус

Виклик: Універсальність Nexus може призвести до відсутності чіткого ігрового фокусу та відчуття мети, коли гравець сам змушений вигадувати, у що саме він грає. Можна все, але не зрозуміло, навіщо.

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

5.3. Ризик незавершеності проєкту

Виклик: Через масштаб і складність Nexus існує ймовірність, що проєкт довго перебуватиме у розробці й не дійде до чітко зафіксованого завершеного стану. Ззовні це може сприйматися як проєкт рівня AAA, що потребує значних фінансових ресурсів та великої команди.

Відповідь: Nexus розвивається як єдиний продукт через послідовні етапи з регулярними релізами та конкретними результатами, кожен з яких наближає проєкт до версії 1.0. Розробка не ведеться у форматі «тривалого прототипу», а є поступальним рухом із завершеними проміжними версіями та результатами, що піддаються перевірці. Критерії успіху та зворотний зв'язок із гравцями дають змогу утримувати проєкт у заданому напрямку.

5.4. Складність налагодження та контролю логіки

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

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

5.5. Ризик відсутності раннього фокусу

Виклик: Широта концепції Nexus на ранніх етапах може утруднити формування чіткого MVP, перевірку інтересу у конкретної аудиторії та розуміння того, для кого саме створюється проєкт, що підвищує ризик інвестування ресурсів в архітектуру до підтвердження ігрової цінності.

Відповідь: У Clarus Victoria є сформована ніша та аудиторія, з якою студія працює понад десять років. Замість окремого абстрактного MVP використовуються самостійні проєкти зі зрозумілим та знайомим гравцям геймплеєм. З кожним новим проєктом цей геймплей поступово розширюється та ускладнюється, наближаючись за напрямком до Nexus 1.0. Критерієм успіху слугують відгуки гравців та відповідність результатів заявленому напрямку розвитку.

Остання зміна документа: 18.01.2026

Nexus - бачення проєкту | Clarus Victoria