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

35

Проектное предложение на программную и информационную разработку

Цель работы

Целью курсовой работы является:

- написание программного продукта, предназначенного для имитации физического взаимодействия между объектами на основе игрового симулятора;

- изучение особенностей современной мобильной платформы Google Android;

- работа со средой разработки Unity3d;

- разработка скриптов на языкеC#;

- графическое моделирование приложения;

Общие положения

Написание приложения должно включать в себя изучение особенностей мобильной платформы Google Android и освоение среды разработки Unity3d.

Технико-экономическое обоснование

Сегодня как в России, так и во всём мире существует тенденция разработки игровых симуляторов. Поэтому на данный момент актуальным является выпуск самих игровых симуляторов, а также платформ для разработки игр и программ симуляции физики. Однако, несмотря на то, что зачастую данные программы используют исключительно в коммерческих целях (выпуск игровых программ), так же данные программы можно использовать в определённой сфере науки. Обе стороны применения программного продукта могут принести не только прибыль, но и внести не малый вклад в развитие технологий в целом. Игровой симулятор наглядно покажет, как происходят физические взаимодействия объектов в компьютерной среде. Примером актуальности может служить игровое приложение «A SlowerSpeedofLight», разработанное Массачусетским технологическим институтом, которое позволяет игроку, перемещается по 3D-пространству на скорости, близкой к скорости света, и собирает сферические объекты, каждый из которых замедляет скорость света на фиксированные значения. При этом в реальном времени обсчитываются визуальные эффекты, в соответствии со специальной теорией относительности.

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

Технические требования

Разработанное приложение должно предоставлять пользователю следующие возможности.

1. Перемещение персонажа по осям X,Y. Сюда входят: перемещение персонажа влево, вправо; падение с высоты, передвижение вверх, вниз по лестнице.

2. Уничтожение земли.

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

4. Управление от касания по экрану на смартфонах поддерживающих multitouch.

5. Наличие главного меню.

6. Использование собранных предметов.

Так же необходимо реализовать:

1. Физический движок, симулирующий движение и столкновение объектов. Для имитации физического взаимодействия объектов нужно создать спрайты окружения: земля, бетон, липкая земля, вода, пещера, телепорт, двери перехода на следующий уровень, бомбы, ключи, отбойный молоток, золото, кирка, трава, ведро липкой жидкости, лестницы, верёвки.

2. Интерфейс, включающий в себя: счёт игрока,количество жизней и бомб, иконка собранного предмета.

3. Спрайтовую анимацию для главного героя и вражеских персонажей.

4. Звуковое сопровождение.

5. Игровой искусственный интеллект.

6. Возможность сохранения, загрузки и удаления данных игрового прогресса.

7. 31 уровень.

Требования к среде разработки

Проекту необходима среда разработки соответствующая следующим основным критериям:

- быстрая;

- поддерживающая несколько систем рендеринга (OpenGL и DirectX);

- расширяемая;

- поддерживающая несколько платформ;

- поддерживающая экспорт моделей из пакета моделирования 3D StudioMax, Blender;

- поддерживающая работу со скриптами;

- возможность разработки игрового приложения на языке С#.



Введение

Сегодня компьютерная индустрия предлагают большой выбор разнообразных мобильных устройств от простейших монохромных телефонов до всевозможных нетбуков. Существует множество различных программных платформ для подобной техники. Но лидирующие роли сейчас занимают ОС от компаний Apple, Microsoft, Google, Nokia, Rim. В данной работе мы подробнее остановимся на операционной системе Android, являющейся частью одноименной платформы от компании Google. Данная платформа была предложена компанией Google как универсальная платформа для смартфонов с открытым кодом. В настоящее время ее поддержкой занимается Openhandsetalliance, в который помимо самого Google входят ведущие производители оборудования, операторы связи и другие крупные игроки на рынке мобильных устройств. К моменту написания данной работы в продаже уже появились смартфоны на базе ОС Android таких известных компаний, как HTC, Motorola, Samsung, Sony Ericsson, LG.

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

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

