Mighty Final Fight. Vol.-3
volume -3
ВНИМАНИЕ!!! ДАННАЯ СТАТЬЯ СОДЕРЖИТ ЗАВЕДОМО ЛОЖНУЮ ИНФОРМАЦИЮ!!! НЕ ЧИТАЙТЕ ЕЕ!!!
-3 :: -2 :: -1 :: 0 :: 1 :: 2 :: 3
Предисловие
После публикации первого поста я понял, что стоит все-таки коротко пройтись по самому инструменту. Очень здорово, что в предыдущем посте Джаз и Verdana_hd исправили неточности в моем описании. Надеюсь, что пользователи, владеющие ГМ, поправят меня и в этой статье.
Прежде всего, я хотел бы акцентировать внимание на минусах инструмента, с которыми мне пришлось столкнуться. Так как я работал в узком жанре, то и проблем возникало не так много. Однако, в этой статье я хотел бы собрать по возможности все известные минусы, поэтому отписывайтесь, пожалуйста, в комментариях, а я буду добавлять их в статью.
Минусы ГМ
1. Ваш исходник будет доступен всем
С этим нужно смириться. Весь ваш код, все спрайты, музыка -- все это будет доступно, как только вы выложите игру в открытый доступ. И все это благодаря декомпиляторам.
Меня это отпугнуло вначале. Понятно, что любую игру можно разобрать на части, но если для декомпиляции серьезных игр понадобятся такие же серьезные скиллы, то для декомпляции екзешника ГМ нужно просто нажать на две кнопки.
Многие начинают извращаться. Пакуют графику в шифрованные архивы, шифруют текстовые и ini-файлы, мучаются потом при дешифровании в коде и так далее.
Я этого не делаю и вот по какой причине.
Спустя какое-то время я понял, что главный скилл любого разработчика -- это умение довести дело до конца. То есть если даже вы выложите исходник игры, в котором останется доделать смену управления, добавить пару звуков и вывести титры в конце -- будьте уверены, никто этого не сделает.
Все это, конечно, сильно утрировано, однако бояться действительно нечего. Любой "умеющий довести дело до конца" разработчик сделает свою игру, все остальные не смогут доделать ничего.
2. Игры на ГМ "жрут" много оперативной памяти
Казалось бы, в большинстве своем игры на ГМ -- это мини-игры с мелкой пиксельной графикой и простейшими вычислениями в игровой механике, почему же оперативная память забивается до отказа, при переходе на новый экран игра тормозит и пули летят так медленно-медленно?
Причин несколько. И помимо использования неправильных функций и не оптимальных алгоритмов есть два основных момента, из-за которых игры на ГМ едят так много ресурсов.
1) Графика
Дело в том, что ГМ выделяет в памяти место по максимуму, в независимости от исходного формата файла. То есть будь это .jpg, .bmp или 4-х битный .png -- в памяти он выделит максимальное место (как для .bmp), учитывая только размер картинки (то есть суммарное количество пикселей).
Исходник, и соответственно екзешник, тем не менее "пухнут" неодинаково. То есть если вы используете 16-цветную палитру на картинке, то и загружать ее в исходник следует как 4-х битный .png.
В связи с этим надо иметь в виду, что чем больше по размеру картинка, тем тяжелее игре. В том числе и поэтому (помимо ностальгии по старым консолям) разработчики на ГМ делают мелкую пиксельную графику, которую впоследствии масштабируют средствами инструмента.
комментарий Jazz'а
это кстати особенность далеко не только гамака. Все графические библиотеки загружают в память несжатые данные.
2) Типы данных
Для облегчения жизни новичков в ГМ предусмотрено только два типа данных (не уверен насчет логических, но по-моему это фикция в ГМ): числовые и строковые.
То есть переменная может содержать либо текстовое, либо числовое значение.
Вы знаете, что в нормальных языках программирования для числовых данных предусмотрено множество типов, используемых в зависимости от диапазона предполагаемых значений переменной. Грубо говоря, чем меньше диапазон, тем меньше места занимает переменная выбранного типа в памяти.
В ГМ же место в памяти занимается по-максимуму, то есть для хранения числовых значений используется самый ресурсоемкий тип данных.
3) Загрузка всех ресурсов исходника в оперативную память
При запуске игры абсолютно все ресурсы (спрайты, музыка, звуки и т.д.), содержащиеся в исходнике, загружаются в память.
Допустим, у вас есть 25 бэкграундов на соотвествующее количество уровней. Во время игры они не нужны вам все сразу, и логично было бы подгружать нужный бэкграунд при старте нового уровня. Но ГМ загружает в память сразу все.
С этим, правда, можно легко бороться, загружая и удаляя ресурсы извне (то есть хранить их в отдельных папках, а не в самом екзешнике).
комментарий Verdana_hd
кстати любой экзешник на любом языке вроде бы всегда целиком загружается в оперативу при запуске. для этого многие файлы хранят вне его
комментарий Jazz'а
Exe-шник-то загружется в оперативку, только ресурсы в нём не хранят. Ну разве что иконки.
Для iOS, Android, да и для MacOS используются архивы в качестве приложений для совместного хранения ресурсов и бинарников. И с оперативкой норм, и файл на жёстком вроде как один
3. Нельзя масштабировать графику простыми средствами
Об этой проблеме и путях ее решения я уже рассказывал.
4. Нельзя на ходу поменять палитру спрайта простыми средствами
Это серьезная проблема, так как довольно часто в играх используются одинаковые враги, различающиеся, например, только цветом штанов.
Есть хитрые обходные пути, которые все же позволяют поменять цвета пикселей (через использование поверхностей), однако они настолько тяжелы, медленны и сложны в применении, что можно считать, что их нет.
Дело в том, что ГМ способен только смешать все цвета на картинке с выбранным цветом.
Для это используется встроенная переменная image_blend. В случае однотонных врагов все работает прекрасно.
Вы просто делаете картинку в оттенках серого и смешиваете с нужным цветом. Однако стоит только захотеть поменять цвет штанов или футболки у персонажа, начинаются проблемы.
Как видно на рисунке, придется вырезать цветные участки, обесцвечивать их, накладывать в игре на изначальный спрайт, и наконец-то окрашивать в нужный цвет. В случае, если у вашего персонажа куча многокадровых анимаций (например, в файтингах или битэмапах) -- сразу становится понятно какая кропотливая и нудная работа предстоит ))
Итого
На выходе мы получаем инструмент с кучей внутренних проблем, которые серьезно ограничивают разработчика на поздних этапах.
Тем не менее, если вы не замахиваетесь на что-то грандиозное и не являетесь серьезным программистом, ГМ к вашим услугам.
- 07 февраля 2012, 13:49
Хотел спросить еще про обзор GML. В принципе, в хелпе все подробно описано, причем на русском.
Я думаю написать еще одну предварительную статью про игровой цикл ГМ, это будет полезно. А вот рассматривать ли сам язык -- не знаю.
Или с языком по ходу дела разберемся?
Хотелось бы услышать мнение новичков. Какие моменты в хелпе по описанию языка им не понятны, например.
1 и 4 не правда. 3 тоже.
Что именно неправда?
1) Исходник можно защитить.
3) Можно создать камеру и зумировать.
4) Как-то ещё делали, видел в примере. Но он у меня не сохранился. :(
1) Как?
3) Прочитай статью, на которую дана ссылка
4) не зачет
1) видимо речь идет о upx...
видимо...
По поводу четвертого пункта, кстати. Действительно можно менять палитру. Через surface и с большим геморроем. Но это настолько медленно и муторно, что почти не работоспособно, поэтому я даже и не стал о нем упоминать.
По крайней мере, тот метод, который знаю я.
С помощью MoleBox, например, или GM Anti-Decompiler.
То есть вот эта фраза из статьи тебя не удовлетворила?
Могу добавить туда, что екзешник тоже можно защитить извращенными способами. Подойдет? Почему не стал добавлять изначально. Потому что с выходом седьмого гмакера вышла какая-то защита, потом ее взломали. Временно был безопасным восьмой ГМ. Потом декомпилировали и его.
Иногда у людей при пользовании всякими анти-декомпиляторами возникали ошибки и куча геморроя, не работали вдруг экстеншены и так далее.
Мне кажется, что защитить его можно только временно, а это все равно, что не защищать.
MoleBox платный к тому же, а бесплатная версия какую-то надпись выдавала, насколько я помню.
Идея была в том, что нечего и париться. Сам я перестал следить за всем этим довольно давно. Или справедливости ради ты считаешь, что нужно добавить все эти дикие методы?
Собственно, если это неправда, я буду только рад ))
Подскажи тогда правильные решения и уберем эти пункты из минусов.
2.2. В гейм мейкере один тип данных. Массив. Объявляя переменную (используя её первый раз) мы фактически объявляем массив 1х1 (как я понял). В дальнейшем массив автоматически расширяется, если использовать индексы. (Это предположение, но разработчик же не дурак, чтоб сразу забивать память =\)
А строка, число - ГМ'у пофиг. То есть такой код
s = "Hello world!";
s = 18;
вполне работает. Только непонятно. кому он нужен.
Мне кажется, ты что-то напутал. Но я подожду опытных товарищей, чтобы они объяснили твою ошибку (а мне кажется, что в твоих рассуждениях она есть).
Инфа из хелпа Гейм Мейкера вообще-то.
...
You can use 1- and 2-dimensional arrays in GML. Simply put the index between square brackets for a 1-dimensional array, and the two indices with a comma between them for 2-dimensional arrays. At the moment you use an index the array is generated. Each array runs from index 0. So be careful with using large indices because memory for a large array will be reserved. Never use negative indices. The system puts a limit of 32000 on each index and 1000000 on the total size.
Прочитай, пожалуйста, первый абзац в приведенном тобой отрывке из хелпа.
Если ты про "массив 1х1", то, повторюсь, это просто догадка моя :)
Нет, я про типы данных.
Ткни уже носом в противоречие, в упор не вижу.
То есть типа данных два, как я и написал в посте. Числовой и строковый.
Гм. Я решил, что это этакий "универсальный" тип данных. Ну да ладно.
В том же хелпе есть даже два подраздела, посвященных функциям с числовыми значениями и строковыми.
Очень странная методика :)
А
это утиная типизацияНе знал. Почитал. Спасибо за наводку :)
Тёрки вокруг типизации, это прекрасно. Желаю тебе большого заряда - с таким темпом дойти до конца будет сложновто. Особенно если версии постов будут в противоположную сторону расти. ;)
)))
Буду стараться. Если мы сделаем в итоге один этап с боссом, титульным экраном, сменой управления и титрами -- я буду считать, что дело сделано.
не подтипов, а просто типов) "подтипы" я такого слова сто лет не слышал, но если уж его интерпретировать, то ближе всего синоним "наследники", а так как типы числовых данных являются примитивами, то и наследовать там нечего, т.е. "типы", да :)
- не во всех языках :-)
ок, "обычно" являются примитивами))
вообще почти везде есть всевозможные матрицы и числовые производные массивов, я их просто не имею в виду)
Ну, в Python'е хотя бы один тип назвать примитивом назвать сложно :-)
Но это так, к слову
блин, я все время забываю про существование презираемой мной динамической типизации :((
не волнуйся, я всегда поддержу беседу на любимые профессиональные темы ;)
но я его не люблю, мешанина всего возможного с высоченной абстракцией и низкой эффективностью
завтра написать третью часть статьи D:
Исправил. Спасибо.
загружает.
выгружать, это освобождать память от ресурсов
кстати любой экзешник на любом языке вроде бы всегда целиком загружается в оперативу при запуске. для этого многие файлы хранят вне его
Ага, спасибо. Исправлю терминологию.
Я уже начинаю думать, что не так уж он и плох, ГМ-то ))
Ну как тебе сказать.
Exe-шник-то загружется в оперативку, только ресурсы в нём не хранят. Ну разве что иконки.
Для iOS, Android, да и для MacOS используются архивы в качестве приложений для совместного хранения ресурсов и бинарников. И с оперативкой норм, и файл на жёстком вроде как один
Добавил ваши ответы в статью.
исправил
- это кстати особенность далеко не только гамака. Все графические библиотеки загружают в память несжатые данные.
Хм. Интересно.
Спасибо за информацию.
То есть получается, что к минусам это нельзя отнести тогда?
Это вряд ли, а вот
это странно.
Я бы назвал весь этот пункт не минусом, а особенностью.
Ну это мое заключение, наверно, я плохо выразился. Что значит "тяжелее" в данном случае не понятно.
Я хотел сказать, что чем больше картинка, тем больше занимается места в памяти, и ему дольше рисовать большую картинку, чем маленькую. Хотя, это скорее всего очевидно.
Надо убрать из минусов, конечно.
Добавил твой коммент в текст статьи, чтобы не разрушать структуру и отделять особенности от минусов.
По четвертому пункту внес уточнения.
На ГМ я пишу 10 лет.
1. Есть обфускатор, есть другие инструменты, предотвращающие декомпил.
2. Для освобождения памяти есть DLL Cleanmem. А ресурсы можно выгружать из оперативки простым удалением.
Вот процессор игры на ГМ действительно едят не дай баже. Ещё не умеют работать с несколькими ядрами. Это решается через DLL GMThreads.
2.1 Ответили уже
2.2 Это согласен, для простоты всего два типа. Иначе бы молодые люди затрахались.
2.3 Не надо запихивать ресурсы в исходник. Грузите извне.
3. Можно простыми, просто фильтрации не будет нужной. Интерполяция к этому не относится она проявляет себя в поворотах картинок, чтобы на углах не было лесенок.
4. А где можно на ходу? Это же ДХ-блендинг. Стандарт. На картинку. Можно составлять спрайт из кусков, каждый кусок блендить. Накладывать потом на сурфейс, сохранять в картинку.
ИТОГО:
минусы ГМ не в этом. Основная проблема для проф. разработчика — «блэк бокс» — нельзя посмотреть, что внутри. Отладка слабенькая. Нельзя вызывать нативный код. Медленный интерпретатор. Ресурсоемкие встроенные функции.
По третьему пункту не понял, вроде все объяснил в статье про масштабирование, но может я и там ошибался.
По остальным тебе виднее. Вообще говоря, думаю, что этот пост лишний, так как содержит слишком много ошибок и моих непрофессиональных домыслов и рассуждений.
Если не лень, пройдись, пожалуйста, по остальным постам. Возможно, я и там накосячил будь здоров.