Я получил тестовое задание от Volka Games написать простую изометрическую игру. С учетом того что я ни разу даже не слышал о такой вещи как Haxe хотелось сразу отказать, но высокая вилка сделала свое дело.Сделав его за отведенный срок я получил отказ. Как всегда без внятной обратной связи. Поэтому хочу поделиться результатом своей работы.
Где в 2023 году искать настоящую нативную кроссплатформенность?
Я прошел Golang → Rust → C# → Python → Java → Kotlin → Free Pascal, в поисках мультиплатфореммнного GUI, для десктопов и мобильных и кое что нашел.
Многие считают что web или pwa это и есть кроссплатформенность, многие считают, что это Flutter или electron, но что там на самом деле?
Процесс разработки можно назвать тогда оптимальным, когда он приносит максимум прибыли с минимумом затрат. Как утверждают классики политэкономии, если одна компания выстраивает все процессы так, что ее продукт получается в два раза дешевле, чем у других, то при прочих равных она получает в два раза больше прибыль, чем другие. И так продолжается до тех пор, пока остальные не введут те же усовершенствования, и ситуация на рынке не выровняется. Цель понятна. Теперь, как этого можно добиться в разработке игр.
Одна из самых больших статей расходов в IT-компаниях — это программисты. К тому же самая сложно управляемая и контролируемая статья. Административные меры тут работают плохо, и чтобы эффективно воздействовать на программистов, нужно самому, минимум, быть программистом. Поэтому опишем чисто программистские меры и способы по снижению затрат и увеличению производительности.
Прежде мы рассмотрели отделение логики отображения от графики, а также разные вспомогательные классы и менеджеры. Все вместе они образуют каркас наших приложений и были вынесены в отдельную библиотеку — Core Framework. Осталось еще разработать методику по написанию остальной логики. В нее входит бизнес-логики и правила игры, данные и их обработка, а также взаимодействие с сервером.
Вся логика будет разбита на слои. Основной смысл слоев тот, что классы одного слоя максимально независимы от классов с соседних слоев и абсолютно независимы от остальных. Все это уже относится не к основному фреймворку (Core Framework), а к фреймворкам для разных групп жанров (Base Game Frameworks) и для каждого отдельного жанра (Game Frameworks).
Рассмотрев компоненты в общем виде, можно приступить к построению полноценного приложения на их основе. Первым делом нам нужно реализовать смену экранов и показ диалогов. Потом мы добавим возможность конфигурировать приложение и легко подставлять измененные реализации классов с помощью инверсии управления (IoC). Используя IoC-контейнер как контекст приложения создадим возможность запускать параллельно несколько игр в одном приложении, что позволит проводить сеансы одновременной игры, как это делается, например, в шахматах или в онлайн-покере. Под конец мы добавим централизованный доступ к ресурсам, локализации и управлению звуками, а также сделаем свою реализацию для логов и сигналов как более экономичную замену событиям.
Все вместе уже можно будет считать вполне оформившимся игровым фреймворком.
Всякая игра — это прежде всего то, что пользователь видит на экране и с чем он взаимодействует посредством устройств ввода (мышь, клавиатура, джойстик). То есть игра — это в первую очередь отображение. Простая игра так может и остаться отображением навсегда. В более сложной — приходится выделять также менеджеры, модели, сервисы, контроллеры. Но об этом в потом. Тут же мы начнем с графики и ее непосредственным управлением.
Метод нашей разработки прост. С одной стороны, чтобы избегать дублирования, мы будем выносить блоки кода сначала в цикл или функцию, потом в класс, а затем и в библиотеку. (И так до тех пор, пока у нас не появится фреймворк.) С другой стороны, мы будем ограничивать себя, создавая только тот код, который нужен именно сейчас, не фантазируя наперед о том, что может или не может понадобиться в будущем. Вот простая пара принципов: избегать дублирования и при этом не усложнять сверх необходимого.
Все примеры реализованы на Haxe + OpenFL), но код должен быть понятен всем, кто знаком с семейством языков ECMAScript. Главное же тут не код, а те идеи, которые за ним лежат.
Скорость разработки и качество кода — вот, пожалуй, одно из главнейших противоречий IT-индустрии. Можно долго продумывать архитектуру приложения, потом ее совершенствовать, улучшать, а в итоге так ничего и не сделать. А можно быстро что-то сварганить, а потом и зарелизить, но из-за ошибок проектирования завести весь проект в тупик. На каждые два часа разработки, шесть часов будет уходить на поиск и исправление багов, в результате чего вся последующая разработка фактически застопорится.
Таким образом, вопрос: качество или скорость переходит в проблему: хороший, но вечно незаконченный проект или хоть как-то, но работающая программа. Любой менеджер как реалист, естественно, выберет второе.
Так и получается, что куда ни ткнись, у всех код если не дрянной, то по меньшей мере неважный. То, что называется многозначительным словом legacy. Все всё понимают, плюются, но поделать ничего не могут. Код уже есть и с ним нужно работать. Все предложения по улучшению не приветствуются, а то и прямо запрещаются.
Как тут быть, что поделать? Попробуем разобраться.
На сегодняшний день у меня выпущены четыре игры в Steam, и все они написаны на языке Haxe. Мне нравится по-максимуму автоматизировать свою работу, и сегодня я поделюсь некоторыми приёмами, которые я использую при программировании своих игр.
Для непосвящённых: Haxe — это язык программирования и кросс-компилятор. Это значит, что можно написать игру на Haxe, и она автоматически "переводится" на другой язык программирования, в зависимости от выбранной платформы (C++ для Windows, JavaScript для Web, и т.д.), и компилируется в нативную программу для той платформы.
У языка есть несколько полезных функций метапрограммирования, которые используются для написания кода, который, грубо говоря, сам себя меняет. Эта статья — не туториал и не руководство, а просто несколько примеров того, как такие приёмы могут быть использованы в разработке компьютерных игр.
Кстати, некоторые из этих функций есть и в других языках, но могут называться по-другому. Так что эти идеи могут пригодится не только тем, кто пишет на Haxe.
Много лет назад я занимался созданием маленьких Flash игр и публиковал их на сайте Newgrounds. Сейчас я делаю полноценные игры для ПК.
На сегодняшний день у меня 4 законченные коммерческие игры в Steam, и самая последняя из них — выпущенная в 2021 году Pilie Pals, о процессе создания которой я расскажу в этой статье.
Я работал над игрой всего примерно 6 месяцев, по вечерам после работы и на выходных. Я занимаюсь дизайном, программированием, графикой, звуками и музыкой в одиночку, и использую свой собственный движок 3D игр.
Речь идёт о игре Speebot, которая была выпущена в Steam в 2017 году.
Я разрабатывал эту игру с января 2016 года в своё свободное время в одиночку. Мною выполнено всё программирование, дизайн игрового процесса, создание графики и музыки. Кроме того, я написал собственный игровой движок с нуля.
Люди часто спрашивают меня, почему я решил создать свой движок, когда на рынке доступно множество бесплатных универсальных движков. Есть много причин, и о них я попытаюсь рассказать в этой статье.
14 октября состоялась небольшая онлайн-конференция HaxeIn 2020. Одним из докладчиков был Александр Кузьменко — разработчик компилятора Haxe.
Доклад Александра — это отчет о работе, проделанной с февраля 2020 (когда состоялся HaxeUp Hamburg, организованный компанией Inno Games). Предлагаю вашему вниманию расшифровку его выступления.
Наш игровой движок Heaps.io и набор инструментов и технологий, на котором он основан, являются результатом опыта, накопленного за двадцать лет, посвященных созданию игр: сначала в компании Motion-Twin (создатели Dead Cells), а с 2012 года в Shiro Games (Evoland, Northgard и Darksburg).
Названные игры (2D и 3D) были созданы с использованием стека библиотек и инструментов, исходный код которых был открытым с самого начала, и которые продолжают развиваться и поддерживаться.
Так как меня часто спрашивают о том, как мы создаем игры, то я подумал, что было бы неплохо поделиться подробностями обо всех элементах технологического стека Shiro Games. Он прекрасно подходит для наших задач, так что возможно он может подойти и другим компаниям.
Предлагаю вашему вниманию перевод доклада Роберта Конрада с прошедшего в октябре прошлого года HaxeUp Sessions 2019 Linz. Данный доклад посвящен процессу портирования на консоли игры CrossCode, изначально написанной на HTML5. Если вам понравится перевод, то рекомендую также посмотреть его в оригинале на английском — Роберт очень веселый человек, постоянно шутит и его интересно слушать.
Немного об авторе: Роберт работает программистом в Deck13, одной из немногих игровых компаний, использующих свои собственные технологии (именно поэтому Роберт и выбрал эту компанию). В основном его работа связана с оптимизацией (например, недавно выпущенной игры Surge 2).
В комментариях к переводу доклада с HaxeUp Sessions 2020 Hamburg — Зимний отчет о состоянии Haxe — был задан вопрос о том, зачем нужен Haxe. На него, конечно же, ответили там же, в комментариях. Предлагаемый вашему вниманию перевод еще одного доклада с прошедшего HaxeUp должен, по моему мнению, стать дополнительным аргументом в защиту Haxe, т.к. данный доклад посвящен игре, заработавшей более 500 млн. евро.
Автор доклада Ненад — один из программистов InnoGames, работавших над конвертацией Forge of Empires из ActionScript в Haxe. 2 года назад в Амстердаме InnoGames рассказывали о своей работе в данном направлении. Сегодня же можно сказать, что им это удалось в полной мере — теперь обе версии веб-клиента (Flash и html5) собираются из единой кодовой базы на Haxe. И данный доклад является по сути обзором проделанной работы и принятых решений, как удачных, так и не очень.
7 февраля в офисе компании InnoGames состоялась очередная мини-конференция HaxeUp Sessions 2020 Hamburg, на которой Саймон Краевский отчитался о проделанной работе, рассказал немного о ближайшем будущем Haxe. И здесь я хотел бы представить перевод основной части его доклада (пропустив начало, в котором Саймон рассказывает о том, как он попал в Haxe и чем занимался в Haxe Foundation. Об этом он уже рассказывал на предыдущем HaxeUp).
Представляю вам перевод еще одного доклада с HaxeUp Sessions 2019 Linz, считаю что он хорошо дополняет предыдущий, т.к. продолжает тему изменений в Haxe, произошедших в 2019 году, а также немного рассказывает о его будущем.
Немного об авторе доклада: Аурел Били познакомился с Haxe, участвуя в различных гейм-джемах, и он продолжает в них участвовать (к примеру вот его игра с последнего Ludum Dare 45).
26 октября в г. Линц-ам-Райн (Германия) прошла мини-конференция HaxeUp Sessions 2019, посвященная Haxe и смежным технологиям. И самым знаменательным ее событием был, конечно же, финальный релиз Haxe 4.0.0 (на момент публикации, то есть спустя примерно неделю, вышло обновление 4.0.1). В этом материале я хотел бы представить вам перевод первого доклада конференции — отчета о работе, проделанной командой Haxe за 2019 год.
Привет, Хабр! Предлагаю вашему вниманию перевод доклада Александра Кузьменко с прошедшей недавно (14-15 июня) конференции Hong Kong Open Source Conference 2019.
До того, как присоединиться к Haxe Foundation в качестве разработчика компилятора Haxe, Александр около 10 лет профессионально занимался программированием на PHP, так что он знает предмет доклада.
Предлагаю вашему вниманию перевод доклада Александра Кузьменко (с апреля этого года он официально работает в качестве разработчика компилятора Haxe) об изменениях в языке Haxe, произошедших с релиза Haxe 3.4.
С момента выпуска Haxe 3.4 прошло более чем два с половиной года. За это время вышло 7 патч-релизов, 5 превью-релизов Haxe 4 и 2 релиз-кандидата Haxe 4. Это был долгий путь к новой версии и она почти готова (остается решить около 20 задач).
