Аналіз розробки комп’ютерної гри незалежним розробником

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

6

Міністерство освіти і науки України

Запорізький національний технічний університет

Кафедра системного аналізу та обчислювальної математики

Курсовий проект

Аналіз розробки комп'ютерної гри незалежним розробником

Виконав

ст. гр. КНТ-812 Спасський А.М.

Перевірив

Бахрушин В.Є.

Запоріжжя

2015



Реферат

ПЗ: 23 с., 10 дж., 10 рис., 1 табл.

Об'єкт дослідження - розробка комп'ютерної гри незалежним розробником.

Мета роботи - проаналізувати процес розробки комп'ютерної гри.

Метод дослідження - процес аналізу проблеми було проведено шляхом складання та визначення проблеми. Для детального аналізу було розроблено дерево цілей, що показує цілі, які потрібно реалізувати для досягнення мети.

На етапі оцінки альтернатив, за заданими критеріями, було обрано засоби за якими буде досягатися мета.

Результатом роботи є детальний опис (аналіз) усіх необхідних етапів розробки. Саме ці етапи дозволяють досягнути поставленої мети і заздалегідь попередити можливі ризики перед тим, як приступати до процесу.

Ключові слова: комп'ютерна гра, розробка, незалежний розробник, аналіз, ризик, модель, альтернатива, дерево, критерій



Завдання на курсовий проект

Студенту Спасському Андрію Максимовичу

1. Тема проекту (роботи): Процес розробки комп'ютерної гри незалежним розробником.

2. Термін здачі студентом закінченого проекту (роботи):

3. Вхідні дані до проекту:_________________________________

4. ЗМІСТ розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):

1 Теоретична частина

2 Дерево цілей

3 Дерево критеріїв

4 Постановка альтернатив

5 Вибір альтернатив

Висновок

5 Дата видачі завдання:



Зміст

Вступ

1. Теоретична частина

1.1 Методології розробки

2. Практична частина

2.1 Дерево цілей

2.2 Дерево критеріїв

2.3 Аналіз вимог і ризиків

2.3.1 Концепція

2.3.2 Вибір цільової аудиторії

2.3.3 Порівняння з існуючими іграми

2.3.4 Вибір платформи

2.3.5 Вимоги до ігри

2.3.6 Ризики

2.4 Розробка

2.4.1 Модель ігри

2.4.2 Створення технічного проекту

2.4.3 Розробка програмного коду

2.4.4 Тестування

2.5 Підтримка

2.5.1 Модернізація

2.5.2 Збір статистики

2.6 Оцінка альтернатив

Висновок

Використана література



Вступ

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

Для досягнення мети потрібно побудувати дерево цілей і детально проаналізувати кожний його етап.

Передбачуваним результатом повинна бути гра, що буде розроблена в зазначений термін. Вона повинна буде відповідати поставленій меті.

Аналіз даної проблеми може бути корисним людям, які хочуть випробувати себе в якості розробника комп'ютерних ігор.

В даній роботі описані основні етапи розробки. Вони включають в себе детально описані теоретичну і практичну частини. Це дозволяє детально ознайомитися з кожним етапом розробки і може бути корисним тоді, коли розробнику недостатньо якихось навичок.

1. Теоретична частина

1.1 Методології розробки

Розробка програмного продукту має багато гідних методологій. Вибір залежить від специфіки проекту, обмеження коштів, суб'єктивних переваг і навіть темпераменту розробника. В роботі описані методології, які можуть бути застосовані в процесі розробки [4].

"Waterfall Model" (Каскадна модель або "Водоспад")

У моделі Waterfall легко керувати проектом. Завдяки її жорсткості, розробка проходить швидко, вартість і термін визначаються заздалегідь. Але це "палиця з двома кінцями". Каскадна модель буде давати відмінний результат тільки в проектах з чіткими вимогами і способами їх реалізації. В ній немає можливості зробити крок назад, до тестування можна приступати тільки після того, як закінчена розробка.

Рис. 1 - Модель водопад

Якщо розробляти продукт за цією методологією без достатньо обґрунтованого її вибору, то він може мати недоліки, про які стає відомо лише наприкінці послідовності вже виконаних дій. Вартість внесення змін висока, оскільки для її ініціалізації доводиться чекати завершення всього проекту. Однак, фіксована вартість часто переважує мінуси підходу. І може бути так, що розробник усвідомлений у можливих ризиках і виправлення їх в процесі розробки варте досягненої мети.

