ТЕМА: Сравнительный обзор Game Maker Studio 1.4

Сравнительный обзор - конечно, с RPG Maker'ом и отчасти другими известными мне движками.
Немного предыстории

Game Maker - серия игровых движков универсального характера (а не специфичных для жанра, как RPG Maker). Проект зародился в 1999 году под названием Animo как редактор 2Д-анимаций. Затем в нём появились простые возможности скриптования, а затем в какой-то момент он стал игровым движком. Тогда он был написан на Дельфи (разновидность Паскаля). В таком виде движок просуществовал много версий и заслужил определённое признание, пока однажды не сделал следующий шаг: превратился в коммерческий продукт Game Maker Studio с экспортом игр на различные платформы и вместо Дельфи был переписан на C++, однако сохранив IDE (конструктор) на Дельфи. В процессе было исправлено много причуд движка, однако и отрезаны некоторые фишки, которые не удалось сделать кроссплатформенными. В основном, впрочем, совместимость с прежним подходом была сохранена, и многие обучалки по-прежнему верны для Студии так же, как и для последней версии до неё (GM8).

Собственно, подход
GMS работает с такими понятиями как "комната" (аналог карты), "объект" (аналог события) и "экземпляр объекта" (нет аналогов в RPG Maker), а основной способ задания поведения - это события (нажатия клавиш, коллизии...) и действия в ответ на эти события (перейти в другую комнату, изменить счёт...).


В первые полчаса работы с системой мне удалось сделать Понг. Он состоял из двух ракеток, правой и левой, которым на кнопки "вверх" и "вниз" было подцеплено изменение координаты; из мяча, которому при столкновении с ракеткой было назначено действие "оттолкнуться"; и из находящихся за пределами экрана объектов-границ, из которых верхняя и нижняя отталкивали мяч подобно ракеткам, а правая и левая - возвращали мяч на исходную точку. Ещё через полчаса они также стали засчитывать очко противоположной ракетке, а в "комнату" добавились два объекта, показывающие счёт соответствующей стороны.

Честное слово, так быстро игру мне ещё сделать не удавалось, даже когда я задумывала себе простую аркадную концепцию. Могу поспорить, что когда движок создавался, что авторы выбрали список классических игр, которые на нём должно быть легко сделать: Понг, Пэкмен, леталку, стрелялку, платформер... Некоторые действия и события будто специально предназначены именно для таких игр. И это замечательно!

Сильные стороны
Главной сильной стороной GMS является, конечно, его универсальность. Количество работы в RPG Maker для реализации своих идей прямо пропорционально расхождению этих идей со стандартной формулой JRPG. В GMS количество работы пропорционально сложности идеи, но не её жанру.

GMS предоставляет решения многих стандартных задач, но в то же время не навязывает никакой игромеханики. Если бы это был какой-нибудь Platformer Maker, то платформеры на нём было бы делать легче, но динамика прыжка скорее всего была бы заданной и неизменной - настроить можно было бы только параметры вроде высоты и управляемости. Но GMS, с одной стороны, имеет все необходимые проверки (коллизии, нажатия кнопок...) и возможности, с другой - позволяет собрать тот же прыжок самостоятельно, с любой "физикой", которая только потребуется. А если не нужно особенной выверенной физики, он даёт сделать прыжок начерно с помощью действий, и этого вполне может быть достаточно.



Таким образом GMS идеально подходит как инструмент срочного прототипирования - создания предварительной версии игры, чтобы убедиться в увлекательности её механики и принять решение о дальнейшей разработке. В него даже встроен графический редактор, в котором можно нарисовать все прототипные спрайты! И возможности этого редактора хотя и напоминают MS Paint, но имеют ряд особенностей, нужных именно в разработке игр - в частности, создание анимированных спрайтов. Говорят, что большая часть игр для гейм-джемов (конкурсов разработчиков со сроками около 24 часов!) делается именно на GMS, и для меня это звучит вполне правдоподобно. Что касается разработки набело, GMS тоже прекрасный инструмент, но нужно учитывать некоторые недостатки.

Прежде чем перейти к недостаткам, хочется отметить физический движок для проектов, требующих более ли менее точной физики. Он есть. Я с ним пока не разбиралась, но нарекания читать не пришлось. Это одна из вещей, которые пытаться на RPG Maker'е - себе дороже. Впрочем, для ролевых игр это обычно и не нужно.

Слабые стороны
У GMS есть и недостатки даже по сравнению с RPG Maker'ом - и это несмотря на то, что у "серьёзных разработчиков" последний вызывает куда более снисходительную улыбку.

Главным недостатком является собственный язык программирования GML. Тут сравнивать действия в Гейм-Мейкере с командами в RPG Maker, а GML - с Руби. Ожидается, что проекты на Гейм-Мейкере будут написаны преимущественно на GML, а действия будут использоваться только для мелочёвки и прототипирования. Во всяком случае так и устроено подавляющее большинство коммерческих проектов, код которых открыли. В этом GMS существенно и понятно отличается от специализированного RPG Maker'а, где вся игра может быть построена на одних командах, а Руби привлекаться только в виде готовых скриптов, скаченных с интернета.

GML, к сожалению, представляет из себя всё то, чего боишься при словах "собственный язык программирования" и "написано на Дельфи". Вся интерпретация и исполнение операторов языка осуществляется в тех рамках, которые авторы движка смогли реализовать самостоятельно. Мне случалось писать интерпретаторы простых скриптовых языков, и это очень сложно. Возникают примерно такие странности, которые я опишу ниже. Один человек или даже команда неспециалистов не повторит всего того, чего смогли добиться создатели Руби, Lua, Яваскрипта и других готовых, полноценных языков.

В GML:

• В переменной можно хранить только число, строку, одномерный или двухмерный массив и некоторые другие экзотические значения, но нельзя хранить объект.
• В массиве можно хранить произвольные значения (хоть на этом спасибо), однако нет нотации массива (записи в духе [1, 3, 10]) и нет способа одной строкой добавить элемент в конец. На странице руководства найдите строчку "count = 3;" и посмотрите, как предлагается инициализировать массив из четырёх элементов - восемью строчками!
• Объекты вроде есть, но через точку можно только получать переменные. Чтобы вызвать метод в контексте объекта, нужно использовать конструкцию with и поменять контекст кода.
• В качестве методов можно использовать "скрипты" - не привязанные к объектам куски кода, поскольку они наследуют контекст вызова. Но как и везде в GML, это противоречит традиционному способу написания ООП-кода.
• В конце строчек в большинстве случаев обязательно ставить точку с запятой, но в то же время растянуть оператор на несколько строчек нельзя (что обычно является преимуществом языков с явным завершением оператора).
• "Структуры данных" - здесь так называются ассоциативные массивы, очереди и другие нескалярные данные - всегда создаются глобально. Обращение к ним идёт либо через специальные функции, которым нужно поставлять числовой идентификатор глобальной структуры, либо через странный синтаксис "аксессоров".
• ...и так далее.

Конечно, если бы я раньше не работала с Руби и другими языками и не знала, что в игровой движок может быть встроен полноценный язык программирования, я бы не жаловалась. Со всеми странностями выше вполне можно сделать игру. Чего там, даже на командах из RPG Maker 2000 энтузиастам удавалось делать полноценные мини-игры! А тут - чудной, непривычный и отсталый, но всё-таки язык программирования. Такие игры как Hotline Miami и Another Perspective доказывают, что на конечном результате это не сказывается. Хотя может сказаться на скорости разработки и усилиях на поддержание кода.

Прочие слабые места

Хотя ощущения от работы с GML после Руби и других самостоятельных языков грозят затмить собой весь обзор, стоит предупредить ещё о паре моментов.

Важно даже не то, что GML неудобен - ведь в нём тьма методов и операций, которые позволяют управлять всеми аспектами игры и походя делать многое из того, для чего в RPG Maker'е нужно написать новый модуль на Руби. Например, генерация экземпляров объекта (пуль, врагов, бонусов...) - RPG Maker рассчитан, что все действующие лица ("события") будут в единственном числе, кроме разве что монстров в бою. Для преодоления этого ограничения нужен скрипт от Янфлая, ну, или собственный. А Гейм-Мейкер изначально умеет сеять объектами. А что если он чего-то не умеет? Например, показывать две комнаты сразу? На RPG Maker'е, опять же, это решается поправками в код благодаря тому, что он открытый и хорошо продуман. А в Гейм-Мейкере, где нельзя показывать на экране две комнаты сразу... это просто нельзя. Если уж очень хочется, то можно соорудить какой-нибудь причудливый механизм копирования одной комнаты в другую, но это вопрос целесообразности.

В GMS есть наследование, и это один из основных механизмов: например, в Понге "Левая ракетка" и "Правая ракетка" были унаследованы от объекта "Ракетка", в котором-то и было заложено общее для них поведение. В "Левой" и "Правой" только устанавливались настройки, специфичные для них. Позднее я воспользовалась эти же механизмом для создания различных типов сообщений, от инструкции к игре до демонстрации счёта и пунктов меню. Но! К сожалению, родитель у объекта может быть только один. Это значит, что если, скажем, в игре есть стреляющие объекты, летающие объекты и уничтожимые объекты, то либо их придётся образовывать от умеющего и стрелять, и летать, и разрушаться объекта, отключая ненужные возможности; либо составлять эти объекты из нескольких, двигающихся и действующих синхронно; ну, или тиражировать код и поведения, а если понадобиться поменять что-то - то менять сразу во многих местах. Руби в этом плане удобнее, поскольку позволяет множественное наследование классов. Но, как говорят, удобнее всего Unity 3D, поскольку использует подход ECS, решающий как раз такие задачи.

Кстати о сообщениях. Удивило ли упоминание выше, что мне нужно было сделать механизм сообщений? Да как же это в движке может не быть механизма сообщений! Может, конечно, если он не делает допущений о жанре игр, которые будут на нём производиться. Каким-то играм нужны сообщений с рамками, каким-то - с прозрачным фоном, каким-то - с портретами, а другим - субтитры или вообще никакие не нужны... Это не общие задачи, а частные, в которых движок оставляет свободу решения на разработчика. То же касается интерпретации нажатия нескольких клавиш сразу и даже показа персонажа сбоку, спереди или сзади в зависимости от того, идёт он вбок, вверх или вниз. GMS не вынуждает использовать прямоугольную сетку с осями, параллельными сторонам монитора. В нём с одинаковой эффективностью можно делать изометрические игры, игры с координатой высоты, игры с кривыми путями и игры со свободным движением. С той поправкой, что всё это придётся делать самостоятельно, лишь пользуясь инструментам, такими как методы "переместить объект к ближайшему узлу сетки" и "находится ли объект на узле сетки?". По-хорошему, готовые решения нужно брать с рынка YoYo Games (авторов движка), но он не столь удобен, как хотелось бы видеть.

Ещё одно маленькое замечание. При работе со шрифтом мне не удалось достичь попиксельного масштабирования в 3 раза - масштаб получился неточным. Тем не менее, в остальном движок оказался очень удобен для работы в больших пикселях, и я полагаю, что проблема со шрифтом преодолима (хотя бы изготовлением изначально отмасштабированного шрифта).



GMS для ролевых игр
Возможности GMS в области JRPG представляет игра/пример/конструктор "YoYo RPG". Сами YoYo Games, авторы GMS, называют это движком, поскольку здесь уже решены главные задачи JRPG: движение по картке с видом сверху, установка спрайта персонажа соответственно курсу движения, диалоги, квесты, сражения и многое другое. Разработчику остаётся только воспользоваться этими заготовками, чтобы создать собственное приключение. Два щелчка в нос RPG Maker'у - это свободное движение (не привязанное к сетке) и бои на карте в реальном времени, как в "Зельде".



Следует сказать также о тайловом движке (доступным для всех игр; это не часть YoYo RPG). Само собой, GMS умеет работать с тайлами. Местами он даже превосходит в этом RPG Maker: тайл определяется как произвольный прямоугольник, вырезанный из фона, который не обязан располагаться по сетке или быть квадратным. В то же время предоставлены все инструменты, чтобы просто рисовать карту квадратами по сетке. И слоёв сколько угодно. Это, в общем-то, квинтэссенция подхода GMS ко всему. Трудность здесь состоит только в том, что и никакой автоматики механизм расположения тайлов предоставить не может. Тут помогает набор скриптов, представленный на рынке (бесплатно) - эти скрипты превращают грубую разметку в аккуратные контуры областей, к которым мы привычны на RPG Maker'е, но это не то же самое, что видеть их сразу.

Одно из главных преимуществ GMS над RPG Maker'ом в изготовлении JRPG - это самобытность внешнего вида. Не секрет, что на Стиме метка и внешние признаки игры на RPG Maker'е оказывает отталкивающий эффект. Вроде бы из-за "завалов шлака, налабанного на коленке школьниками с помощью RPG Maker'а", но, признаться, я что-то не заметила этого вала. Так или иначе, серьёзные коммерческие продукты на RPG Maker'е, такие как A Bird Story, всячески стараются избежать этого клейма и сообщить игрокам в каждом скриншоте, что "мы не они" - мы не как те второсортные поделки, мы настоящие игры. У GMS характерного внешнего вида нет и плохой репутации нет, так что тратить силы на подобное не понадобится.

