Когда увидел статью, ожидал увидеть там реализацию написания своего шейдера через плагин. Просто через постобработку делать целл-шейдинг на конкретных объектах нецелесообразно. Но все равно новичкам будет полезно :)
Кстати говоря, ограничение первого способа — отсутствие влияния теней, можно решить, отрендерив вручную каскады, вместо самого источника света. Ну и наложив в шейдере) Но это гемор, согласен)
И ещё… Я бы избегал использование if'ов. Есть риск нарваться на алиасинг.
К сожалению это проблема не столько дизайнеров, как самих движков. Тот же Unreal Engine 4 устроен так, то бы на блупринтах можно было написать легко любую игру. А в редакторе материалов можно собрать любой шейдер без знания HLSL. Новички так и делают. И из-за такой легкости совсем не думаешь об оптимизации и о том, что все эти инструменты — ещё один уровень абстракции, который работает медленнее.
Компании так же нанимают людей, которые вроде могут работать с движком, но о конкретике не задумаются: «О, этот парень сделал игру на анриале. Значит он нам подойдет.», но никто не спрашивает себя «Этот парень сделал игру, но сможет ли он оптимально решить нашу задачу?».
Но все это с опытом приходит, если есть интерес… Благо, те же блупринты хоть и медленные, но позволяют писать достаточно грамотный и быстрый код. То же самое и с материалами.
Да, вы правы. Тем не менее на стримах я стараюсь пару частей уделить именно графике (импорт, настройка, дизайн уровней). Например в этой серии мы сделали постобработку с обводкой, а так же задизайнили пару уровней.
К сожалению с юнити не работаю, так что такие вещи не смогу там сделать. Да и мне анриала достаточно, на самом деле, в нем все необходимое есть, что есть и в юнити.
Такие игры очень классные, кстати, но нужно давать свой, более интуитивный интерфейс для задания поведения. Например графический редактор программирования существа. Давать разные события, вроде «Противник появился на экране» или «Вас атаковали» и функции «Идти туда» «Повернуться туда». Посмотрите Blueprint в Unreal Engine 4. Там правда это полноценный ООП графический, но идея та же, только чуть полегче.
Так и аудитория будет больше, и игра будет дружелюбнее к обычным пользователям, при этом развивая их логическое мышление. Особенно полезно будет детям и школьникам, которые смогут совмещать соревнование и развитие.
Плюс такого подхода в том, что если для нового вида оружия требуется новое поведение, мы не переписываем BaseGun
При наследовании нам так же не обязательно лезть в главный класс, если он правильно реализован…
Например для дробовика достаточно поставить цикл и вызвать родительскую логику выстрела несколько раз, меняя перед этим разброс. При выстреле из гранатомета, достаточно поменять класс прожектайла. Ну или просто перезаписать функционал выстрела.
Более того, как написали выше, что бы поменять у экшена какую-то мелочь, нужно создавать отдельный класс, либо лезть в общий и добавлять туда переменные, что опять же противоречит вашим словам о том, что этого не нужно делать по сравнению с наследованием…
Ну и в довесок можно сказать, что вам все равно придется наследовать пушки, хотя бы изходя из того, что вам нужен один класс «Оружие», с которым будет работать менеджер оружия или интерфейс, например. Ну и хранить какой-то общий функционал для всего оружия… А наследование + компоненты это не очень удобно…
Плюсы такой системы определнно есть, но не в вашем случае) Например это удобно делать, когда нужно совсем разным объектам придать общий функционал, вроде взаимодействия, включения/выключения… Или же когда нужно динамические компоненты с функционалом добавлять, вроде тех же экшенов, но в другой форме.
Давно работаю с ИИ в Анриале. По правде сказать, инструмент Behavior Tree какой-то слишком неудобный и бесполезный, хотя и не выглядит таковым на первой взгляд. Ещё и дерево выполняется последовательно и, как правило, каждый кадр с проверками…
Несколько раз пытался все же попробовать его, мол вдруг я не прав и на самом деле инструмент хороший, но сколько раз не пытался на нем писать хоть немного сложный ИИ, выходило либо костыльно, неудобно и в некоторых местах вообще без возможности что-либо реализовать. И это несмотря на то, что с инструментом хорошо знаком.
Уже два года пишу все ИИ либо на плюсах, либо на блупринтах, о BT даже не думаю, так как разработал свой паттерн. Удобный, гибкий, расширяемый.
Для тех, кому интересно, создаю компоненты, которые отвечают за определенную логику (преследование, бой, убегание, патрулирование, укрытия и так. далее). Контроллер в свою очередь привязывается в нужным событиям и переключает работу компонентов. Кстати можете увидеть примерную реализацию у меня в стримах по созданию выживалки (у меня в аккаунте можно найти статью).
В целом компоненты можно заменить поддеревьями, однако там проблема в том, что не так просто перескочить с ветки на ветку, а так же и слушать одной веткой совершенно другую диспатчером. Таких проблем ещё не мало, которые придется решать какими-то выкрутасами. Поэтому вообще не вижу смысла париться и юзать Behavior Tree
Есть от Nvidia так называемый Flex — технология на основе частиц. Она как раз на GPU работает, то есть аналогично (в плане идеи) игре выше. Вроде с PhysX не связана, но все равно стоит посмотреть, так как та же компания. Сам же PhysX работает чисто на CPU и никак не связан с видяхой.
В инете можно найти демки, а так же исходники для Unreal Engine.
Никогда не понимал все эти мизерные отлики. Мне коллеги говорили, мол в сетевых играх, где важно быстро реагировать, там важны миллисекунды.
Но как так? У тебя пинг по сети миллисекунд 60. Твоя реакция около 100мс. ПК тоже не мгновенный. Из этого следует, что от действия на сервере до получения реакции игрока уже на сервере — проходит как минимум 250мс. Неужели лишние 20мс насколько существенны, что бы потратить лишние 7 тысяч рублей?
При Saturate он ставит сам saturate() как и положено.
Кстати говоря, ограничение первого способа — отсутствие влияния теней, можно решить, отрендерив вручную каскады, вместо самого источника света. Ну и наложив в шейдере) Но это гемор, согласен)
И ещё… Я бы избегал использование if'ов. Есть риск нарваться на алиасинг.
В остальном спасибо за перевод!
Компании так же нанимают людей, которые вроде могут работать с движком, но о конкретике не задумаются: «О, этот парень сделал игру на анриале. Значит он нам подойдет.», но никто не спрашивает себя «Этот парень сделал игру, но сможет ли он оптимально решить нашу задачу?».
Но все это с опытом приходит, если есть интерес… Благо, те же блупринты хоть и медленные, но позволяют писать достаточно грамотный и быстрый код. То же самое и с материалами.
Так и аудитория будет больше, и игра будет дружелюбнее к обычным пользователям, при этом развивая их логическое мышление. Особенно полезно будет детям и школьникам, которые смогут совмещать соревнование и развитие.
При наследовании нам так же не обязательно лезть в главный класс, если он правильно реализован…
Например для дробовика достаточно поставить цикл и вызвать родительскую логику выстрела несколько раз, меняя перед этим разброс. При выстреле из гранатомета, достаточно поменять класс прожектайла. Ну или просто перезаписать функционал выстрела.
Более того, как написали выше, что бы поменять у экшена какую-то мелочь, нужно создавать отдельный класс, либо лезть в общий и добавлять туда переменные, что опять же противоречит вашим словам о том, что этого не нужно делать по сравнению с наследованием…
Ну и в довесок можно сказать, что вам все равно придется наследовать пушки, хотя бы изходя из того, что вам нужен один класс «Оружие», с которым будет работать менеджер оружия или интерфейс, например. Ну и хранить какой-то общий функционал для всего оружия… А наследование + компоненты это не очень удобно…
Плюсы такой системы определнно есть, но не в вашем случае) Например это удобно делать, когда нужно совсем разным объектам придать общий функционал, вроде взаимодействия, включения/выключения… Или же когда нужно динамические компоненты с функционалом добавлять, вроде тех же экшенов, но в другой форме.
http://wnconf.com/
Проходит три раза в году: Москва, Спб, Прага. Хотя первые два города во второй половине года, как правило…
Несколько раз пытался все же попробовать его, мол вдруг я не прав и на самом деле инструмент хороший, но сколько раз не пытался на нем писать хоть немного сложный ИИ, выходило либо костыльно, неудобно и в некоторых местах вообще без возможности что-либо реализовать. И это несмотря на то, что с инструментом хорошо знаком.
Уже два года пишу все ИИ либо на плюсах, либо на блупринтах, о BT даже не думаю, так как разработал свой паттерн. Удобный, гибкий, расширяемый.
Для тех, кому интересно, создаю компоненты, которые отвечают за определенную логику (преследование, бой, убегание, патрулирование, укрытия и так. далее). Контроллер в свою очередь привязывается в нужным событиям и переключает работу компонентов. Кстати можете увидеть примерную реализацию у меня в стримах по созданию выживалки (у меня в аккаунте можно найти статью).
В целом компоненты можно заменить поддеревьями, однако там проблема в том, что не так просто перескочить с ветки на ветку, а так же и слушать одной веткой совершенно другую диспатчером. Таких проблем ещё не мало, которые придется решать какими-то выкрутасами. Поэтому вообще не вижу смысла париться и юзать Behavior Tree
В инете можно найти демки, а так же исходники для Unreal Engine.
Но как так? У тебя пинг по сети миллисекунд 60. Твоя реакция около 100мс. ПК тоже не мгновенный. Из этого следует, что от действия на сервере до получения реакции игрока уже на сервере — проходит как минимум 250мс. Неужели лишние 20мс насколько существенны, что бы потратить лишние 7 тысяч рублей?