⚠️ Обращайте внимание на даты.
Этот блог больше не ведётся с 17 января 2023, и на тот момент с написания этой страницы (30.04.2014) прошло 8 лет.
Это по большей части небольшой но мощный и разочаровывающий (скорее всего) для многих анонс. Этот момент должен был наступить, вопрос был во времени. Я нашёл хорошую альтернативу GMS для себя, в которой у меня будет больше контроля над ситуацией. Я, в общем-то, её не искал. Но безумные идеи, которые приходили в голову, подталкивали к тому, что с GMS и GM вообще мне стало весьма неудобно работать.
С чего всё началось? С Parakeet. Он мне напомнил о том, что сколько бы я ни привыкал к костылям GML, это всё ещё костыли. Он ввёл собственный синтаксис обработки событий… что мило, но на данный момент исполнено на редкость криво. Parakeet, как IDE, поддерживается очень хило, но его фичи заманчивы, и хочется ещё. К тому же, категорический отказ автора выпустить исходный код Parakeet лично меня разочаровал — он потерял много продуктивных человекочасов ради возможности однажды превратить Parakeet в коммерческий проект, который бы оказался слишком узкоспециализирован. Даже на лицензию GMS многим жаль потратиться, что уж говорить о среде, которая вряд ли будет дешёвой для своей мощи (которой, хочется надеяться, он будет обладать).
Поэтому я задумался над тем, чтобы реализовать для GML язык-обёртку на основе Ruby. Сам язык к этому располагает, я уже писал о фичах. Я начитался интересных вещей про Ruby, и вроде изучил достаточно, чтобы сделать в GML годный настоящий ООП на классах… но я не успел начать этот проект, потому что наткнулся на Haxe. Забавно, но он делает примерно то же самое, только на куда более широкий набор языков и технологий. Вокруг него более крупное сообщество, кодовая база, а набор платформ всё ещё покрывает все мои нужды.
Что касается языка-обёртки, реализовать мне хотелось, в основном, две фичи.
- Сделать проверку типов. В свежем GML 4 типа, в более старых вариантах и того меньше — 2. Реальных же типов больше десятка, но большая их часть кодируется числами.
- Завернуть группы функций для конкретных ресурсов в классы с их методами.
Выглядеть это могло бы примерно следующим образом:
То есть, перечисляю штуки, которые лично меня в GML вымораживают:
- У переменной нет конкретного типа (когда он подразумевается), и её зачастую можно обрабатывать самыми разными методами — но только одна группа методов будет работать, как надо. Напрашивается на систему класс-методы, чтобы не писать каждый раз, какого типа переменную считаешь на этот раз.
- У переменной нет конкретного типа, и компилятор ни слова не скажет, если творить с переменной что-то, что её типу не соответствует, потому что компилятор не знает, какого она типа. Язык не предусматривает средств для этого. Баг наверняка вылезет, но поймать его может быть затруднительно, когда такие ошибки вполне может ловить компилятор.
- Код часто получается весьма длинным, но с большим количеством повторов. Особенно это касается раздела “структуры данных”. Это сейчас пытаются исправить при помощи специального синтаксиса accessor’ов, но это превращает буквенный ад в символьный ад, делает код непонятным, зато коротким. Непохоже на улучшение.
- Запись больших объёмов данных в GML, похоже, отсутствует. Вообще. Вы не можете заранее закодировать массив, например. В Haxe можно сделать так:
var a : Array<Int> = [1,2,3,4];
. В Ruby почти так же:a = [1,2,3,4]
. Для удобной сериализации данных необходим всего лишь удобный синтаксис для чисел (есть), строк (есть), списков (нет) и мапов (нет). В GMS появилась сериализация в JSON, но способов собрать данные ДО сборки игры как таковых нет. Приходится прилеплять внешний файл в JSON или писать огромную строку в коде, что, разумеется, сожрёт сколько-то лишней памяти.
В общем, теперь я ушёл в Haxe. Придётся привыкать, но это цена системы, с которой удобно работать. Мне понравился Ruby, и я даже могу объяснить, чем (и объяснял в постах ранее).