Ця модель використовується у наступних випадках:

· Коли вимоги відомі, зрозумілі і зафіксовані. Суперечливих вимог немає.

· У відносно невеликих проектах.

"V-Model"

Успадкувала структуру "Крок за кроком" від каскадної моделі. V-подібна модель застосовна до систем, яким особливо важливо безперебійне функціонування. Наприклад, прикладні програми в клініках для спостереження за пацієнтами. Особливістю моделі є те, що вона спрямована на ретельну перевірку та тестування продукту, що знаходиться вже на початкових стадіях проектування. Стадія тестування проводиться одночасно з відповідною стадією розробки, наприклад, під час кодування пишуться модульні тести.

Рис. 2 - V-Model

Проект виконується за чітким ТЗ до якого включений етап тестування інтерфейсу, функціоналу, навантаження і інтеграції.

Ця модель використовується у наступних випадках:

· Якщо потрібне ретельне тестування продукту, то V-модель виправдає закладену в себе ідею: validation and verification.

· Для малих і середніх проектів, де вимоги чітко визначені і фіксовані.

"Incremental Model" (Інкрементна модель)

У інкрементної моделі повні вимоги до системи поділяються на різні збірки. Термінологія часто використовується для опису поетапної збірки ПЗ.

Модель має кілька циклів розробки, які складають життєвий цикл "Мульти-водоспад". Цикл розділений на більш дрібні легко створювані модулі. Кожен модуль проходить через фази визначення вимог проектування, кодування, впровадження та тестування. Процедура розробки за інкрементною моделлю передбачає на першому великому етапі випуск продукту в базовій функціональності, а потім вже послідовне додавання нових функцій, так званих "інкрементів". Процес продовжується до тих пір, поки не буде створена повна система.

Рис. 3 - Інкрементна модель

Інкрементні моделі використовуються там, де окремі запити на зміну ясні і можуть бути легко формалізовані і реалізовані.

Ця модель використовується у наступних випадках:

· Коли основні вимоги до системи чітко визначені і зрозумілі. У той же час деякі деталі можуть доопрацьовуватися з часом.

· Потрібно ранній висновок продукту на ринок.

· Є кілька ризикових особливостей або цілей.

"RAD Model" (Швидка розробка)

RAD-модель - різновид інкрементної моделі. У RAD-моделі компоненти і функції розробляються кількома командами паралельно, ніби кілька міні-проектів. Тимчасові рамки одного циклу жорстко обмежені. Створені модулі потім інтегруються в один робочий прототип. Синергія дозволяє дуже швидко надати замовнику для огляду щось робоче з метою отримання зворотного зв'язку і внесення змін.

Рис. 4 - RAD-модель

RAD-модель включає наступні фази:

· Бізнес-моделювання: визначення списку інформаційних потоків між різними підрозділами.

· Моделювання даних: інформація, зібрана на попередньому етапі, використовується для визначення об'єктів та інших сутностей, необхідних для циркуляції інформації.

· Моделювання процесу: інформаційні потоки пов'язують об'єкти для досягнення цілей розробки.

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

· Тестування: тестуються нові компоненти і інтерфейси.

Коли використовується RAD-модель?

"Agile Model" (Гнучка методологія розробки)



Рис. 5 - Гнучка методологія розробки

У "Гнучкій" методології розробки після кожної ітерації замовник може спостерігати результат і розуміти, задовольняє він його чи ні. Це одна з переваг гнучкої моделі. До її недоліків відносять те, що через відсутність конкретних формулювань результатів складно оцінити трудовитрати і вартість, необхідні на розробку.

Методологія підходить для великих або націлених на тривалий життєвий цикл проектів, що постійно адаптуються до умов ринку. Відповідно, в процесі реалізації вимоги змінюються.

Методологія використовується:

· Коли потреби користувачів постійно змінюються.

· Зміни на Agile реалізуються за меншу ціну через часті інкрементів.

· Коли для старту проекту досить лише невеликого планування.

"Iterative Model" (Ітеративна модель)