Примером актуальности подобных приложений может служить игровое приложение «A SlowerSpeedofLight», разработанное в Массачусетском технологическом институте (MIT), которое позволяет игроку, перемещается в 3D-пространстве на скорости, близкой к скорости света. От игрока требуется собирать сферические объекты, каждый из которых замедляет скорость света на фиксированные значения. При этом в реальном времени обсчитываются визуальные эффекты, в соответствии со специальной теорией относительности.

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



1. Обзор и сравнение существующих средств для разработки игровых симуляторов

Игровой Движок - это центральный программный компонент компьютерных и видео игр или других интерактивных приложений с графикой, обрабатываемой в реальном времени. Он обеспечивает основные технологии, упрощает разработку и часто даёт игре возможность запускаться на нескольких платформах, таких как игровые консоли, мобильные телефоны и настольные операционные системы. Основную функциональность обычно обеспечивает игровой движок, включающий движок рендеринга («визуализатор») для 2D или 3D графики, физический движок или обнаружение столкновений (и реакцию на столкновение), звук, язык скриптов и систему их использования, анимацию, игровой ИИ, поддержку сетевой игры, работу с потоками и управление памятью. Часто на процессе разработки можно сэкономить за счет повторного использования одного игрового движка для создания множества различных игр или покупки готового движка.

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

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

1.1 Требования к движку

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

Проекту был необходим современный движок соответствующий следующим основным критериям:

- быстрый;

- поддерживающий несколько систем рендеринга (OpenGL и DirectX);

- расширяемый;

- поддерживающий несколько платформ;

- поддерживающий экспорт трехмерных моделей из пакета трехмерного моделирования 3D StudioMax;

- возможность разработки игры на C#;

- простая и гибкая ООП модель.

1.2 Анализ существующих решений (движков)

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

1.2.1 UnrealEngine

UnrealEngine- игровой движок, разрабатываемый EpicGames. Первая игра, созданная на этом движке - Unreal- появилась в 1998 году. С тех пор различные версии UnrealEngine были использованы в десятках игр, в том числе DeusEx, Lineage II, Thief: DeadlyShadows, сериях игр BrothersinArms, TomClancy'sSplinterCell, TomClancy'sRainbowSix и, конечно, в серии игр Unreal. Будучи приспособленным в первую очередь для шутеров от первого лица, движок использовался и при создании игр других жанров, например файтингФайтинг - жанр компьютерных игр, имитирующих рукопашный бой малого числа персонажей в пределах ограниченного пространства, называемого ареной. MortalCombat и стратегия X-com.

Написанный на языке C++, движок подходит для создания игр для большинства популярных платформ: Win32, Linux, Mac OS X, консолей Xbox, Xbox 360, PlayStation 2, PlayStationPortable, PlayStation 3 и других. Для большей портируемости, движок поддерживает различные системы рендеринга (DirectX, OpenGL) и воспроизведения звука. Последняя версия -UnrealEngine 4, которая, несмотря на цену почти в миллион долларов, является одним из самых популярных движков.http://wiiu.pro/unreal-engine-4-predstavlen/

В конце 1999 года EpicGames опубликовала часть исходных кодов исполняемых файлов UnrealTournament, что послужило началу работы проекта OpenUT по портированию движка и игры на Linux. Через некоторое время работу над OpenUT перехватила LokiGames, а поддержка OpenUT была прекращена.Linux-версия UnrealTournament была выпущена в продажу LokiGames.

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

Вторая версия по прежнему доступна для лицензирования. EpicGames предлагают её для создания игр на «действующие» персональные компьютеры или приставок шестого поколения за сумму $ 350 000 и больше (зависит от количества поддерживаемых платформ).

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

Для бюджетных проектов доступно также лицензирование UnrealEngine 2 Runtime по цене от $ 8000. Стоимость лицензии зависит от количества разработчиков.

