Участие в разработке компонентов игрового программного продукта

 

Федеральное государственное образовательное учреждение высшего профессионального образования

Мурманский государственный технический университет

Политехнический факультет

ОТЧЕТ

по производственно-технологической практике

Место прохождения практики: ООО «Игровые системы»

Тема: Участие в разработке компонентов игрового программного продукта

студентки Дмитриевой Нино Самсоновны

Руководитель практики Лазарева И.М.

МУРМАНСК 2012

Содержание

1. Ознакомительная часть

.1 Сведения о предприятии ООО «Игровые системы»

.2 Описание общих технических характеристик аппаратных комплексов

.3 Обзор используемого системного и прикладного программного обеспечения

.4 Функциональная модель

.5 Информационная модель

.6 Описание существующей компьютерной сети

.7 Описание использования сети Internet

. Практическая часть

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

.2 Описание программного решения

.3 Описание тестов и оценка качества программного продукта

Заключение

Список используемой литературы

1. Ознакомительная часть

.1 Сведения о предприятии ООО «Игровые системы»

Компания ООО «Игровые системы» была организована в начале 2010 года. Генеральный директор - Гуркин Дмитрий Викторович. Основным направлением деятельности является профессиональная разработка игр для самого динамично развивающегося рынка мобильных устройств - смартфонов и планшетов на базе iOS Apple, WindowsPhone и Android. В цикл работы входят все стадии разработки игры, начиная с создания ее концепции, сценария, отрисовки графического контента, программирования, тестирования и заканчивая поддержкой пользователей после выпуска приложения.

1.2 Описание общих технических характеристик аппаратных комплексов

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

iOS разработка

1.Mac mini

a.Процессор 2.4 ГГц Intel Core 2 Duo

b.Графика NVIDIA GeForce MX

c.Память 2-4 ГБ DDR3.

2.Все модели из линейки Apple iPad

.Все модели из линейки Apple iPod

Android разработка

1.Windows-совместимое оборудование

a.Процессор Intel Core iX

b.Графика NVIDIA GeForce GT X

c.Память 2-4 ГБ DDR3.

2.Множество устройств на платформе Android

WindowsPhone разработка

1.Windows-совместимое оборудование

a.Процессор Intel Core iX

b.Графика NVIDIA GeForce GT X

c.Память 2-4 ГБ DDR3.

2.Устройства на платформе WindowsPhone

.3 Обзор используемого системного и прикладного программного обеспечения

iOS разработка

1.Операционная система: Mac OS X

.Среда разработки: Xcode

.Программные пакеты: iPhone SDK

.Офисные пакеты: Libre Office, Neo Office

Android разработка

1.Операционная система: Windows XP, 7

.Программные пакеты: NDK, Android SDK

.Среда разработки: Eclipse, IDEA

.Офисные пакеты: Open Office, Microsoft Office

WindowsPhone разработка

1.Операционная система: Windows XP, 7

.Программные пакеты: WinPhone SDK, Silverlight

.Среда разработки: Microsoft VisualStudio

.Офисные пакеты: Open Office, Microsoft Office

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

1.4 Функциональная модель

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

Рис. 1. Функциональная модель предприятия

Рис. 2. Функциональная модель подразделения разработки

1.5 Информационная модель

Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации. Используем стандарт DFD для построения информационной модели предприятия в нотации Гейна-Сарсона:

Таблица 1. Нотация Гейна-Сарсона

НаименованиеНотация Гейна-СарсонаПоток данных ИмяПроцесс Номер ИмяВнешняя сущность Имя

Рис. 3. Информационная модель предприятия

1.6 Описание существующей компьютерной сети

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

1.7 Описание использования сети Internet

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

2. Практическая часть

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

Для качественной реализации задачи был проведен анализ экономической составляющей игры, или игрового баланса. В качестве программного продукта выступает так называемый «сити-билдер», то есть приложение, основной игровой процесс которого заключается в построении различных зданий и объектов на карте и затем взаимодействие с ними. Например, некоторые здания каждый интервал времени производят такой ресурс как деньги и население, а также пользователь может заключить контракт со зданием на производство различных продуктов. Каждое здание выполняет данное ему задание за определенное время, по истечении которого над ним появляется метка, указывающая на возможность собрать готовый продукт. Требуется реализовать механизм одновременного сбора сразу нескольких ресурсов. Иллюстрация к трем типам ресурсов, изготовляемых зданиями:

