Ламаю стереотипи про GameMaker: Як я будую архітектуру гри під 8000 NPC (ECS vs OOP)

Всім привіт! Я TerraMedievale-Dev. І я роблю гру своєї мрії. Ви можете подумати: «О чергова історія де мрійник намагається зробити „Вбивцю ГТА“ де можна заходити в кожен будинок, а потім кидає коли не може закодити скроллбар?» Частково ви праві. У моїй грі дійсно можна буде заходити в кожен будинок 😀.

Але є нюанс. В мене за плечима 3 роки невдалих і кинутих проектів. Я пробував себе в різних жанрах Grand-Strategy, RPG. Де я дійсно брав на себе забагато, не розумів всю архітектуру, не було достатньо досвіду. Але тепер в мене достатньо досвіду для проекту такого масштабу.

Читайте далі і я вам ДОВЕДУ чому 8К НПС це можливо (з краплею магії оптимізації).

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

Що таке Terra Medievale

Terra Medievale — це 2D хардкорний симулятор життя в середньовіччі.

Головна фішка: світ живе без гравця.

Амбіція проекту: Створити симуляцію, де до 8000 НПС мають свої реальні потреби (Їсти, спати, пити), і вони їх дійсно задовольняють, а не лише імітують життя.

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

Моя філософія — Ефект Метелика:

• Приклад: Сталася посуха > Мало врожаю > Лорд не знизив податки > Селяни збунтувалися > Гарнізон перебили > Сусідній лорд захоплює землі.

І ніхто вам не заважає бути цією «посухою» — наприклад спалити поля.

⚠️ Обережно: Далі трохи «підкапотної» магії!

Я розумію, що більшість з вас тут заради геймплейної сторони. Але я мушу пояснити технічну частину, щоб довести: чому 8000 живих НПС у фінальній версії — це не фантастика, а математика.
Якщо вам не цікаво читати про архітектуру пам’яті та оптимізацію — сміливо гортайте вниз до розділу «Структура Світу». Там ми поговоримо про замки, міста і економіку! 😀

Чому 8К НПС це можливо (ECS vs OOP)

Більшість скаже: «Сучасні ААА-ігри задихаються з 50 НПС імітаторами, а ти хочеш зробити 8К ще й з симуляцією життя? Твій процесор згорить»

