Программирование и портирование мобильных игр
Независимый разработчик из Торонто Амос Лабер (Amos Laber) в своем блоге поделился мыслями о работе над мобильными играми и их портированием на различные платформы.
Платформы
В первую очередь, необходимо определиться с платформой, — считает Лабер. — У начинающего и независимого разработчика, как правило, не густо со средствами, так что, если хотите сделать действительно качественную игру, разрабатывайте ее изначально под одну единственную платформу. Если она станет успешной – вы в дальнейшем всегда сможете ее портировать на другие платформы.
И тут уже возникает другой вопрос – какую платформу выбрать для начала. Причем те, кто разрабатывает казуальную двухмерную игру, зачастую мечутся даже не между двумя-тремя мобильными платформами, а между тем, стоит ли делать десктоп-игру для Facebook или мобильный проект под iOS.
По сути, обе платформы предоставляют доступ к огромной аудитории, обе поддерживают как микротранзакции, так и социальные функции. Единственное действительно крупное отличие между платформами состоит в тех играх, которые пользуются популярностью на каждой из них.
Правда, уже сейчас это грань смывается, так что отличия между платформами становятся сугубо техническими.
Портирование
Портирования даже замечательной игры может быть утомительным делом, которое займет уйму времени. В отличие от ААА-игр, где, как правило, используются кросс-платформенные движки, которые позволяют писать один код для нескольких платформ, казуальные и мобильные игры при портировании зачастую полностью переписываются. Это еще одна причина, почему все-таки следует сосредоточиться на какой-либо одной версии и шлифовать ее, а потом уже начинать работу над другими.
Часто бывает так, что игра, ставшая популярной на какой либо одной платформе, портируется на другую только через шесть-двенадцать месяцев после оригинального релиза. Так было с Angry Birds, Where is My Water?, так будет, судя по последним данным, с Temple Run.
В каждом из этих случаев разработчики тратили на создание порта большие суммы, возможно, вполне сопоставимые со стоимостью оригинала. И, конечно, как уже было сказано, время.
Впрочем, при аккуратном подходе к дизайну и тщательном планировании, выпустить две версии игры по цене одной вполне возможно. Это, скажем так, один из подходов: изначально делать так, чтобы фрагменты кода и ассеты легко переносились с платформы на платформу (модульный подход).
Однако и в этом случае возникает множество проблем. При программировании исходного материал вы должны сразу учитывать все то многообразие инструментов, систем, языков программирования и, конечно, железа, на котором вы собираетесь запустить вашу игру. Это очень сложно. Кроме того, всегда есть риск, что при разработке продукта, подходящего ко всем платформам, он не будет нормально работать ни на одной.
Конечно, часть проблем может быть решена с помощью использования инструментов вроде Unity 3D или Corona, которые подходят сразу для нескольких платформ, но в этом случае разработчик жертвует гибкостью разработки. Причем порой ограничения бывают очень серьезными.
Так что, в идеале, разрабатывать одну игру все-таки следует для каждой платформы отдельно: используя родные для нее инструменты и библиотеки.
Советы
Ниже ключевые принципы, от который следует отталкиваться при разработке игры, если вы хотите в дальнейшем ее портировать:
— Используйте общие типы данных (например, bitmap, sprite sheet и т.п.)
— Позаботьтесь о хорошем инструментарии для подготовки графических и игровых ресурсов
— Используйте объектно-ориентированный язык программирования со строгой типизацией и среду разработки с хорошим дебаггером
— Возьмите за основу хорошо зарекомендовавший себя фреймворк
Да, при использовании Facebook Flash лучше в качестве фреймворка использовать AS3, а при Cocos2D — Objective-C.