Разработка игрового приложения на Android

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

приложение программирование алгоритм трехмерный

Данная работа посвящена созданию игрового приложения для операционной системы Android. В качестве игрового приложения было решено вести разработку игры по образцу уже существующей, вышедшей в 2001 году на ПК под названием «Дальнобойщики-2». Настоящие материалы содержат исследование такой предметной области, как «игровые приложения для мобильных устройств», обоснование выбора тематики разрабатываемого приложения, процесс разработки и тестирования приложения.

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

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

Приложение было протестировано вручную и выложено в интернет для тестирования всеми желающими. По итогам игры была собрана статистика соответствия продукта изначальным требованиям. Можно утверждать, что продукт соответствует всем поставленным требованиям и в целом, оставляет о себе положительное впечатление.

Над приложением планируется дальнейшая работа: исправление возникающих ошибок, увеличение игрового мира и доступных игровых объектов и приближение продукта к оригинальной игре, по образцу которой велась разработка. Приложение не предполагает собой получение коммерческой выгоды напрямую, так как автор не обладает лицензией на коммерческое использование товарных знаков «Дальнобойщики-2», всех изображенных в игре автомобилей и музыки группы «Ария», использование которой предполагается в будущем в соответствии с оригинальной игрой. Однако разработанные алгоритмы и полученный опыт позволяют при желании создать отдельное игровое приложение без нарушения авторских прав и легально его продавать.



1. Анализ предметной области

Актуальность выбранной темы подтверждается исследованиями: по данным аналитической фирмы Apptopia, рынок мобильных игр в 2017 году вырос на 23,3% по сравнению с 2016-м, а его объём составил 50,4 миллиарда долларов[1]. Аналитическая фирма AppAnnie в свою очередь провела исследование[2], показывающее, что к 2020 году из прогнозируемой прибыли от мобильных приложений в 101 млрд долларов в год, 74,6 млрд долларов должно прийтись на игры.

Согласно исследованиям DeviceAtlas[6], на март 2018 года 45% всех мобильных устройств в Европе имеют в качестве операционной системы Андроид, большинство (34%) мобильных устройств обладают дисплеями с диагональю от 4,6 до 5 дюймов, на втором месте (31%) - устройства с диагональю от 5,1 до 5,5 дюймов. По данным же британского статистического агентства StatCounter[7], доля ОС Андроид на российском рынке за сентябрь 2017 года составляет внушительные 67,98% (по сравнению с 28,72% у iOS и 1,71% у Windows). Таким образом, вести разработку мобильного приложения целесообразно именно для ОС Андроид, учитывая её популярность в России.

По оценкам МТС[8], средняя цена смартфона, проданного в кредит, в 2017 году составила 19 тысяч рублей, средняя же цена смартфона в целом - 13,6 тысяч рублей. Используя данные агрегатора товаров «Яндекс. Маркет», можно составить портрет усредненного устройства, который в целом совпадает с данными статистических компаний: экран 5,5 дюймов в диагонали, разрешение от 1280х720 до 1920х1080 пикселей, объем оперативной памяти - 3 ГБ.

Статистический опрос, проведенный в рамках написания ВКР, даёт следующие результаты: версия Андроид - 7.0.0, 4 ядра с частотой 1,3 ГГц, 3 ГБ оперативной памяти; что в целом не противоречит характеристикам устройств, доступных на рынке за 13,6 тыс. рублей (см. выше).

В работе используются некоторые понятия, которые требуют расшифровки:

Android («Андроид») - операционная система для мобильных устройств, игровых приставок и смарт-телевизоров, разрабатываемая и поддерживаемая бизнес-альянсом «Open Handset Alliance» и фирмой «Google Inc». Основана на ядре ОС Linux[3].

Unity («Юнити») - среда разработки компьютерных игр для различных платформ. Позволяет вести разработку для более чем 20 операционных систем, в том числе Android. Поддерживает написание программ на языке C# и диалекте языка JavaScript, использует физический движок PhysX. Разрабатывается компанией «Unity Technologies» [4].

Физический движок - программа (чаще всего не самостоятельный продукт, а связующее звено), моделирующая физические процессы с той или иной степенью достоверности. Используется в приложении для моделирования динамики автомобилей и взаимодействия их друг с другом и с окружающим миром[5].

Среда Юнити оперирует таким понятием, как «игровой объект» (Game Object). Это некоторый объект, который обладает именем, координатами (позицией, ориентацией и растянутостью) и располагается в иерархии среди других игровых объектов. Он может принадлежать игровому объекту-родителю (или не принадлежать, в таком случае он располагается в корне сцены), и ему могут принадлежать другие игровые объекты. Также к игровому объекту могут применяться различные компоненты Юнити, такие как: отрисовщик графической модели объекта, аниматор, обработчик физической модели объекта, источник звука, и многие другие. Кроме того, одним из компонентов, применимых к объекту, может быть скрипт с классом (одним или несколькими), описывающим поведение объекта и его взаимодействие с игрой. Стандартный класс для игрового объекта является наследником встроенного класса Юнити MonoBehaviour, и обладает некоторыми стандартными методами, среди которых есть метод Start, выполняемый только при первом появлении игрового объекта, и Update, выполняемый каждый такт игрового процесса.

Такая область, как мобильные игры, является очень обширной и широко исследованной, а среда Юнити развивается с 2005 года и тоже обладает популярностью среди разработчиков. Поэтому, помимо богатого раздела официальных справочных материалов, в свободном доступе существует большое количество уроков и статей, описывающих разработку мобильных игр и пути решения часто возникающих проблем. Кроме того, Юнити предлагает такой сервис, как «Asset Store», являющий собой магазин «ассетов» - готовых решений для часто встречающихся задач (к примеру, ассеты для управления виртуальным автомобилем и тому подобное). Но ввиду дороговизны либо невысокого качества ассетов, я по возможности избегаю их использовать.