Рис. 4. Три типа ресурсов, производимых в игре

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

.Тип ресурса «Продукт»

Таблица 2. Тип ресурса - продукт

ХарактеристикаКаждое здание производит продукт определенного типа в количестве одной штуки. После сбора продукта он кладется на склад, откуда может быть продан. В зависимости от уровня продукта цена продажи различается.ОграничениеОграничением является количество ресурсов на складе. Допустим, вместимость склада M. На момент сбора продуктов на складе уже лежит N элементов. Тогда можно собрать всего M-N шт. Пример сообщения о переполнении склада: Решение проблем с превышением ограниченияЕсли количество готового к сбору продукта превышает M-N, то на склад кладутся элементы с наибольшей ценой продажи.Дополнительные ресурсыПри сборе очередного продукта добавляется такой пользовательский атрибут как Опыт.

Рис. 5. Окно склада

Тип ресурса «Население»

ХарактеристикаКаждое здание производит определенное количество населения в зависимости от типа и уровня. При сборе данный элемент добавляется к такому атрибуту игрока, как Население. Атрибут иллюстрируется баром: ОграничениеОграничением является максимально возможное количество населения на данном уровне. Допустим, максимум равен M. На момент сбора населения его сумма уже равна N. Тогда можно собрать всего M-N.Решение проблем с превышением ограниченияЕсли количество готового к сбору населения превышает M-N, то берется только возможное число. Причем, возможна такая ситуация: со здания можно собрать P населения, но до максимума всего P-2, тогда со здания снимается P-2 населения, а 2 остается висеть в метке до следующего сбора.

.Тип ресурса «Деньги»

Таблица 4. Тип ресурса - деньги

ХарактеристикаКаждое здание производит определенное количество денег в зависимости от типа и уровня. При сборе данный элемент добавляется к такому атрибуту игрока, как Валюта.ОграничениеНеограниченное количество.

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

Таблица 5. Основные составляющие окна

Элемент окнаХарактеристикаДекоративный заголовок с информацией для игрокаПредставляет собой заголовок с названием окна, картинку с персонажем игры и сообщение о возможностях использования окна.Кнопка для сбораНа кнопке написана текущая стоимость производимого действия, при клике запускает процесс сбора всех возможных продуктов.Фон окнаОтрисовка фона окна состоит из 3 частей: отрисовка верхних, нижних углов, центра.Таблица ресурсовОтображает все собираемые ресурсы с прокруткой. В таблице каждый ресурс представлен изображением с подписью о собираемом количестве. Причем ресурсы одного типа должны показываться одним элементом с суммированным показателем их количества. Например, пусть собирается M денег, N продукта одного типа с первого здания и P продукта такого же типа, но с другого здания. Тогда в таблице должно присутствовать всего два элемента: изображение денег с подписью M и изображение продукта с подписью K, где К = N+P.

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

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

2.2 Описание программного решения

В процессе создания программного компонента требуется реализовать визуальный интерфейс и алгоритм работы разрабатываемого модуля. Средой разработки является Xcode, платформа iOS, используемое API Cocoa. Кроме того, для организации анимаций и части интерфейса в игровой проект внедрен движок Cocos2d-iphone.

Окно запускается из панели на главном экране. На данной панели при выполнении определенных условий появляется картинка, при клике на которую пользователь запустит открытие окна. В качестве условий берется некое количество готовых элементов каждого типа, например: должно быть готово к сбору n ресурсов-денег, m ресурсов типа продукт, p ресурсов населения. При подсчете каждого из них следует учитывать ограничения по населению и складу. Таким образом, первой задачей является поиск возможности контролировать количество готовых продуктов и отслеживать его изменение. Платформа разработки позволяет сделать это двумя способами. Первый способ: посекундный пересчет готовых ресурсов в режиме запущенной игры. Второй способ: использование такого компонента Objective-C как NSNotificationCenter, механизма передачи уведомлений. Регистрация и получение уведомления будет происходить в классе MainPanel.m, а отправляться они будут в нескольких классах, в которых происходит изменение текущего состояния готовности продукта. Каждый раз, когда уведомление отлавливается, происходит проверка условий для появления кнопки запуска окна в панели. Например, выполнился контракт на получение населения, отправилось уведомление, оно было поймано, и тут же происходит пересчет всех готовых ресурсов для проверки удовлетворения условиям.

