Comments 29
Видимо сравнения шли с Unity 5, т.к. в Unity 2017 очень много плюшек завезли для 2D разработки. К примеру Tilemap присутствует в Unity 2017.2 (https://unity3d.com/ru/unity/whats-new/unity-2017.2.0).
ну редактор тайловых карт в юнити с последним обновлением появился, а в бета версии уже год как
Вообще то тени от спрайтов в юнити есть.
Основная проблема Unreal — отсутствие встроенной 2D-физики
Объясните пожалуйста зачем нуженo отдельнo 2D-физикa
Проще для реализации игровой механики, меньше багов, приносимых попытками "побороть" третье измерение, выше производительность. Не будет случаев, когда из-за физики объект улетит за границы 2D мира "в глубину".
Это не проблема, в настройках физики объекта есть раздел, где можно заблокировать движение/вращение по любым осям и все будет отлично работать.
Это искусственное ограничение, всё будет по прежнему работать по избыточным алгоритмам которые учитывают 3d координаты. Просто третья координата всегда будет статичной. И если вам нужно много физики, то той пиковой производительности которые позволяют достичь алгоритмы которые учитывают 2d координаты, вы никогда не достигните. Но в большинстве случаев это конечно да, решение.
Кто-нибудь может подсказать как правильно настроить камеру для создания псевдо 3д платформера, как, например, этот:
Если делать ортографическую камеру, то ящики и дома не будут выглядеть 3d. Да и чтоб спрайт не искажался под взглядом камеры в 45 градусов — надо спрайты тоже поворачивать под 45 градусов.
Если делать обычную камеру, то спрайты будут менять размер в зависимости от отдаленности.
Есть ли кака-нибудь серебрянная пуля для реализации олдскульного 2.5D бит эм апа, вся графика для которого будет нарисована вручную (и персонажи и пол и задник)?
Прочитал кучу статей и вопросов, но ответов так и не нашел
Скрин
Если делать ортографическую камеру, то ящики и дома не будут выглядеть 3d. Да и чтоб спрайт не искажался под взглядом камеры в 45 градусов — надо спрайты тоже поворачивать под 45 градусов.
Если делать обычную камеру, то спрайты будут менять размер в зависимости от отдаленности.
Есть ли кака-нибудь серебрянная пуля для реализации олдскульного 2.5D бит эм апа, вся графика для которого будет нарисована вручную (и персонажи и пол и задник)?
Прочитал кучу статей и вопросов, но ответов так и не нашел
Если не ошибаюсь, это не псевдо, это вполне себе 3D, глубина же присутствует. Хотя персонажи спрайтовые. А камеру, получается, под углом ставить.
В том то и проблема, что персонажи не в 3D, а все остальное — 3D. Получается что ящик объемный, а персонаж — плоский. И если на плоский персонаж будет смотреть камера под углом, то геометрия персонажа нарушится и он станет сплюснутым. Следственно спрайт надо тоже под углом к камере располагать. И тогда если персонаж будет стоять около задней стены, то его часть уйдет в стену.
Элементарно, можно же вручную задать коэффициенты у матрицы камеры.
Допустим, у нас есть какие-то внутриигровые координаты (x,y,z) — 'x' и 'z' по горизонтали, 'у' повертикали, и камера располагается на x_camera, y_camera.
Нужно подобрать матрицу, чтобы её произведение с нашими координатами давало координаты на экране.
Как видно, х_screen = x — z — x_camera
y_screen = y + z — y_camera
чтобы видеокарта рисовала более близкие элементы поверх далёких, можно ещё сделать z_screen = z.
Из этого получается, что матрица камеры будет такой:
(1, 0, -1, -x_camera)
(0, 1, 1, -y_camera)
(0, 0, 1, 0)
(0, 0, 0, 1)Ну или транспонированной от этой.
Там ортографическая камера + параллакс.
UFO just landed and posted this here
Увы, аркады может мелкие и норм на UE4 делать, но вот сложная логика и скриптинг на C++, лютое зло, учитывая, что документация вечно устаревшая, еще ладно на нормальные функции, но когда суют кругом макросы и документация по ним в большинстве своём вообще неактуальная, то это лютое зло. Да и полностью забить на идиологии разработки на C++. В итоге так и не стал использовать UE4.
Не соглашусь с вами.
Пилю РТС с терраформингом на UE4. Встроенного терраформинга нет, так что пришлось делать свой ландшафт, который может динамически изменятся. Что, согласитесь, не самая обычная задача для типичного игроково проекта.
Да, пришлось несколько раз столкнуться с устаревшей документацией. Так же пришлось столкнуться с неработающим макросом(который в документации висит как ПЕРЕХОДИМ НА НЕГО, ИСПОЛЬЗОВАТЬ ТОЛЬКО ЕГО, СТАРЫЙ DEPRICATED!!!!!), но по факту новый максром не рабочий и использовать его нельзя.
Однако, несмотря на то, что это первый опыт работы с глубинами UE — особых проблем не возникло. Да, пару раз правил им вики, пару раз застревал на месте не на долго. Но всё вполне решаемо.
А уж если говорить про проекты, которые не требуют написания новых сложных сущностей — так и вообще всё прекрасно. Пожалуй единственное что периодически напрягает — упор на массовых пользователей, в итоге приоритет отдается блюпринтам и как итог документация по блюпринтам точнее и проработанней, чем по С++.
Пилю РТС с терраформингом на UE4. Встроенного терраформинга нет, так что пришлось делать свой ландшафт, который может динамически изменятся. Что, согласитесь, не самая обычная задача для типичного игроково проекта.
Да, пришлось несколько раз столкнуться с устаревшей документацией. Так же пришлось столкнуться с неработающим макросом(который в документации висит как ПЕРЕХОДИМ НА НЕГО, ИСПОЛЬЗОВАТЬ ТОЛЬКО ЕГО, СТАРЫЙ DEPRICATED!!!!!), но по факту новый максром не рабочий и использовать его нельзя.
Однако, несмотря на то, что это первый опыт работы с глубинами UE — особых проблем не возникло. Да, пару раз правил им вики, пару раз застревал на месте не на долго. Но всё вполне решаемо.
А уж если говорить про проекты, которые не требуют написания новых сложных сущностей — так и вообще всё прекрасно. Пожалуй единственное что периодически напрягает — упор на массовых пользователей, в итоге приоритет отдается блюпринтам и как итог документация по блюпринтам точнее и проработанней, чем по С++.
Не понимаю почему в первую очередь, говоря об анреале, точнее его преимуществах, говорят о блюпринтах? Они же годятся максимум для несложных прототипов и не более. Я лично пронаблюдал среди нескольких своих знакомых которые пробовали делать достаточно простые инди поделки без особых изысков и думали что смогут сделать на блюпринтах. Результат предсказуем (хотя во всех случаях я предупреждал что так будет) — один пошел делать на юнити и с# и выпустил 4 игры уже на айос. Двое других в итоге бросили свои начинания. Причём один ещё ладно достаточно быстро понял что без нормального программирования он не сможет реализовать свои идеи, а связываться с с++ нет желания просто забил. Другой же полтора года (!) убил на попытки таки довести всё на блюпринтах. Во всех трёх случаях это были очень простые в плане графики 2д игры — т.е. люди полезли в анреал не за графоном (а тут сложно критиковать — у анреала из коробки очень мощный инструментарий и хорошая оптимизация для графики близкой к фотореалистичной), а именно начитавшись статей и насмотревшись видео на ютюбе где восторженно расказывали что ВОТ! Вот всё теперь не надо ничего программировать! Даже если вы не программист вы можете без строчки кода сделать игру!
Чувак который таки выпустил в итоге 4 игры на юнити потом сказал что конечно хорошо что научился в юнити работать на первых двух проектах которыебыли совсем простые но сейчас бы он их на гейммейкере сделал бы.
Вобщем история про гвозди и микроскоп.
Чувак который таки выпустил в итоге 4 игры на юнити потом сказал что конечно хорошо что научился в юнити работать на первых двух проектах которыебыли совсем простые но сейчас бы он их на гейммейкере сделал бы.
Вобщем история про гвозди и микроскоп.
Unreal сам по себе весьма непростой движок, поэтому полтора года, особенно если человек начинающий, не так много. У многих инди проектов судьба печальная и зачастую не сильно зависит от используемого движка. Как говорится, "нельзя так просто взять и зарелизить свой первый проект". Конечно, базовые знания программирования (функции, циклы, переменные и т.п.) необходимы, чтобы хоть что-то реализовать на блупринтах. Блупринты хвалят, так как они предоставляют средства, которыми могут пользоваться не только программисты. В сложных проектах они тоже используются вовсю, просто основная часть сложных систем реализована на C++, а для блупринтов доступны функции взаимодействия с ними.
Больше всего удивляют высказывания вроде «на UE4 можно создать игры БЕЗ программирования!» — вот, где реальная подмена понятий и откровенная ложь. Справедливости ради, простые игры типа марио или какой-нибудь метроидвании вполне реально собрать на принтах, но идея, как ни крути, сомнительная.
я то сам не против визуального программирования как идеи — я сам работаю много в такой программе как Houdini в которой почти всё на этом построено. Для работы с шейдерами на хай левеле это вобще идеальный практически подход — он и в оффлайн рендер системах стал стандартом уже давно (даже реньше чем сами блюпринцы появились).
Понятно что профессионал будет знать какой инструмент лучше подходит для каких задач и будет использовать когда это выгодно — и блюпринты, и юнитевские разнообразные аналоги типа плеймейкера.
Моя же претензия не к технологии, а к тому как сами Эпики и всевозможные популяризаторы движка агрессивно пиарят эту тулзу как панацею от необходимости кодить. Это приводит к тому что новички ставшие жертвой этого маркетинга убивают кучу времени впустую и часо просто бросают это всё вапще. Что может быть и неплохо но не очень честно.
Понятно что профессионал будет знать какой инструмент лучше подходит для каких задач и будет использовать когда это выгодно — и блюпринты, и юнитевские разнообразные аналоги типа плеймейкера.
Моя же претензия не к технологии, а к тому как сами Эпики и всевозможные популяризаторы движка агрессивно пиарят эту тулзу как панацею от необходимости кодить. Это приводит к тому что новички ставшие жертвой этого маркетинга убивают кучу времени впустую и часо просто бросают это всё вапще. Что может быть и неплохо но не очень честно.
Добабавлю, чувак который свичнулся на юнити+с# никогда не программировал, исключительный гуманитарий (образование режиссёрское, работал режиссёром монтажа) — идельная ЦА для маркетинга таких инстурментов «шоб не программировать». В итоге без проблем освоил шарп и на третьей игре уже осилил клиент-сервер архитектуру для мультиплеера реюзая куски чужого кода и готовые модули, естествено.
К сожелнию это диктует рынок. Надо привлекать пользователей, чтобы они оставляли деньги в сторе. А как привлечь? Простым инструментом. Блюпринт из таких.
Вот в итоге он и превращается из инструментя для скрипитнга высокоуровневых механик в основной инструмент.
Вот в итоге он и превращается из инструментя для скрипитнга высокоуровневых механик в основной инструмент.
Премного благодарен за статьи, с удовольствием сохраняю себе в оффлайн, т.к. почерпнул много чего интересного как и из самих статей, так и (возможно особенно) из комментариев.
Правда сложилось устойчивое впечатление, что чуть ли не единственным плюсом UE является наличие блюпринтов. Возможно (да и скорее всего), это совсем не так, но лично для меня этот «маркетинговый трюк» возымел абсолютно обратный эффект: как человек, имеющий опыт разработки на C#, я еще больше убедился, что правильно выбрал движек для пробы пера в геймдеве.
Правда сложилось устойчивое впечатление, что чуть ли не единственным плюсом UE является наличие блюпринтов. Возможно (да и скорее всего), это совсем не так, но лично для меня этот «маркетинговый трюк» возымел абсолютно обратный эффект: как человек, имеющий опыт разработки на C#, я еще больше убедился, что правильно выбрал движек для пробы пера в геймдеве.
Полезно будет, статья хороша.
Sign up to leave a comment.
UE4 для Unity разработчиков: создание 2D-игр