Программировать работу игры было решено на языке C#. Unity Technologies обещают отойти от строгого следования парадигме объектно-ориентированного программирования в ближайших версиях, но на данный момент придется следовать ей в полной мере, используя классы даже в тех случаях, когда экземпляр класса планируется только один.

Кроме того, была решена проблема с пользовательским интерфейсом: множество мобильных устройств на данный момент хоть и обладают разрешением экрана большим, чем у персональных компьютеров на момент выхода игры (1920 на 1080 пикселей на мобильных устройствах против 800 на 600 пикселей на ПК в 2001 году), но меньше в диагонали, а значит, становится сложнее увидеть мелкие надписи и элементы управления. Кроме того, нужно учитывать, что сенсорный экран у мобильных устройств - это средство ввода, и элементы управления должны выглядеть и быть расположены так, чтобы, с одной стороны, сделать удобным управление, а с другой, чтобы пальцы игрока не закрывали обзор игрового мира. Создавать элементы интерфейса предлагается в редакторах двумерной графики, доступных по бесплатной лицензии.

Графические модели для игрового приложения предлагается создавать в редакторе трехмерной графики «Autodesk 3Ds max», также доступном по бесплатной студенческой лицензии.

Звукового сопровождения в игре на данном ее этапе не планируется.

Таким образом, разработку игры для ОС Андроид предпочтительно вести в среде Юнити, с использованием языка C# и встроенного физического движка PhysX. По возможности не должны использоваться готовые решения («ассеты»). Требуется составить логику работы приложения, основанную на использовании игровых объектов, по большей части имеющих обработчик физической модели, отрисовщик графической модели и имеющих неопределенное количество скриптов - объектов своих классов (для большей функциональности они должны быть наследниками встроенного класса MonoBehaviour). Графические модели предлагается создавать с помощью редактора трехмерной графики, элементы интерфейса - с помощью редактора двумерной графики и с расчетом на небольшие сенсорные экраны мобильных устройств. Производительность игры должна соответствовать значениям производительности среднего устройства на рынке.



2. Постановка задачи

В качестве темы для выпускной квалификационной работы была выбрана «Разработка игрового приложения на Android».

Традиционная разработка игры предполагает[22] такие этапы, как:

1. Создание концепта игры. Разработчиком или командой разработчиков вместе с гейм-дизайнерами создается первоначальный образ игры с определением жанра игры, того, как будет идти игровой процесс, чем и как игроку предлагается управлять, какие игровые задачи будет предлагаться решить пользователю в процессе игры, какие будут критерии выигрыша или проигрыша, наличие и содержание сюжета и многое другое. Составляются документы, описывающие принятые решения, концепт-художниками создаются предварительные визуальные образы. Составляется проектная документация и план разработки продукта.

Если финансирование предполагается со стороны инвесторов, то весь получившийся набор материалов собирается в презентацию и представляется потенциальным инвесторам.

2. Создание прототипа. Упрощенный рабочий прототип игры создается с целью убедиться, что разработанная концепция работоспособна, и в эту игру будет интересно играть. Кроме того, прототип предполагает решение задач, которые могут быть не до конца ясны команде разработчиков на этапе создания концепта.

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

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

5. Закрытый бета-тест. Этап предполагает тестирование игры некоторым ограниченным количеством тестировщиков или игроков, сбор статистики, анализ сообщений о программных ошибках и их исправление.

5. Открытый бета-тест. На этом этапе идет тестирование игры большим количеством игроков. Если игра предполагается многопользовательской, то этап считается стресс-тестом на большие нагрузки, и игра при необходимости оптимизируется.

6. Запуск. Игра выпускается в общий доступ. На этом этапе должна быть налажена работа технической поддержки, график обновлений и нововведений, срочное исправление ошибок и получение прибыли.

Однако мною было решено не разрабатывать игру «с нуля», а взять в качестве образца уже существующую игру «Дальнобойщики-2», разработанную фирмой «Softlab-Nsk» в 2001 году. Причин тому было несколько:

1. Оригинальная игра до сих пор имеет большую фанатскую базу и множество форумов и групп в социальных сетях. Пользователями разрабатываются различные модификации для оригинальной игры, включающие в основном модификации текстур. Одной из проблем у большинства пользователей является то, что оригинальная игра, будучи разработанной в 2001 году, имеет некоторые проблемы с запуском на большинстве современных операционных систем, и при том, что желающих играть в оригинальную еще достаточно много, большинство из них сталкиваются с необходимостью установки виртуальных машин для запуска игры. Сторонними разработчиками была написана программа - «лаунчер», позволяющая запускать оригинальную игру на таких ОС, как Windows 7, однако запуск по-прежнему остается не самой простой задачей, а процесс игры усложнен из-за неподходящих разрешений экрана и цветовой глубины современных мониторов.

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

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

2. Разработка игры по мотивам уже существующей позволит не проводить полный цикл разработки. В частности, можно исключить такие этапы, как разработка концепции и прототипирование, и урезать этап производства контента. Такой «упрощенный» цикл производства позволяет решить такую крупную задачу, как разработка трехмерной игры на мобильное устройство, в ограниченный срок и одним разработчиком.