І вони будуть праві... Якщо ми будемо дивитися з точки зору класичного ООП. В ООП це дійсно неможливо. Але з точки зору ECS (Entity, Component, System) — це не просто можливо, а вже працює (Згадайте Factorio де мільйони предметів їдуть на конвеєрах.

Я вже імплементував чисту ECS-архітектуру. Зараз вона керує інтерактивними об’єктами (Скрині та ін.) та рослинами (близько 20-50 сутностей), але оскільки це просто дані в масивах, масштабування до 8000 для процесора — це лінійна задача, а не експоненційна (як в ООП)

У чому секрет? Уявіть, що замість тисяч важких об’єктів, процесор обробляє просто суцільні масиви даних (немов колонки в Excel):

• В ООП: Щоб додати яблуко в інвентар НПС, процесор змушений завантажити в пам’ять «усю людину»: її спрайт, звуки кроків, здоров’я, історію хвороб. Це величезні витрати ресурсів на одну просту дію.
• В ECS (Мій підхід): У кожного НПС є тільки ID (номер у таблиці). Якщо я хочу змінити інвентар — я звертаюся тільки до компоненту інвентаря. Процесор не чіпає ні графіку, ні здоров’я.

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

AoS (Array of Structures) — Якщо ми хочемо дістати значення X, то наша RAM має ще підгрузити Y, Z, таким чином 66% пропускної здатності пам’яті (Memory Bandwidth) витрачається на сміття, яке процесору зараз не потрібне

SoA (Structure of Array) — Ми просто беремо з глобального масиву значення X. 100% ефективність.

Дані згруповані не по об’єктах, а по Системах. Система Голоду завантажує тільки масив Голоду. Система Рендеру — тільки спрайти. Процесор не чекає, він просто працює.

Структура і Масштаб Світу: 1:1:3:8:40 (Політика та Логістика)

Я часто бачу в RPG дивну демографію: одне величезне місто і два маленькі хутори поруч. З економічної точки зору таке місто померло б з голоду за тиждень.

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

1. Велике Місто (~2000 НПС) Аналог: Оксенфурт (Witcher 3) або Куттенберг (KCD2). Центр торгівлі, влади та ремісничих цехів. Тут крутяться найбільші гроші і найбрудніша політика.
2. Монастир (~200 НПС) Аналог: Сазавський Монастир (KCD). Не варто знецінювати владу церкви. Це центр книгописання, медицини і знань. І так, якщо гравець захоче, він може постригтися в ченці і грати за монаха.
3. 3 Містечка (~150 НПС кожне) Аналог: Сазава (KCD). Регіональні хаби. Менші за Місто, але мають свої ринки. Зазвичай залежні від феодала або церкви.
4. 8 Замків (~100 НПС кожен) Військові бази. Тут може сидіти феодал, чернечий лицарьский орден або навіть барон-розбійник. Вони нічого не виробляють (окрім зброї і смерті), але є головними стовпами влади.
5. 40 Селищ (~50 НПС кожне) Фундамент усього. Тут виробляється їжа, яку споживає вся мапа. Вони найбільш вразливі і завжди залежать від чийогось захисту.

Разом це дає ~5500 постійного населення. Решта до 8000 — це динамічні гарнізони, армії лордів, каравани та бандити, які наповнюють світ.

Щодо розмірів мапи: На релізі я планую безшовний регіон 1.5К х 1.5К тайлів з процедурною генерацією ландшафту.

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

Що вже зроблено

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

• UI Framework: Я вбив 2 тижні лише на те, щоб закодити свій Скролбар 😂. Але це дало результат: тепер у мене є гнучка система інтерфейсу, яку легко редагувати і масштабувати.

  

• Приклад зробленого Інвентарю (Повністю функціональний)
• Інвентар: Система предметів, спорядження, ваги та стаків.
• Навички (Skills): Система навичок, атрибутів і перків.
• Землеробство: Повний цикл вирощування (від оранки до збору).
• Ремесла (Crafting): Система рецептів і виробничих ланцюжків.

Що залишилося до Демки (Roadmap)

Мій план до релізу Демо чіткий:

• Будівництво: Система розміщення стін та меблів (щоб НПС та гравець мали де спати).
• Бойовка: Проста бойова система.
• Штучний Інтелект (GOAP): Найважливіший етап. Навчити «болванчиків» користуватися всіма цими системами самостійно.
• Візуал та Флейвор: Замінити «квадрати» на арт і додати атмосферні описи.

КОЛИ ДЕМО

Якщо вас зацікавила моя гра, у вас виникає логічне питання: «КОЛИ?». Я соло-розробник, і для мене це марафон, а не спринт. Я ставлю якість вище за швидкість, тому орієнтовна дата виходу публічної Демо — 2026 рік.

Чим Демо відрізнятиметься від повного Релізу? Це буде Vertical Slice (Вертикальний Зріз) гри:

• Мапа: Замість процедурної генерації — один детально пророблений вручну регіон (1 Замок, 3 Села).
• Геометрія: У демо світ поки що буде «плоским» (без Z-рівнів/висоти), щоб я міг сфокусуватися на відшліфуванні економіки та ШІ.

Але це не буде «обрізок» на 15 хвилин. Це буде повноцінна пісочниця з усіма основними системами (Крафт, Агрономія, Соціум). Демо буде безкоштовним, доступним завжди і отримуватиме оновлення механік паралельно з розробкою.

Стежте за розробкою

Якщо ви дочитали до кінця — значить, вам цікаві складні системи так само, як і мені.

Я запрошую вас у свій Discord-сервер. Там я буду:

• Публікувати ексклюзивні скріншоти, які не потраплять у статті.
• Радитися з вами щодо механік (ваша думка вплине на гру).
• Набирати перших тестерів для закритих білдів.

👉 Приєднатися до Discord: discord.gg/DSvhXSsx6f

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев