Впервые о намерении VK создать отечественный аналог движков Unity или Unreal Engine стало известно в 2022 году. Теперь компания подробнее рассказала о своём творении, которое назвала Nau Engine.
По словам девелоперов, Nau Engine представляет собой open-source движок, который подойдёт как для разработки игр, так и для производства медиа-контента. Специалисты обещают предоставить «мощное ядро» с удобным редактором.
Созданием Nau Engine руководит Александр Мясищев — он занимается разработкой на протяжении 14 лет. Он поделился, что в новом движке будет содержаться целый комплекс инструментов, благодаря которому получится не только собрать игру, но и донести её до пользователей, а также облегчить пострелизную поддержку проекта. Мясищев и его команда намерены «упростить вход для любого разработчика», чтобы период от старта обучения работы с движком до воплощения идеи исчислялся не годами, а всего лишь днями.
Если верить авторам Nau Engine, движок позволит делать проект сразу для нескольких платформ, среди которых ПК, консоли, мобильные устройства и даже браузеры. Инструмент будет выполнен по принципу открытого кода и будет доступен для специалистов с любой квалификацией. Также девелоперы позаботятся об удобном создании метасистем игры: контентных обновлений, таблиц лидеров и так далее.
Команда уже принимает заявки на тестирование Nau Engine на своём сайте. Кроме того, коллектив расширяет штат — открыто несколько вакансий, включая арт-директора и разработчика программного обеспечения. Компания намерена выпустить движок к концу 2025-го.
Читай также
Лучшие комментарии
Унити на C++ работает...
Человек выше всё правильно написал. Да, скриптинг на шарпах, но внутренние механизмы на плюсах написаны и есть шарповая прослойка между пользовательским кодом и системами движка.
При этом использование .net рантайма скорее легаси и больше подходит для билдов во время разработки. Для релиза обычно юзают юнитишный транслятор кода, который код шарпов конвертит в плюсы.
Так что, юнити куда больше плюсовый движок, чем наоборот.
А в чём ты прав? Ты хоть что-то на нём делал когда-либо?
В том, что он довольно-таки грузный в плане исполнения и его инструкции исполняются через транслятор, CLR. Не нативно, не в виде голого байт-кода на выходе.
Я сам пишу на C#, и ряд вещей с симметричным кодом исполняется заметно быстрее даже на той же Delphi 6 лохматого года. Для различных утилит и не-низкоуровневой разработки он удобен и хорош. Он удобен тем, что не нужно менеджить память и достаточно лояльно относится к промахам в коде.
Но он не шибко подходит как основа для того, что должно исполняться максимально быстро — игрового движка.
У меня есть ряд хороших знакомых, кто работал с Unity, и… скажем так, это ребята уровня от миддла до сеньора (скилловее меня, т.к. я в разработку перешел из системного администрирования), и хорошего о движке я слышал прямо-таки мало, особенно это касалось серьезных проектов, а не пет-проектов или дебютных проектов. Особенно, когда дело доходит до портирования на низкопроизводительные платформы и профилирование быстродействия. Там нахероверчено много лишнего в библиотеках, как они утверждают, и им приходится ряд ключевых кусков функционала просто брать и переписывать с нуля под себя.
Вон, в Neptunia: Sisters VS Sisters разработчики по неопытности или дурости херанули стандартный(!!!) каденс-таймер обновления игровых событий на 50 Гц (Какого хрена в движке (!!!) по умолчанию (!!!) события обновляются в 50 Гц, не симметрично стандартным 30\60\120(40)?), из-за чего на всех платформах она статтерит как последняя мразь. Игру я таки люблю, а вот эти затыки — нет.
Они засунули обновление логики в стандартный кусок кода для обновления логики, который какого-то хрена по дефолту идет в 50 гц.
Хорошего — достаточно, как и негатива. Негатива больше от тех, кто работает с движком много и долго. Особенно те, кто его использует больше 10 лет (движку уже 18 лет).
В данном контексте положительные стороны были опущены, т.к. мы обсуждали проблемы движков от людей, которые зарабатывают на том, чтобы донести до потребителя качественный продукт. Простота и доступность — здесь это неоспоримые плюсы.
Не холивара ради. Но я, что первый раз когда услышал про «свой» движок, не понял зачем оно надо, что сейчас.
Есть «наш», «свой», «родной» Unigine. У них даже запись в реестре отечественного ПО есть —
Они ПРОФИ своего дела. И в отличии от unity, они сами разрабатывают приложения на своем движке и поэтому понимают что надо в движке. А не просто теоретические фичи наворачивают.
Они даже под Unity его сейчас задизайнили, чтобы было просто перейти.
Вот доклад Дениcа Шергина о целесообразности разработки «движка» —
И почему-то Денису я верю. И смысл в его докладе понимаю. А вот Александру не очень.
Просто посмотрите доклад Дениса и все вопросы отпадут.
В свете исторических событий и того, как всякие инициативы загибались до логического завершения или выходили урезанными.
В слове Nau последняя буква перевернута и лишена палки. Там должна быть h, чтобы отразить истинно «наш» колорит в разработке чего-либо масштабного или «ответа» кому бы то ни было.
Ну и в тексте ни слова о реальных возможностях движка.
Unity уже так не позиционируется, времена Слендер хорроров на Unity уже давным-давно прошли. Сейчас его используют и большие компании в больших играх (типа Life Is Strange: Before The Storm, Syberia: The World Before, Genshin Impact, Honkai: Star Rail). Для новичков в геймдеве подходят конструкторы которые легко освоить типа Game Maker Studio, RPG Maker, Game Guru Max и подобное.
Во-первых, юнити написан в основном на плюсах. Можешь хоть паровоз точек ставить, но этого ты не изменишь. Во-вторых, любой игровой движок, если только это не хрень для визуальных новелл (RenPy) или типа того, будет написан на плюсах. Даже какой-нибудь XNA, который весь насквозь дотнетовский, под капотом весь на плюсах. Ну и наконец в-третьих, эта радость тоже написана на плюсах, в чем легко убедиться зайдя в список вакансий у них на сайте и посмотрев кто им нужны.
Конечно же одновременно лёгкий в освоении и невероятно функциональный. Это же mail.ru, они славятся высочайшим качеством своих проектов.
Кстати если уж речь зашла про байткод, юнити уже незнамо сколько лет предоставляет альтернативный скриптовый бэкенд il2cpp, который конвертит байткод в плюсы, а потом компилит в нативный бинарь. Им, правда, мало кто пользуется, но я несколько игр встречал с этим. Уж не знаю добавляет ли это скорости, но модить точно становится невозможно. Байткод же модить одно удовольствие — он декомпилится на раз-два.
Как то мало веры в успех, в США облигие игровых движков на любой вкус обосновано высоким уровнем возможностей получить инвестиции или кредитование, а так же благоприятные условия для IT рынка.
Когда майлрушники которые свои то проекты до ума порой довести не могут, сделали нечто столь комплексное как игровой движок? Слишком много централизации
Дельта — это конечно хорошо, без нее совсем печально было бы, но все равно. Писать логику апдейта на произвольное количество миллисекунд мне кажется куда сложнее чем если заранее известно сколько там будет промежуток.
Про «другие движки» ничего не знаю, я уже говорил что мой опыт геймдева исключительно любительский (но если бы я решил написать игру, я бы ее писал на годоте. потому что! :) ). Но мне кажется что писать однопоточные игры в нынешних реалиях должно быть моветоном, многоядерные процы уже давно даже на телефонах. Неудивительно что потом выходят все эти «смуты» которые тормозят «на топовом железе».
В юнити, насколько я помню, два таймера. Один привязан к частоте кадров, второй фиксированный. Предполагается что все, что относится к графике идет по первому таймеру, а все, что касается игровой логики — по второму. чтобы не было как во многих старых играх, что частоту кадров поменял и все поломалось нахрен. Так что это разработчик виноват что повесил графику на фиксированный таймер, он не для этого предназначен. Что же касается байткода, так в дотнете JIT-компиляция испокон веков, и все эти рассказы про «трансляцию» и «нативный код» неактуальны уже лет пятнадцать как. Можно было бы порассуждать про применимость виртуальных машин с уборкой мусора к real-time системам (а любая игра по сути real-time система, там счет на миллисекунды идет), но практика показывает что они работают, если только разрабы не полные дураки, и не генерят мусор мегабайтами в секунду.
Cities: Skylines — на Unity.
Для логики всё-таки нужен Update с умножением всего живого на Time.deltaTime. FixedUpdate нужен для физики, и его нормальные разрабы редко используют насколько я знаю
интересно он будет какой же легкий в освоении как юнити или сложный, но технологичный как анрил
Ты уверен что он вообще будет?
И да — на унити я сделал две недоигры и одну относительно нормальную в ранней стадии разработки делаю