3. Оригинальный игровой процесс проходит по готовым алгоритмам. В игре присутствует хорошо понятное поведение автомобилей, логика работы регуляторов дорожного движения (светофоры, радары, дорожная разметка, машины ГАИ), экономическая система и цели и задачи, которые ставятся перед игроком. По этой причине вместо разработки полной концепции игры и построения алгоритмов работы элементов игры «с нуля», возможно ограничиться проведением анализа работы элементов оригинальной игры, упрощением или игнорированием некоторых из них для ускорения процесса разработки, и проведение некоего подобия обратной разработки. Такая задача полезна для студента и может привести к пониманию того, как устроены алгоритмы игровых приложений.

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

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

2.1 Функции приложения

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

Как уже сказано ранее, в качестве ориентира была взята оригинальная игра «Дальнобойщики-2» 2001 года. Однако, учитывая ограниченность времени на разработку собственного игрового приложения, недостаточность опыта и факт того, что предполагалось разрабатывать игру самостоятельно, без посторонней помощи, функционал оригинального приложения в полном объеме повторен не был: некоторые функции представлены в урезанном варианте, а некоторые отсутствуют.

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

Автопарк в игре «Дальнобойщики-2» 2001 года представлен 35-ю моделями, из которых 22 - грузовики, которые можно себе купить, и 13 - неигровой трафик на дорогах. В собственном проекте же было решено ограничиться 4-мя моделями, из которых только одна - грузовик и доступна игроку. Было создано 4 варианта ее раскраски, и все получившиеся вариации модели в нескольких копиях представляют собой водителей-конкурентов, при этом характеристики (грузоподъемность, собственный вес, жесткость подвески и пр.) и динамика поведения этих машин (интенсивность разгона и торможения, скорость и максимальный диаметр поворота руля и пр.) одинаковы. Для трафика же было создано 3 модели в 9 вариантах раскраски. Их поведение так же одинаково.

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

Повреждение транспортного средства в оригинальной игре ведет, во-первых, к визуальным изменениям: детали мнутся, отлетают; повреждение бензобака может повлечь за собой пожар, а повреждение колес делает дальнейшее передвижение невозможным. Чтобы стало возможным уложиться в предоставленные сроки разработки, последствия повреждения автомобиля ограничиваются невозможностью его передвижения, если показатель его «целости» падает ниже определенного значения. Сам же показатель постоянно виден игроку, чтобы тот мог контролировать работоспособность своего автомобиля.

За соблюдением правил дорожного движения в оригинальной игре следят радары, установленные на дорогах, и машины ГАИ, которые могут остановить и оштрафовать игрока за превышение скорости, перевозку запрещенного груза и проезд на красный свет, а также могут устроить погоню и открывать огонь по машине игрока в случае неподчинения. Подобные возможности также было решено не реализовать, поэтому правила дорожного движения в собственном проекте представлены лишь остановкой трафика на красный свет светофора.

Машины конкурентов в разрабатываемом проекте ведут себя в зависимости:

а) От того, находятся ли в данный момент в соревновании с машиной игрока;

б) От уровня «дерзости» поведения, который назначается им случайным образом в начале соревнования.

Поэтому при достаточном уровне «дерзости» машины конкурентов могут проигнорировать красный свет светофора или даже обогнать машину игрока по встречной полосе.

Мафия, которая в оригинальной игре могла ограбить игрока, в проекте отсутствует. Рация, через которую можно держать связь с участниками движения, - тоже.

Подводя итоги сравнения, можно свести все критерии в таблицу:

Таблица 1. Сравнение игры «Дальнобойщики-2» на ПК и собственного приложения

Критерий	«Дальнобойщики-2» на ПК	Собственная игра
Населенных пунктов	11	3
Моделей транспорта	35	4
Доступных игроку автомобилей	22	1
Возможность найма водителей	Есть	Нет
Улучшение работы машины	Гибкая настройка	Повышение мощности в процентах
Слежение за соблюдением ПДД	Машины ГАИ, радары	Нет
Мафия	Есть	Нет
Нелегальные грузы	Есть	Нет
Повреждение машины	Визуально, постепенное ухудшение управляемости	Невозможность передвижения при значении ниже порогового
Разнообразное поведение соперников	Разные машины, разный стиль вождения	Разный стиль вождения
Рация	Есть	Нет
Соревнования без груза на гоночной карте	Есть	Нет
Смена времени суток	Есть	Нет
Смена погоды	Есть	Нет

Таким образом, весь функционал разрабатываемого приложения представлен следующими пунктами:

1. Возможность управлять грузовиком при нажатии соответствующих кнопок;

2. Предоставление и обновление грузов для перевозки игроком;

3. Обработка результатов перевозки и выдача виртуальных денег игроку;

4. Обновление карты с обозначениями городов, пунктов обслуживания и положением игрока и соперников;

5. Симуляция поведения машин соперников;

6. Симуляция поведения машин трафика;

7. Реагирование на состояние машины и количество топлива;

8. Ремонт и улучшение работы на виртуальных станциях тех. обслуживания;

9. Заправка топливом на виртуальных заправочных станциях.

Симуляция поведения машин соперников также включает в себя расчет кратчайшего пути до требуемого населенного пункта и поведение в зависимости от заданного стиля поведения.

Как видно, набор функций в разрабатываемом приложении значительно скуднее, чем в оригинальной игре. Тем не менее, такой функционал возможно реализовать в заданные сроки и с имеющимся уровнем опыта.

2.2 Требования, предъявляемые к разрабатываемому приложению

Для приложения, разрабатываемого в ходе ВКР, были определены следующие требования:

1. Работа на ОС Android не ниже 4.4.2;

