Чому я не взяв Unity чи Unreal, а написав власний рушій і створив симулятор МКС

Всім привіт! Мене звати Ілля Журбенко. Я інді-розробник з Києва. Навчаюся у КАІ (Київський авіаційний інститут) на інженерії програмного забезпечення. Наразі я активно розробляю гру — симулятор МКС під назвою Beyond The Cupola: ISS Simulator.

Коли я починав цей проєкт, то прийняв рішення, яке більшість розробників вважає божевільним — написати власний рушій з нуля на C++. Ця стаття про те, чому я обрав цей шлях, що з цього вийшло і чого я взагалі не очікував.

Я не знав, наскільки це складно — і це зіграло ключову роль

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

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

Мій бекграунд і чому готові рушії мені не підходили

Мабуть, чому я написав свій рушій, а не просто взяв Unreal чи Unity — це найчастіше питання, яке я коли-небудь отримував за ці всі роки, але щоб зрозуміти, чому я обрав такий шлях, треба дізнатися контекст.

Я повсякчас грав та надихався іграми, створеними на власних рушіях, з їхніми унікальними технологіями, атмосферою та фінансуванням. Свій шлях у геймдеві та загалом у програмуванні в мене почався у Minecraft-моддингу. Я обожнював збирати складні збірки, що поступово переросло у бажання навчитися писати свої модифікації та втілювати свої ідеї зі своїм баченням. Так я і почав вчити Java та архітектуру Forge, так для мене почався світ програмування. Що цікаво, моїми улюбленими іграми були серія ігор S.T.A.L.K.E.R. та, власне, Minecraft, обидві написані на власній архітектурі та, звісно ж, на своїх рушіях.

Мені завжди кортіло робити ігри, і коли це бажання переважило, з’явилося перше питання, яке постає на цьому непростому шляху: який рушій використовувати? На той час з двох гігантів Unreal Engine 4 та Unity вибір для мене був більш ніж очевидним: Unreal Engine 4 для мене був більш user-friendly та мав величезну підтримку спільноти.

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

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

Саме тоді виникла ідея: взяти все те що мені було до вподоби у Unreal Engine та в кастомного рушія майнкрафта (з яким я звик доволі багато працювати із середини), втілити свої бажання у світ та створити свій рушій де будуть мої технічні рішення, мова програмування та графічне API яке захочу я, де нічого не буде заважати.

Так ми і прийшли до самого створення.

В процесі переходу від моддингу до створення власного рішення та протягом усієї розробки — мене надихає філософія рушія x-ray, попри однопотокову структуру(що не завжди погано в випадку затримки вводу)

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

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

Практичні переваги:

1. Безпека від читів: Якщо ти пишеш онлайн або просто переживаєш за чесність проходження гри, то в мережі не буде вже готових сервісів чи готових застосунків для зламу твого рушія або гри, в принципі, не буде готових рішень — як без дозволу втручатися у процес гри та використовувати це у своїх цілях.
2. Свобода вибору бібліотек: Повна свобода у виборі фізичних, звукових та мережевих бібліотек: немає передналаштованих застарілих бібліотек, а лише ті, які ти сам обрав зараз, виходячи з багатьох факторів.
3. Гнучкість графіки: Повна свобода у графіці: край можливості — це тільки твої знання. Можна втілити абсолютно все: хочеш — пиши на OpenGL, хочеш — щось по новіше перепиши на Vulkan.
4. Незалежність від корпорацій: Ти нікому не повинен платити за використання, тремтіти над ліцензіями та правилам, не треба підписувати договори, ніхто раптово не змінить умови використання та ціни, як це було з Unity Runtime Fee в вересні 2023 що призвело до великого скандалу навколо інді розробки, і майже унеможливила розробляти гру маленьким інді студіям та інді соло розробникам, переважно яка була саме на цьому рушії. Якщо завтра вийде податок, мито, тариф чи як його б не назвали від іншої найпровіднішої країни світу, вам не доведеться терміново переходити на інші рішення.
5. Точність налаштування: рушій можна заточити під конкретну гру, для реалізації найцікавіших ідей.
6. Абсолютна оптимізація: В рушії немає нічого зайвого, він майже нічого не важить, а фінальна гра виходить максимально легкою
7. Менший поріг входу: зручніший UI/UX без нагромаджених зайвих застарілих речей.

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

Існує багато цікавих рушіїв, які б могли мене задовольнити у свій час, але вони або для власного використання компаній, які їх створили, або відкриті, проте чимось мене в собі не влаштовують. Загалом, розробка свого рушія — це, звісно, брання абсолютно всієї відповідальності на себе або на команду, зі своїми плюсами та мінусами. У вас немає техпідтримки чи індусів на YouTube, які вирішать вашу специфічну проблему за 5 хвилин.

Beyond the Cupola

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

Команда, яка знає що робить

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

Beyond the Cupola — гра яка народилась з цього рушія

Після двох років закритої розробки рушія я відчув, що час перевірити його в реальних бойових умовах. Ідеальною можливістю став хакатон NASA Space Apps Challenge 2025 у Києві. Принести на 48-годинний хакатон власний, ще не до кінця обкатаний рушій — це був величезний ризик, але тематика заходу ідеально підходила для тестування моїх напрацювань у фізиці та графічній візуалізації.

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

Beyond the Cupola

Так і з’явилася Beyond the Cupola — гра, де ти і твоя команда виживаєте в МКС, де все йде шкереберть, і ваша задача — протриматися якнайдовше та виконувати поставлені завдання. Тут ви зможете побачити МКС як зсередини, так і ззовні та відчути, як це бути у невагомості у відкритому космосі.

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

Заходьте на сторінку та додавайте у вішлісти.

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

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

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