GDevelop — игровой движок, как Unity или Unreal, но более простой. Основное отличие GDevelop заключается в акценте на визуальное программирование, где игровые механики разрабатываются с помощью готовых блоков и функций, без необходимости писать код вручную.
В этой статье я рассматриваю GDevelop как дополнительный инструмент разработки для T-shaped специалиста в e-learning. Если вы уже работаете в каком-то конструкторе курсов и ищете дополнительный инструмент, который расширит ваши возможности, — эта статья для вас.
Дисклеймер: в статье я гораздо больше говорю о минусах движка. Это не значит, что движок плохой, мне не понравился, и я считаю, что он совершенно не подходит для задач e-learning. Наоборот, он мне понравился, это был интересный опыт. И вполне возможно, он сможет решить не одну вашу задачу (ну или как минимум вы с интересом проведёте время). Очень важно знать о минусах и ограничениях перед тем, как начнёте разбираться в инструменте, правда?
Как выглядит визуальное программирование в GDevelop?
В GDevelop можно задать объекту определенные поведения и просто настроить параметры в таблице:
Либо настроить триггеры самостоятельно (я тут просто игрался, исключительно пример, а не руководство к действию):
Вот так это выглядит в Unity:
Про простоту
Тут проще один раз показать.
Вот так выглядит интерфейс Unity:
А вот так в GDevelop:
Внизу — слои. Если у вас есть опыт работы в Storyline, Illustrator, Photoshop, Figma, да и ещё много где, — здесь сразу всё будет понятно. Справа у нас список объектов на сцене. Слева — настройки. В дополнительной вкладке — визуальное программирование.
Через две минуты уже, по большому счёту, понятно, что где находится и что примерно со всем этим делать.
Для большей убедительности покажу процесс экспорта (публикации) игры. В GDevelop выбираем, под какую платформу хотим собрать игру: ПК, iPhone, Android или web (в нашем случае web, ведь мы хотим сделать курс и загрузить его в LMS)...и всё. Игра собрана. Собираем её в архив и можно загружать.
В Unity у нас целый вагон дополнительных настроек, и большая часть из них важна, особенно если мы собираем 3D-проект. Например, если вы сделаете простой проект, но включите классные, современные тени, то на офисных компьютерах и смартфонах всё это великолепие будет ужасно тормозить. Нужно разбираться.
Плюсы
1. Визуальное программирование
Его проще освоить, особенно если вы никогда не работали с кодом. Если вам знакома система триггеров того же Storyline или логика интерактивов в iSpring, вам будет проще вспомнить, как здесь всё устроено, даже если долго не работали с движком. А это очень вероятно, ведь далеко не каждый проект нуждается в сложных механиках, так что, скорее всего, GDevelop вы будете включать раз в год. Из собственного опыта скажу: год не поработав в Unity, я практически полностью забыл всё, что знал про C# (ну, не совсем всё, но без помощи Google или копания в старых проектах я ничего не сделаю). С визуальным программированием таких проблем не будет: все функции перед глазами. Нужно только потратить немного времени на поиск нужной.
2. Готовые наборы базовых механик
Базовые механики разрабатываются без программирования и без необходимости искать, скачивать и разбираться в ассетах. Можно сказать, что несколько десятков базовых ассетов (разного качества) уже встроены в сам движок. Например, накидываем на персонажа поведение «персонаж платформера», и наш герой уже может бегать по локации, прыгать, на него будет действовать элементарная физика, и он не провалится сквозь землю. Добавляем поведение «Аниматор персонажа платформера», вот и анимации добавлены. Буквально в пару кликов и всё готово. Удобно, правда?
3. Бесплатно
Конечно, есть и платные лицензии, но для наших задач они не несут практически никакой пользы.
4. Работает как на ПК, так и просто в браузере
Каждый сможет выбрать для себя наиболее подходящий вариант. Версия для ПК однозначно намного удобнее. Есть возможность установить? Лучше так и сделать. Но, понимая реалии корпоративной разработки, крайне маловероятно, что нам разрешат что-то установить на рабочий компьютер. Поэтому можно открыть движок в браузере (если он не заблокирован ИБ) и пользоваться. Бонусом получаем возможность работать над одним проектом вместе с коллегами и совсем небольшое (на бесплатной версии) облако для хранения проектов. Можно даже на смартфоне запустить и разрабатывать игры. Такого я ещё не видел (я не понял, в какой ситуации мне может понадобиться разрабатывать игру на смартфоне, но это забавно).
5. Разработка игр с ИИ
Об этом я делал отдельный пост в своем канале в телеграм. Если кратко: прикольно, но пока работает не очень хорошо. Сомнительно, что это можно применить не просто «по приколу», а для какой-то задачи. Но, возможно, функционал доработают и тогда действительно будет полезно.
Минусы
1. Самый важный минус — ограниченный функционал
Особенно сильно это ощущается при работе с 3D.
Возьмём простой кейс: хотим сделать диалоговый тренажёр в 3D.
Лицевая анимация (чтобы у персонажей была адекватная мимика), задача не самая базовая даже для более сложных движков. В GDevelop её сделать практически нереально (только с невероятно большими костылями). Анимация разговора (чтобы персонаж открывал рот, когда говорит) — тоже задача не для GDevelop. Опять же, не говорю, что это сделать прямо невозможно. Но чтобы все выглядело хоть немного адекватно — очень сложно (и долго). Не для этого движок. Да даже просто, чтобы персонаж следил за тобой, смотрел тебе в глаза и поворачивал голову — тоже не для GDevelop кейс.
Красивые тени — тут их нет. Интересное освещение — тоже нет.
С 2D всё проще. Самый большой минус (для меня) — отсутствие костной* анимации (она есть в бета-тестировании, так что, возможно, скоро появится в каком-то приличном виде).
*если очень просто: в 2D есть два основных вида анимации — покадровая, когда каждый кадр мы рисуем отдельно и меняем их несколько раз в секунду (как в старых мультиках Диснея, да и практически любых других), и костная, когда мы «разрезаем» персонажа по суставам (кисти отдельно, предплечья отдельно и всё остальное отдельно) и двигаем нужные части тела. Покадровая анимация, даже с нейросетями, это сложно и дорого. Костная — это просто и быстро. Вот просто и быстро не получится (пока).
2. Мало ассетов*
Количество готовых материалов для GDevelop и для Unity или Unreal отличается многократно. Даже крупные студии нередко используют готовые материалы (зачем нам рисовать огонь или дубы, если их можно скачать бесплатно или за совсем небольшие деньги?). В нашем случае ассеты — единственный возможный вариант для разработки чего угодно в 3D.
*Нужно отметить, что ассеты на любую базовую механику есть.
3. Производительность
С одной стороны, настройки графики и вообще всего происходящего выставлены так, чтобы всё работало максимально просто и, следовательно, не потребляло слишком много ресурсов. Для простых проектов этого будет более чем достаточно. Но если мы решим собрать что-то более сложное — здесь простых настроек и технологий нам не хватит. Как-то дополнительно оптимизировать проект у нас не получится.
4. Маленькое и непрофессиональное сообщество
Эксперты по GDevelop, естественно, есть. Существует несколько каналов на YouTube, где специалисты доступно и понятно всё объясняют (один из каналов — от самих разработчиков движка), но в любом случае сообщество принципиально меньше, чем у Unity или Unreal. Попробуйте написать «как сделать 'что угодно' в Unity» в поиске на YouTube — вы получите десяток видео, где разбирается кейс, похожий на ваш. С GDevelop пользоваться поиском особо нет смысла. У вас есть буквально несколько каналов — если там ответа нет, значит, его нет.
Отдельно стоит сказать про использование ИИ для разработки игры. Языковые модели очень плохо разбираются в GDevelop. Спрашивать у них совет, просить помочь найти решение — практически не имеет смысла. В случае с Unity или Unreal ИИ отлично поможет с разработкой игры. Да, уроки на YouTube всё равно лучше и полезнее. Если хотите сделать какую-то важную механику, которая будет стоять в основе геймплея, — совершенно точно лучше узнать у человека, как это сделать. А вот вопросы по документации или небольшие куски кода — тут ИИ отличный помощник (которого у GDevelop нет).
Варианты использования
1. Самое очевидное — мы можем делать сложные проекты, например, симуляции рабочих процессов.
Какие есть «но»?
GDevelop не умеет в VR и AR, да и вообще, для симуляции работы условного бурильщика движок слишком слабый. Если хотим сделать симуляцию работы магазина/отдела/бизнеса (последнее — верхнеуровнево), — вот тут пожалуйста.
Симуляция работы магазина — сложная задача с точки зрения продумывания логики и механики всего происходящего. Поверхностно изучить/вспомнить C# намного проще, чем пытаться уместить логику сложных процессов в ограничения движка.
Очевидный тренд на уменьшение time-to-market. Точно ли найдутся проекты и ресурсы под такую задачу?
Уж если мы хорошенько вложились в какой-то проект, мы, скорее всего, хотим, чтобы проект жил долго. Не поменяется ли через месяц/полгода/год что-то в бизнес-процессах, из-за чего нужно будет вносить горсть правок в проект? Внесение правок в подобные проекты занимает принципиально больше времени, чем в обычные курсы. Хватит ли у вас ресурсов?
Может показаться, что я отговариваю от разработки подобных проектов, но это не так. ЦА большая, бизнес-процессы практически не меняются годами, ресурс на разработку есть, и вы понимаете, что подобная симуляция решит задачи — нужно делать, а GDevelop вполне можно рассмотреть как один из возможных инструментов.
2. Частичная замена Articulate Storyline
Есть необходимость делать сложные интерактивы, но возможности купить лицензию. Articulate нет — можно рассмотреть GDevelop как возможную альтернативу.
Нужно сделать акцент на том, что движок хорошо подойдёт именно для частичной замены, чтобы создать интерактив и вставить его в лонгрид или слайдовый курс в iSpring. Делать полноценный слайдовый курс совершенно нецелесообразно. Движок ориентирован на разработку игр, и хотя в нём есть некоторые механики, за которые мы любим Storyline: удобная работа с переменными, понятные триггеры, ховеры на кнопках. Но слоёв, тем более упаковки в SCORM и разнообразных шаблонов тестов в нём нет. Time-to-market получится запредельным (особенно в первый раз, когда будем создавать шаблон для упаковки всего этого в SCORM, а если захотим сохранять прогресс, а мы, по-хорошему, должны захотеть, — это будет вовсе не простой задачей).
3. Расширение возможностей в интерактивах и упражнениях
Здесь я в первую очередь говорю про 3D.
Например, мы хотим показать что-то со всех сторон, условно какую-то деталь или оборудование. Да, мы можем сфотографировать его с нескольких ракурсов, приложить какую-то схему/чертёж или снять на видео. В некоторых случаях один из предложенных способов будет более эффективным, в других будет понятнее, если можно будет покрутить 3D макет. А если макет будет интерактивным, например, деталь можно будет разобрать, то 3D модель, скорее всего, выиграет. «Вот так выглядит огнетушитель. Ты уже изучил, за что тут дёргать и куда нажимать — давай теперь на практике подёргай и понажимай».
На примере ниже добавлена интерактивная модель персонажа в лонгрид в Rise. Его можно крутить, перемещать, кликать на кнопки, и что-то будет происходить (в нашем случае меняются анимации).
Какие есть «но»?
А где мы возьмём модель «огнетушителя»?
Стоки с 3D моделями, скорее всего, рассматривать нет смысла, особенно если нам нужна какая-то уникальная модель.
Модель можно заказать на фрилансе или в студиях.
Разработать модель самостоятельно. Не могу сказать, что задача собрать «огнетушитель» (или любой другой объект с простой геометрией, небольшим количеством деталей и в реалистичном стиле) сложная. Открываешь Blender и делаешь кальку с фотографии (если вы перерисовывали чертежи, подложив под них стекло и лампу — вы понимаете, о чём речь). Сама механика разработки 3D моделей простая, но Blender или любой другой софт для 3D моделирования имеет безумно сложный интерфейс. Это совершенно точно не та программа, в которой можно полгода ничего не делать, а потом открыть и что-то собрать. Скорее всего, придётся смотреть гайды с самого начала и вспоминать, в какой вкладке меню находится нужная функция.
Сгенерировать модель в ИИ. Конечно, 3D модели ИИ генерирует далеко не так хорошо, как картинки, текст или код, но, немного терпения, десяток генераций, и мы сможем получить что-то, что потом просто доработаем «напильником» в Blender и получим адекватный результат. Однако ИИ справится не с любой задачей. Сложный станок с большим количеством деталей сгенерировать не получится. А вот огнетушитель, пожалуйста, даже без напильника:
Конечно, нейросетям нужно просто дать ещё немного времени. Уже появляется специальный софт, который позволяет походить возле оборудования с iPhone (если у вас новая Pro модель с датчиком LiDAR), поснимать его со всех сторон и получить относительно адекватную модель.
4. Имиджевые проекты
Нужен ВАУ-эффект. Что-то такое, что будет выделять курс на фоне остальных. Что-то, что покажет «смотрите, как могём!». Или нужен проект для внутреннего маркетинга или вишенка на торт большого проекта — вот тут GDevelop справится отлично.
Итог
GDevelop — безумно интересный движок. Он прост в освоении. Что-то, что будет работать, получится у вас буквально за час (да, это не будет какой-то глубокий и сложный проект, со сложными и разнообразными механиками, но всего за час с нуля!). Хорошо подойдёт как инструмент, которым вы пользуетесь «по случаю», для решения небольших задач. Также это отличный промежуточный этап между чем-то совсем простым, как iSpring, и относительно сложным, как Unity или Unreal. Разберётесь с базовой логикой, с 3D объектами, набьёте шишек и сможете переходить (если потребуется) к чему-то более сложному.
Сложно понять, а вообще нужна ли нам условная «симуляция работы магазина в 3D с элементами геймификации», будет ли это эффективно? С GDevelop можно не очень затратно проверить теории и сделать вывод, а нужно ли вам это вообще.
Сделать в нём что-то интереснополезное или полезноинтересное (что лучше) совершенно точно можно.
Кстати, я веду свой канал в Телеграм про разработку курсов. Рассказываю о своем опыте и простых решениях сложных задач, в том числе про новые инструменты в e-learning. Присоединяйтесь.