2. Минимальное количество кадров в секунду - 12;

3. Возможность дублирования элементов интерфейса в зависимости от конфигурации устройства.

Как было выяснено раньше (см. «Анализ предметной области»), характеристики среднего мобильного устройства в 2017 году составляли: версия Андроид - 7.0.0, 4 ядра с частотой 1,3 ГГц, 3 ГБ оперативной памяти. Однако, учитывая крайнюю ограниченность бюджета, покупка устройства с подходящими характеристиками в планы не включена, а тестирование работы приложения предполагается на уже имеющемся устройстве со следующими характеристиками: версия Андроид - 4.4.2, 4 ядра с частотой 1,3 ГГц, 1 ГБ ОЗУ (именно этим объясняется требование к минимальной версии ОС). Как видно, характеристики данного устройства не превышают характеристики среднего устройства за 2017 год ни по какому из параметров, поэтому можно утверждать, что добившись удовлетворительной работы на имеющемся образце, можно будет рассчитывать на стабильную работу на современных устройствах.

Требование 12-и кадров в секунду в качестве минимума продиктовано личным опытом автора и исследованиями, проведенными кинематографистами в начале 20-го века[8], показывающими, что именно такое количество (по некоторым данным - 10) кадров в секунду - минимальное для того, чтобы человеческий глаз воспринимал его как движение (при значениях меньше мозг обрабатывает кадры как сменяющиеся картинки без движения). И хоть средняя скорость смены кадров в кинематографе и видеоиграх возрастает, 12 кадров в секунду до сих пор остается минимальным стандартом, к примеру, в анимации[8]. Таким образом, требование к частоте смены кадров продиктовано удобностью игрового процесса.

Согласно исследованиям StatCounter[7], 67,98% смартфонов и планшетов в России используют в качестве операционной системы Андроид, однако прочих устройств, использующих эту ОС по умолчанию настолько мало, что статистика по ним не ведется (в расчет не берется ОС Android Wear, используемая в смарт-часах и версия Андроид, используемая в смарт-телевизорах), а случаи выпуска таких устройств вызывают некоторый резонанс, и рассматриваются новостными изданиями скорее как «эксперименты» [10]. Тем не менее, учитывая возможность подключения QWERTY-клавиатур к устройствам на ОС Андроид, решено продублировать возможность управления приложением с помощью клавиатуры.



3. Описание инструментальных средств разработки

Для того чтобы создание трехмерной игры было возможным, требовалось подобрать следующие инструменты:

1. Язык программирования;

2. Среда разработки;

3. Редактор трехмерной графики.

Было решено обойтись без редактора двумерной графики, так как текстуры для сохранения внешнего облика необходимо было брать из оригинальной игры. Некоторая необходимая мелкая работа, такая, как размытие изображения и его цветовая коррекция для создания фонового меню, была проведена с помощью бесплатных онлайн-сервисов по обработке изображений.

Также для экономии времени было решено пренебречь звуками в игре, поэтому никакой звуковой редактор не используется.

3.1 Язык программирования

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

1. Поддержка данного языка в хотя бы одной из популярных сред для разработки компьютерных игр;

2. Оценка удобства и полезности языка профессиональными программистами на основе сравнения его с прочими языками;

3. Поддержка в стандартных библиотеках некоторых функций, таких как сериализация, работа с указателями и пр.;

4. Собственный опыт разработки на различных языках.

Основной опыт работы с языками программирования, на которых возможно написание подобной игры, был получен мной за время учебы в ВоГУ. Прочие языки, некоторый опыт работы с которыми был получен мной в школе (Visual Basic, Pascal), во внимание было решено не брать, так как, во-первых, вряд ли стоит надеяться на широкую их поддержку в популярных средах разработки игр, а во-вторых, возможность разработки на них насколько-нибудь серьезной трехмерной игры - вопрос спорный. Таким образом, выбирать приходилось из Си-подобных языков: C++, Java, C#.

Первый критерий для выбора языка, как уже сказано ранее, - это наличие его поддержки одной из популярных сред разработки. В качестве кандидатов на среду для разработки собственного проекта я рассматривал Unity и Unreal Engine (см. 3.2 Среда разработки).

Unity поддерживает разработку на двух языках: C# и специальную модификацию JavaScript, которая носит название UnityScript. В прежних версиях была также возможна разработка на диалекте Boo («Бу») языка Python, однако сейчас этой возможности нет. Учитывая, что ни JavaScript, ни Python не рассматривались как возможные варианты, будем считать, что разработка в Unity в данном положении предполагается с помощью C#.

Основным языком, который поддерживает Unreal Engine, является C++. Вплоть до выхода Unreal Engine 4, в качестве основного языка разработки использовался[13] так называемый UnrealScript - высокоуровневый язык программирования для игр, основанный на Java. Однако в 4 версии Unreal Engine разработчики полностью отказались от поддержки этого языка, уделив основное внимание C++.

Кроме того, в Unreal Engine существует система визуального программирования с помощью нодовой структуры, которая носит название Blueprints Visual Scripting[14]. Утверждается, что система, хоть и разработана для прототипирования уровней, но может заменить собой языки программирования во множестве случаев, и даже позволяет спроектировать рабочий образец игры полностью без использования языков программирования. Однако такой способ кажется не весьма удобным, учитывая размер разрабатываемого проекта; кроме того, опыта в визуальном программировании у автора слишком недостаточно.

Также на форумах, посвященных разработке игр на Unreal Engine, обсуждаются[15] различные способы написания кода на C# в данной среде, однако все они предполагают использование сторонних плагинов и нестандартных решений, а значит, не могут обеспечить достаточную надежность и работоспособность.

