Игру разрабатывал примерно 4 месяца на собственном игровом движке. Сначала появилась идея об игре-стратегии, сделал экспериментальный прототип и начал развивать дальше.

Разработкой занимался по вечерам и на выходных. Процесс разработки можно разделить на этапы, на каждый уходила примерно 1 неделя:

- Прототип игры: можно строить здания и отбиваться от врагов

- Развитие прототипа: эксперименты с новыми механиками игры, интерфейс, разновидность врагов и турелей, апгрейды для зданий, добыча ресурсов и т.д.

- Планирование дальнейших шагов: продуманы типы зданий, балансировка, типы и разновидности врагов, ресурсов и т.д.

- Разработка системы эффектов

- Создание и балансировка алгоритмов генерации врагов. Враги постоянно "мутируют" и улучшаются, меняются в своих характеристиках.

- 3D графика - модели, текстуры и анимации для всех зданий и типов врагов

- Дополнительные элементы игры: выбор случайных наград, дополнения к зданиям, "способности", которые можно применить во время боя, и т.д.

- Иконки, интерфейс

- Написание музыки и звуковых эффектов

- Поддержка геймпадов

- Перевод текстов (поддерживается английский и русский) - всего около 900 строчек текста

- Оптимизация производительности

- Создание трейлера, скриншотов, оформление страницы игры в Steam

- Всё остальное время: дополнительное тестирование, балансирование, "полировка", улучшения в интерфейсе.

Демо доступна в Steam (добавьте игру в список желаний, если понравилась): https://store.steampowered.com/app/2248390/Citadelic

Встроенный редактор уровней в игре Пайли, который доступен только в режиме разработки.

Эта функция также позволяет мне отделять ресурсы для "demo" и "prod" версий. Демо версии моих игр включают в себя несколько уровней игры, и я использую флаги компилятора, чтобы определить, какие уровни, файлы музыки и т.д. нужно включить в сборку. Так неиспользуемые ресурсы просто не попадают в демо версии.

Кроме того, я использую флаги компиляции для включения или выключения некоторой оптимизации в моём игровом движке. Например, объединение 3D объектов в общую модель не используется в режиме разработки, потому что оно только мешает во время редактирования уровней. Другими словами, движок оптимизируется для редактирования уровней в режиме разработки. В финальных билдах — движок оптимизирован для самого игрового процесса.

Мета данные

В Haxe есть функции metadata, которые могут быть использованы для аннотации, чтения и манипуляции частей исходного кода, который обычно не доступен.

В моём случае, есть класс Settings, в котором есть набор переменных для опций, доступных игроку в меню Опции. Настройки пользователя хранятся в отдельном файле. Этот файл генерируется автоматически на основе класса Settings. Движок бежит по всем переменным класса, и сохраняет или загружает значения из файла. Для этого используется reflection API.

Не все переменные в Settings нужно сохранять в файле, так как там есть и константы, которые менять не нужно. Такие поля помечаются мета тэгом "@ignore(true)". Движок, видя эту аннотацию, не включает такое поле в файл.

Макро

Это самая сложная и самая интересная функция метапрограммирования в Haxe. Macro позволяют запускать реальный Haxe код во время компиляции, который может напрямую модифицировать исходный код игры.

Самое простое применения этому: добавления времени компиляции и номера сборки. Эта информация у меня используется вместо номеров версий. Она всегда обновляется автоматически, поэтому мне не нужно вручную увеличивать какие-то версии.

Но самый большой плюс для меня — это возможность переместить код из run-time в compile-time.

В игре Speebot есть меню выбора уровней, которое показывает, сколько в каждом уровне кристаллов, которые игрок может собрать. Чтобы посчитать количество кристаллов в уровне, игра должна загрузить файл уровня, обработать его, посчитать кристаллы, и выдать число.

Эта логика работает нормально до тех пор, пока не становится необходимо показать эту информацию для 200 уровней одновременно. Игре необходимо загрузить и обработать 200 файлов уровней, что использует много памяти и реально тормозит игру на несколько секунд.

Всего 4 мира, в каждом по 50 уровней. Процент прохождения высчитывается на основе количества пройденных уровней и собранных кристаллов в каждом уровне данного мира.

Конечно, я мог бы вручную посчитать все кристаллы и прописать количества в исходном коде игры, но мне лень. Кроме того, могут появиться ошибки, если я отредактирую уровень и забуду поменять число.

Решение: написать макро, которое загружает все 200 уровней (у макро есть доступ к файловой системе), обрабатывает все необходимые данные, и сохраняет нужные числа в массивы. Игре больше не нужно ничего вычислять в run-time, потому что вся информация на этот момент уже жёстко прописана в исходном коде игры с помощью макро.

Такой же подход используется в игре Путь Фантома. Игрок может найти артефакт, который показывает количество пропущенных секретов, сокровищ, записок и т.д. в каждой области игры на карте. Вместо того, чтобы загружать и обрабатывать информацию всех областей игры в run-time, это происходит в момент компиляции с помощью макро.