Ітеративна модель життєвого циклу не вимагає для початку повного визначення вимог. Замість цього, створення починається з реалізації частини функціоналу, що стає базою для визначення подальших вимог. Цей процес повторюється. Версія може бути неідеальна, головне, щоб вона працювала. Усвідомлюючи кінцеву мету, кожен розроблюваний крок має бути максимально результативним, а кожна версія - працездатна.

На діаграмі показана ітеративна розробка Мони Лізи. Як видно, у першій ітерації є лише начерк Джоконди, у другій - з'являються кольори, а третя ітерація додає деталей, насиченості і завершує процес. У інкрементній моделі функціонал продукту нарощується по шматочках, продукт складається з частин. На відміну від ітераційної моделі, кожен шматочок являє собою цілісний елемент.

Рис. 6 - Ітеративна модель

Як оптимально побудувати ітеративну модель?

· Вимоги до кінцевої системі заздалегідь чітко визначені і зрозумілі.

· Проект великий або дуже великий.

· Основне завдання повинне бути визначено, але деталі реалізації можуть еволюціонувати з часом.

"Spiral Model" (Спіральна модель)

Рис. 7 - Спіральна модель



"Спіральна модель" схожа на інкрементну, але з акцентом на аналіз ризиків. Вона добре працює для вирішення критично важливих задач, коли невдача несумісна з діяльністю.

Спіральна модель передбачає 4 етапи для кожного витка:

· Планування.

· Аналіз ризиків.

· Конструювання.

· Оцінка результату і при задовільній якості перехід до нового витка.

У сучасній практиці моделі розробки програмного забезпечення багатоваріантні. Немає єдиного вірного для всіх проектів. Методології частково перетинаються в засобах і місцями схожі одна на одну [4].



2. Практична частина

2.1 Дерево цілей

Для можливості досягнення поставленої мети було розроблено дерево цілей, що має усі необхідні етапи. Воно має чотири рівні. Нижчі рівні - цілі, що необхідно виконати для досягнення вищих.

Аналіз вимог та ризиків - перший етап і він буде використовуватися на початку реалізації поставленої мети. Другим етапом є розробка, а третім - підтримка. Дерево цілей зображено на рисунку номер вісім [2].

комп'ютерний гра програмний модуль

Рис. 8 - Дерево цілей

2.2 Дерево критеріїв

Дерево критеріїв визначає ступінь досягнення поставленої мети. Мета вважається досягнутою, якщо виконуються усі етапи що розташовані рівнем нижче. Дерево критеріїв зображено на рисунку номер дев'ять.



Рис. 9 - Дерево критеріїв

2.3 Аналіз вимог і ризиків

2.3.1 Концепція

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

Етапи креативного мислення можливо поділити на такі етапи:

· Натхнення - пошук ідей з використанням різних джерел;

· Синтез - об'єднання різних ідей;

· Резонанс - отримання ефекту синергії від синтезу ідей;

· Конвергенція - формулювання концепції ігри.

В основі будь-якої гри лежить мрія. Саме з мрії автора починається розроблятись гра. Протягом усього періоду розробки вона залишається незмінною, але з можливістю бути модифікованою і розвитися, проходячи крізь всі заплановані етапи.



2.3.2 Вибір цільової аудиторії

Для початку достатньо буде скласти список з декількох категорій користувачів.

Наприклад:

· Любителі футбольних симуляторів;

· Школяри і студенти;

· Дорослі чоловіки.

Спочатку потрібно враховувати інтереси цільової аудиторії (любителі футбольних симуляторів) і тільки потім її розширяти далі (дорослі чоловіки). Деякі аудиторії неможливо отримати за допомогою ігрової преси, інші, інакше, будуть самі шукати гру. Третіх можливо залучити лише за допомогою реклами. Цей етап досить важливий і його реалізацію потрібно проводити заздалегідь, тому кошти для просування не будуть зайвими.

2.3.3 Порівняння з існуючими іграми

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

Інтересний сюжет, красива графіка - не є особливостями.

2.3.4 Вибір платформи

Цей пункт залежить тільки від розробника, а саме від того, які цілі він переслідує і що він вміє.

2.3.5 Вимоги до ігри

Це документ, що описує потрібні для системи характеристики.

2.3.6 Ризики