Таким образом, разработку предлагается вести или в среде Unity с использованием языка C#, или в среде Unreal Engine с использованием C++. Сравнение прочих достоинств и недостатков этих средств разработки приведено в разделе «3.2 Среда разработки».

Выбор между C# и C++ предполагает сравнение этих языков между собой по различным параметрам. Не имея достаточно опыта в программировании на обоих языках, предпочтительнее ознакомиться с различными источниками[12] [16], излагающими авторитетное мнение.

Оба этих языка объектно-ориентированные, оба широко используются для написания веб-приложений и программ на ПК. C++ считается языком более сложным для изучения, но более предпочтительным для написания таких продуктов, как игры, операционные системы и в случаях, когда требуется использование низкоуровнего программирования с лучшим контролем памяти и работы оборудования.

И C++, и C# - это Си-образные языки, поэтому их синтаксис не сильно различается: для разграничения фрагментов программы используются скобки и фигурные скобки, и механизмы зависимостей, наследований и использования библиотек очень похожи. Если разработчик знаком с Java или C++, то ему не составит труда перейти на C#. Однако, перейти с C# на C++ гораздо сложнее, потому что при работе на C++ приходится учитывать его низкоуровневость, и некоторые проблемы, решение которых берет на себя C#, приходится решать уже разработчику. Тем не менее, оба эти языка объектно-ориентированные, то есть в них обоих существуют понятия классов, наследования и полиморфизма.

Основные же различия, если их сократить до наиболее часто встречающихся, следующие:

1. Размер скомпилированных двоичных файлов. Оба языка - компилируемые, то есть код превращается в двоичные исполняемые файлы. Но, учитывая, что, как уже было написано ранее, C# решение многих проблем берет на себя, то подключение многих библиотек автоматически увеличивает размер исполняемого файла. То есть, готовые исполняемые файлы C++ гораздо менее массивные, чем файлы C#.

2. Производительность. C++ широко используют, когда языки более высокого уровня не могут проявить достаточную эффективность. Код, написанный на C++, гораздо более быстрый, чем код C#. Это имеет значение для проектов, где высокая скорость работы является важным фактором. Однако, существует такое решение, как написание фрагментов кода, где наиболее важно быстродействие (скажем, подсчет анализ интернет-трафика), на C++, а написание остальной части программы - на C#, потому что при работе стандартных приложений в быстродействии особенной разницы заметно не будет.

3. Сбор мусора. Используя C#, можно не беспокоиться об этой проблеме: сборщик мусора работает по умолчанию. Используя C++, разработчик должен следить за выделением и освобождением памяти для своих объектов.

4. Нацеленность на платформу. Язык C# был разработан Microsoft на замену языка Java, однако вопреки планам корпорации, не получил должного распространения, поэтому в кроссплатформенности он скорее проигрывает C++. Программы на C# обычно нацелены на использование в ОС Windows, несмотря на усилия Microsoft по кросплатформенной поддержке языка. На C++ можно разрабатывать проекты для любых платформ, включая Windows, Mac, Linux и много других.

5. Типы проектов. Программисты C++ в основном сосредотачиваются на приложениях, работающих напрямую с оборудованием, или требующих лучшей производительности. Это могут быть серверные приложения, приложения, обслуживающие работу сети, игровая индустрия, драйверы и многое другое. C# в основном используется для веб-приложений, мобильных приложений и приложений для ПК.

6. Сообщения компилятора. C++ позволяет разработчику выполнить практически любой код, при условии, что в нем нет синтаксических ошибок. Неверный код может привести к повреждениям работы устройств. C# гораздо более защищен от подобных случаев, и компилятор выдает предупреждения и сообщения об ошибках, предотвращая причинение необратимого ущерба[16].

Учитывая недостаточный опыта автора в разработке сколько-нибудь крупных проектов; то, что разрабатываемый проект - игра для мобильного устройства, но при этом не требует достаточно большой скорости работы (по сравнению с анализаторами интернет-трафика и приложениями, ведущими сложные расчеты в режиме реального времени); а также то, что при написании кода на C# компилятор берет на себя значительную часть работы с библиотеками, математическими вычислениями и выделение и очистку памяти, принято решение, что желательным языком для написания программной части приложения будет именно C#.

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

а) Для полноценной работы игрового приложения на ОС Андроид при его установке и так будут автоматически добавлены большое количество библиотек, а также графические файлы и трехмерные модели, используемые в игре. На фоне добавленных ресурсов увеличение конкретно исполняемого файла программы будет совершенно незначительно;

б) Современные устройства, работающие на ОС Андроид, как правило, располагают достаточным объемом ПЗУ, чтобы при разработке можно было не беспокоиться по поводу каждого ресурса, увеличивающего виртуальный размер продукта (до разумных пределов).

Таким образом, я могу утверждать, что мне, как программисту с недостаточно большим опытом, предпочтительнее было бы вести разработку с использованием C#.

3.2 Среда разработки

Статистических исследований, показывающих популярность различных движков, используемых для разработки игр для ОС Андроид, автором найдено не было, однако, проанализировав некоторое количество источников[17] [18] [19] [20] [21], список самых популярных и поддерживаемых средств разработки можно свести к следующим:

1. Unity (он же Unity3D);

2. Unreal Engine (он же UE4);

3. GameMaker Studio;

4. Adobe Flash;

5. Corona SDK.

