Comments 13
Чем то напомнило мне старенькую игру infestation 2000-го года.
Может когда-нибудь попробуете сделать на NeoAxis Engine :)
Ну, редактор у NeoAxis довольно страшноват, если честно. Документации всего ничего, развивается всё как-то очень тихо и медленно. Pbr вроде и заявлен, но на скриншотах оно так не выглядит. Что ещё. Разработка только под Windows. Как бы и опенсурс, но лицензия с требованием упоминания в титрах. Просто не увидел каких-то преимуществ, кроме некоторого количества готового полезного инструментария. Есть наверное какие-то скрытые плюсы, но тут всё упирается в наличие желания рассматривать данный вариант.
Просто с тем же Godot на поле опенсурс движков конкурировать почти нереально, а это ещё не вышла 4-ка.
Скорее я посмотрел бы на Stride, где C# в качестве основного языка, инструментария немного, но как-то целостно и приятно всё выглядит. Или на вот буквально на днях вышедший Cocos Creator 3D, который тоже развивается и кажется перспективным. Правда у двух последних пока не наработана база примеров/исходников и туториалов.
Просто с тем же Godot на поле опенсурс движков конкурировать почти нереально, а это ещё не вышла 4-ка.
Скорее я посмотрел бы на Stride, где C# в качестве основного языка, инструментария немного, но как-то целостно и приятно всё выглядит. Или на вот буквально на днях вышедший Cocos Creator 3D, который тоже развивается и кажется перспективным. Правда у двух последних пока не наработана база примеров/исходников и туториалов.
:) Ну спору нет, PBR в таких зарослях сложно заметить) Если из сорцов собирать, демки докачиваются через ассет стор.
Просто когда у движка на официальном канале последнее видео годовой давности, а прочие аж 7-летней, то это как-то не очень способствует популяризации. Тем более, что какие-то новые версии они выкатывали не 7 лет назад и как раз есть повод поснимать каких-то новых видео/туториалов и всякого подобного.
Со стороны видео значит выглядит малообновляемым, спасибо. Пока есть только сторонние обзоры, типа такого:
Как мне кажется, повышению интереса к движку способствуют разрабатываемые на нём проекты, в том числе силами самих разработчиков движка. Может даже чисто демонстрационные. Чтобы наглядно показать пайплайны, инструментарий. Опять же — лишние инфоповоды, вроде новостей из дневников разработки, но не касаемо самого движка, а каких-то прототипов на его основе.
Лучше всего даже каких-то супер-простых, от которых новоприходящим разработчикам проще моддить свои проекты. Даже в том же Unity не сразу к этому пришли — относительно недавно (хотя на сайт к ним давно не заглядывал) на сайте появились официальные мини-проекты с разбором отдельных элементов, вроде простой гонки, шутера и так далее.
Я просто вспоминаю, как начал делать игры на том же Flash именно после того как нашёл где-то на Kongregate пошаговое руководство по написанию простой леталки. В итоге около десятка игр на эту платформу написал. Хотя, конечно, сам интерес к разработке на Flash изначально появился не от наличия туториала, а по иным причинам, но без существования этой точки старта я в то время, наверное, продолжал бы использовать Blitz3d или ушёл в какие-то другие среды разработки.
В случае со входом в Blitz3d тоже попалась некоторая обучалка возможностям и примеры сборки чего-то простого. А на Unity можно было относительно просто вкатиться благодаря сторонним мини-прототипам в асстет-сторе, пока не было расписанных пошаговых официальных.
Лучше всего даже каких-то супер-простых, от которых новоприходящим разработчикам проще моддить свои проекты. Даже в том же Unity не сразу к этому пришли — относительно недавно (хотя на сайт к ним давно не заглядывал) на сайте появились официальные мини-проекты с разбором отдельных элементов, вроде простой гонки, шутера и так далее.
Я просто вспоминаю, как начал делать игры на том же Flash именно после того как нашёл где-то на Kongregate пошаговое руководство по написанию простой леталки. В итоге около десятка игр на эту платформу написал. Хотя, конечно, сам интерес к разработке на Flash изначально появился не от наличия туториала, а по иным причинам, но без существования этой точки старта я в то время, наверное, продолжал бы использовать Blitz3d или ушёл в какие-то другие среды разработки.
В случае со входом в Blitz3d тоже попалась некоторая обучалка возможностям и примеры сборки чего-то простого. А на Unity можно было относительно просто вкатиться благодаря сторонним мини-прототипам в асстет-сторе, пока не было расписанных пошаговых официальных.
Насколько я понимаю, Unreal и Unity сейчас самые популярные движки с большим отрывом. Т.е. ресурсов по ним больше всего, опыт по ним самый востребованный. Оба бесплатные (по крайней мере на начальном уровне).
Какой практический смысл делать прототипы в чём то другом?
Какой практический смысл делать прототипы в чём то другом?
Например, новый опыт и теоретический успех. Идти по трудной дороге бывает легче, меньше попутчиков-соперников
Не всем и не всегда нужен гигантский движок с уймой лишних фич, особенно если есть чёткое понимание какой именно функционал движка будет необходим. Не всегда удобны предоставляемые инструменты и парадигмы разработки (скажем, подход со сценами в Unity, подход в префабами, система ресурсов, и т. д.). Также, многие встроенные функции движков не дотягивают до уровня, который можно получить используя сторонний middleware или просто написав свою имплементацию (например, меня не устраивают UI любых существующих движков поэтому я предпочитаю NoesisGUI (библиотека векторного UI), а для high-level сетевого слоя в последнем проекте понадобилось совершенно кастомное решение с глубокой интеграцией непосредственно в выбранную UDP библиотеку — с большим успехом в итоге, и просто гигантский контраст с тем, что по крайней мере на тот момент предлагали как Unity так и Unreal Engine (Unity HLAPI был годами набит багами, надеюсь они нашли людей доработать это недоразумение; в Unreal просто требовалась уйма сравнительно очень страшного кода на макросах в C++ для их magic репликации).
У меня есть многолетний опыт трудной работы с Unity, который просто доводил нашу студию до отчаяния в эпоху версии Unity 5 — была уйма критических багов, которые не фиксились месяцами (багрепорты часто месяцами игнорировались). А когда фиксились одни, то регрессились другие и долгое время не было доступно действительно полностью стабильной версии для релиза игры (дело дошло даже до постов с извинениями в их блоге и рассказом как они меняют свой подход к QA). Из-за того, что это проприетарный движок, я не мог залезть в его исходники и поправить какую-нибудь критическую мелочь самостоятельно (только на особых «договорных» энтерпрайз лицензиях тогда это было доступно, сейчас стало чуть проще — при условии что у вас много лишних денег). Но нужно понимать, что код движка там C/C++, а не C#, и всё наверняка будет совсем не просто в плане билда.
С тех пор я заработал огромный опыт написания собственного движка и работы с MonoGame.
Если бы я сейчас делал прототип игры, я бы вряд ли воспользовался Unity. Но новичкам в программировании (и тем более людям далёким от программирования) я его рекомендую — он достаточно логичный, зрелый, имеет массу качественных обучающих материалов. Unreal Engine тоже (во многом за счёт визуального скриптинга на Blueprints; рекомендовать новичкам в программировании работать с С++ API я бы не стал). В обоих движках есть удобный редактор сцены и 99% нужных фич по крайней мере для сборки прототипа большинства игр. Asset Store данных движков также может быть очень полезным (там немало бесплатных ассетов и расширений).
В случае наличия чёткого видения проекта и отсутствия потребности в лишних фичах (а так же просто опытным C# программистам) я порекомендую Stride (бывший Xenko) для 3D проектов (и/или когда нужен редактор сцены) и MonoGame для 2D (но там придётся писать свой редактор или ограничиваться сторонним решениями для работы с тайловыми картами, например). Для меня Unreal просто гигантский и медленный, с совершенно другими парадигмами разработки и без ориентации на глубокую интеграцию с C#, что оказалось принципиально важным моментом для выживания нашей студии с 2013 года (речь не только об унификации клиент-серверного кода для игр — на C# пишется вся инфраструктура включая сайты, бэкенд, тулзы, автоматизация облачных серверов и т. д. — всё это здорово ускоряет разработку и обслуживание).
Добавлю, что существует ещё один немаловажный нюанс — ограниченный инструментарий часто заставляет искать другой подход к разработке, который не может не привести к совершенно другому результату, чем если бы использовался полный движок с уймой готовых функций — они не могут быть лучшим выбором во всех случаях и навязывают определённые подходы к разработке. Нередко мы видим действительно уникальные проекты с необычным геймплеем или графикой именно от разработчиков избравших минималистичный путь написания своих движков, что с одной стороны ограничивает, с другой стороны полностью развязывает руки (попробуйте изменить какой-нибудь популярный движок, чтобы он полностью поддерживал live reloading всего и вся в игре, включая C# код — а у меня получилось ещё несколько лет назад на своём движке и это здорово экономило время при дальнейшей разработке — в сравнении с Unity, где приходилось ждать по несколько минут перекомпиляцию прошлого крупного проекта несмотря на его разделение на отдельные библиотеки). До середины 2000-ых это было вполне стандартным подходом, и мы были свидетелями огромного числа действительно уникальных проектов. Сейчас же рынок просто перегружен однообразными играми сделанными на двух наиболее популярных движках… кстати, где-то была статистика по движкам игр в Стиме среди наиболее популярных (worldwide top seller) проектов — и более трети игр имели кастомные движки. Сейчас такой информации не могу найти, но есть статистика по наиболее рейтинговым (исходя из оценки игроков) играм в Steam в 2019 (там в основном инди-игры получились, уж так пошло в Стиме, что они собирают наиболее позитивные отзывы).
У меня есть многолетний опыт трудной работы с Unity, который просто доводил нашу студию до отчаяния в эпоху версии Unity 5 — была уйма критических багов, которые не фиксились месяцами (багрепорты часто месяцами игнорировались). А когда фиксились одни, то регрессились другие и долгое время не было доступно действительно полностью стабильной версии для релиза игры (дело дошло даже до постов с извинениями в их блоге и рассказом как они меняют свой подход к QA). Из-за того, что это проприетарный движок, я не мог залезть в его исходники и поправить какую-нибудь критическую мелочь самостоятельно (только на особых «договорных» энтерпрайз лицензиях тогда это было доступно, сейчас стало чуть проще — при условии что у вас много лишних денег). Но нужно понимать, что код движка там C/C++, а не C#, и всё наверняка будет совсем не просто в плане билда.
С тех пор я заработал огромный опыт написания собственного движка и работы с MonoGame.
Если бы я сейчас делал прототип игры, я бы вряд ли воспользовался Unity. Но новичкам в программировании (и тем более людям далёким от программирования) я его рекомендую — он достаточно логичный, зрелый, имеет массу качественных обучающих материалов. Unreal Engine тоже (во многом за счёт визуального скриптинга на Blueprints; рекомендовать новичкам в программировании работать с С++ API я бы не стал). В обоих движках есть удобный редактор сцены и 99% нужных фич по крайней мере для сборки прототипа большинства игр. Asset Store данных движков также может быть очень полезным (там немало бесплатных ассетов и расширений).
В случае наличия чёткого видения проекта и отсутствия потребности в лишних фичах (а так же просто опытным C# программистам) я порекомендую Stride (бывший Xenko) для 3D проектов (и/или когда нужен редактор сцены) и MonoGame для 2D (но там придётся писать свой редактор или ограничиваться сторонним решениями для работы с тайловыми картами, например). Для меня Unreal просто гигантский и медленный, с совершенно другими парадигмами разработки и без ориентации на глубокую интеграцию с C#, что оказалось принципиально важным моментом для выживания нашей студии с 2013 года (речь не только об унификации клиент-серверного кода для игр — на C# пишется вся инфраструктура включая сайты, бэкенд, тулзы, автоматизация облачных серверов и т. д. — всё это здорово ускоряет разработку и обслуживание).
Добавлю, что существует ещё один немаловажный нюанс — ограниченный инструментарий часто заставляет искать другой подход к разработке, который не может не привести к совершенно другому результату, чем если бы использовался полный движок с уймой готовых функций — они не могут быть лучшим выбором во всех случаях и навязывают определённые подходы к разработке. Нередко мы видим действительно уникальные проекты с необычным геймплеем или графикой именно от разработчиков избравших минималистичный путь написания своих движков, что с одной стороны ограничивает, с другой стороны полностью развязывает руки (попробуйте изменить какой-нибудь популярный движок, чтобы он полностью поддерживал live reloading всего и вся в игре, включая C# код — а у меня получилось ещё несколько лет назад на своём движке и это здорово экономило время при дальнейшей разработке — в сравнении с Unity, где приходилось ждать по несколько минут перекомпиляцию прошлого крупного проекта несмотря на его разделение на отдельные библиотеки). До середины 2000-ых это было вполне стандартным подходом, и мы были свидетелями огромного числа действительно уникальных проектов. Сейчас же рынок просто перегружен однообразными играми сделанными на двух наиболее популярных движках… кстати, где-то была статистика по движкам игр в Стиме среди наиболее популярных (worldwide top seller) проектов — и более трети игр имели кастомные движки. Сейчас такой информации не могу найти, но есть статистика по наиболее рейтинговым (исходя из оценки игроков) играм в Steam в 2019 (там в основном инди-игры получились, уж так пошло в Стиме, что они собирают наиболее позитивные отзывы).
Ёмко.
Кстати, соглашусь с важной ролью ограничений, благодаря которым появляются специфические геймплеи или способы реализации чего-то внутри игры, организации пространств и так далее. Собственно, в статье и описаны различные подходы к устройству прототипа, которые выросли в процессе разработки из специфики того или иного движка. Да и в целом сама полигональная графика и её пайплайны тоже выросли из ограничений, потому как считать реалтайм 3д через «честные» воксели — драматически непроизводительно. Или вот такой особый «переходный» поджанр, как 3d игры с фиксированной камерой и пререндеренными задниками. Да даже в эпоху 2д тоже хватало своих «нечестных» трюков и ухищрений, чтобы обходить ограничения и добиваться адекватной производительности.
Тоже в качестве C# движка рассматриваю Stride как один из интересных вариантов. Потому как в Unity на шарпе замечательно всё писалось и хотелось бы чего-то подобного. Вот почему и взялся за Unigine, в котором эта возможность тоже есть, хотя пока в основном описано невизуальное использование скриптового языка. Но опыт Unity туда хорошо переносится. В Godot, напротив, выбрал всё-таки внутренний GDScript, потому как из нескольких скриптовых языков в движке я лучше возьму тот, который лучше проработан и интегрирован. Тем более отличия от шарпа не такие большие, чтобы это было какой-то прям проблемой — пишешь себе логику и пишешь.
Кстати, соглашусь с важной ролью ограничений, благодаря которым появляются специфические геймплеи или способы реализации чего-то внутри игры, организации пространств и так далее. Собственно, в статье и описаны различные подходы к устройству прототипа, которые выросли в процессе разработки из специфики того или иного движка. Да и в целом сама полигональная графика и её пайплайны тоже выросли из ограничений, потому как считать реалтайм 3д через «честные» воксели — драматически непроизводительно. Или вот такой особый «переходный» поджанр, как 3d игры с фиксированной камерой и пререндеренными задниками. Да даже в эпоху 2д тоже хватало своих «нечестных» трюков и ухищрений, чтобы обходить ограничения и добиваться адекватной производительности.
Тоже в качестве C# движка рассматриваю Stride как один из интересных вариантов. Потому как в Unity на шарпе замечательно всё писалось и хотелось бы чего-то подобного. Вот почему и взялся за Unigine, в котором эта возможность тоже есть, хотя пока в основном описано невизуальное использование скриптового языка. Но опыт Unity туда хорошо переносится. В Godot, напротив, выбрал всё-таки внутренний GDScript, потому как из нескольких скриптовых языков в движке я лучше возьму тот, который лучше проработан и интегрирован. Тем более отличия от шарпа не такие большие, чтобы это было какой-то прям проблемой — пишешь себе логику и пишешь.
Очевидно что это не игра, демо-версия чего, как вы сами бы охарактеризовали?
Sign up to leave a comment.
Демо-версии Невангеров для Unigine и Godot