Приветствую вас, хабровчане! В этой части я буду создавать и настраивать мяч для игры Pong. Если вы пропустили начало, то оно здесь. Уровень статьи по прежнему начинающий.
Под катом по прежнему много скринов.
Зовите детей и welcome под кат.
Для редактирования проект открывается двойным кликом по названию проекта или кнопкой "Edit".
При повторном запуске движка созданная ранее сцена не открылась. Открыть её можно двойным кликом по ней в панели "File System" аналог панели в Unity называется Project.
Теперь можно создавать мяч, правильный порядок для данного движка, физическое тело и два его наследника: коллайдер и графика. Но я буду делать в другом порядке, заодно и расскажу почему нужен именно такой порядок узлов.
Первое что я хочу сделать с мячом, увидеть его. Потому начну с графики. Я могу нарисовать белый квадрат 3 на 3 пикселя в любом графическом редакторе. Однако я не люблю делать в сторонней программе, то что могу сделать прямо в движке.
Для добавления узла на сцену нужно нажать на плюс в панели сцены. (Разумеется есть возможность использовать контекстное меню или горячие клавиши)
В открывшемся окне появляется огромный список различных типов узлов. Их все нужно просмотреть, в идеале прочитать про каждый из узлов в документации, или хотя бы просмотреть все узлы прямо в списке прочитав описание каждого из них.
Это поможет лучше понимать какие узлы есть в движке и что с ними делать. А для нашей текущей цели подходит узел Polygon2D.
По умолчанию все узлы создаются дочерними относительно корневого узла, если нужно создать узел дочерний относительно какого-то конкретного узла его следует создавать предварительно выделив родительский узел. Очевидно, что с корневым узлом это делать не обязательно.
Пришло время обратить внимание на правую часть окна, там располагается панель инспектора.
Квадрат это геометрическая фигура состоящая из 4-х углов и 4-х сторон, при чём у него все стороны равны между собой.
Размер полигона определяет количество углов, после чего появляется список точек координаты которых следует ввести, лично я предпочитаю начать с левого верхнего угла и двигаться по точкам по часовой стрелке. Обрисовывая фигуру вокруг центра. По умолчанию, в Godot, центром всех узлов является левый верхний угол сцены. И введение долей пикселя разрешено.
Теперь можно настроить "Transform" и расположить мяч в центре сцены.
Чтоб лучше его видеть нужно слегка увеличить игровую сцену в основной части окна.
Прокручивание скроллера на мышке позволяет увеличивать и уменьшать сцену, а клик на скроллер и перемещение мышки двигать сцену.
Теперь нужно заставить мяч двигаться, и тут есть два основных пути:
- Можно менять настройку "Transform", и двигать мяч так-же как я подвинул его в центр сцены но, с помощью программного кода и плавно.
- А можно добавить к этой графике узел физического элемента такие называют "Твёрдое тело" или "Физический объект". И двигать воздействием физического движка на этот объект.
Физический движок позволяет использовать максимально аккуратные, плавные и правдоподобные движения без необходимости описывать все сложные расчёты самостоятельно.
К тому же, помимо движения мяча нам ещё нужно определять столкнулся ли мяч с границей экрана? Если столкнулся, то с какой из границ? Столкнулся ли мяч с ракеткой? Если столкнулся то с какой из ракеток и с какой её частью? А вот эти вещи легче всего проверять используя физический движок.
Вообще для этого выбора есть очень простая схема. Если все объекты в игре двигаются по сетке и существует очередь движения. Например, в шахматах черный игрок не начнёт свой ход до того как белый игрок свой ход завершил. И никто из игроков не имеет права двигать несколько фигур одновременно.
В таких играх удобно напрямую менять настройки "Transform".
Для всех остальных случаев есть физический движок.
Теперь, думаю, очевидно, что в игре Pong удобней использовать физический движок.
Для этого нужно к мячу, сейчас это узел "Polygon2D" добавить узел "PhysicsBody2D"
Но таких узла три: Kinematic, Rigid и Static. Согласно описанию:
- Kinematic — это физический объект двигающийся согласно написанному программному коду, не подчиняясь физическому движку. (Наш вариант)
- Rigid — это физический объект полностью подчиняющийся физическому движку.
- Static — это неподвижный физический объект.
Аналоги этих узлов имеются во всех известных мне игровых движках, при чём в Unity они имеют такие же названия и свойства.
После добавления узла "KinematicBody2D" появляется уведомление об ошибке.
Наведя на него курсор станет понятно, что причиной ошибки является отсутствие у данного узла маски столкновений "Collider", в данном случае мне предложили на выбор один из двух вариантов: "CollisionShape2D" или "CollisionPoligon2D".
Полигон создавать я уже пробовал, теперь хочу посмотреть на форму. Которая при создании сообщает об ещё одной ошибке. На этот раз она говорит, что маска вроде бы и есть, а форму маски никто не создавал.
Создаётся она на панели "Inspector". Для нашего квадрата подходит форма "RectangleShape2D" со следующими настройками.
Теперь можно начинать двигать мяч по экрану но, физическим движком можно двигать только "Физическое тело" со всеми наследниками и двигаться оно будет относительно своего родителя. В данном случае тело вместе с коллайдером будет двигаться относительно нарисованного на сцене квадрата, который останется неподвижным на экране. Исправить это очень просто:
- Чтоб физическое тело двигалось относительно сцены, его нужно сделать дочерним узлом сцены.
- Чтоб нарисованный квадрат двигался вместе с физическим телом, его нужно сделать дочерним относительно физического тела.
Вот теперь двигая физическое тело я буду двигать маску столкновений вместе с нарисованным квадратом.
Мяч готов двигаться, в следующий раз мы наконец его запустим и посмотрим как это будет выглядеть в игре.
Буду рад вашей критике в комментариях.
Комментарии (13)
valdemar-const
13.09.2019 12:16+1А почему бы не сделать kinematic body корнем сцены? Вы собираетесь логику движения в сцену мяча вставлять? В годо гибкая система сцен. Для такой игры как понг можно было бы сделать, например, сцену с меню и сцену с игрой, в которой и прописать всю логику по управлению и взаимодействием объектов. Благодарю за уроки. Сам давно слежу за годо, хотел попробовать 3д игры делать на нем, но он пока сыроват в этом направлении. Думаю с поддержкой vulkan все изменится в лучшую сторону.
nesqvic Автор
13.09.2019 12:20В конечном итоге, свои сцены будут у всех объектов. И логика будет раскидана по всем объектам, считаю, что так новичкам легче понять процесс.
shalm
Какие должны быть причины, чтоб изучать и использовать godot вместо unity?
nesqvic Автор
Чтоб изучать что либо должны быть причины? Лично у меня ограниченный трафик интернета и я не могу позволить себе качать и обновлять Unity. А почему авторы коммерческих игр предпочитают Unity, Godot, Unreal Engine или Cry Engine спрашивать надо у авторов этих игр.
shalm
Ограниченный трафик — редкая в наши дни проблема, я например смотрел недавно godot и выбрал unity в итоге из-за нескольких причин, но главное это гдскрипт — он узко специализирован под применение только в этом движке, c# много где может быть использован, если с unity захочется расстаться, и второе — те кто пытался работать с godot пишут, что многое не работает или забаговано и реализовать задуманное не получается, и третье — любая встреченная в unity проблема легко гуглится, а по godot кроме документации особо негде поискать решение.
Мне кажется Ваши уроки на unity изучило бы гораздо больше людей.
nesqvic Автор
Спасибо за совет, я к нему обязательно прислушаюсь. Как только закончу данную серию.
Ti_Fix
ScratchUA
Использую Godot более года и сразу уточню, что я не ярый фанат Godot и также на постоянной основе использую Unity.
Первое. Помимо версии с GDScript есть также Mono-версия, в которой используется С# (в ней я и работаю).
Второе. По поводу "пытался работать" — стоило бы уточнить, что именно не получается и каков уровень "попытчиков", а то звучит просто как голословное утверждение.
Третье. Помимо официальной документации по Godot очень много видеоуроков и туториалов. Для поиска решения специфических проблем и общего развития лично мне очень помогают (по степени полезности):
Все сообщества Godot
Минусами Godot (с натяжкой) лично для себя считаю только следующее:
1) отсутствие поддержки формата FBX из коробки (из-за нежелания разработчиков платить за использование проприетарного формата), хотя при помощи Blender FBX конвертируется в DAE в пару кликов.
2) официальный магазин расширений для Godot по масштабам существенно уступает Asset Store, но там есть практически всё необходимое для начала работы и первоначального обучения, причем всё это абсолютно бесплатно. Качество многих решений не уступает коммерческим ассетам Asset Store. В Discord выкладывают очень много бесплатных готовых решений также по качеству не уступающих качественным платным ассетам Unity (где, зачастую, цена не соответствует качеству).
3) Возможности сборки готового приложения под различные ОС (устройства) существенно уступают Unity.
Существенный плюс, который перекрывает все минусы — более продуманная архитектура Godot, которая не тащит за собой Legacy-наследие Unity 14-летней давности.
Сравнение возможностей Unity и Godot
Ситуация Godot vs Unity очень напоминает ситуацию Linux vs Windows: бесплатная ОС с ограниченным количеством качественных бесплатных программ против коммерческой ОС с гигантским количеством качественных коммерческих программ.
shalm
Мне интересна тема процедурной генерации уровней и если я начинаю гуглить " godot процедурная генерация поверхности" все ссылки как это делается в unity. Я даже просто выяснить не смог способен ли godot процедурно добавлять узлы и треугольники в меш и менять координаты узлов.
nesqvic Автор
Увы, тема процедурной генерации пока выше моей головы. Я делал генерацию из пиксельной карты в Unity и это в Godot абсолютно реально.
shalm
Нет там ничего такого уж сложного, из пикселей я делал на питоне, сначала картинку генерировал, а потом из неё 3д карту, но это как трусы через голову одевать. Проще уж сразу составлять нужный объект, добавляя узлы и треугольники.
Tiendil
А разве процедурная генерация уровней специфична для движка? о_О