Цена лицензирования версий 3.0 и выше не публикуется, однако упоминается что имеется выбор из различных вариантов лицензий, в том числе и для не игровых продуктов.

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

5 ноября 2009 года был выпущен пакет UnrealDevelopmentKit, бесплатная версия UnrealEngine 3.0 для некоммерческого использования с возможностью покупкикоммерческой лицензии. Если написание игр на UnrealEngine 2 Runtime было строго запрещено, то написание игр с использованием UDK допустимо, однако запрещено на его базе создание продуктов, которые могут или будут соперничать с UDK, а также связующим ПО (middleware) или ПО для разработки игр (game development software) созданным EpicGames

1.2.2 Cry Engine

CryEngine 2 - игровой движок, созданный компанией Crytek и впервые используемый в шутере от первого лица Crysis. CryEngine 2 базируется на движке CryEngine, созданным этой же компанией в 2004 году и впервые используемым в игре FarCry. На момент своего выхода является самым технологически продвинутым и фотореалистичным движком по сравнению с конкурентами. Сама Crytek позиционировала CryEngine 2 как первый по-настоящему фотореалистичный движок. Как стало известно с официальных источников, в сиквеле Crysis 2, который вышел в 2009 году, разработчики улучшат текстуры и скелетную анимацию.

Компания Crytek предлагает три типа лицензий на CryEngine 2. Для получения лицензии и самого движка покупатель должен зарегистрироваться на официальном сайте, после чего ему будет послано соглашение о неразглашении, которое покупатель должен принять. Лишь после его принятия покупатель может узнать стоимость движка. Движок не продаётся частным лицам, а также для некоммерческого использования.

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

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

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

1.2.3 Unity3D

Unity- это мультиплатформенный инструмент для разработки двух- и трёхмерных приложений и игр, работающий под операционными системами Windows и OS X. Созданные с помощью Unity приложения работают под операционными системами Windows, OS X, Android, AppleiOS, Linux, а также на игровых приставках Wii, PlayStation 3 и XBox 360. Есть возможность создавать интернет-приложения с помощью специального подключаемого модуля к браузеру Unity, а также с помощью экспериментальной реализации в рамках модуля AdobeFlashPlayer. Приложения, созданные с помощью Unity, поддерживают DirectX и OpenGL.

- сценарии на C#, JavaScript (модификация) и Boo;

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

- работа с ресурсами возможна через простой Drag&Drop. Интерфейс редактора настраиваем;

- осуществлена система наследования объектов;

- поддержка импорта из очень большого количества форматов;

- встроенный генератор ландшафтов;

- встроенная поддержка сети;

- есть решение для совместной разработки -AssetServer.

Все виды лицензии и их цены указаны в таблице 1

Таблица 1 - Виды лицензий

Вид лицензии	Стоимость
UnityFree	Бесплатно
Unity Pro (Windows, OS X, Linux)	$1500.00
Возможность компиляции под AdobeFlashPlayer	$400.00
Возможность компиляции под AdobeFlashPlayer, Pro версия	$1500.00
Возможность компиляции под iOS	$400.00, Trial
Возможность компиляции под iOS, Pro версия	$1500.00, Trial
Возможность компиляции под Android	$400.00, Trial
Возможность компиляции под Android, Pro версия	$1500.00, Trial
Asset Server client (Team License)(необходималицензия Unity 3.x Pro)	$500.00
Возможность компиляции под Wii standaloneandWiiWare	Индивидуально
Возможность компиляции под MicrosoftXbox 360	Индивидуально
Возможность компиляции под PlayStation 3	Индивидуально
Возможность компиляции под другие платформы	Индивидуально
Sourcecode	Индивидуально

1.3 Вывод

Для сравнения были выделены наиболее важные характеристики, такие как:

- цена;

- поддерживаемые языки программирования;

- компиляция под мобильные платформы;

- поддерживаемые ОС.

Если выбирать движок по цене, то стоит выбрать Unity3Dили UDK. Цена этих движков приемлема и их может приобрести любой желающий, в то время как CryEngine не продается физическим лицам.