Так, полностью пропадает зависание игры при просмотре карты. Кроме того, игра использует меньше памяти, так как не нужно подгружать все уровни сразу.

Сыграть в HTML версию можно здесь https://shaman4d.github.io/games/klondike_solitaire_hx/index...

И сейчас я расскажу как все было.

В начале года проходил конкурс от AirConsole, сервиса, который позволяет запускать игру на компьютере, а смартфоны подключать и использовать в качестве джойстиков.

Таким образом, сразу может играть и при этом не ютиться за одной клавиатурой большое количество людей.

Конкурсы на платформе проходили и в предыдущие годы, но до этого они как-то прошли мимо меня.

Участников в прошлом году было немного, поэтому была надежда на хорошие шансы на победу.

Дело было за малым - найти художника и сделать игру.

К счастью, как раз в это время я познакомился с иллюстратором, который хотел попробовать свои силы в геймдеве.

Оставалось выбрать идею, подходящую под подобное управление, в которую могли играть несколько человек и разобраться с javascript.

Но с джаваскриптом хотелось поработать поплотнее, поэтому была выбрана непосредственно под него библиотека Pixi, которая берет на себя работу с графикой.

Для библиотек на JavaScript существуют обертки (экстерны), которые содержат их описание и позволяет писать типизированный код с нормальным ООП и прочими плюшками (похоже на TypeScript, который появился гораздо позже).

Для AirConsole тоже нашлась своя библиотека, немного устаревшая и без некоторых функций, но вполне рабочая, что вселяло оптимизм.

Порывшись в старых прототипах были извлечены на свет наброски футбола, в который можно было играть вдвоем и выглядевшим в то время примерно так:

В то время там была реализована только базовая механика управления игроком и подсчет забитых мячей.

Физический движок собрался и запустился без проблем и вполне устроил скоростью работы.

Игру было решено делать в минималистичном стиле и первые наброски сразу же были одобрены.

Дальше был отбор популярных футбольных национальных команды, а потом возникла идея добавить соперников, в виде разных монстров и мифологических личностей.

После того как были нарисованы игроки, возникли нюансы с формой национальных сборных, поскольку в разных чемпионатах она менялась и сложно было выбрать однозначную.

В итоге после обсуждения форму и бутсы решили перекрасить под цвета флагов стран.

Добавим немного логики для игры против компьютера и режим чемпионата для азарта и блюдо готово.

Как часто бывает до окончательной готовности не хватило пару дней, поэтому на конкурс игра была отправлена без звука, добавленного позднее, и еще каких-то мелочей.

В конкурсе, как уже понятно из названия, мы не выиграли, но нам предложили выпустить игру у них на платформе.

Поскольку оставались не сделанными мелочи в виде звука и небольших правок, то с выпуском у них мы ничего не теряли и решили попробовать.

Варианты персонажа для платформы:

Игра вышла, специально для них была нарисована фирменная команда, но количество игроков на платформе не очень впечатляет.

Возможно у топовых приложений ситуация получше, но нашей игре из середины списка популярности похвастаться пока особо нечем.

Дальше с помощью вышеупомянутого OpenFL была выпущена версия под Android, где из-за общего языка программирования большая часть кода была переиспользована.

Различные функции, которые специфичны и присутствуют не на всех платформах (реклама, вибрация и тп), реализуются с помощью нативных расширений.

В планах еще множество идей и улучшений, которые будут постепенно внедряться в игру, благо мобилки позволяют это делать очень просто.

Специально для жителей Пикабу был добавлен новый персонаж, который вошел в последнее обновление Android версии - это знаменитая печенька, выступающая под своим флагом с кексиком (огромное спасибо администрации за разрешение).

Чтобы выбрать или сменить команду на первом экране жмите на флаг или знак вопроса.

Ссылка на Google Play: https://play.google.com/store/apps/details?id=com.mokogames....

Если история вам понравилась, играйте и оставляйте свои отзывы и предложения, комментарий для минусов прилагается.

Спасибо за внимание!

Графика конечно же не моя, собирал на opengameart'е, как и музыку.

Поиграть можно тут - http://www.kongregate.com/games/Whited43/snow-run

В любом случае, опыт есть опыт, происходит общее понимание логики игр, да и если не программировать,  то со временем всё забывается.

Первую свою игру я писал на Libgdx, писал ее для попытки продажи на сайте envato market, но ее не приняли, не указав причин, потом решил просто тренироваться в программировании игр, а не задаваться целью продавать. Да я читал, что некоторые продают flash-игры на сайте FGL за 1-2 тысячи долларов, конечно, сейчас было бы очень актуально, но все же я решил немного поучиться сначала, Вот планирую после НГ написать игрушку на Construct2.

Может на PIKABU есть еще геймдевелоперы, кто на чем пишет? Интересует именно не команды, а в одиночку, т.к. этот путь более тернист)