Уведомления будет принимать класс MainPanel.m. Для этого зарегистрируем его в центре уведомлений в момент, когда инициализируется класс:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onShowCollectAllButton:) name:NOTIFY_DROP_ITEM_DROPPED object:nil]; bserver - это объект, который будет принимать уведомление. В данном случае текущий класс MainPanel.m.- это метод, который будет вызван в момент приема уведомления. В данном случае метод, который запускает проверку условий для появления окна. - имя уведомления. - это объект, который отправил уведомление (на тот случай, если нужно получать это уведомление от конкретных объектов).

Отправляться уведомления будут в нескольких классах: [[NSNotificationCenter defaultCenter] postNotification name:NOTIFY_DROP_ITEM_DROPPED object:nil];

После получения уведомления требуется проверить три ресурса: деньги, продукты и население:

.Деньги: на деньги не накладываются никакие ограничения, поэтому последовательно просматривая все здания на карте, которые их производят, считаем здания с готовым ресурсом. Далее полученное число сравнивается с заданным условием.

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

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

Если все три компонента выполняют условие, на панели появляется кнопка запуска окна. Кнопка пульсирует, привлекая внимание игрока. Анимация реализована с использование игрового движка Cocos2d-iphone.

Появление кнопки в правом нижнем углу отображено на рисунке 6:

Рис. 6. Отображение кнопки запуска окна

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

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

При отрисовке компонентов с использованием такого элемента среды разработки Xcode как FormBuilder, сложные графические объекты базируются на специальном виде xml файла - plist. В нем хранится информация о том, как и где расположены составляющие компонента. Для текстовых частей можно указать цвет и размер, кнопке может ставиться в соответствие ссылка на функцию, изображение может масштабироваться. Класс RewardNode будет использовать plist для организации ячейки таблицы.

После создания ячейки нужно организовать работу таблицы. Таблица создается на основе такого механизма как CCScrollView, поэтому чтобы получить доступ к некоторым методам этого класса, нужно наследовать основной класс CollectAll.m от скролла. CCScrollView класс принадлежит игровому движку cocos2d-iphone, который используется в приложении. Так как функционал данного механизма все еще находится в разработке и он является лишь контейнером для ячеек, для его правильной работы следует:

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

- (void)actionScrollLeft:(id)sender

{* rewardContainerScroll = (CCScrollView*)[_buildernodeWithName:@"rewardContainerScroll"];cellWidth = rewardContainerScroll.pageSize.width;

CGPoint pt = rewardContainerScroll.contentOffset;.x += cellWidth;.x = roundf(pt.x / (float)cellWidth);(pt.x > 0)

{.x = 0;

}.x *= cellWidth;

[rewardContainerScroll setContentOffset:pt animated:YES];

}

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

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

.Отцентровать положение ячеек в контейнере, если их количество меньше, чем вмещается на все поле прокрутки

В результате получаем контейнер CCScrollView с ячейками, изображенный на рисунке 7:

Рис. 7. Таблица с прокруткой

А также окно:

Рис. 8. Окно модуля «Собрать все»

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

.Деньги: происходит добавление полученного количества к атрибуту money из класса GameStat.m, а также метка над зданием изменяется с изображения готового ресурса на картинку с изготавливающимся продуктом.

.Продукты: все собранные продукты кладутся на склад, причем одинаковые ресурсы складываются группами по 20 штук, метка над зданием меняется на метку свободного здания. Кроме того, запускается анимация машинки, которая отвозит ресурс на склад. Над машинкой указывается, какой ресурс она везет и его количество.

.Население: происходит добавление полученного количества к атрибуту population. Метка над зданием меняется на метку изготовления. Кроме того, учитывается такой вариант сбора, когда с определенного здания собирается лишь часть населения, поэтому в метке над зданием остается висеть еще n населения.

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

Классы, используемые в работе компонента:

Класс, контролирующий появление кнопки на игровой панели и ее анимацию.

MainPanel- onShowCollectAllButton- actionCollectAll- pulseButton