Мета управління ризиками полягає в тому, щоб зробити процес розробки максимально безпечним. Для цього потрібно:

· Мінімізувати знайдені ризики.

· Складати проектну документацію.

· План розробки на наступні етапи.

Ризики, що пред'являються до гри, мінімізуються за допомогою створення прототипу (початковою версії гри, що містить приклади функціоналу, графіки або інших ризикових аспектів). Ризики менеджменту мінімізуються шляхом складання плану (опис процесу розробки з прив'язкою до часу). Ризики розробника (команди) вибором вже освоєних технологій і досвідом випуску вже схожих проектів.

2.4 Розробка

2.4.1 Модель ігри

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

Під час побудови моделі потрібно документувати причини, за якими було прийняте те чи інше рішення.

Рис. 10 - Модель ігри

Сценарій

Сценарій для ігри не є особовим. Його в загалі може не бути. Дійсно, він додає грі певного інтересу, атмосфери и бажання дізнатися чим все закінчиться.

Рішення про потрібність і об'єм сценарію потрібно обговорювати до початку етапу розробки. Якщо ви хочете розповісти історію, то вам знадобиться сюжет. Якщо ви хочете зробити сервіс, то сюжет вам не потрібен.

Геймплей

З технічної точки зору - це підрозділ економічної науки, в якому за допомогою відповідного математичного апарату аналізуються системи, керовані правилами. Мета цього аналізу - підрахунок перемог і поразок, до яких може призвести кожний з можливих результатів. Сукупність стратегій, що приводять до певних результатів, називаються "ігровим процесом", або геймплеєм (gameplay).

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

Інтерфейс

Ніколи не треба забувати про інтерфейс. Він існує не для того, щоб прикрашати гру. Основне призначення його - допомога користувачу у грі.

Для розробки гарного інтерфейсу достатньо відповісти на питання: Що я можу зробити, щоб користувачу не довелося діяти всупереч системі? Інтерфейс - елемент, що дозволяє користувачу забути про те, що можливості користування грою обмежені.

Ігрові можливості

Це саме те, чим ваша гра буде відрізнятися від інших, тому краще розпочати саме з цього пункту. Ігрові можливості мають бути основою усієї документації. Це допоможе зберегти первісний задум впродовж усього процесу.

Ігрові можливості є породженням правил. Якщо говорити на технічній мові, то це означає можливість розробки нової ігрової можливості.

Правила

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

На цьому етапі можна лише припускати, за якими правилами буде будуватися модель. Саме цьому, впродовж усього процесу, правила будуть неодноразово переписані і дописані. Але, досить важливо пам'ятати про те, що одне правило, може повторювати інше, або приводити до конфліктних ситуацій з іншими правилами. Тому слід подумати, чи потрібне воно взагалі?!

2.4.2 Створення технічного проекту

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

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

Модуль створюється на основі проектної документації, що представлена в певній формі.

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

2.4.3 Розробка програмного коду

Модулі реалізуються на основі технічної документації. Модулем може бути: програмний файл, тривимірна модель, двовимірний рисунок, текстовий файл з конфігурацією або інший файл, що необхідний для роботи проекту.



2.4.4 Тестування

Тестування проходить за зразком плану тестування, який розробник готує разом з планом тестування. На цьому етапі розробник повинен перевірити працездатність усіх функцій, заданих модулю [1].

2.5 Підтримка

2.5.1 Модернізація

Планування змін

Зміни потрібно планувати для того, щоб вносити до проекту нові ідеї для його розширення, або для виправлення помилок, що могли виникнути під час проектування, або розробки.

2.5.2 Збір статистики

Канали

Канали бувають: куплені, особисті, заслужені.

Особисті - сайт, блог, соціальні мережі. Нехай це не телемережа, але це ваша особиста аудиторія і вона більш лояльна ніж аудиторія з інших каналів.

Куплені - класична реклама. Усі статті на правах реклами, банери на сайтах, статті в журналах.

Заслужені - сайти, блоги, люди та інші медіа, що пишуть про вас безкоштовно. Ці публікації ви заслужили своїм трудом. Цей вид каналів базується на вашій роботі з аудиторією та партнерами.

Існує декілька способів закупівлі реклами:

СРМ - плата за показ рекламного повідомлення (вимірюється в тисячах).

