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

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

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

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

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

ОТЧЕТ

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

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

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

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

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

МУРМАНСК 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. Тип ресурса - продукт

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

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

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

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

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

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

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

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

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];

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

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