О котах, снах и разноцветных цветах
TLDR: Будет много про текста про Godot, про муки разработки и геймдев в целом. Кода в тексте не будет(могу залить на GitHub для особо страждущих). Внизу есть ссылочка на играбельные билды и брейншторм доску в Miro.
Заголовок прочитали? Вдохните поглубже. Представьте сон — вы на даче и видите, как из дома выбегает куча котов. Они разбегаются по саду, мяукают, прыгают, запутываются в каких-то растениях и, внимание, начинают тихо обрастать корнями, врастать в землю, превращаясь в цветы. Выдохните.
Скажу честно, когда мне рассказали этот сюжет я подумал, что это кошмар уровня кладбища домашних животных — не так давно я сам расстался с верным пушистым другом и похоронил с почестями на даче возле его любимого дуба (куда он залазил и орал часами). Но рассказчик был уверен, что на самом деле было весело распутывать котов из губительных корней во сне.
КОТЫ ПРЕВРАЩАЮТСЯ В ЦВЕТЫ. CПАСИ ИХ.
Как ни странно, но эта мысль зацепила. На том и решили – игре быть! Только уберем очевидный могильный подтекст о конечности любого бытия…
Идея есть, вроде даже оригинальная, осталось самое простое реализовать её! Нужно всего лишь… найти движок, программиста, UX дизайнера, художника, подобрать ассеты и визуальный стиль, подумать о монетизации, продвижении, ретеншене игроков, распланировать бюджет и майлстоуны, организовать плейтесты, раздать ключи стримерам и ютуберам. Ладно я шучу. Ничего такого в этой статье не будет.
О чем речь?
Простая 2D top-down (хоть и выглядит как изометрическая) спрайтовая гиперказуальная игра, геймплей которой состоит из простого таскания разбегающихся по статичной карте котов в коробку. Звучит просто да?
Как назвали: Garden Cats
Движок: Godot Вы ожидали Unity? Unreal? Давайте будем честны здесь хватило бы и простого фреймворка типа Love для Lua или PyGame — использовать что-то крупнее не имело смысла.
Без лишних слов
Почему Godot?
- По золотому стандарту «больших» движков имеет кучу готовых фич из коробки для разработки любого типа игр (навигационные меши, физика, спрайты, тайлы, звук, шейдеры, рейкасты и тд), которые реально очень легко использовать в режиме plug&play.
- Есть готовые элементы UI. Вам все равно придется скорее всего пилить свой интерфейс для более-менее серьезного проекта, но для прототипов и отладки 10/10.
- Имеет встроенные сигналы для общения между объектами, которые на самом деле реализуют паттерн Observer, с ним приятно работать, а не изобретать свой велосипед для передачи событий.
- Синтаксис осилит без подготовки любой script-buddy знающий в принципе любой язык (особенно Lua или Python)
- Документация суховатая, но достаточно полная. Сейчас уже довольно много контента от комьюнити в сети.
- Сам движок кроссплатформенный и представляет собой… 1 исполняемый файл меньше ста мегабайт! Можно таскать на флешке вместе с самим проектом.
- Релизные сборки под Win/Android у меня заняли всего по 30мб каждый (для Android правда нужно еще доставить ADB и JDK на рабочую машину).
Из минусов:
- Пока на Godot не очень много успешных коммерческих продуктов.
- Если не начать думать сигналами и независимыми сценами можно запутаться в коде и логике (я называю это godot-way)
- Проект нужно готовить правильно (структурировать папками, скрипты хранить отдельно, не налегать на инспектор, чтобы эффективно работать в команде через Git (разгребать конфликты в сценах – не весело)
- Платформы: Godot может все – но разбираться с XCode/AppStore не хотелось, так что пока только Android/Win.
Все по полочкам
Да, это первая законченная игра. Было много различных попыток в рогалики на Python, в тайкуны/кликеры на Lua, но именно эта прошла полный цикл от идеи до готового релиза (хоть и на уровне MVP). Именно в этом проекте получилось выделить нормальные игровые циклы и связанные между собой четкие механики.
Команда: я в качестве программиста (хотя мой Python код как малокские табуреты), друзья-знакомые-родственники, которые играли в промежуточные билды и давали фидбек, остальное закрывалось через открытые и бесплатные (некоторые не совсем) музыку, звуки, спрайты. Коты авторские. Художник работал натурально за еду.
Инструменты: Paint.net для правки спрайтов, Miro для всех схем и канбана задач, звук конвертировал и обрезал в онлайне.
Дедлайн: 3 недели. Дедлайн?! В моей гиперказуалке с 1 экраном, да люди такое за день делают, н?! Но вышло так — одна неделя на MVP, неделя на основной цикл и главные фичи и последняя неделя на полировку и дебаг. Добро пожаловать в прекрасный мир геймдева. При этом нужно еще работать и уделять время семье.
Мотивация
Вообще, дедлайн был выбран не случайно, в то время разогревались минимум 2 джема-хакатона на DTF, которые разрешали готовые проекты и MVP:
К слову сказать, в этот график до хакатонов я уложился, ибо ставил реальные цели. И когда есть сроки – есть пассивная мотивация что-то делать каждый день.
Деньги не были особо мотивацией, ибо у меня есть вполне любимая работа да и пилить я собрался явно не три-в-ряд-аниме-адалт-гачу, чтобы бороться за CTR. Фейкшоты и (не)геймплейные ролики тоже рука не поднимается делать.
А какие были цели:
- 2D игра в один экран (sprites, animation)
- Котов можно ловить и таскать (drag’n’drop)
- Коты бегают по игровому полю (navigation mesh и простой pathfinding)
- Коты могут решить стать цветами (state machine)
- Котов нужно всех успеть перетаскать в коробку пока они все не стали цветами (game goals, core loop)
- Подсвечивать объекты при наведении (outline shaders) — я выпилил из финального билда за ненадобностью, хотя работали.
Когда делал: по утрам, до работы c 8 до 10-11 благо график позволял. Третью неделю был в отпуске, но там так же по 2-3 часа каждый день.
А почему бы не работать над игрой больше, чем 3 часа в день, особенно в отпуске? Качество и оригинальность кода падает экспоненциально со временем непрерывной работы. Начинает банально "подгорать". Очень хотеться все бросить или еще хуже «переписать все заново, но в этот раз «лучше»». Это ловушка перфекциониста из которой очень сложно выбраться. Так что лучше маленькими порциями каждый день, чем кранчевать сутками. Не стоит переживать что делаешь плохо, главное делать гибко чтобы потом можно было отрефакторить куски кода, от которых кровоточат глаза, не ломая весь проект по пути.
Про курсы и книги
Помогло умение правильно сформулировать вопрос чтобы получить более-менее релевантную выдачу в поиске. Официальная документация ваш лучший друг, видео на Youtube могут только направить в нужное русло/подсказать/вдохновить. Они довольно быстро устаревают как по синтаксису так и эффективности решений. Курсы по Godot, разумеется, уже доступны. Но лучше начать с более абстрактных вещей типа структур данных, алгоритмов поиска пути игровых циклов и т.д. Я быстрее уперся в ограниченность фундаментальных знаний и приемов (как делать что-то?), чем в ограничения движка (используя что сделать?)
Чему научился
- Лучше писать код чем менять параметры редактора или инспектора. Когда только начинаешь есть большой соблазн все делать через редактор. Сигналы там посоединять, настраивать позицию и размеры нод в инспекторе. Но чем сложнее и динамичнее ваша игра, тем быстрее вы придете к логичным ограничениям этого подхода — когда сцены и ноды и просто забьют ваше дерево проекта. Эффективно создавать/управлять/изменять/удалять множественные объекты или группы объектов можно только через код. Плюс, очень сложно через 2 недели разработки вспомнить, где ты выключал маску коллизии на объекте и главное почему, а код помнит!
- Patterns matters! Паттерны дизайна и программирования были придуманы умными людьми и не просто так. Изначально я сделал прототип на наивном подходе используя десятки ветвлений (if/match statements), и оно работало просто непредсказуемо. Когда я переделал «это» на машины состояний (FiniteStateMachine) я очень сильно упростил себе жизнь и дальнейшую разработку/масштабирование. Изучайте паттерны для решения конкретных задач, но помните, они имеют свои недостатки и генерируют специфичные баги.
- Планируете поток данных и ресурсов. Я использовал сигналы встроенные в Godot для передачи информации наверх к родителю (от кнопки/объекта до основного цикла игры). Для передачи информации вниз от основного цикла до объектов — вызывал напрямую методы объектов проверяя что они есть. Для оповещения множества объектов использовал call_group. Можно, конечно, попробовать сделать все через сигналы в обе стороны – но есть большой шанс все только усложнить на простых проектах. Про эффективную организацию потока данных между объектами можно читать/говорить очень много.
- Мечтают ли загрузочные экраны об SSD? Загрузочные экраны и создание/удаление объектов в фоне нужны и важны. Когда вы услышите, как похрипывает звук и дергается экран при создании 25+ объектов на телефоне – вы поймете, о чем я. Я не заморачивался особо с этим, но даже на уровне такой простой игры сталкивался с артефактами внезапного создания ресурсов без предварительной загрузки.
- День независимости. Один из столпов godot-way на мой вкус. Делайте сцены независимыми – она должна запускаться и существовать без ошибок изолированно. Как и вся ваша игра должна в идеале запускаться без одной какой-то сцены. Это не просто, но того стоит — позволяет избавится от некоторых ошибок интеграции и взаимодействия подсистем и позволит тестировать более эффективно.
- Все придумали до нас. В Godot очень много готовых инструментов/нод для решения почти всех задач –не нужно двигать спрайты по пикселям, когда есть навигационные меши и физические тела с готовой физикой столкновений.
- Тестируй! Тестируйте то, что делаете, на самом раннем этапе. Смело добавляйте отладочную информацию прямо над объектами, рисуйте маршруты вашей навигации, проверяйте как работают коллизии – выключите перед сборкой. Пока я не начал рисовать маршрут навигационных мешей я вообще не понимал куда и почему топают коты. Делайте тестовые площадки для отладки нового функционала. Я пожалел, что не такую для отладки выбора анимации кота в зависимости от направления движения. Запускать всю игру раз 20 просто чтобы убедится, что 1 кот ходит правильно в нужную сторону невероятно тупо. Уверен при должном упорстве можно даже организовать автоматические тесты для выделенных сцен
- Настоящий дизайн и интерфейсы — это сложно. Что выглядит нормально на экране ПК – может выглядеть совершено ужасно даже в горизонтальном режиме на телефоне. Грамотный UI – это целая наука, а не просто кнопки в случайных местах. Не умеете рисовать, проектировать интерфейсы – не делайте это. Используйте временные заглушки и подсмотрите интерфейс уже у существующих проектов. Подобрать готовые production-ready спрайты, звуки и музыку даже для прототипа – очень непростая задача не важно если вы готовы заплатить за это. У меня не было видения визуального стиля игры почти до самого конца (да и сейчас его считай нет) – хотя с этого стоило бы начинать.
Что не успел/забил:
- UI – он был добавлен в самом конце по принципу костыли и палки. Он ни черта не динамический и не красивый. Не нужно так.
- Не до конца разобрался со звуком. Все эти bus’ы, bypass флаги, которые починили заедания звуков – они просто работают, но я не уверен как
- Профилирование – не смотрел ни на производительность, ни на потребление ресурсов — очень велика возможность утечек, запускал пару раз симуляцию на 100 котов – вроде норм; )
Вместо заключения
- Понравилось, что получилось в итоге – вполне, покрыло мои скромные ожидания.
- Сделал все что планировал — да.
- Понравилось делать – 50/50, была пара очень унылых итераций, состоящих из сплошных багфиксов.
- Буду продолжать работу над этим проектом – спорно.
- Буду делать новый проект – да, позже, используя полученные наработки и опыт. Очень хочется попробовать сеть.
- Буду участвовать в джемах от издателей — нет. Если вы не планируйте коммерческий продукт изначально, лучше вытащить продукт на публику и собрать все помидоры, чем просто месяц ждать письма "у вас низкий CTR". Автор статьи снизу вполне прав, хоть я и не испытывал никаких надежд по поводу хакатона или джема. В следующий раз, только для души, для себя или просто "just for lulz".
Страница проекта на Miro (для тех кто любит творческие страдания): https://miro.com/app/board/o9J_kqoD_TE=/
Скачать последние билды для Win/Android можно тут:
Братан, заходишь к издателю - он тебе в ноги фичер кидает, ты главное смотри за ним не нагибайся, спросят какие метрики мониторишь - говори что мужику за дашбордом не место и вообще воронки поцаны нормальные не бьют. Нарисуют на вайтборде график инсталлов - скажут дорисуй, но ты стой ничего не делай, если чего скажешь что органику ждешь
Комментарий недоступен
Комментарий недоступен
Комментарий недоступен
Комментарий недоступен
Комментарий недоступен
Да. Не вижу причин не делать этого.