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. В случае однотонных врагов все работает прекрасно.

Вы просто делаете картинку в оттенках серого и смешиваете с нужным цветом. Однако стоит только захотеть поменять цвет штанов или футболки у персонажа, начинаются проблемы.

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