СРС - плата за кожний клік користувача по рекламі.

СРІ - плата за повноцінний загрузку гри.

Для підрахунку ефективності рекламних каналів потрібно слідкувати за кожним користувачем індивідуально. Це можна робити як за допомогою особистого ПЗ, так і за допомогою вже існуючого. Цей процес називається - облік конверсій. Його суть полягає у підрахунку коштів на кількість залучених користувачів.

Особисті і заслужені канали працюють за тією ж схемою, але вони не потребують затрат на закупівлю реклами [5].

2.6 Оцінка альтернатив

На цьому етапі було обрано можливі засоби досягнення мети. Було обрано альтернативи і відповідні для них критерії. Вони зображені в таблиці номер один. Методом ранжування було обрано альтернативи, які максимально підходять для нашої мети [3].

Табл. 1 - Альтернативи та критерії

	Альтернативи	Критерії
Вибір цільової аудиторії	1. Діти 2. Підлітки 3. 18+ 4. Жінки	1. Масштаб аудиторії 2. Корисність аудиторії 3. Відповідність аудиторії до ігр, що схожі на розроблювану
Порівняння	1. Ігра 1 2. Ігра 2 3. Ігра 3 4. Ігра 4	1. Масштаб аудиторії 2. Різниця в моделях 3. Важкість розробки
Вибір платформи	1. ПК 2. Консоли 3. Моб. ОС	1. Популярність платформи (відсоток ринку) 2. Важкість розробки під дану платформу (час на розробку) 3. Можливість підтримки (розвиток проекту)

Вибір цільової аудиторії:



Порівняння з існуючими іграми:

Вибір платформи:



Висновок

Розробка комп'ютерної гри незалежним розробником - завдання досить складне. Воно потребує певних навичок програмування, а також навичок роботи з додатковим ПЗ, яке необхідне для реалізації запланованих об'єктів.

Метою курсового проекту було проведення аналізу розробки комп'ютерної гри. Курсова робота поділена на етапи, що детально описують процес розробки ігри, до якого входить етап взаємодії з різними каналами ігрової спільноти.

Саме ці канали використовуються для збору статистики. Будь яка реклама, стаття, відео або завантаження гри - це об'єкт для збору статистичних даних. Дані, що збираються, повинні носити як позитивний, так і негативний характер. Це дозволить визначити переваги і недоліки програми, і можливо, визначити напрямок подальшого розвитку ігри, відштовхуючись від відгуків користувачів.

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



Використана література

1. Роллінгз Е., Морріс Д. Проектування і архітектура ігр.: Пер. З англ. - М.: Издательский дом "Вильямс", 2006. - 1040 с.: ISBN 5-8459-0914-7 (рус.)

2. Горбань О.М., Бахрушин В.Є. ОСНОВИ ТЕОРІЇ СИСТЕМ І СИСТЕМНОГО АНАЛІЗУ: Навчальний посібник. - Запоріжжя: ГУ "ЗІДМУ", 2004. - 204 с.

3. Перегудов Ф.И., Тарасенко Ф.П. Введение в системный анализ. М.: Высшая школа, 1989. - 367 с.

4. Edison. Ещё раз про семь основных методологий разработки - habrahabr.ru, 2015 (http://habrahabr.ru/company/edison/blog/269789/)

5. Галёнкин С. Маркетинг Игр - galyonkin.com, 2014 (http://galyonkin.com/book/)

6. Максим Кузнецов. Обзор процесса разработки программного обеспечения - habrahabr.ru, 2015 (http://habrahabr.ru/post/255991/).

7. Максим Кузнецов. Применение agile при разработке проекта для государственного заказчика - megamozg.ru, 2015 (http://megamozg.ru/post/14554/).

8. Сергей Рогачёв. Планирование и отслеживание итеративной разработки с помощью Microsoft Project - agilerussia.ru, 2012 (http://agilerussia.ru/practices/planning-ms-project/).

9. Стив Макконнелл. Остаться в живых. Руководство для менеджеров программных проектов - СПб.: Питер, 2006.

10. Хомяков П.М. Системный анализ:краткий курс лекций/Под ред. В.П. Прохорова - М.: КомКнига, 2006. -- 216 с.

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

...