Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
[Комментарий про сову]
Так пост и не декларировался как туториал.
А паиграть где? =)
Результат работы можно посмотреть по ссылке в теме проекта: SkyRanger.
Пока нигде. Хабраэффект убил мне дропбокс. В ближайшее время перенесу на свой хостинг все ссылки, и восстановлю доступ.
Jungle|Desert|Urban Strike жив!
Современное продолжение Jungle|Desert|Urban Strike? Я двадцать джва года жду эту игру.
Спасибо, прочитал с удовольствием. Вдохновляет :)
Очень интересно.
Если сообществу будет интересно, я напишу статью о том, как делался переход на UE4 и с какими сложностями при этом пришлось столкнуться.
Очень интересно.
Было бы интересно еще почитать мануал, про первую неделю разработки, хотя на самом деле интересно почитать вообще про всю разработку более подробнее ))
+1 с примерами кода. И я так и не понял какой фреймворк использовался в начале? Самописный?
Фреймворк свой, планировалось развить его до уровня современных проектов. Однако выход UE4 в свободный доступ перечеркнул это будущее и фреймворк останется только для разработки мобильных игр, которые мы сейчас иногда делаем. Все что 3Д и для дектопа — сейчас пробуем делать только на UE и связываем с этим большие планы.
По поводу примеров кода… А что вы хотите увидеть? Никаких особо интересных решений там нет. Просто код и все. Самый обычный. Сложных задач в процессе разработки не возникало. Каких-то гениальных архитектурный решений тоже не было. :(
По поводу примеров кода… А что вы хотите увидеть? Никаких особо интересных решений там нет. Просто код и все. Самый обычный. Сложных задач в процессе разработки не возникало. Каких-то гениальных архитектурный решений тоже не было. :(
Хорошо, напишу лично свое пожелание. Хотя на самом деле страшно за карму )))
У меня как у веб разработчика, был небольшой опыт написание 2Д платформера с мультиплеером на Box2D. Поэтому свои познания в создания полноценных игр я свожу к минимуму. Соответственно нету представления о том каким образом используя 2Д движок вы смогли интегрировать 3д модели. Каким образом переносятся шейдеры, настраивается камера и еще миллион задач, которых лично мне (поскольку я не ознакомлен с разработкой 3D чего-либо) кажутся чем-то невероятно сложным. Тем более с математической точки зрения. Для познания садится, читать мануалы, пытаться велосипедить мне не хочется. Но вот почитать об опыте и как решаются какие-то общие задачи — было бы полезно. Вот как-то так.
У меня как у веб разработчика, был небольшой опыт написание 2Д платформера с мультиплеером на Box2D. Поэтому свои познания в создания полноценных игр я свожу к минимуму. Соответственно нету представления о том каким образом используя 2Д движок вы смогли интегрировать 3д модели. Каким образом переносятся шейдеры, настраивается камера и еще миллион задач, которых лично мне (поскольку я не ознакомлен с разработкой 3D чего-либо) кажутся чем-то невероятно сложным. Тем более с математической точки зрения. Для познания садится, читать мануалы, пытаться велосипедить мне не хочется. Но вот почитать об опыте и как решаются какие-то общие задачи — было бы полезно. Вот как-то так.
На конкретные вопросы я могу ответить прямо здесь в комментариях. Писать статью — ИМХО достаточно бесполезно. Я просто повторю материалы всех тех туториалов, что уже написаны.
Отвечу на то, что уже обозначено — перенос шейдеров и настройка камеры.
Перенос шейдеров
Шейдеры отрисовки ландшафтов идут вместе с редактором ландшафтов, который я использовал. Это Land — для отрисовки ландшафта и objects — для отрисовки объектов и дорог.
Я скопировал эти шейдеры в каталог с контентом проекта и выпилил оттуда всякую ненужную фигню.
Например, шейдеры умеют динамический рассчет нормалей. Он нужен для того, чтобы при скульптинге освещение геометрии менялось в реальном времени. Этот код в игре не нужен, т.к. в игре ландшафт статичен и нормали предрассчитаны. Также шейдеры умеют рисовать кисть. Этот код тоже не нужен в игре. Его выпилил.
Убирать код легко. Например с нормалями убираем функцию calcNormal и код:
заменяем на:
Плюс я перевел шейдеры на новую версию GLSL — то есть отказался от depricated элементов(вместо встроенных gl_Normal,gl_Vertex и т.п. — ручками установленные атрибуты).
Камера
3D камера должна уметь две основных вещи:
1) Проецирование 3D пространства в 2D для отображения на плоском экране — это делается через задание матрицы проекции. Для обычной камеры используется перспективная матрица проекции(чем дальше объект, тем он меньше). Это очень простая операция. Даже математику знать не надо. Исходники методов строящих матрицу проекции есть в интернете, тысячи их.
2) Работа с видом. Вид — это перемещение камеры в 3D пространстве(вообще, формально мы не камеры двигаем, а само пространство, в то время как камера всегда находится в центре системы координат. Но это математические мелочи имеющие мало значения для практики). Видовая матрица считается очень просто(если вы знаете что такое базис, то проблемы понять что это за матрица — не будет):
Подматрица 3х3 задает вращение с помощью направляющих векторов. По сути задается три оси координат базиса и смещение.
m3 m7 и m11 на самом деле могут быть не 0. Это масштабирование. Но при задании видовой матрицы стараются избегать масштабирования, т.к. вылезает много сторонних проблем. Гораздо проще достигать масштабирования сцены другими способами.
В случае OpenGL матрица будет транспонированной.
Перемножив матрицы из пунктов 1 и 2 мы получим финальную матрицу. С помощью которой точка где-то в 3Д мире превращается в точку на экране нашего монитора.
Отдельным пунктом идет задание не перспективной проекции, а ортогональной. Ортогональная проекция — это, грубо говоря, чертежная проекция. Размер объекта не меняется при изменении расстояния до него. Такая проекция нужна для построения теней от бесконечно удаленных источников света(например, солнца). Ортогональная проекция тоже достаточно просто строится. Мануалы есть в сети.
Настройка камеры сводилась к выбору угла обзора и высоты на которой висит камера. С одной стороны надо было показать игровое пространство достаточно большое для удобства играния, а с другой — не слишком большое, чтобы объекты не превратились в неразборчивые пиксели. Сюда же наклон камеры и направление источника света, чтобы скрыть артефакты от карт теней на зданиях.
В общем-то всё.
Ответил?
Конечно, всё что я сейчас написал не является каким-то откровением, т.к. лежит в основе базовых понятий 3Д графики.
Отвечу на то, что уже обозначено — перенос шейдеров и настройка камеры.
Перенос шейдеров
Шейдеры отрисовки ландшафтов идут вместе с редактором ландшафтов, который я использовал. Это Land — для отрисовки ландшафта и objects — для отрисовки объектов и дорог.
Я скопировал эти шейдеры в каталог с контентом проекта и выпилил оттуда всякую ненужную фигню.
Например, шейдеры умеют динамический рассчет нормалей. Он нужен для того, чтобы при скульптинге освещение геометрии менялось в реальном времени. Этот код в игре не нужен, т.к. в игре ландшафт статичен и нормали предрассчитаны. Также шейдеры умеют рисовать кисть. Этот код тоже не нужен в игре. Его выпилил.
Убирать код легко. Например с нормалями убираем функцию calcNormal и код:
vec3 N;
if (DynamicNormals==1)
N = calcNormal(gl_Vertex.xyz, MapCoords);
else{
N = normalize(gl_Normal);
}
normal = N;
заменяем на:
normal = normalize(gl_Normal);
Плюс я перевел шейдеры на новую версию GLSL — то есть отказался от depricated элементов(вместо встроенных gl_Normal,gl_Vertex и т.п. — ручками установленные атрибуты).
Камера
3D камера должна уметь две основных вещи:
1) Проецирование 3D пространства в 2D для отображения на плоском экране — это делается через задание матрицы проекции. Для обычной камеры используется перспективная матрица проекции(чем дальше объект, тем он меньше). Это очень простая операция. Даже математику знать не надо. Исходники методов строящих матрицу проекции есть в интернете, тысячи их.
2) Работа с видом. Вид — это перемещение камеры в 3D пространстве(вообще, формально мы не камеры двигаем, а само пространство, в то время как камера всегда находится в центре системы координат. Но это математические мелочи имеющие мало значения для практики). Видовая матрица считается очень просто(если вы знаете что такое базис, то проблемы понять что это за матрица — не будет):
Подматрица 3х3 задает вращение с помощью направляющих векторов. По сути задается три оси координат базиса и смещение.
m3 m7 и m11 на самом деле могут быть не 0. Это масштабирование. Но при задании видовой матрицы стараются избегать масштабирования, т.к. вылезает много сторонних проблем. Гораздо проще достигать масштабирования сцены другими способами.
В случае OpenGL матрица будет транспонированной.
Перемножив матрицы из пунктов 1 и 2 мы получим финальную матрицу. С помощью которой точка где-то в 3Д мире превращается в точку на экране нашего монитора.
Отдельным пунктом идет задание не перспективной проекции, а ортогональной. Ортогональная проекция — это, грубо говоря, чертежная проекция. Размер объекта не меняется при изменении расстояния до него. Такая проекция нужна для построения теней от бесконечно удаленных источников света(например, солнца). Ортогональная проекция тоже достаточно просто строится. Мануалы есть в сети.
Настройка камеры сводилась к выбору угла обзора и высоты на которой висит камера. С одной стороны надо было показать игровое пространство достаточно большое для удобства играния, а с другой — не слишком большое, чтобы объекты не превратились в неразборчивые пиксели. Сюда же наклон камеры и направление источника света, чтобы скрыть артефакты от карт теней на зданиях.
В общем-то всё.
Ответил?
Конечно, всё что я сейчас написал не является каким-то откровением, т.к. лежит в основе базовых понятий 3Д графики.
Я не знаю о чем тут можно написать. Даже краткое изложение разработки превратилось в огромную портянку…
Если я просто распишу один день — получится статья больше этой… Да и будет ли это интересно?
Я не решал никаких серьезных задач… Ну я могу, например, рассказать как интегрировал карту теней в игру.
Но получится просто пересказ туториала по которому я сам все делал и на который ссылался в тексте статьи,
Не было вообще задач, которые бы заслуживали подробного описания. ИМХО
Если я просто распишу один день — получится статья больше этой… Да и будет ли это интересно?
Я не решал никаких серьезных задач… Ну я могу, например, рассказать как интегрировал карту теней в игру.
Но получится просто пересказ туториала по которому я сам все делал и на который ссылался в тексте статьи,
Не было вообще задач, которые бы заслуживали подробного описания. ИМХО
>Класс камеры даже не пришлось писать, за годы разработки он у меня уже был сделан.
Комментарий:
Вот это «игра за 14 дней»? или всё-таки «игра за 14 дней от гуру, который потратил годы разработки на написание движков к играм»?
Комментарий:
Вот это «игра за 14 дней»? или всё-таки «игра за 14 дней от гуру, который потратил годы разработки на написание движков к играм»?
Очевидно, что если вы(утрированно) никогда не писали ничего и видите компьютер второй раз в жизни — то за две недели проект не сделаете. И за два года — тоже. Просто потому что в основе любой работы лежит огромная база знаний.
Кто сделает игру за 14 дней? Тот, кого вы наймете(или привлечете бесплатно) чтобы сделать вам прототип.
То есть это попытка рассказать, чего можно ждать от специалиста в разработке игре.
А также напомнить программистам, что разработка это достаточно быстро, если сосредоточиться на задаче.
Кто сделает игру за 14 дней? Тот, кого вы наймете(или привлечете бесплатно) чтобы сделать вам прототип.
То есть это попытка рассказать, чего можно ждать от специалиста в разработке игре.
А также напомнить программистам, что разработка это достаточно быстро, если сосредоточиться на задаче.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Игра за 14 дней [Для тех, кто годами собирает команду, но так и не сделал прототип]