Прежде всего, стоит выяснить, на каких из представленных движков возможна разработка трехмерных игр. Под этот критерий сразу не попадают GameMaker Studio, Adobe Flash и Corona SDK, поэтому в качестве кандидатов рассматривались только Unity и Unreal Engine.

Для правильного выбора пришлось подробнее рассмотреть характеристики этих сред.

Необходимо определиться с требованиями к системе, на которой будет вестись разработка. На имеющемся у меня оборудовании установлена ОС Windows 7 64-bit. Обе среды позволяют[11] вести разработку на этой системе, причем для Unreal Engine это минимальное требование, в то время, как Unity работоспособен уже на Windows XP SP2.

Не менее важным было наличие возможности компилировать продукт для ОС Андроид. Согласно заявленным возможностям[11], UE4 позволяет выпускать продукт для таких платформ, как: iOS, Android, VR, Linux, Windows, Mac OS X, SteamOS, HTML5, Xbox One, и PS4, в то время, как для Unity список следующий: iOS, Android, Windows Phone 8, Tizen, Android TV и Samsung SMART TV, Xbox One и 360, Windows, Mac OS X, Linux, WebGL, VR (в том числе Hololens), SteamOS, PS4, Playstation Vita, и Wii U. Как видно, обе платформы позволяют вести разработку для ОС Андроид, но при этом, если планировать дальнейшее развитие продукта для других платформ, то используя Unity, можно будет охватить большее число устройств.

Немаловажен при выборе средства разработки также поддерживаемый им язык программирования. Списки поддерживаемых движками языков полностью расходятся: Unity3D предлагает написание кода на диалекте Javascript под названием «UnityScript» или C#, а Unreal Engine поддерживает только C++. Существуют различные споры[12] о том, на каком языке лучше вести разработку подобных игровых проектов, однако для автора предпочтительнее C# (см 3.1 Язык программирования).

Прочие критерии, по которым часто сравнивают Unreal Engine и Unity:

1. Стоимость движка. Оба движка условно-бесплатные, то есть на них возможно вести разработку в определенных пределах, не заплатив фирмам-изготовителям движков. Полноценное же пользование ими требует некоторых вложений:

Для пользования UE4 требуется платить 5% от доходов с продаж готового продукта, если прибыль за квартал превышает 3000 долларов. Если прибыль не достигает этого значения, пользоваться движком можно бесплатно, при этом не существует никаких ограничений функционала.

Разработчик Unity требует купить полноценную версию за 1500 долларов или оплатить месячную подписку за 75 долларов, если прибыль разработчика игры составляет 100000 долларов за год. Кроме этого, существую отдельные сборы за разработку игр для iOS или Android. Если разработчик игр получает на продажах своего продукта меньше этой суммы, можно пользоваться бесплатной версией Unity, при этом в ней существуют некоторые ограничения по сравнению с полноценной версией. В основном они связаны с подготовкой или продажей собственных пакетов ресурсов и предустановок (Asset Bundle), с невозможностью разработки мультиплеерных игр с коммуникацией через интернет и с заменой обязательного логотипа Unity, который появляется при запуске игрового приложения.

2. Магазин ассетов. Понятие «ассет» может означать ресурс, который можно использовать в собственном игровом приложении (это может быть трехмерная модель, двумерный рисунок, текстура, звук, анимаций) или предустановку (это может быть исполняемый скрипт, позволяющий решить одну из часто встечающихся задач). К примеру, ассет управления автомобилем может состоять из заранее соединенных между собой нужным образом физических моделей колес с подвеской, временного заменителя корпуса автомобиля и скрипта, который привязывает клавиши к управлению и реализует динамику движения такой заготовки автомобиля.

Оба движка имеют собственные онлайн-магазины ассетов. Там можно получить готовые к использованию трехмерные модели персонажей, текстуры, модели окружения, а также звуковые файлы и системы частиц. Однако по количеству предлагаемых в магазине ассетов Unity3D одерживает верх над UE4. В качестве примеров уникальных ассетов, предлагаемых Unity, можно привести готовую анимацию, генераторы пользовательского интерфейса, системы искуственного интеллекта, ассеты для работы с дополненной и виртуальной реальностью, и фреймворки для создания так называемых RPG (ролевых игр, как правило, связанных с историческими событиями или жанром фэнтези).

3. Простота использования. Unity известен своим интуитивно понятным интерфейсом, который несколько снижает входной порог для начинающих разработчиков. И даже несмотря на то, что в новых обновлениях Unreal Engine было проделано много работы по улучшению интерфейса, с точки зрения удобства использования он все еще находится на втором месте.

Пользовательские интерфейсы в Unity и в Unreal Engine довольно похожи, если учесть растягиваемость и перемещаемость панелей инструментов, но интерфейс Unreal Engine все же более перегружен и сложен, и совершение многих действий, таких как импорт и сохранение ассетов, в нем занимает больше времени и требует большего количества шагов. Unity в этом плане быстрее (Unity может довольно быстро работать на Windows XP SP2), его интерфейс ощущается более дружелюбным и охотнее откликающимся на действия пользователя.

4. Графика. Что касается графики, то Unreal Engine выдает результат лучше, чем Unity. Движок Unreal Engine способен на такие вещи, как сложное динамическое освещение и симуляция частиц. Однако, во-первых, в моем проекте графика не столь важна (учитывая, что нужно скопировать внешний облик игры 2001 года), а во-вторых, в ближайших версиях Unity разработчики обещают поднять уровень графики до конкурентоспособного.

Среди прочих особенностей Unity и Unreal Engine можно выделить следующие:

5. В обоих средах присутствует «профайлер» - инструмент, позволяющих анализировать загруженность вычислительных ресурсов конкретными процессами игры: от работы скриптов и сборщика мусора до отрисовки.