Game- collectAllWith:- canCollectAllWith:- canCollectBuilding:- collectBuilding:

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

Реализация некоторых методов класса Game:

- (BOOL)canCollectBuilding:(Building *)building alert:(BOOL)alert

{

NSString *type = building.typeName;

int value = [building inCountToCollect];([type isEqualToString:@"house"])

{

value -= building.dropedValue;

int population = [_gameStat valueForAttribute:ATTR_POPULATION];

int dropedPopulation = [self.map.dropItemManager totalValueOfItemsWithType:DROP_ITEM_ATTRIBUTE name:@"population"];

int happiness = [_gameStat valueForAttribute:ATTR_HAPPINESS];

int v = (population + value + dropedPopulation) - happiness;(((v > 0) && (v == value)) || (value - v) < 0 || ![_gameStat canAddValue:(value - abs(v)) forAttribute:ATTR_POPULATION])

{

if (alert)

{

[Game showNotEnoughHapinessAlertForBuilding:building];

}

return NO;

}

}

else if ([type isEqualToString:@"entertainment"])

{

if (![_gameStat canAddValue:value forAttribute:ATTR_MONEY1])

{

if (alert)

{

[Game showCantCompleteAlert];

}

return NO;

}

}YES;

}

(void)collectBuilding:(Building*)building