Если сравнить движки по возможности компиляции под мобильные платформы то лидером является Unity3d. Данный движоккомпилирует приложения под такие мобильные платформы, как Androidи iOS, что является преимуществом по сравнению с CryEngine, так как он не компилирует ни под одну мобильную платформу. Минус Unity3Dзаключается в том, что лицензия на компиляции под мобильные платформы стоят по 400$ за каждую.

Если сравнивать по поддержки ОС лидером так же являетсяUnity3Dтак как, сам движок может быть установлен на Windows, OSX и Linux, а CryEngine и UDKработают только с Windows.

Сравнив поддерживаемые языки программирования невозможно однозначно сказать какой движок лучше, но Unity3Dподдерживает три разных языка программирования - С#, модифицированный JavaScript, Boo.CryEngineподдерживает только 1 язык - С++, а UDKподдерживает только собственный UnrealScript.

Данные по сравнению движков приведены в таблице 2.

Проанализировав все данные, было принято решение использовать движок Unity3D.

Таблица 2 - Сравнение движков.

	Unity3d	CryEngine	UDK
Цена	Free	-	99$
Языки программирования	C#, JavaScript, Boo;	С++	Unreal Script
Компиляция под Android	+	-	-
Компиляция под iOS	+	-	+
Поддерживаемые ОС	Windows, OS X, Linux	Windows	Windows



2. Моделирование игрового симулятора

Моделирование и разработку симулятора можно разбить на 5 частей.

1. Первая часть посвящена созданию спрайтов для приложения.

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

3. В третье части будит разрабатываться физическое взаимодействие в виртуальной среде.

4. Четвертая часть будит, посвящена разработке ИИ.

5. В заключительной, пятой части, будит, проведён анализ ресурсоёмких мест в игровом симуляторе и их оптимизация.

2.1 Обзор средств создания спрайтов

В разрабатываемом приложении важную роль играют спрайты. Спрайт (англ. Sprite - фея: эльф)-визуальное представлениеобъектов в игре. Чаще всего - растровое изображение, свободно перемещающееся по экрану. Наблюдение спрайта под несоответствующим углом приводит к разрушению иллюзии. На рисунке 2.1 продемонстрировано игровое приложение под соответствующим и несоответствующим углами.

Рисунок 2.1 - Изображение игрового приложения под разными углами



2.1.1 Обзор графического редактора Adobe Photoshop

Adobe Photoshop- многофункциональный графический редактор, разработанный и распространяемый фирмой Adobe Systems. В основном работает с растровыми изображениями, однако имеет некоторые векторные инструменты. Продукт является лидером рынка в области коммерческих средств редактирования растровых изображений, и наиболее известным продуктом фирмы Adobe. Часто эту программу называют просто Photoshop. В настоящее время Photoshop доступен на платформах Mac и Windows.

Photoshop имеет отличный инструмент для создания спрайтовой анимации - это шкала времени. На ней можно разместить все созданные спрайты и посмотреть полноценную анимацию. Это позволит найти ошибки на этапе создания спрайтов.

В Photoshop для создания кадров анимации используется панель «Анимация» (PhotoshopExtended CS5) или «Шкала времени» (CS6). Каждый кадр представляет собой структуру слоев. Изображение (рис. 2.2) персонажа находится в собственном слое. Положение слоя меняется в каждом кадре анимации.

Рисунок 2.2 -Пример анимации

2.1.2 Обзор TexturePacker

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

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

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

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

2.2 Анализ оптимального комбинирования спрайтов

Каждый спрайт имеет маленький объем памяти, так как спрайты имеют размер 22х22 пикселя. И это приводит к увеличению объема занимаемой памяти на HDD, комплекса таких спрайтов. Поэтому было принято решение объединить спрайты в текстурный атлас.

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

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

- позволяет сократить количество смен состояний до одного для всего атласа;