6. Unreal Engine слабее оптимизирует проектируемые приложения для работы на мобильных устройствах.

7. Интерфейс Unity отличается возможностью использовать «Drag-and-drop» - функцию, автоматически импортирующую элементы в проект или преобразующую их в нужный формат (к примеру, из изображения в текстуру с координатами) просто при перемещении этих элементов мышью из одного окна в другое.

8. И у Unity, и у Unreal Engine есть большие сообщества разработчиков и справочные материалы, позволяющие найти уже существующие решения для множества задач.

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

Рисунок 1. Интерфейс Unity3D с открытым проектом разрабатываемой игры

Интерфейс Unity представлен на рис. 1. Основные элементы:

Таблица 2. Основные элементы интерфейса Unity3D

Цифра	Название	Комментарий
1	Панель инструментов	Содержит элементы управления сценой и запуском / остановкой игры
2	Окно сцены («Scene»)	Окно для работы с элементами сцены: добавление, выделение, перемещение, масштабирование, поворот
3	Окно игры («Game»)	Работа игры (если включен режим игры).
4	Структура сцены («Hierarchy»)	Содержит иерархию всех добавленных в сцену элементов.
5	Окно проекта («Project»)	Содержит все импортированные ресурсы и скрипты
6	Инспектор («Inspector»)	Управление добавленными к игровым объектам компонентами

В среде присутствуют и другие элементы интерфейса, которые могут быть вызваны через пункт меню Window или через контекстное меню.

Панель инструментов содержит следующие кнопки (по порядку, слева направо):

Рисунок 2. Панель инструментов

1. Hand Tool («рука») позволяет перемещать камеру (точку зрения) в окне Scene.

2. Move Tool («перемещение») позволяет выделять и перемещать объекты по сцене. При выделении объекта он обводится оранжевой линией по контуру, и в центре его локальных координат появляются три цветных стрелки, взявшись за которые можно перемещать объект по одной из осей. Между каждыми двумя стрелками также появляется полупрозрачный квадрат, взявшись за который возможно переместить объект сразу по двум осям.

3. Rotate Tool («поворот») позволяет выделять и поворачивать объекты вокруг одной из своих трех осей. При выделении объекта он обводится оранжевой линией по контуру, и в центре его координат появляется полупрозрачная конструкция из трех перпендикулярных друг другу цветных окружностей, взявшись за любую из которых, можно повернуть объект по любой из его осей. Взявшись за пустое пространство между этими окружностями, можно свободно вращать объект без привязки к осям. Кроме того, появляется серая, перпендикулярная оси камеры окружность, взявшись за которую, можно вращать объект вокруг оси направления камеры.

4. Scale Tool («масштабирование») позволяет выделять и масштабировать объекты. При выделении объекта он обводится оранжевой линией по контуру, и в центре его координат появляется полупрозрачная конструкция из трех цветных кубиков, отстоящих от серого кубика в центре на некоторое расстояние. Взявшись за один из цветных кубиков, можно изменить масштаб трехмерной модели вдоль одной из осей объекта, а взявшись за серый кубик, можно изменять масштаб всего объекта с сохранением его пропорций.

5. Rect Tool («прямоугольник») также позволяет выделять, масштабировать и перемещать объекты, но при этом в качестве графической подсказки использует прямоугольник, очерчивающий габариты объекта относительно той его плоскости, угол между нормалью которой и осью камеры минимален. Инструмент рассчитан скорее на работу с двумерными объектами, но работает и с трехмерными моделями. Взявшись и потянув курсором за один из углов прямоугольника, можно «растянуть» объект в соответствующую сторону, а взявшись за любое место внутри прямоугольника можно перемещать объект вдоль плоскости прямоугольника.

6. Move, Rotate or Scale Selected Objects («Передвинуть, вращать или масштабировать выделенные объекты») - инструмент совмещает в себе функции инструментов №2, 3 и 4.

7. Pivot/Center («Привязка / Центр») - Кнопка переключения «Pivot» (привязка) позволяет переключать режим поворота, перемещения и масштабирования объектов относительно точки начала координат объекта или относительно геометрического центра объекта.

8. Local/Global («Локальная/глобальная») - инструмент переключает систему координат объекта. В зависимости от включенного режима «Center» или «Global», вращение, масштабирование и перемещение будут осуществляться с учетом уже заданной ориентации объекта. Если объект имеет не нулевые координаты поворота, и при этом включен режим «Local», то графические подсказки (стрелки, окружности или кубики) будут соответствовать ориентации объекта. Если же включен режим «Global», они всегда будут соответствовать состоянию «по умолчанию», вне зависимости от заданной ориентации.

9. Play («запуск») - запускает режим игры. Если в ходе программирования допущены ошибки, то появится окно консоли с сообщениями об ошибках. В противном случае игра запустится в окне Game. В запущенном режиме игры отключены некоторые функции приложения, чтобы обеспечить правильную работу. Все изменения, совершенные в окне Scene во время режима игры, аннулируются после остановки игры или окончания сценария.

10. Pause («пауза») - приостанавливает ход игры, не выключая при этом режим игры. Позволяет оценить состояние объектов и изменить нужные параметры любого из них.

11. Step («шаг») - запускает работу скриптов и физического движка на одну итерацию и изменяет состояние игровых объектов на один шаг вперед, не выходя при этом из режима игры.