{

NSString *type = building.typeName;*attribute = nil;([type isEqualToString:BUILDING_TYPE_HOUSE])

{

attribute = ATTR_POPULATION;

[[Counters instance] updateWithType:TYPE_COLLECT_TIMES subType:@"population" addValue:1];

}

else

{

attribute = ATTR_MONEY1;

[[Counters instance] updateWithType:TYPE_COLLECT_TIMES subType:@"money1" addValue:1];

}(attribute != nil)

{

NSMutableArray *dropItems = [NSMutableArray arrayWithCapacity:3];value = [building inCountToCollect];

if ([[building typeName] isEqualToString:BUILDING_TYPE_HOUSE])

{

value -= building.dropedValue;

int population = [_gameStat valueForAttribute:ATTR_POPULATION];

int happiness = [_gameStat valueForAttribute:ATTR_HAPPINESS];

int dropedPopulation = [self.map.dropItemManager totalValueOfItemsWithType:DROP_ITEM_ATTRIBUTE name:@"population"];

int v = - happiness + (population + value + dropedPopulation);(v > 0)

{

value -= v;

building.dropedValue += value;

}

else

building.dropedValue = 0;

}([_gameStat canAddValue:value forAttribute:attribute])

{

DropItem *item = [[[DropItem alloc] initWithMap:building.map attribute:attribute count:value] autorelease];

[dropItems addObject:item];

}exp = [building valueForParam:@"in_exp"];

if (exp != 0)

{

DropItem *xpItem = [[[DropItem alloc] initWithMap:building.map attribute:ATTR_EXP count:exp] autorelease];

[dropItems addObject:xpItem];*bonus = [Bonus bonusByName:@"bonus_collect"];

[dropItems addObjectsFromArray:[bonus apply]];([Game game].collectAllMode) // do not show drop when CollectAll

[building.map.dropItemManager applyInvisibleDrops:dropItems];

[building.map.dropItemManager dropItems:dropItems atObject:building];

}

[building afterCollect];

[[Counters instance] addValue:1 forCounter:@"count_collect_times"];

}

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

DropItemManager- dropItems:- collectItem:- applyInvisibleDrop:Синглтон-класс, отвечающий за получение данных о текущем состоянии какого-либо атрибута и его изменение.

GameStat- setValue:- canAddValue:- valueForAttribute:

RewardNode- buildContentWithTouchPriority:- setIconWithName:- setLabelText:

Класс, отвечающий за создание ячейки в таблице.

CollectAllВыполняемое действие- buildProfitNodeОрганизация окна, таблицы. Запуск алгоритма сбора.- countItemsForProfit- onCollectAll- xpForContract:Подсчет выходных атрибутов при сборе: опыт, население, продукты. Суммирование элементов для отрисовки в ячейке таблицы.- xpForAllContracts:- peopleForHouse:- peopleForAllHouses:- sumContractsFor:- actionScrollLeft:Работа с прокруткой.- actionScrollRight:- updateButtons- compareContractsCost:Сортировка ресурсов по цене.+ resultPopulationBuildingsПроверка условий для появления кнопки запуска окна.+ resultFactoryBuildings+ canCollectHouse:Проверка возможности сбора.

Реализация некоторых методов класса CollectAll:

NSInteger compareContractsCost(Building* building1, Building* building2, void *context){*contract1 = ((FactoryBuilding*)building1).contractInProgress;

Contract *contract2 = ((FactoryBuilding*)building2).contractInProgress;*res1 = [Resource resourceByCode:[contract1 outResource]];

Resource *res2 = [Resource resourceByCode:[contract2 outResource]];(res1.sellMoney1 != res2.sellMoney1)

{

return -(res1.sellMoney1 - res2.sellMoney1);

}

return 0;

}

(int)xpForContract:(FactoryBuilding*)factoryBuilding

{

Contract *contract = factoryBuilding.contractInProgress;

return contract.outXP;

}

(int)xpForAllContracts:(NSArray*)buildingsWithContracts

{

int allXp = 0;(int i = 0; i < buildingsWithContracts.count; i++)

{

allXp += [self xpForContract:(FactoryBuilding*)[buildingsWithContracts objectAtIndex:i]];

}allXp;

}

+ (NSArray*)resultFactoryBuildings

{

NSMutableArray *result = [NSMutableArray array];

NSMutableArray *buildingsWithReadyContract = [NSMutableArray array];

int freeWarehouseSpace = [[Game game].resourcesManager freeSpace];*map = [Game game].map;

for (Building *building in [map allBuildings]) {*type = building.typeName;([type isEqualToString:@"factory"])([(FactoryBuilding*)building canCollectContract])

{

[buildingsWithReadyContract addObject:building];

}(buildingsWithReadyContract.count > freeWarehouseSpace) // if there is no so much space in warehouse

{

[buildingsWithReadyContract sortUsingFunction:compareContractsCost context:nil];(int i = 0; i < freeWarehouseSpace; i++)

{

[result addObject:[buildingsWithReadyContract objectAtIndex:i]];

}

}

else

{

[result addObjectsFromArray:buildingsWithReadyContract];

}result; // buildings, which contracts can be added to warehouse

}

2.3 Описание тестов и оценка качества программного продукта

программный игровой компьютерный визуальный

Игровой продукт написан для планшетов Apple iPad, поэтому тестирование проводилось на всех устройствах этой линейки, так как каждый из них использует различную версию платформы iOS.

Требуется проверить несколько аспектов работы компонента:

.Производительность приложения во время работы компонента: основным показателем является такая характеристика как кадровая частота, или FPS(Frame Per Second) планшета. Под кадровой частотой понимается частота, генерируемая самой игрой в зависимости от ресурсов устройства и необходимости передачи движений разной интенсивности. Так как сбор сразу нескольких ресурсов запускает много анимаций, кадровая частота может уменьшаться. Во время тестирования FPS не опускался ниже среднего показателя 25, что является неплохим показателем.

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

Заключение

По итогам прохождения производственно-технологической практики я ознакомилась с платформой iOS, API Cocoa, языком программирования Objective-C и его парадигмами, а также с игровым движком Cocos2d-iphone. Кроме того, был проведен анализ экономической составляющей игры, совместная работа с отделом тестирования позволила выявить слабые места и ошибки приложения, и в итоге разработан компонент программного продукта, удовлетворяющий заявленным требованиям:

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

.Механизм сбора функционирует корректно

.Производительность игры остается на высоком уровне

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

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

.Реализация возможности выбора, какие ресурсы собирать, а какие оставить в готовом состоянии

.Логгирование на сервер изменения денежного атрибута

.Оптимизация анимации с целью ее добавления без потери производительности

.Оптимизация кода для уменьшения используемого объема памяти

Список используемой литературы

1.Хиллегаас, А. Objective-C. Программирование для iOs и MacOs. - М: Питер, 2010. - 304 с.

.Кочан, С. Изучаем iOS программирование. - М: Орейли, 2012. - 428 с.

.Иттерхейм, С. Изучаем создание игр с использованием Cocos2d. - М: Апресс, 2011 - 218 с.

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

Больше работ по теме: