Haxe *

Скорость разработки и качество кода — вот, пожалуй, одно из главнейших противоречий 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 задач).

Задумал я как-то написать игру. Причем, по-быстрому. Желательно за неделю при условии работы на полставки. Финальным этапом должна была стать публикация на Google Play (что, конечно, недостаточно, но об этом позже). Таким образом, это будет статья о разработке в стиле "вжух-вжух и в продакшен", или, как сказали друзья "устроил себе Ludum Dare". Технических деталей будет, впрочем, немного.

После небольшого брейнсторма родилась идея "складывания ленты". Лента бесконечной длины, её можно сгибать под прямым углом (количество сгибов ограничено), и её "лицевая" и "изнаночная" стороны разного цвета. Так же есть контрольные точки "лицевого" и "изнаночного" цветов. Игрок выигрывает когда лента пройдёт соответствующими сторонами по всем контрольным точкам. Быстрый поиск не дал ничего похожего.

За последние полгода редактор для создания игр и просто баннеров под HTML5 прилично пообтесался, упростился (в смысле концепции и интерфейса) и, в итоге, стал ближе к конечному пользователю. Пришла пора посмотреть, что есть в нём (в редакторе, а не в пользователе, конечно) интересного. Под катом — тяжёлые картинки и немного текста.