Окно Scene позволяет устанавливать объекты в нужное место, выделять их, перемещать, вращать, масштабировать, и также перемещать и вращать рабочую камеру (точку зрения для работы). В верхнем правом углу присутствует полупрозрачная конструкция из одного серого куба и шести цветных конусов. При нажатии на один из конусов камера выравнивается в соответствии с выбранной осью. Нажатие на куб позволяет переключаться между изометрическим видом и перспективой. Значок замка справа от конструкции позволяет заблокировать вращение рабочей камеры.

В верхней панели окна Scene присутствуют переключатели, позволяющие включить или отключить освещение, различные эффекты (туман, блики), звук или отображение вспомогательных объектов сцены: игровых камер, нефизических объектов и пр. Также строка поиска в верхней панели окна позволяет быстро найти нужный объект в сцене.

Окно Game демонстрирует изображение с игровых камер, и работающий пользовательский игровой интерфейс (если он создан разработчиком). Окно позволяет переключаться между разными игровыми камерами, установленными в сцене и масштабировать картинку. При нажатии режима Maximize On Play окно автоматически разворачивается во весь экран при входе в режим игры. При необходимости в этом окне также можно отобразить неигровые объекты, однако любое перемещение, масштабирование и вращение объектов внутри этого окна невозможно, если так не запрограммировано разработчиком.

Окно Hierarchy содержит все игровые объекты, которые есть в сцене. Объекты в обязательном порядке должны иметь имя (не обязательно оригинальное), положение в иерархии сцены и компонент Transform (см. абзац про окно Inspector). Любой объект может содержать в себе неограниченное количество других объектов. При изменении ориентации, положения или масштаба объекта, объекты внутри него изменяются соответствующим образом. Объекты можно дублировать, выделив их в окне Scene или Hierarchy и нажав Ctrl+D или вызвав соответствующую команду через контекстное меню. В верхнем поле окна Hierarchy также присутствует полоса для быстрого поиска игровых объектов.

Окно Project позволяет импортировать, создавать или преобразовывать ресурсы. К примеру, импорт изображения, звука или трехмерной модели возможен, если перетащить соответствующий файл из проводника Windows в это окно. Также через контекстное меню этого окна можно создать новый скрипт, чтобы потом отредактировать его в одном из редакторов кода и применить к игровому объекту.

Окно Inspector содержит компоненты, примененные к игровым объектам, и их свойства. По умолчанию у любого игрового объекта присутствует неудаляемый компонент Transform, содержащий данные о положении и системе координат игрового объекта и всех его дочерних объектов. Помимо описанных выше способов трансформации объекта с помощью инструментов на панели инструментов, возможно изменение любой из его координат путем введения нового значения в поля Position, Rotation или Scale компонента Transform. Каждый компонент имеет название может дублироваться несколько раз в пределах одного игрового объекта. Значения компонентов можно сбросить на значения по умолчанию, если зайти в контекстное меню компонента, нажав значок шестеренки в его правом верхнем углу и выбрав пункт меню Reset. Сами компоненты могут превращать игровой объект, к которому они применены, в игровую камеру, источник света, элемент пользовательского интерфейса, трехмерный объект, двумерный объект и многое другое, в зависимости от выбора конкретного компонента. Поля компонентов доступны программно из скриптов самого игрового объекта или любого другого в пределах одного проекта. Сами скрипты применяются к игровым объектам отдельно и в свою очередь также являются компонентами.

Подробнее об используемых в проекте компонентах см. «5.1 Компоненты Unity, используемые для разработки приложения».

Сам по себе Unity не позволяет писать и редактировать код исполняемых скриптов, только отображая их текст в отдельной панели при выделении скрипта. Поэтому написание скриптов ведется во внешних средах разработки, которые подключаются к Unity, дополняя его функционал. При скачивании Unity пользователь должен выбрать из двух по умолчанию предлагаемых сред разработки: Microsoft Visual Studio или MonoDevelop. Автором был сделан выбор в пользу MonoDevelop, учитывая небольшой объем занимаемой памяти и нетребовательность этой среды к ресурсам компьютера.



Рисунок 3. Интерфейс среды разработки MonoDevelop с выполняющейся в данный момент программой

Среда разработки MonoDevelop включает в себя компилятор языка C# с самых своих ранних версий, а на данный момент позволяет вести написание программ также на языках Boo, C, C++, F#, Java, Visual Basic.NET и некоторых других. При выборе этой среды во время установки Unity, скачивается специальная сборка MonoDevelop-Unity, уже подключенная к среде разработки игр.

Интерфейс MonoDevelop-Unity достаточно лаконичен: большую часть окна программы занимает панель вкладок с текстовым полем. Каждый новый скрипт, открытый через Unity, создает новую вкладку в MonoDevelop.

На панели управления содержатся поле для поиска текста, кнопка запуска программы, меню выбора режима работы программы (Debug или Release) и меню выбора среды, через которую предполагается работа написанной программы (по умолчанию Unity Editor). При запуске программы, если не обнаружено ошибок, скомпилированный скрипт передается в Unity, и в Unity запускается редактируемый уровень игры. При этом на панели управления MonoDevelop кнопка запуска заменяется кнопкой остановки, а также появляются новые кнопки, позволяющие приостановить работу программы или выполнить трассировку или пошаговое выполнение.

MonoDevelop-Unity имеет функцию автодополнения текста, при которой поля и методы, используемые Unity, автоматически предлагаются в качестве выбора при написании кода.

Используя метод Debug. Log(), можно выводить нужные сообщения для отладки в окно консоли Unity, а используя прочие методы Debug, можно также добиться отображения специальных, нужных разработчику для отладки простых линий или форм в окне редактора уровня Unity.