Если хочется включить в JRPG нестандартные элементы (особенно экшен), такие как бои на карте в реальном времени и перестрелки, GMS может сократить время разработки - во всяком случае этих элементов. Причём подобные вещи JRPG совершенно не чужды, ведь приключенческая и атмосферная составляющая - только половина особенностей жанра, а вторая - сложная и всякий раз экспериментальная игровая система. В этом плане, увы, RPG Maker необоснованно ограничивает проекты единственной ролевой и боевой системой. В целом и тут, и там для реализации собственной ролевой системы придётся кодить (на GML ли на Руби), и тут уж остаётся только соизмерить, сколько усилий GMS сэкономит, а сколько - заставит потратить лишних.

Ценовая политика
GMS распространяется бесплатно. Только "про-функции" стоят денег, и эти уж - достаточно дорого. Собственно про-лицензия, позволяющая выпускать коммерческие игры и содержащая некоторые необходимые для командной работы и кроссплатформенности функции, стоит на Стиме 5000 российских рублей, а у авторов - $150 (почти 10 000 рублей по текущему курсу). И это не считая модулей для экспорта на платформы помимо Винды, многие из которых даже дороже. Рецензенты рекомендуют брать именно оригинальную версию, поскольку она быстрее получает обновления, да и к ней прилагается стимовский ключ. В долларах их цена почти не отличается, а вот в рублях она заметна...

Есть ещё один фактор. Так же, как мы ждём зимой RPG Maker MV, который совершит кроссплатформенную революцию и выведет движок на очередной новый уровень, и поклонники GMS ждут версии 2.0, о которой, правда, пока ничего неизвестно, даже даты запланированного выхода. Получат ли текущие владельцы лицензию на новый продукт или какие-то преимущества в приобретении таковой - неизвестно.

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

Заключение и пример
По этой ссылке можно ознакомиться с изготовленным мной Понгом - как исходным кодом, так и собственной игрой (файл .exe в корне). Поскольку я использую про-версию, то исходный код можно посмотреть как набор XML-файлов, включая куски GML. Кстати, мой антивирус очень оживился при запуске этого О БОЖЕ НЕИЗВЕСТНОГО ФАЙЛА НЕИЗВЕСТНОГО РАЗРАБОТЧИКА ПОЯВИВШЕГОСЯ НА КОМПЬЮТЕРЕ ПРОСТО ИЗ НИОТКУДА, но я просто пока не умею подписывать файлы.



Итак, как и всякий инструмент, GMS наиболее полезен, если используешь его сильные стороны и обходишь слабые. Делать в нём 2Д-шутер или квест со свободным перемещением куда целесообразнее, чем на RPG Maker'е. Делать "чистую" JRPG во большинстве случаев лучше на RPG Maker'е. Как и в одном, так и в другом движке можно многого достичь без кодерских навыков, но серьёзный самобытный проект - пожалуй, только с ними.

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

Дополню немного)
Теперь при покупке Студии модули экспорта на маки(но оно опять же, требуют для дистрибьюции мак машину да акк разраба) и на Убунту идут бесплатно при покупке студии, начиная с середины мая 2015 года(остались модули в продаже видимо для тех, кто не купил модули ранее, ибо бесплатно не раздали), только вот сама студия есть только на Windows(для мака есть старая версия), для других платформ нужна вторая локальная машина с нужной осью.

GML хоть и интерпретируемый язык, но начиная со Студии, при сборке пакета игры проект переводится на С++, улучшая быстродейственность(через YoYoCompiler)
Так же, GML можно расширить библиотеками.

Ещё большой плюс GameMaker - поддержка шейдеров. Второй большой плюс - поддержка систем контроля версий(Git, Svn)

Так же, при наличии соответствующих аддонов и лицензий, GM игры можно запустить почти везде, а конкретно:

• Windows
- есть поддержка YYC.

• Mac OS X
- есть поддержка YYC.

• Ubuntu
- есть поддержка YYC.

• HTML5
- для этой платформы доступен JS.

• iOS
- есть поддержка YYC.

• Android
- есть поддержка YYC, разных архитектур процессоров.

• Windows 8
- есть поддержка YYC для нативной или JS сборки.

• Windows Phone 8
- есть поддержка YYC.

• Tizen
Нативная или JS сборка.

• XBOX One
- есть поддержка YYC.

• PlayStation 3, 4 и Vita
- есть поддержка YYC.

Для ГМ всё-таки кодерские навыки нужны, хотя бы базовые, ибо DnD тут хватает, но часто лучше сделать это всё на скриптах. В этом плане ГМ похуже Scirra Construct(Почти всё там делается на событиях и в крайних мерах доп-модулях, а сами проекты игр на html5 + JS)