- уменьшает количество занятых текстурных слотов до одного для всего атласа;

- минимизируется фрагментация видеопамяти;

- появляется возможность использования NPOT текстур (Т.е. атлас будет соблюдать PowerofTwo, а его элементы можно делать произвольного размера).

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

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

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

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

- создание атласов вручную может быть трудоёмко, поэтому потребуется использовать специальные программы для автоматической генерации атласов из набора текстур;

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

Пример текстурного атласа указан на рисунке 2.3.

Рисунок 2.3 -Текстурный атлас персонажа



2.3 Разработка физического взаимодействия в виртуальной среде

игровой симулятор спрайт мобильный платформа

Unity использует движок AgeiaPhysX для симуляции физики. PhysX- кроссплатформенный физический движок для симуляции ряда физических явлений, а также комплект средств разработки (SDK) на его основе.nVidia адаптировала движок для ускорения физических расчётов на своих графических чипах с архитектурой CUDA. PhysX может также производить вычисления с использованием обычного процессора. В настоящее время PhysX доступен на следующих платформах: Windows, Linux, Mac OS X, Wii, PlayStation 3, Xbox 360, но аппаратное ускорение возможно только на платформе Windows.

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

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



2.3.1 BoxCollider

BoxCollider-это базовый примитивный коллайдер в форме куба. Иллюстрация группы BoxCollider приведены на рисунке 2.4.

Рисунок 2.4 -Группа BoxColliders

Основные свойства BoxCollider описаны в таблице 3.

Таблица 3 - СвойстваBoxCollider.

Material	Ссылка на физический материал (PhysicMaterial) определяет свойства этого коллайдера при взаимодействии с другими.
IsTrigger	Если включено коллайдер будет использоваться для событий по триггерам, и будет игнорироваться физикой.
Size	Размер коллайдера.
Center	Позиция коллайдера в локальной системе координат объекта.

BoxCollider может масштабироваться, принимая форму любого параллелограмма (рис. 2.5). Его можно успешно использовать для определения столкновения двух объектов.

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



Рисунок 2.5 -СтандартныйBoxCollider

У коллайдеров-триггеров есть события OnTriggerStay и OnTriggerExit, которые вызываются всякий раз, когда что-то пересекает область триггера или единожды когда выходит за его пределы.

2.3.2 Raycast

Raycast - это луч, выпускаемый из определённой позиции, в определённом направлении. Данный луч проверяет столкновение с коллайдером и возвращает информацию о столкновении. Raycast имеет булево значение, но при столкновении, можно получить информацию, о расстоянии на котором луч столкнулся с коллайдером, а так же имя и ссылку на объект.

2.3.3Linecast

Linecast - это отрезок, проведенный между двумя объектами. Данный отрезок как и Raycast проверяет столкновение с коллайерами, но в отличии от рэйкаста, конечная точка может меняться в реальном времени.

2.3.4 Создание физического движка

Физический движок выполняет две главные задачи:

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

2. Определяет столкновения. Вторая задача - определять столкновения между игроком и другими объектами на уровне. Что бы различать разные коллайдеры между собой, каждому типу коллайдеров были присвоены теги Тег, иногда тэг, (англ. tag -- ярлык, этикетка, бирка; метить):.

Физический движок разрабатываемого приложения должен предоставлять пользователю следующие возможности: Персонаж должен двигаться по осям X,Y; возможность уничтожать землю слева или справа от персонажа, если это возможно; собирать золото, бомбы и другие игровые объекты, предназначенные для этого; получать урон;

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

При уничтожении земли так же используется Raycast. Для уничтожения нужно чтобы выполнились несколько условий:

- персонаж не должен падать, он должен стоять на земле,быть на лестнице либо находиться на верёвке;

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

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

Все эти условия проверяют лучи и при выполнении условия, воспроизводится анимации персонажа и земли, которую уничтожили.

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

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

На рисунке 2.6 показаны лучи, которые выпускает персонаж для проверки на блокировку.

Луч R1 и R2 проверяют на блок для выстрела и блок движения, R3 и R6 проверяют, есть ли земля слева или справа внизу, R4 и R5 проверяют, есть или нет земли под персонажем. Коллайдеры объектов обведены зелеными квадратами.

Окружение, как и персонаж, в зависимости от условий ведёт себя по-разному. В проекте было разработано более 40 разных взаимодействий с окружением и персонажами. Например, земля, может быть уничтожена и восстановлена, как при стрельбе персонажа, так и взорвавшейся рядом бомбы. Земля, как и бетон, могут поменять свои свойства при использовании на них персонажем ведра с липучей жидкостью. Многие объекты могут быть уничтожены без права на восстановление при помощи большой бомбы и т.д.



Рисунок 2.6 -Иллюстрация Raycast'ов

2.4 Разработка игрового искусственного интеллекта

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

1. Найти самый короткий путь от своего местоположения, до главного героя.

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

Нахождения короткого пути весь игровой мир был разбит на квадраты размерами 22х22 пикселя (размер 1 земли в приложении). В середине каждого квадрата был помещён граф, который может иметь 4 соединения с другими соседними графами, которые находятся на 1 квадрат слева, справа, сверху или снизу от данного графа. В зависимости от того где этот граф находится, ему присваивается тег и соединение с другим графом, если он удовлетворяет условия соединения (рис. 2.7). С помощью соединений между графами вычисляется самый короткий путь. Зелёной линией обозначен короткий путь к персонажу.

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

Рисунок 2.7 - Распределение графов по игровому миру.



3. Разработка игрового симулятора

3.1 Анализ ресурсоёмких мест в игровом симуляторе и их оптимизация

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

Рисунок 3.1 - Собранная статистика по приложению



3.1.1 Минимизация DrawCalls

Еще до запуска профайлера было очевидно, что слабое место - в кол-ве DrawCalls. В среднем сцена выдавала порядка 70 DrawCalls, что для устройств уровня iPad1 и ниже является фатальным. Нормой для них является- 30-40 DrawCalls. Посмотреть кол-во DrawCalls можно прямо в редакторе в окне Game->Stats. Что бы сократить количество Draw Calls необходимо:

1. Использовать атласы для комбинирования нескольких текстур в одну большую. На самом деле важнее даже, чтобы спрайты/модели использовали не то что бы одну общую текстуру, а скорее один общий материал. Именно в кол-ве различных материалов измеряется кол-во DrawCalls. Поэтому в проекте используемые изображения объединены в атласы, разбитые на категории: объекты, используемые на всех сценах, объекты GUI, задний фон и т.д.

2. Статические объекты пометить как Static. Тогда будет использоваться Static Batching, который тоже поможет сократить кол-во DrawCalls.

3. Использовать объекты с одним и тем же материалом на одном и том же расстоянии от камеры. Тогда будет использоватьсяDynamicBatchingDynamicBatching-Группирование объектов с одним и тем же материалом в один DrawCall..

4. Исключить ситуации, когда объекты с разными материалами перекрывают друг друга.

5. Исключить использование многопроходных (multi-pass) шейдеров.

6. Минимизировать количество систем частиц. Каждая система частиц дает 1 DrawCall. Поэтому если на экране одновременно N систем частиц - это автоматически как минимум N DrawCalls. Обычно, одного и того же эффекта можно достигнуть разными способами, в том числе меньшим числом как систем частиц, так и частиц в системе.



3.1.2 Скачки производительности

Второй фактор, влияющий на производительность - так называемые скачки производительности. Переодически в игре были «зависания» на 0,5-1 секунду, что, конечно же, было неприемлемо и напрямую влияло на геймплей. Причем такое наблюдалось даже на самых последних устройствах (рис 3.2). И в этом случае помог профайлер. Чтобы исключить «зависания» в приложении необходимо:

1. Отказаться от использования функции Instantiate(),особенно для сложных объектов. Скачки производительности приходились в основном на вызовы Instantiate(), которые создавали новые объекты из префабовПрефаб -- это собрание заранее подготовленных объектов и компонентов для их многократного использования в игре., или клонировали существующие. Причем некоторые объекты были очень громоздкими, что и повлияло на время их создания. Вместо этого было решено переписать систему так, чтобы объекты использовались заново. Т.е. состояние объекта после окончания использования (или перед использованием) приводилось к начальному. Это также помогло сократить объем используемой памяти (так как на новые объекты больше не нужно было новой памяти) и количество вызовов Destroy().

Рисунок 3.2 - Наглядный пример скачка производительности в профайлере



2. Минимизировать количество вызовов Destroy(). Destroy (особенно для больших объектов) почти всегда приводит к манипуляциям с памятью. А это обычно плохо сказывается на производительности. Это правило напрямую связано с правилом выше, ибо вызовы Instantiate()/Destroy()обычно связаны. Таким образом, использование объектов заново лишило необходимости уничтожать их.

3. Минимизировать вызовы gameObject.SetActiveRecursively(). Для сложных объектов вызов может быть очень долгим, потому что он предполагает не просто активацию объектов и их компонентов, но в некоторых случаях и загрузку необходимых ресурсов.

4. Минимизировать вызовы Object.Find(). Время этой операции зависит от кол-ва объектов на сцене. Сюда же относятся функции типа GetComponent().

5. Минимизировать вызовы Resources.UnloadUnusedAssets() и GC.Collect().Unity иногда сама прибегает к ним, если недостаточно памяти для загрузки нового ресурса или пришел запрос от ОС освободить неиспользуемую память. Таким образом, первые 2 правила автоматически сокращают кол-во таких вызовов. Лучшее место для вызова Resources.UnloadUnusedAssets вручную -перед загрузкой сцены или непосредственно сразу после ее запуска. Это также помогаетосвободить дополнительную память для сцены, что иногда бывает критично.

3.1.3 Оптимизация скриптов

Некоторые скрипты выполнялись всё время, что приводило кпотери производительности. Некоторые из них необходимо переписаны так, чтобы выполнялись только тогда, когда от них это требуется. Остальные нужно оптимизировать следующим образом:

1. Не использовать GetComponent<T>() в Update, FixedUpdate и других подобных функциях. Вместо этого лучше кэшировать компонент в Awake() или Start(). При кешировании, поиск нужного компонента выполняется 1 раз, при этом в кэш сохраняется ссылка на данный компонент, если объектов, использующих скрипт, очень много, такое кэширование может значительно сократить время работы скрипта. Иначе при каждом обращении через GetComponent<T>(), поиск компонента начинается заново, что плохо сказывается на производительности.

2. Кэшировать встроенные компоненты типа transform, renderer и т.д. Особенно если они используются в функциях типа Update().Ибо каждый такой вызов делается через GetComponent().

3. Использовать Vector2(3,4).sqrMagnitudeвместо magnitude.

4. Использовать Color32 и Mesh.colors32 вместо Color и Mesh.colors при доступе к цветам меша.

5. Использовать OnBecameVisible/OnBecameInvisible для скриптов, которые могут быть отключены, когда камера больше не видит объект.

6. Использовать встроенные массивы. Они намного быстрее всех остальных коллекций.

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

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

3.1.4 Оптимизация расчётов физики

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

1. Деактивировать неиспользуемые RigidbodyЧем меньше одновременно активных Rigidbody, тем лучше.

2. Отключить вычисления физики между коллайдерами, которые не должны рассчитывать столкновения, сняв галочку в матрице коллайдеров. Иллюстрация приведена на рисунке 3.3.

3. Сократить количество FixedUpdate в единицу времени. FixedTime рвное0.03333 гарантирует физику со скоростью 30 вычислений в секунду, что обычно очень неплохо. Даже 20 может быть приемлемым, что соответствует FixedTime равное0.05 (рис. 3.4)

