D:\sideБлогParakeet ­­­- зачем ещё?

Хочу познакомить всех, кому небезразличен движок GameMaker Studio (именно как движок, для тех, кого конструкторная составляющая мало интересует) с одним довольно забавным проектом. Вырос он из довольно простых соображений. Те, кто пользуются серией конструкторов GameMaker (Game Maker ранее), замечают, что для них графический интерфейс среды разработки – обуза, замедляющая процесс и усложняющая лишними кликами мыши работу с проектом. Выпиливать эту фичу из GM нельзя по одной простой причине – одна из главных его фич это отсутствие требования писать код. Но что если вы уже умеете писать код, и вам эта фича без надобности?

Обычный техпроцесс. Вы открываете проект, запускаете с целью посмотреть, «что я хочу сделать сегодня». Или смотрите в список задач. Или в «roadmap» (предпочитаю не переводить). Затем, чтобы дописать нужный вам участок кода, вы открываете объект, щёлкаете на событие, выискиваете в панели справа действие __«Выполнить фрагмент кода», щёлкаете правой кнопкой (всё ещё перетаскиваете?), и только тогда получаете окошко, в которое можно вбить кусочек кода. Кошмарище!

 Parakeet создан из идеи это устранить, поскольку с такой проблемой сталкиваются многие разработчики GM, как только погружаются в дебри GML. Почему этот появился только сейчас? Потому что GameMaker Studio ­– первый в линейке использует многофайловый формат хранения исходников. То есть, каждый объект, скрипт и прочие – отдельные файлы с собственными параметрами.

Для редактирования кода в большинстве мест проекта вместе с Parakeet требуется пара щелчков мыши. Весь объект преобразуется в один огромный файл кода на GML. Стоп. Не совсем GML, в этом языке же нет синтаксиса для описания событий. Parakeet решает этот вопрос при помощи PEGML: чуточку расширенного GML. В среду встроен преобразователь PEGML\(\leftrightarrow\)GML, работающий «на ходу» при сохранении и открытии. У этого преобразователя есть существенный недостаток: работает он только с кодом, и на любые другие действия он чихает весьма таинственными вещами. Поэтому не рассчитывайте, что наугад взятый проект успешно откроется в Parakeet без доработки. Даже самый опытный разработчик, работая с обычным интерфейсом, нет-нет да и вставит что-нибудь не на GML, и всё сломается.

То есть, самое существенное изменение в PEGML ­– поддержка синтаксиса определения событий. И выглядит это примерно так:

PERFORM_EVENT argument {
    //код события
}

Лаконично. Аргументы есть не у всех событий. Есть они, например, у нажатий клавиш и столкновений. Стоит отметить, что в больших проектах такой подход в сочетании с автодополнением удобнее выбора некоторых значений из большущего выпадающего списка. Почему? Посудите сами: проще ли вам полистать большущий список, или же проще вбить первые буквы вашего ресурса и увидеть все ресурсы, что начинаются с них же? У опытных разработчиков частая практика – использовать префиксы у всех ресурсов, дабы не было шансов назвать два ресурса одинаково и получить очень весёлые последствия.

Есть у PEGML ещё одна удобная особенность: когда вы пишете собственный скрипт, вы можете его задокументировать: что он означает, в каком порядке идут какие аргументы, что означает возвращаемое значение. Эта информация будет всплывать всякий раз, когда вы будете вводить в коде вызов этого скрипта. Тоже исключительно удобство.

Прочие мелкие удобства в Parakeet ­­– сворачивание блоков кода, автоматические отступы, подсветка синтаксиса для GML и шейдерных языков. Также реализована система «префабов» – ресурсов, которые изготавливаются заранее, наподобие полуфабрикатов. Сейчас эта система почти никак не используется, префабов почти нет, так что удобство это довольно сомнительное.

Но есть и недостатки. Например, сейчас Parakeet сколько-нибудь годится только для редактирования объектов, потому что он ещё совсем сырой, и содержит, по сути, просто сильно улучшенный редактор кода. Для всего остального лучше использовать 5pice.

Ещё один неприятный баг (версия 0.4.8) – проблемы с backspace. Часто, при попытке стереть русский символ, Parakeet вдруг выкидывает исключение. Налицо проблемы с недосмотром за многобайтовыми кодировками. Стоит начать пользоваться символами, которым нужно больше байта, начинается веселье. Но лично я могу это простить на фоне того, что аналогичный баг я нашёл… у ЕА! В их платформе распространения игр Origin. Баг, как потом выяснилось, известный всем, кроме ЕА. И они сами никак не могли его обнаружить, потому что их локали (языковые настройки) системы предполагали только ASCII-символы, которым одного байта достаточно. Чтобы обнаружить баг, нужно было переключить локаль на что-нибудь более безумное, вроде русского языка. Отмечу также, что я и сам был автором такого бага, когда осваивал работу с Qt (а на нём, кстати, написан Origin), но я всё же русский, и интересные последствия ввода фраз на родном языке меня сразу насторожили.

Ссылочки!