>>Нельзя несколько комнат сразу
Ну... Я даже не знаю зачем это, тоже самое что в Юнити несколько сцен сразу отобразить.

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

Спасибо %)

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

Ну, тут как и везде, можно просто рендерить изменения c одной карты на другую(хотя да, это немного затратно)

Кэт, очень интересно, но не помешало бы добавить картинок.

Попробую наскринить %)

Добавлены иллюстрации.

Кстати, GMS ещё поддержвивает LiquidFun
google.github.io/liquidfun/

Так же, с 1.3 есть поддержка Скелетной анимации

Годный пост, отпишу-ка я комментариев.

EvilCat пишет: Всё как есть, абсолютная правда. Говорю как работавший с Гейм Мейкером ещё с 2006 года. Тогда он ещё не умел некоторых вещей из описанного (а бывало, имел другие, позже урезанные фичи, типа проигрывания звука на произвольной скорости), но уже тогда был хорош именно в этом - быстро прототипировать. Ну и просто собирать произвольные игры, задавшись конкретной целью, далеко уходящей от более узкопрофильных "Мейкеров".

EvilCat пишет: Большая плата за большую свободу. И, как по мне, вполне соразмерная.

EvilCat пишет:

• В переменной можно хранить идентификатор экземпляра объекта, и соответственно писать/читать его переменные.
• Запись в духе [1, 3] есть, но больше двух измерений нельзя использовать. Нет способа одной строкой добавить элемент в конец - это не проблема массива, для этого в GML есть списки, которые ds_list.
• В GML вообще нет понятия метода, это терминология общего ООП). with меняет контекст, а event_user(...) вызывает событие. У метода-то хотя бы есть аргументы, а тут - нет.
• Традиционные способы написания ООП, серьёзно? В таких случаях ставится вопрос "Вам шашечки, или ехать?".
• Эм, што? Я точку с запятой никогда не ставил вообще в GML, даже в циклах for. И многоэтажные вычисления в несколько строк тоже писал. Что-то тут неправильно совсем в этом пункте.
• Новомодные аксессоры даже для меня выглядят странно, но они вполне себе работают. Дело привычки.

EvilCat пишет: Какой такой "отсталый"? Неполный по Тьюрингу, может? Мне так не кажется. Ну буду спорить, что GML какой-то угловатый, впрочем.

EvilCat пишет: Тем не менее, можно использовать несколько Viewports одновременно. Только при этом нужно размещать абсолютно всю карту всего мира в одной комнате, и в целях оптимизации деактивировать всё что плохо лежит (за рамкой всех существующих видов). Так что проблема решаема, хоть и не из коробки. Но это экзотическое игровое решение, вправду.

EvilCat пишет: Могу только ненавязчиво предложить ознакомиться с моим постом о минусах GML эпохи GM8.1. С тех пор минусы мало поменялись, а вот описанные наверху плюсы - пропали.

Впрочем нет, могу предложить ещё одно - описывать поведения объектов в отдельных скриптах, и маршрутизировать их использование для достижения тех или иных комбинаций оных. Я это когда-то хотел сделать через макросы, в своей собственной IDE для Game Maker'а, но потом как раз наступила Студия, и как-то оно всё заглохло. А потом ещё пошёл развиваться Parakeet - это такая альтернативная среда разработки для него же, и я совсем оставил это дело. В конце концов, я хочу делать игры, а не играть в геймдевелопера. За десять лет-то пора бы стать на тот путь, который действительно рисовал в мечтах. Ладно, о чём это я...

EvilCat пишет: Ну так, скрипты принимают аргументы, и создают нужные объекты с нужными параметрами, как насчёт такого варианта? Если бы не скрипты в качестве связующих звеньев, то Гамак был бы не Гамаком, а действительно дырявым решетом. Для разных рамок нужна система сообщений в движке? Вот уж не согласен.

EvilCat пишет: Не проблема движка, надо покрутить ещё. У меня с этим всё получалось, по крайней мере.

EvilCat пишет: Вот тут не поспорить. Но на случай прямо плотной работы с картой, авто-тайлы можно построить один раз и кэшировать в одну большую картинку на фоне.

EvilCat пишет: Это кстати весьма грустно. И отчего так, непонятно.

EvilCat пишет: Достаточно сказать, что АндерТейл сделана на GML. Не знаю кто как, а я, если б я уже не знал, точно бы пошёл его изучать после открытия такого факта.

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

EvilCat пишет: Не-а, не жду. Или я не поклонник? Хм, даже не знаю! Ссылка на источник бы точно не помешала в данном вопросе.