4. Минимизировать использование Continuous или Dynamiccollisiondetection. Они очень ресурсозатратны. Для 2d-приложений они обычно не нужны.

Рисунок 3.3 - Матрица коллайдеров



Рисунок 3.4 -TimeManager

3.1.5 Оптимизация анимации

Анимация так же способствует потери производительности, особенно если анимированных объектов на сцене очень много. Для оптимизации анимации необходимо:

1. Следить за количеством анимированных объектов на экране. Чем меньше - тем лучше.

2. Вместо нескольких простых анимаций на сложном объекте, сделать одну сложную, делающую то же самое.

3. Уменьшить SampleRate у клипа, если анимаций очень много.

4. Использовать Culling Type равноеBased On Renderers или Based On User Bounds. Тогда анимация будет проигрываться только тогда, когда объект виден на экране.

3.1.6 Оптимизация системы частиц

Каждая система частиц дает 1 DrawCall. Поэтому если на экране одновременно N систем частиц - это автоматически как минимум N DrawCalls. Поэтому для повышения производительности, при использовании систем частиц, необходимо:

1. Использовать Vertical Billboard вместо Billboardв Particle Renderer.

2. На мобильных устройства использовать шейдеры из Mobile->Particles. Это касается не только системы частиц.

3. Использовать как можно меньше систем частиц и самих частиц в системе для достижения нужного эффекта.

4. Для слабых систем отключить некоторые малозаметные или несущественные системы частиц. Что позволит сохранить несколько DrawCalls и поднять на них производительность в ущерб эффектности.

3.1.7 Оптимизация звуковых эффектов

Использование компрессии на звуках позволит не только сократить размер приложения, но и объем используемой им памяти, для улучшения производительности так же необходимо

1. Использовать AudioFormatравнымNative для очень коротких и маленьких по размеру звуков (меньше100 Kb).Для остальных использовать компрессия.

2. ИспользоватьLoadType равным Compressedin Memory для большинства ужатых звуков. Это позволит уменьшить объем используемой памяти, но может влиять на производительность, так как требует распаковки во время воспроизведения.

3. Для фоновой музыки использоватьLoadType равнымStreamfromdisk, особенно на системах с быстрым HDD. Это позволит сохранить очень много памяти.

4. Использовать DecompressonLoad во всех остальных случаях. Звук будет занимать больше памяти, но практически не будет «сажать» CPU, что поможет иногда избавиться от скачков производительности.

5. ИспользоватьHardwareDecoding для фоновой музыки. Встроенный декодер в устройствах iOS позволяет сократить использование CPU на проигрывании фоновой музыки, но это может быть сделано только для одного трека одновременно.

6. Используйте ForcetoMono, если стерео не нужно. Или если в файле оно присутствует, но не различимо. Это в 2 раза уменьшит объем используемого места (как в памяти, так и на диске).



3.1.8 Другие оптимизации

Были исключены вызовы OnGUI() так как каждый такой вызов - несколько дополнительных DrawCalls. Тоже самое относится к GUILayout. И вообще, реализация GUI в Unity имеет много недостатков. Для проекта разработана своя система GUI, основанная на спрайтах.

Размер текстуры, генерируемой для шрифта, можно уменьшить, добавив только используемые символы. В FontSettings установить Character равное CustomSet, а в CustomChars включить используемые символы (рис. 4.5).

Рисунок 4.5 -Выключение не используемых символов

Отключить акселерометр, если он не используется.

Ограничить максимальный FPS на старых устройствах. Например, установив его в: Application.targetFrameRateравным30. Обычно это приводит к плавной анимации.

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

Использовать правильный формат текстур. Это также позволит уменьшить объем используемой текстурной памяти, а соответственно и повысить производительность.

Иногда достаточно использовать текстуры с глубиной цвета 16 bit, особенно если вся графика нарисована всего в нескольких цветах. Сравнение на рисунке 3.6.

Рисунок 3.6 - Сравнение двух текстур разного качества

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

Размещено на Allbest.ru

...