ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6671| Title: | Управління проєктом створення комп’ютерної гри з процедурною генерацією вмісту ігрового середовища |
| Authors: | Підгорний, Микола Володимирович Пустовіт, Андрій Володимирович |
| Keywords: | ПРАВЛІННЯ ПРОЄКТАМИ;GAMEDEV;ПРОЦЕДУРНА ГЕНЕРАЦІЯ ВМІСТУ;ГІБРИДНИЙ ЖИТТЄВИЙ ЦИКЛ;SCRUM-HYBRID;УПРАВЛІННЯ РИЗИКАМИ;FITNESS FUNCTION;ТЕХНОЛОГІЧНИЙ РИЗИК. |
| Issue Date: | 17-Dec-2025 |
| Abstract: | Сучасна індустрія комп'ютерних ігор (GameDev) постійно висуває високі вимоги до масштабності, реіграбельності та унікальності ігрового контенту. Традиційні підходи до створення контенту (ручне моделювання, дизайн рівнів) стають економічно неефективними та часозатратними для проєктів із великими відкритими світами або жанрів, що вимагають високої динаміки та варіативності (наприклад, roguelike). Актуальність роботи зумовлена гострою потребою у розробці адаптованої, гібридної PM-методології та інструментарію, які б дозволили ефективно планувати, контролювати якість та мінімізувати технологічні ризики в інноваційних проєктах із PCG-ядром. Мета дослідження: Теоретично обґрунтувати, розробити та запропонувати детальні методичні рекомендації з управління інноваційним проєктом створення комп’ютерної гри, ключовою особливістю якої є використання процедурної генерації вмісту ігрового середовища (PCG). Об’єктом дослідження є процес управління проєктом створення комп’ютерної гри з процедурною генерацією вмісту ігрового середовища. Предмет дослідження є проект створення комп’ютерної гри з процедурною генерацією вмісту ігрового середовища. Апробація результатів роботи. Основні положення і результати кваліфікаційної роботи магістра доповідалися і були обговорені на ІV Міжнародній науково-практичній Інтернет-конференції ІННОВАЦІЇ ТА ПЕРСПЕКТИВНІ ШЛЯХИ РОЗВИТКУ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ (ІПШРІТ-2025), Черкаси, 25 листопада 2025 року. Публікації. Пустовіт А.В. Підгорний М.В. Управління організаційно-технологічними процесами в розробці комп’ютерних ігор з процедурною генерацією вмісту [Текст]: // ІV Міжнародна науково-практична Інтернет-конференція ІПШРІТ-2025, Черкаси, 25 листопада 2025 року, ЧДТУ. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6671 |
| Appears in Collections: | 122 Комп’ютерні науки (Управління стартапами і проектами в галузі інформаційних технологій) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Пустовіт Андрій_МСТП-2402_2025-2026.pdf Restricted Access | 2.7 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
магістра
(освітньо-кваліфікаційний рівень)
на тему: «Управління проєктом створення комп’ютерної гри з процедурною
генерацією вмісту ігрового середовища»
Виконав: студент 2 курсу, групи МСТП-2104
спеціальності 122 «Комп’ютерні науки»
(шифр і назва спеціальності)
освітня програма «Управління стартапами
(назва освітньої програми)
і проєктами в галузі інформаційних технологій»
Пустовіт Андрій Володимирович
Керівник Підгорний М.В.
(прізвище та ініціали)
Рецензент Мельник В.П.
(прізвище та ініціали)
Черкаси 2025 року
2
Бланк завдання на кваліфікаційну роботу магістра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Магістр
Спеціальність 122 – комп’ютерні науки
Освітня програма Управління стартапами і проєктами в галузі інформаційних технологій
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2025 р.
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Пустовіту Андрію Володимировичу
(прізвище, ім‘я, по батькові)
1. Тема роботи Управління проєктом створення комп’ютерної гри з процедурною генерацією
вмісту ігрового середовища
Керівник роботи Підгорний Микола Володимирович, к.т.н., професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «07» жовтня 2025 р. №307 /03-03 .
2. Строк подання студентом роботи до «11» грудня 2025 року.
3. Вихідні дані до роботи:
Результати та матеріали з проходження виробничої та переддипломної практики
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
1. Аналіз та дослідження об’єкту управління
2. Розробка концепції проєкту
3. Планування проєкту та розробка pm-інструментарію
4. Моделювання виконання проєкту
Висновки
5. Перелік додатків (з точним зазначенням назв додатків):
А.
1Б. Інструкція користувача
3
Б.
В.
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ посада
завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 02.09.2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів кваліфікаційної роботи магістра Примітка
етапів роботи
1 Видача завдання на кваліфікаційну роботу
до 07.10.2025
магістра.
2 Аналіз літературних джерел, об’єкту та предмету
до 10.10.2025
дослідження.
3 Написання теоретичного розділу кваліфікаційної
до 25.10.2025
роботи магістра.
4 Написання аналітичного розділу (аналіз об’єкту
до 03.11. 2025
й предмету дослідження).
5 Написання практичних розділів й висновків
до 27.11.2025
кваліфікаційної роботи магістра.
6 Передзахист кваліфікаційної роботи магістра на
до 28.11.2025
засіданні випускової кафедри.
7 Подання роботи завідувачу кафедри КНСА. до 01.12.2025
8 Захист кваліфікаційної роботи магістра. 17.12.2025
Студент _____________________________ Андрій ПУСТОВІТ
(підпис)
Керівник роботи ____________________________ Микола ПІДГОРНИЙ
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота магістра містить: 104 c., 21 рис., 24 табл., 55
використаних джерел.
Актуальність теми. Сучасна індустрія комп'ютерних ігор (GameDev) постійно
висуває високі вимоги до масштабності, реіграбельності та унікальності ігрового
контенту [1]. Традиційні підходи до створення контенту (ручне моделювання, дизайн
рівнів) стають економічно неефективними та часозатратними для проєктів із великими
відкритими світами або жанрів, що вимагають високої динаміки та варіативності
(наприклад, roguelike).
Вирішенням цієї проблеми є Процедурна Генерація Вмісту (PCG). Проєкти на
основі PCG, хоч і забезпечують бажаний рівень масштабованості, створюють унікальні
управлінські виклики, які не можуть бути ефективно вирішені класичними
методологіями (Waterfall) або чистими гнучкими практиками (Agile) [2]. Основна
проблематика полягає у високій технологічній невизначеності, ризику створення
неграбельного або непередбачуваного контенту та складністю переведення
суб'єктивних вимог гейм-дизайну в об'єктивні, алгоритмічно контрольовані параметри.
Актуальність роботи зумовлена гострою потребою у розробці адаптованої,
гібридної PM-методології та інструментарію, які б дозволили ефективно планувати,
контролювати якість та мінімізувати технологічні ризики в інноваційних проєктах із
PCG-ядром.
Мета дослідження: Теоретично обґрунтувати, розробити та запропонувати
детальні методичні рекомендації з управління інноваційним проєктом створення
комп’ютерної гри, ключовою особливістю якої є використання процедурної генерації
вмісту ігрового середовища (PCG).
Основні задачі дослідження:
- проаналізувати та систематизувати існуючі методології управління проєктами в
GameDev та визначити їхні обмеження стосовно проєктів із PCG;
5
- обґрунтувати та розробити адаптовану концепцію та PM-методологію, що
включає гібридний життєвий цикл;
- розробити детальний план реалізації (WBS, Календарний графік, Бюджет);
- створити адаптовану модель управління ризиками, ідентифікувавши критичні
загрози, пов’язані з розробкою PCG-ядра;
- сформулювати кількісні критерії оцінки якості (QA) та метрики ефективності
(KPI) для контролю згенерованого контенту;
- провести моделювання продукту та процесу для підтвердження його технічної та
управлінської життєздатності.
Об’єктом дослідження є процес управління проєктом створення комп’ютерної
гри з процедурною генерацією вмісту ігрового середовища.
Предмет дослідження є проект створення комп’ютерної гри з процедурною
генерацією вмісту ігрового середовища.
Апробація результатів роботи. Основні положення і результати кваліфікаційної
роботи магістра доповідалися і були обговорені на ІV Міжнародній науково-практичній
Інтернет-конференції ІННОВАЦІЇ ТА ПЕРСПЕКТИВНІ ШЛЯХИ РОЗВИТКУ
ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ (ІПШРІТ-2025), Черкаси, 25 листопада 2025 року.
Публікації. Пустовіт А.В. Підгорний М.В. Управління організаційно-
технологічними процесами в розробці комп’ютерних ігор з процедурною генерацією
вмісту [Текст]: // ІV Міжнародна науково-практична Інтернет-конференція ІПШРІТ-
2025, Черкаси, 25 листопада 2025 року, ЧДТУ.
Перелік ключових слів: ПРАВЛІННЯ ПРОЄКТАМИ, GAMEDEV,
ПРОЦЕДУРНА ГЕНЕРАЦІЯ ВМІСТУ (PCG), ГІБРИДНИЙ ЖИТТЄВИЙ ЦИКЛ,
SCRUM-HYBRID, УПРАВЛІННЯ РИЗИКАМИ, FITNESS FUNCTION, WBS,
ТЕХНОЛОГІЧНИЙ РИЗИК.
6
ABSTRACT
Master's Thesis Content: 104 pages, 21 figures, 24 tables, 55 references used.
Relevance of the Topic. The modern computer game industry (GameDev) continuously
places high demands on the scalability, replayability, and uniqueness of game content.
Traditional content creation approaches (manual modeling, level design) are becoming
economically inefficient and time-consuming for projects with large open worlds or genres that
require high dynamism and variability (e.g., roguelike). The solution to this problem is
Procedural Content Generation (PCG). While PCG-based projects provide the desired level of
scalability, they introduce unique management challenges that cannot be effectively addressed
by classical methodologies (Waterfall) or pure agile practices (Agile). The main challenge lies
in the high technological uncertainty, the risk of creating unplayable or unpredictable content,
and the difficulty of translating subjective game design requirements into objective,
algorithmically controlled parameters.
Goal of the Research: To theoretically substantiate, develop, and propose detailed
methodological recommendations for managing an innovative computer game creation project,
the key feature of which is the use of procedural generation of game environment content
(PCG).
Key Objectives of the Research:
- to analyze and systematize existing project management methodologies in GameDev and
define their limitations concerning PCG projects;
- to substantiate and develop an adapted concept and PM methodology, including a hybrid
life cycle;
- to develop a detailed implementation plan (WBS, Calendar schedule, Budget);
- to create an adapted risk management model by identifying critical threats associated
with the development of the PCG core;
- to formulate quantitative quality assessment criteria (QA) and performance metrics
(KPI) for controlling the generated content;
7
- to conduct product and process modeling to confirm their technical and managerial
viability.
Object of the Research is the process of managing a project for creating an innovative
software product—a computer game with procedural generation functionality for the game
environment.
Subject of the Research is the set of management relations, methods, tools, and
technologies aimed at effective planning, organization, and control of resources, quality, and
risks under the conditions of developing a high-tech core that utilizes Procedural Content
Generation.
Results Approval. The main provisions and results of the Master's thesis were presented
and discussed at the IV International Scientific and Practical Internet Conference
INNOVATIONS AND PROMISING WAYS OF INFORMATION TECHNOLOGY
DEVELOPMENT (IPWIT-2025), Cherkasy, November 25, 2025.
Publications. Pustovit A.V. Pidhornyi M.V. Management of organizational and
technological processes in the development of computer games with procedural content
generation [Text]: // IV International Scientific and Practical Internet Conference IPWIT-2025,
Cherkasy, November 25, 2025, ChSTU.
List of Keywords: PROJECT MANAGEMENT, GAMEDEV, PROCEDURAL
CONTENT GENERATION (PCG), HYBRID LIFE CYCLE, SCRUM-HYBRID, RISK
MANAGEMENT, FITNESS FUNCTION, WBS, TECHNOLOGICAL RISK.
8
ЗМІСТ
ВСТУП ....................................................................................................................................... 9
1 АНАЛІЗ ТА ДОСЛІДЖЕННЯ ОБ’ЄКТУ УПРАВЛІННЯ .............................................. 12
1.1 Аналіз та характеристика галузі розробки ігор з процедурною генерацією .......... 12
1.2 Аналіз конкурентних проєктів та аналогів ................................................................. 14
1.3 Проведення аналізу галузі за методом 5 сил Портера .............................................. 20
1.4 SWOT-аналіз проєкту ................................................................................................... 23
1.5 Особливості управління проєктами створення ігор з процедурною генерацією ... 26
Висновки до Розділу 1 ........................................................................................................ 26
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ ................................................................................ 27
2.1 Первинні та вторинні зацікавлені сторони, аналіз їх впливу на проєкт.................. 27
2.2 Цілі організації розробки та місія проєкту ................................................................. 32
2.3. Цілі, очікувані результати та структура продукту проєкту ..................................... 33
2.4 Життєвий цикл проєкту (стартапу), перелік ключових віх ...................................... 36
Висновки до Розділу 2 ........................................................................................................ 39
3 ПЛАНУВАННЯ ПРОЄКТУ ТА РОЗРОБКА PM-ІНСТРУМЕНТАРІЮ ....................... 40
3.1 Управління змістом проєкту ........................................................................................ 41
3.2 Організаційна структура проєкту ................................................................................ 55
3.3 Розробка календарного плану проєкту ....................................................................... 62
3.4 Планування бюджету проєкту ..................................................................................... 70
3.5 Управління ризиками проєкту ..................................................................................... 76
3.6 Управління якістю проєкту .......................................................................................... 82
Висновки до розділу 3 ........................................................................................................ 86
4 МОДЕЛЮВАННЯ ВИКОНАННЯ ПРОЄКТУ ................................................................ 87
4.1 Опис моделювання продукту проєкту ........................................................................ 87
4.2 Опис процесу реалізації проєкту ................................................................................. 88
4.3 Аналіз отриманих результатів ..................................................................................... 95
Висновки до розділу 4 ........................................................................................................ 97
ВИСНОВКИ ............................................................................................................................ 98
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................................ 100
9
ВСТУП
Актуальність і значення обраної теми. Сучасна індустрія розробки
комп'ютерних ігор (GameDev) переживає період експоненційного зростання очікувань
користувачів щодо масштабу, деталізації та унікальності ігрового світу. Створення
величезних відкритих світів за допомогою традиційних методів ручного моделювання
та дизайну вимагає залучення значних людських та фінансових ресурсів, що часто
призводить до збільшення термінів розробки, зростання бюджетів та підвищення ризику
"scope creep" (розповзання обсягу проєкту).
Для вирішення цих викликів, технологія Процедурної Генерації Вмісту (Procedural
Content Generation, PCG) набуває стратегічного значення. PCG дозволяє автоматично
створювати унікальний, різноманітний та практично безкінечний ігровий контент
(ландшафти, рівні, об'єкти, завдання) на основі алгоритмів та правил. Хоча PCG вирішує
проблему масштабування, вона одночасно породжує нові, нетипові для класичного IT-
менеджменту виклики в управлінні проєктом:
- непередбачуваність результату: складність контролю якості та естетичної
привабливості контенту, який генерується алгоритмом;
- управління ризиками алгоритмів: необхідність тестування та валідації самого
генератора, а не лише кінцевої сцени;
- міждисциплінарна координація: синхронізація роботи програмістів, які
створюють генератори, та гейм-дизайнерів/художників, які задають правила
генерації.
Таким чином, класичні методології управління проєктами (навіть адаптовані
Agile-підходи) потребують суттєвої модифікації та доповнення для ефективного
управління проєктами, де PCG є критично важливим елементом. Актуальність теми
магістерської роботи полягає в обґрунтуванні, розробці та адаптації комплексної
методології управління проєктом створення комп'ютерної гри з PCG, що дозволить
мінімізувати специфічні ризики, оптимізувати планування та забезпечити високу якість
10
продукту.
Зв’язок роботи з науковими програмами, планами, темами. Дослідження
проводиться в рамках загальнодержавної програми розвитку інформаційних технологій
в Україні та узгоджується з сучасними тенденціями розвитку індустрії розробки
програмного забезпечення, зокрема GameDev. Робота є частиною наукового напряму
кафедри, що присвячений розробці та впровадженню гнучких моделей управління
інноваційними проєктами.
Мета дослідження полягає у теоретичному обґрунтуванні та розробці методичних
рекомендацій з управління проєктом створення комп'ютерної гри, ключовою
особливістю якої є використання процедурної генерації вмісту ігрового середовища.
Для досягнення поставленої мети визначено такі завдання:
- проаналізувати та систематизувати сучасні методології управління проєктами у
сфері розробки комп’ютерних ігор (GameDev) та визначити їхні обмеження
стосовно проєктів із PCG;
- дослідити технічні особливості та класифікацію алгоритмів процедурної генерації
вмісту ігрового середовища та їхній вплив на структуру робіт (Work Breakdown
Structure, WBS) проєкту;
- розробити адаптовану модель управління ризиками, специфічними для проєктів
PCG (технічні ризики генерації, ризики балансу та естетики контенту);
- сформулювати критерії оцінки якості (Quality Assurance) та метрики ефективності
(KPI) для контролю результатів процедурної генерації;
- на основі отриманих результатів розробити практичні рекомендації та шаблон
планування [3] для управління проєктом створення PCG-гри.
Об’єкт дослідження: є процес управління проєктом створення інноваційного
програмного продукту — комп’ютерної гри з функцією процедурної генерації ігрового
середовища.
Предмет дослідження: є проектом створення комп’ютерної гри з процедурною
генерацією вмісту ігрового середовища.
11
Перелік застосованих методів дослідження. Для досягнення поставленої мети і
виконання завдань у роботі використано комплекс взаємопов'язаних методів:
- системний аналіз – для виявлення та структурування взаємозв'язків між
підсистемами управління проєктом та технологічними особливостями PCG;
- метод порівняльного аналізу – для зіставлення класичних методологій управління
проєктами (Waterfall, Scrum, Kanban) з вимогами проєкту PCG-гри;
- теоретичне узагальнення – для формування універсальної структури управління
проєктом та адаптації PMBOK-практик до специфіки GameDev та PCG;
- методи моделювання – для розробки структури управління ризиками та процесу
забезпечення якості (QA) процедурно генерованого контенту;
- експертні оцінки – для валідації розроблених методичних рекомендацій з
управління.
Практичне значення отриманих результатів полягає у розробці чітких та
адаптованих методичних рекомендацій та шаблонів для менеджерів проєктів (Project
Managers), які працюють над створенням ігор із використанням PCG. Отримані
результати можуть бути безпосередньо використані:
- у малих та середніх студіях розробки ігор для зниження фінансових та часових
ризиків при масштабуванні ігрового світу;
- для стандартизації процесів QA при тестуванні процедурно генерованого
контенту;
- в освітньому процесі при підготовці фахівців з управління IT-проєктами, зокрема
GameDev-проєктами;
12
1 АНАЛІЗ ТА ДОСЛІДЖЕННЯ ОБ’ЄКТУ УПРАВЛІННЯ
1.1 Аналіз та характеристика галузі розробки ігор з процедурною генерацією
Сучасна індустрія інтерактивних розваг (GameDev) перебуває в стані динамічного
та безперервного розвитку, що супроводжується стрімким зростанням очікувань
аудиторії щодо обсягу, різноманітності та загальної якості ігрового контенту. Гравці
дедалі частіше орієнтуються на масштабні, візуально насичені світи, які повинні бути не
лише стилістично виразними, але й деталізованими, функціональними та здатними
підтримувати високу залученість протягом тривалого часу. Відповідно до глобальних
тенденцій у галузі, створення візуальних активів (асетів), ігрових рівнів та повноцінних
світів потребує значних фінансових та людських ресурсів: у великих комерційних
проєктах ці статті витрат можуть сягати 60–70% від загального бюджету розробки [4].
Ця ситуація породжує на ринку відому кризову проблему, яку часто описують
терміном «Content Treadmill» [5] — своєрідну «контентну бігову доріжку». Вона полягає
в тому, що темпи споживання нового контенту гравцями постійно зростають, і
користувачі очікують стабільного потоку оновлень, нових локацій, персонажів, механік
та історій. Натомість можливості розробників, які покладаються виключно на традиційні
методи ручного моделювання та створення контенту «вручну», обмежені фізичними
ресурсами команд і тривалістю виробничих циклів. У результаті швидкість виробництва
контенту істотно відстає від швидкості, з якою аудиторія його проходить, виснажуючи
студії та ускладнюючи підтримку проєкту на конкурентному рівні.
Таке розбалансування між попитом і можливостями виробництва стає одним із
ключових аргументів на користь переходу до процедурних і напівавтоматизованих
методів генерації контенту, які здатні суттєво підвищити масштабованість і
продуктивність процесу розробки.
У відповідь на згаданий виклик та загальну ескалацію потреби у швидкому,
масштабованому та економічно ефективному виробництві ігрового контенту, технологія
Процедурної Генерації Вмісту (Procedural Content Generation — PCG) [6] поступово
13
перестала бути вузькоспеціалізованим, майже експериментальним інструментом, який
використовували лише окремі ентузіасти чи невеликі команди. Вона трансформувалася
у повноцінний стратегічний компонент сучасного виробничого процесу, без якого
дедалі складніше уявити розробку масштабних та довготривалих проєктів. PCG з
нішевої технології перетворилася на індустріальний стандарт, який активно впливає на
геймдизайн, технічну архітектуру проєктів та економічну модель їхньої підтримки.
На сьогодні застосування PCG виходить далеко за межі інді-сектору, де вона
традиційно слугувала інструментом компенсації обмежених людських і фінансових
ресурсів, дозволяючи малим командам створювати вражаюче великі світи або
різноманітний ігровий контент без необхідності значного збільшення штату. Сучасна
індустрія демонструє, що навіть AAA-студії — великі комерційні виробництва з
багатомільйонними бюджетами — активно інтегрують процедури генерації для
розбудови гігантських відкритих світів, наповнених унікальними ландшафтами,
варіативними подіями, системами, що адаптуються, та складними екосистемами. Це
дозволяє значно пришвидшити розробку, оптимізувати витрати й водночас створювати
масштабні, динамічні та живі світи, які неможливо відтворити традиційними методами
у прийнятні строки.
Таким чином, PCG сьогодні виступає не просто допоміжною технологією, а
ключовим напрямом технологічної еволюції GameDev-індустрії, який визначає
конкурентоспроможність студій та життєздатність довгострокових проєктів у умовах
зростаючих ринкових вимог.
Проте з точки зору управління проєктами впровадження PCG формує середовище
з підвищеним рівнем невизначеності, оскільки об’єктом контролю стає не конкретний
перелік задач, а система, здатна створювати практично необмежену кількість варіацій.
Це зумовлює необхідність перегляду класичних підходів до планування [7]:
- зміна фокусу контролю: менеджер керує не кінцевим результатом (готовою
сценою чи рівнем), а наборами правил, параметрів та обмежень, які повинні
утворювати допустимий простір варіацій;
14
- ризики «чорної скриньки»: алгоритми генерації здатні продукувати
непередбачувані або небажані результати — артефакти, «зламані» мапи,
непрохідні маршрути — що ускладнює прогнозування часу тестування та
навантаження на QA-команду;
- ітеративність: налаштування генератора відбувається у циклі без чітко визначених
меж, оскільки кожна зміна параметра може змінити весь простір результатів, що
робить процес менш передбачуваним порівняно з лінійним ручним створенням
рівнів.
Таким чином, сучасна ігрова індустрія вирізняється надзвичайно високим
технологічним порогом входу, який зумовлюється складністю виробничих процесів,
необхідністю опанування передових інструментів розробки та інтеграції різноманітних
технологій, зокрема процедурної генерації контенту, у щоденну практику. Крім того,
успішна робота в цій галузі вимагає від фахівців наявності специфічних управлінських
компетенцій, які виходять за межі стандартного менеджменту проектів. Йдеться про
здатність ефективно балансувати між автоматизацією творчого процесу — коли частина
контенту генерується алгоритмічно, з мінімальним ручним втручанням — та
підтриманням високого рівня контролю якості, який гарантує естетичну цілісність,
функціональність та узгодженість ігрових елементів. Саме така комплексна координація
технологічних рішень і управлінських підходів стає ключовим фактором, що визначає
успіх проекту, його конкурентоспроможність на ринку та здатність відповідати
зростаючим очікуванням гравців.
1.2 Аналіз конкурентних проєктів та аналогів
Для того, щоб сформувати дійсно ефективну та життєздатну стратегію управління
стартапом, необхідно спершу провести ретельний та всебічний аналіз існуючих рішень
на ринку, які вже застосовують процедуру процедурної генерації контенту (PCG) як
ключову механіку, що визначає їхній унікальний торгівельний аспект (USP — Unique
Selling Point). Важливо відзначити, що такий аналіз не обмежується лише оцінкою
15
ігрового процесу або розважальної складової продукту, а зосереджується передусім на
глибокому вивченні підходів до організації внутрішніх виробничих процесів,
структуризації робочих етапів і управління ресурсами, які забезпечують стабільність та
якість реалізації процедурних елементів. Це дозволяє зрозуміти, які методи й практики
застосовуються для підтримки високого рівня контролю над випадковістю генерації
контенту, як оптимізуються технічні процеси та які рішення забезпечують баланс між
ефективністю виробництва і кінцевою якістю продукту, що, в свою чергу, формує
основу для створення конкурентоспроможного та інноваційного стартапу в умовах
сучасного ринку.
Аналог 1: No Man's Sky (Hello Games) показує складнощі [8] масштабного
процедурного проєктування:
- характеристика: проєкт планетарного масштабу з процедурною генерацією флори,
фауни та ландшафту, що дозволяє створювати мільярди унікальних планет (на
рисунку 1.1 наведено кілька прикладів);
- управлінський аспект: на старті проєкт зазнав розчарування через неможливість
ручного контролю якості такої величезної кількості контенту, алгоритмічна
різноманітність призвела до «одноманітної каші», і команда зіткнулася з
проблемою балансування масштабності та унікальності;
- технологічні виклики: складність синхронізації великої кількості процедурних
алгоритмів та підтримки продуктивності гри на різних платформах;
- взаємодія з користувачами: відгуки гравців після релізу допомогли виявити
критичні проблеми генерації та стали стимулом для постійних оновлень контенту;
- стратегія масштабування: потреба у поетапному додаванні механік і планет через
патчі, що дозволяє поступово адаптувати алгоритми до реальних сценаріїв гри;
- висновок для нашого проєкту: необхідність впровадження жорстких метрик якості
(Fitness Functions) ще на етапі прототипування, а також планування циклічних
оновлень та механізмів збору фідбеку від користувачів для корекції алгоритмів.
16
Рисунок 1.1 - Приклад повної процедурної генерації біому в грі No Man's Sky
Аналог 2: Hades (Supergiant Games) демонструє ефективність [9] гібридного
підходу до процедурної генерації:
- характеристика: використовує процедурну генерацію для побудови підземель
(dungeon crawling), проте кімнати фіксовані та створені вручну, що дозволяє
поєднувати унікальність кожного проходження з високою художньою якістю
(Гібридний підхід, проілюстрований на рисунку 1.2, демонструє використання
заздалегідь створених художниками асетів);
- управлінський аспект: гібридний підхід з чітким розподілом зон відповідальності
— алгоритм визначає лише порядок розташування кімнат, а художники
відповідають за їх дизайн, що забезпечує баланс між процедурною
різноманітністю та естетичною привабливістю;
- висновок для нашого проєкту: доцільно застосовувати модульну систему
генерації, де процедурний алгоритм оперує заздалегідь перевіреними блоками
(префабами), щоб поєднувати повторювану структуру та контроль якості.
17
Рисунок 1.2 - Модульний підхід до побудови рівня в грі Hades
Аналог 3: Minecraft (Mojang) демонструє силу воксельної генерації та взаємодії з
користувачами:
- характеристика: воксельна генерація світу (як це можна побачити на рисунку 1.3)
здійснюється на основі шуму Перліна [10], що дозволяє створювати практично
нескінченні та унікальні ландшафти, включаючи різноманітні біоми та геологічні
структури;
- управлінський аспект: відкритий підхід до розробки (Early Access), коли
користувачі фактично виступали тестувальниками генератора протягом багатьох
років, дозволив збирати дані про помилки та недоліки системи без значних витрат
QA-ресурсів;
- висновок для нашого проєкту: важливо впроваджувати ранній доступ або бета-
тестування для збору реальних даних про критичні помилки генерації, які
неможливо виявити силами обмеженої команди контролю якості.
18
Рисунок 1.3 - Воксельна генерація ландшафту на основі шуму в грі Minecraft
Порівняльна характеристика основних підходів, які активно застосовуються в
сучасних рішеннях із використанням процедурної генерації контенту (PCG),
представлена у Таблиці 1.1. У цій таблиці систематизовано та структуровано ключові
аспекти кожного підходу, включно з їхніми технічними особливостями, методами
організації робочих процесів, масштабованістю, ресурсозатратністю та впливом на
кінцеву якість процедурно згенерованого контенту. Такий формат дозволяє наочно та
зручно оцінити суттєві відмінності між підходами, визначити їхні сильні й слабкі
сторони, а також зрозуміти, які з методів більш ефективно інтегруються в процес
розробки, забезпечують стабільність і передбачуваність результатів та дозволяють
підтримувати необхідний рівень якості продукту.
Крім того, використання такої порівняльної систематизації створює передумови
для глибшого аналітичного підходу при прийнятті рішень (Таблиця 1.1), адже дозволяє
розробникам і менеджерам оцінювати доцільність застосування того чи іншого підходу
залежно від масштабів проєкту, доступних ресурсів та стратегічних цілей. Це сприяє
оптимізації виробничих процесів, підвищенню ефективності роботи та формуванню
19
стратегії впровадження процедурної генерації контенту в комерційні та інноваційні
проєкти (Таблиця 1.2) (Рисунок 1.4).
Таблиця 1.1 – Порівняльний аналіз управлінських підходів у проєктах-аналогах
Критерій Повна генерація Гібридна Воксельна/Шумо Проєкт
порівняння (No Man's Sky) генерація ва (Minecraft) (Стартап)
(Hades)
Передбачуваніс Низька Висока Середня Середня
ть строків
Контроль якості Складний Ручний + Через спільноту Гібридний
(автоматизовани Алгоритмічни (QA +
й) й автотести)
Залежність від Низька Висока Низька Середня
художників
Масштабованіст Безмежна Обмежена Безмежна Висока
ь асетами
Таблиця 1.2 – Порівняльний аналіз техніко-економічних показників реалізації PCG
Критерій порівняння Наш No Man's Sky Hades Minecraft
проєкт (Аналог 1) (Аналог 2) (Аналог 3)
Ступінь автоматизації 80% 100% 30% 95%
контенту (%)
Витрати на Art-Department (у 25% 15% 60% 10%
% до бюджету)
Витрати на R&D та 55% 70% 30% 80%
програмування (у % до
бюджету)
20
Продовження Таблиці 1.2
Прогнозований час 3 12 4 6
тестування (міс.)
Рівень унікальності ігрової 8 10 6 9
сесії (1-10)
Ризик "зламаної" генерації (1- 7 9 2 4
10)
Название диаграммы
1500%
1000%
500%
0%
Наш проєкт No Man's Sky Hades (Аналог Minecraft
(Аналог 1) 2) (Аналог 3)
Ступінь автоматизації контенту (%)
Витрати на Art-Department (у % до бюджету)
Витрати на R&D та програмування (у % до бюджету)
Прогнозований час тестування (міс.)
Рівень унікальності ігрової сесії (1-10)
Ризик "зламаної" генерації (1-10)
Рисунок 1.4 – Діаграма порівняльного аналізу техніко-економічних показників
1.3 Проведення аналізу галузі за методом 5 сил Портера
Для оцінки привабливості запуску стартапу в даному сегменті застосовано модель
М. Портера [11]:
- загроза появи нових гравців (Середня). Бар'єри входу знизилися завдяки
доступності рушіїв (Unity, Unreal Engine 5) [12] та готових асетів. Проте,
створення якісного та збалансованого PCG вимагає високої математичної
кваліфікації програмістів, що є природним фільтром. Більшість новачків
створюють "клони", які не виживають;
21
- вплив покупців (Висока). Гравці мають величезний вибір. Вимоги до якості
графіки та глибини геймплею постійно зростають. Успіх залежить від відгуків у
Steam. Якщо процедурна генерація створює "нудні" рівні, гравці миттєво
повертають кошти (refund);
- вплив постачальників (Низька). Постачальники ПЗ (Unity, IDE, Jira) та
маркетплейси асетів конкурують між собою. Ціни на інструментарій є
стабільними або умовно-безкоштовними (модель Royalty share) до моменту
отримання прибутку;
- загроза товарів-замінників (Висока). Ігри з лінійним сюжетом та ручним дизайном
(наприклад, The Last of Us) пропонують гарантовано якісний, зрежисований
досвід, з яким важко конкурувати процедурним іграм у плані емоційного
залучення. Також замінниками є інші форми розваг (стрімінг, соцмережі);
- рівень конкурентної боротьби (Дуже високий). Ринок перенасичений. Щодня в
Steam виходить понад 30 ігор. Щоб виділитися, проєкт повинен пропонувати
унікальну механіку реіграбельності, яку забезпечує саме грамотно налаштована
система PCG.
Також проведено кількісну оцінку сил конкуренції за моделлю М. Портера (Результати
наведено в таблиці 1.3 і візуалізовано на блок-схемі на рисунку 1.5)
Таблиця 1.3 – Кількісна оцінка сил конкуренції за моделлю М. Портера (Експертна
оцінка)
Фактор конкуренції Критерій оцінювання Оцінка Вагомість Зважена
(Сила) (1-10) фактора (0-1) оцінка
1. Загроза появи Доступність рушіїв 9 0.15 1.35
нових гравців (Unity/UE5)
Технологічний бар'єр 4 0.15 0.60
(складність PCG)
Середнє за фактором 6.5 1.95
22
Продовження таблиці 1.3
2. Вплив покупців Чутливість до ціни 8 0.10 0.80
(розпродажі Steam)
Вимогливість до якості 10 0.10 1.00
контенту
Середнє за фактором 9.0 1.80
3. Вплив Вартість ліцензій ПЗ 3 0.05 0.15
постачальників (Royalty share)
Залежність від асет- 4 0.05 0.20
сторів
Середнє за фактором 3.5 0.35
4. Загроза товарів- Ігри з ручним дизайном 9 0.10 0.90
замінників (AAA-блокбастери)
Інші форми розваг 7 0.10 0.70
(Twitch, TikTok)
Середнє за фактором 8.0 1.60
5. Рівень Насиченість жанру 9 0.20 1.80
конкурентної Survival/RPG
боротьби
Швидкість виходу 10 0.20 2.00
нових релізів
Середнє за фактором 9.5 3.80
РАЗОМ 1.00 9.50
(Інтегральний
показник)
23
Оцінка сил конкуренції
Середня оцінка (1-10) Середня зважена оцінка
1. Загроза
появи нових
гравців
10
8
5. Рівень 6
4 2. Ринкова
конкурентної
2 влада покупців
боротьби
0
4. Загроза 3. Ринкова
товарів- влада
замінників постачальників
Рисунок 1.5 – Діаграма до таблиці експертної оцінки
Висновок: Галузь є висококонкурентною, але перспективною для команд, що
володіють сильною технічною експертизою. Ключ до успіху — не просто наявність
генерації, а її якість та інтеграція в геймплей.
1.4 SWOT-аналіз проєкту
Для визначення стратегії управління проведено SWOT-аналіз [13] (Strengths,
Weaknesses, Opportunities, Threats) власного проєкту розробки гри (Є в таблиці 1.4).
Таблиця 1.4 – SWOT-аналіз стартапу
Сильні сторони (Strengths) Слабкі сторони (Weaknesses)
1. Висока реіграбельність за рахунок 1. Висока залежність від кваліфікації
процедурної генерації (низька вартість ключового програміста (Bus factor).
години геймплею).
2. Менша потреба у великому штаті левел- 2. Складність коректного балансування
дизайнерів та художників оточення. рівнів та прогресії.
3. Використання сучасного технологічного 3. Відсутність досвіду команди у
стеку (Unity/UE5) з готовими бібліотеками. розробці комерційних PCG-продуктів.
24
Продовження таблиці 1.4
4. Ризик появи одноманітних локацій
при тривалій грі.
Можливості (Opportunities) Загрози (Threats)
1. Можливість виходу в Early Access для 1. Зміна політики комісій платформ
отримання фінансування та фідбеку. (Steam/Epic).
2. Потенціал портування на консолі завдяки 2. Вихід аналогічного продукту від
оптимізованим структурам даних. великої студії з високим
маркетинговим бюджетом.
3. Зростання популярності жанрів 3. Критичні помилки у генерації, що
Roguelike/Survival. можуть вимагати повного wipe
збережень.
Також було створено матрицю кількісної оцінки факторів SWOT (Таблиця 1.5) і
візуалізовано на рисунку 1.6
Таблиця 1.5 – Матриця кількісної оцінки факторів SWOT
Група факторів Фактор Вага Оцінка Підсумковий бал
(A) впливу (B) (AxB)
(1-10)
Strengths (Сильні Реіграбельність (PCG) 0.4 9 3.6
сторони)
Низька собівартість 0.3 8 2.4
контенту
Сучасний техно-стек 0.3 7 2.1
Сума Strengths: 8.1
Weaknesses (Слабкі Залежність від Lead 0.5 -9 -4.5
сторони) Developer
Складність QA 0.3 -8 -2.4
25
Продовження таблиці 1.5
Брак маркетингового 0.2 -6 -1.2
досвіду
Сума Weaknesses: -8.1
Opportunities Модель Early Access 0.4 8 3.2
(Можливості)
Портування на 0.3 6 1.8
консолі
Зростання жанру 0.3 7 2.1
Сума Opportunities: 7.1
Threats (Загрози) Конкуренція з 0.4 -8 -3.2
великими студіями
Зміна комісій Steam 0.2 -5 -1.0
Критичні баги 0.4 -10 -4.0
генерації
Сума Threats: -8.2
Название диаграммы
Критичні баги генерації
Конкуренція з великими …
Зростання жанру
Модель Early Access
Брак маркетингового досвіду
Залежність від Lead Developer
Сучасний техно-стек
Реіграбельність (PCG)
-15 -10 -5 0 5 10
Підсумковий бал (AxB) Оцінка впливу (B) (1-10) Вага (A)
Рисунок 1.6 – Візуалізація матриці кількісної оцінки факторів SWOT
26
1.5 Особливості управління проєктами створення ігор з процедурною
генерацією
Специфіка об'єкта управління вимагає адаптації класичних методологій.
Управління GameDev-проєктом з PCG має такі відмінні риси:
- технологічна невизначеність [50] (R&D heavy): Значна частина часу йде не на
"виробництво", а на дослідження (Research & Development). Неможливо точно
оцінити час на написання алгоритму, який "генерує красиві печери", оскільки
поняття "красиві" є суб'єктивним [14];
- дані як ресурс: Замість ручного створення об'єктів, команда створює дані та
правила для їх комбінування. Це зміщує акцент з арт-відділу на технічних
художників та програмістів;
- специфічний QA: Тестування не може покрити 100% варіантів гри (їх мільярди).
Тому управління якістю переходить від перевірки сценаріїв до перевірки
граничних значень та створення ботів-тестувальників.
Висновки до Розділу 1
У першому розділі кваліфікаційної роботи проведено комплексний аналіз
предметної області та об’єкта управління, яким є проєкт створення комп’ютерної гри з
використанням процедурної генерації вмісту (PCG). Результати дослідження
дозволяють сформулювати низку концептуальних положень, що визначають подальшу
стратегію роботи.
Таким чином, аналіз підтвердив необхідність розробки адаптованої системи
управління проєктом, яка б поєднувала гнучкість R&D-процесів з жорстким контролем
якості. Це завдання буде вирішуватися в наступних розділах через побудову специфічної
ієрархічної структури робіт (WBS), розробку матриці ризиків, орієнтованої на PCG, та
впровадження спеціалізованих метрик ефективності. Отримані аналітичні дані стануть
фундаментом для формування концепції проєкту та планування його реалізації.
27
2 РОЗРОБКА КОНЦЕПЦІЇ ПРОЄКТУ
2.1 Первинні та вторинні зацікавлені сторони, аналіз їх впливу на проєкт
Управлінський успіх проєкту визначається здатністю Менеджера проєкту
ефективно управляти зацікавленими сторонами (стейкхолдерами) [15], чиї інтереси
часто є конфліктними. У контексті Процедурної Генерації Вмісту (PCG), цей аналіз є
критичним, оскільки він допомагає спрогнозувати джерела змін і вимог до якості, що є
найбільшими ризиками для проєкту.
Первинні стейкхолдери є ядровою групою, що має прямий фінансовий або
операційний вплив на хід проєкту, і їхні очікування мають бути проактивно включені в
розроблену PM-методологію (наведено в таблиці 2.1):
- засновник/менеджер проєкту: Його ключовий інтерес — успішне впровадження
розробленої гібридної методології та дотримання початкових фінансових і
часових обмежень. Вплив є високим, оскільки він приймає остаточні рішення щодо
управління ризиками PCG та розподілу ресурсів. Управлінська стратегія повинна
забезпечити Менеджера чіткими метриками прогресу розробки алгоритмів, щоб
мінімізувати суб'єктивність;
- команда розробників (Програмісти PCG): Їхній інтерес — стабільність технічного
завдання та висока продуктивність обраного ігрового рушія. Вплив — дуже
високий, оскільки вони безпосередньо створюють PCG-модуль, і будь-які зміни у
правилах генерації вимагають значного часу на перекодування. Їхні вимоги мають
бути формалізовані в Технічному Завданні для розробки Функції Фітнесу;
- команда дизайнерів (Гейм- та Левел-дизайнери): Їхній інтерес — максимальна
гнучкість у коригуванні параметрів генерації для досягнення бажаної естетичної
та геймплейної якості. Вплив — дуже високий, оскільки вони визначають "красу"
та "грабельність" світу. Вони вимагають розробки PCG Editor Tool, що дозволяє
їм змінювати правила без втручання в код, знижуючи ризик конфлікту з
програмістами;
28
- інвестори (власники бюджету): їхній інтерес — максимізація ROI та дотримання
ключових фінансових віх. Вплив — високий через регулярний фінансовий
контроль. Їм потрібні прозорі звіти про ризики PCG та обґрунтування того, як
розроблена PM-методологія мінімізує ймовірність створення неякісного контенту;
- гравці (цільова аудиторія): їхній інтерес — феноменальна реіграбельність та
баланс кожного згенерованого світу. Вплив — дуже високий на етапі релізу та
після нього, оскільки їхні оцінки безпосередньо впливають на комерційний успіх.
Управлінська стратегія повинна включати фазу раннього доступу для збору
фідбеку від гравців щодо якості генерації, а не лише функціоналу.
Таблиця 2.1 – Первинні стейкхолдери
Стейкхолдер Ключовий Інтерес Рівень Необхідна Стратегія
Впливу Управління
Засновник / Успішне впровадження Високий Забезпечити чіткими
Менеджер гібридної PM- метриками прогресу
Проєкту методології, розробки алгоритмів для
дотримання мінімізації суб'єктивності та
фінансових та часових сприяння прийняттю
обмежень. остаточних рішень щодо
ризиків та ресурсів.
Команда Стабільність Дуже Формалізувати вимоги в
Розробників Технічного Завдання та Високий Технічному Завданні,
(Програмісти висока продуктивність особливо для розробки
PCG) обраного ігрового Функції Фітнесу (Fitness
рушія. Function), зважаючи на
високу вартість
перекодування програмного
забезпечення
29
Продовження таблиці 2.1
Команда Максимальна Дуже Розробити PCG Editor Tool,
Дизайнерів гнучкість у Високий що дозволяє їм змінювати
(Гейм- та Левел- коригуванні правила генерації без
дизайнери) параметрів генерації прямого втручання в код,
для досягнення знижуючи ризик конфлікту з
естетичної та програмістами.
геймплейної якості.
Інвестори Максимізація ROI та Високий Надавати прозорі звіти про
(Власники дотримання ключових ризики PCG та
Бюджету) фінансових віх. обґрунтування того, як
розроблена PM-методологія
мінімізує ймовірність
створення неякісного
контенту.
Гравці (Цільова Феноменальна Дуже Включити фазу Раннього
Аудиторія) реіграбельність та Високий Доступу для збору фідбеку
баланс кожного (на етапі щодо якості генерації (а не
згенерованого світу. релізу та лише функціоналу), що
після безпосередньо впливає на
нього) комерційний успіх.
Вторинні стейкхолдери мають опосередкований вплив, але можуть впливати на
зовнішнє середовище проєкту, що вимагає постійного моніторингу (Таблиця 2.2):
- постачальники технологій (Unity/Unreal Engine): Їхній інтерес — популяризація
їхніх рушіїв. Вплив — середній. Вони можуть опосередковано впливати на проєкт
через оновлення рушія, які можуть вимагати перекомпіляції або переробки PCG-
модуля, що становить технічний ризик;
30
- конкуренти (Інші студії PCG-ігор): Їхній інтерес — моніторинг ринкової ніші.
Вплив — непрямий, але їхні дії можуть впливати на маркетингову стратегію та
очікування гравців. Якщо конкурент випустить якісний PCG-продукт раніше, це
може знизити попит на гру, що вимагає акцентування на унікальності нашої PCG-
системи;
- спільнота GameDev та медіа: Їхній інтерес — новини та інноваційні технології.
Вплив — середній. Позитивне чи негативне висвітлення у медіа може суттєво
вплинути на сприйняття продукту. В управлінні це вимагає чіткого плану
комунікації, який пояснює, як саме ми керуємо ризиками PCG.
Таблиця 2.2 – Вторинні стейкхолдери
Стейкхолдер Ключовий Інтерес Рівень Впливу Необхідна Стратегія
Управління / Моніторингу
Постачальники Популяризація та Середній Постійний моніторинг
Технологій розширення (Технічний оновлень рушія та їхнього
(Unity/Unreal використання їхніх Ризик) впливу на PCG-модуль.
Engine) ігрових рушіїв. Врахування ризику
перекомпіляції або
переробки коду через
технічні зміни рушія.
Конкуренти Моніторинг Непрямий Активне відстеження ринку та
(Інші студії PCG- ринкової ніші, (Ринковий конкурентних релізів.
Акцентування на унікальності
ігор) успіх власних Ризик)
та інноваційності нашої PCG-
продуктів.
системи у маркетинговій
стратегії, щоб мінімізувати
вплив від раннього випуску
якісного продукту
конкурентом.
31
Продовження таблиці 2.2
Спільнота Отримання новин Середній Розробка чіткого Плану
GameDev та та висвітлення (Репутаційний Комунікації та PR-стратегії.
Медіа інноваційних Ризик) Пояснення громадськості,
технологій ігрової як команда керує ризиками
індустрії. PCG (наприклад, неякісним
контентом), щоб
забезпечити позитивне
сприйняття продукту.
Для візуалізації та стратегічного планування взаємодії використовується Матриця
Вплив-Інтерес [16]. На основі цього аналізу розробляються конкретні стратегії:
- високий вплив / високий інтерес (Засновник, Інвестори, Команда): Стратегія
"Тісне управління (Manage Closely)". Вимагає щотижневих звітів та щоденної
взаємодії. Для Інвесторів це означає надання кількісних метрик якості генерації.
Для Команди — забезпечення інструментарієм (PCG Editor Tool);
- високий вплив / низький інтерес (Платформи): Стратегія "Задоволення потреб
(Keep Satisfied)". Вимагає дотримання всіх юридичних та технічних вимог
платформ дистрибуції;
- низький вплив / високий інтерес (Гравці/Спільнота): Стратегія "Постійне
інформування (Keep Informed)". Вимагає постійного збору фідбеку, особливо на
етапі Альфа/Бета-тестування, що критично важливо для валідації якості PCG;
- низький вплив / низький інтерес (Постачальники): Стратегія "Моніторинг
(Monitor)". Вимагає лише відстеження оновлень та загроз.
Ефективне управління стейкхолдерами у проєкті з PCG означає трансформацію
креативних вимог дизайнерів та очікувань гравців на формалізовані вхідні параметри та
функцію фітнесу для алгоритму, що є центральною управлінською задачею.
32
2.2 Цілі організації розробки та місія проєкту
Місія розроблюваного продукту полягає у створенні безпрецедентного за
масштабом, унікального та захоплюючого ігрового досвіду в жанрі Survival-RPG, який
долає обмеження традиційного ручного дизайну. Ми прагнемо надати гравцям
нескінченну кількість невідомих світів для дослідження, використовуючи передові
алгоритми процедурної генерації, керовані інноваційною управлінською методологією,
що гарантує стабільну якість ігрового середовища та високу реіграбельність. Ця місія
підкреслює подвійний фокус стартапу: як на креативному продукті, так і на
методологічному новаторстві в управлінні.
Візія (Найвищий рівень, 5-10 років): Стати визнаним лідером інді-сегменту у світі
комп'ютерних ігор, спеціалізуючись на розробці високореіграбельних Survival-RPG ігор
з PCG, та створити універсальну PM-платформу для управління подібними проєктами,
яку можна буде ліцензувати.
Стратегічні цілі (Середній рівень, 3 роки): Цілі, що стосуються позиціонування та
стійкості бізнесу, які включають:
- фінансова стійкість: Забезпечення чистого прибутку на рівні 250% від початкових
інвестицій протягом перших 18 місяців після релізу, що доводить життєздатність
бізнес-моделі PCG;
- ринкове визнання: досягнення показника > 85% позитивних відгуків на ключових
платформах, що критично підтверджує високу якість згенерованого контенту;
- технологічне лідерство: розробка власного PCG Toolset, який буде визнаний
галуззю як ефективний інструмент для швидкого прототипування процедурних
світів;
- розширення IP: розробка концепції для другого PCG-проєкту, використовуючи
набуті методологічні знання.
Операційні цілі (Проєктний рівень, 1 рік): Безпосередня реалізація та підтримка
проєкту, які включають:
33
- розробка PCG-модуля: Завершення розробки ядра генератора до [Дата X], що
забезпечує генерацію світу площею 100 км² за час, не довший за 30 секунд;
- впровадження PM-системи: Повна інтеграція гібридної PM-методології,
забезпечуючи зниження кількості критичних багів у згенерованому контенті на
40% порівняно з пілотними тестами, що буде підтверджено системою
автоматичного QA;
- продуктова готовність: Виконання всіх вимог до функціоналу, необхідних для
переходу у фазу бета-тестування;
- оптимізація ресурсів: Дотримання показника використання ресурсів
(запланований час / фактичний час) з відхиленням не більше ±10%.
Кожна стратегічна ціль організації має пряме відображення в методах управління
проєктом. Наприклад, ціль "Ринкове визнання" вимагає від Менеджера проєкту
пріоритезувати Спринти якості та розробку Функції Фітнесу над простим додаванням
нового функціоналу. Таким чином, дерево цілей не лише визначає що робити, але й як
управляти. Управлінська модель, розроблена в цій роботі, є прямим інструментом
досягнення операційних цілей, оскільки вона формалізує контроль над найбільш
ризикованим елементом — генератором.
Ключові показники успіху (KPI), що випливають з дерева цілей і
використовуються для моніторингу прогресу, включають:
- відсоток прохідності згенерованих рівнів;
- середній час генерації світу;
- відхилення фактичних витрат від бюджетних показників.
2.3. Цілі, очікувані результати та структура продукту проєкту
Цей підрозділ формалізує кінцевий результат проєкту, переводячи стратегічну
місію в конкретні, вимірювані цілі та деталізуючи всі компоненти, які мають бути
створені. Чітке визначення цих елементів є основою для подальшої розробки плану робіт
(WBS) та управління якістю PCG.
34
Головна ціль проєкту — успішний комерційний реліз інноваційної комп'ютерної
гри, розробленої з використанням гібридної PM-методології, що забезпечує
феноменальну реіграбельність та стабільну якість згенерованого контенту. Для
забезпечення контрольованості та вимірюваності, ця ціль декомпозується на наступні
ключові, вимірювані (SMART) цілі:
- ціль PCG та якості (Specific, Measurable): Розробити та інтегрувати PCG-модуль,
здатний генерувати унікальні ігрові світи (включаючи ландшафти та підземелля),
де відсоток неграбельних згенерованих зон не перевищує 2% від загальної площі,
що буде підтверджено автоматизованою Функцією Фітнесу до завершення фази
Бета-тестування. Цей поріг у 2% встановлює критичний стандарт якості для
випадковості;
- ціль технологічна (Achievable, Relevant): Створити PCG Editor Tool —
користувацький інтерфейс, який дозволяє гейм-дизайнерам змінювати вхідні
параметри генерації та перевіряти вплив змін на якість протягом 5 хвилин після
внесення правок, що значно підвищує ефективність ітераційного дизайну;
- ціль управлінська (Time-bound): Повністю впровадити та протестувати
розроблену Адаптовану Scrum-Hybride методологію, яка дозволяє скоротити час
на ітерацію QA-PCG циклу на 20% порівняно з базовою моделлю, що буде
зафіксовано у звіті про ефективність PM-системи наприкінці фази Продакшн;
- ціль релізна (Relevant): Випустити гру у стані Beta-релізу до [Дата Z],
забезпечивши повну функціональність ключових систем та відповідність вимогам
платформ дистрибуції.
Структура продукту деталізує всі елементи та підсистеми, які необхідно створити.
У проєкті PBS акцентує увагу на модульності PCG-системи, що критично важливо для
подальшого паралельного управління розробкою.
Ігровий Рушій та Базовий Функціонал: Цей блок включає стабільне ядро гри,
систему рендерингу, що оптимізована для відображення великих процедурних світів,
фізичний модуль, що коректно обробляє колізії згенерованих об'єктів, та базовий
35
інтерфейс користувача.
Процедурна Генерація Вмісту (PCG): Це центральний, найбільш складний блок,
який потребує найбільшої уваги з точки зору управління ризиками. Він складається з:
- ядро Генератора топографії: модулі шуму перліна та генерації біомів [18],
відповідальні за великомасштабні ландшафти;
- генератор структур та збалансованості: модулі клітинних автоматів та WFC[19]
для створення підземель, печер та штучних споруд, а також алгоритми, що
забезпечують логічне розміщення ресурсів та точок інтересу (POI);
- генератор екосистеми: модулі модульної PCG для створення унікальної фауни та
флори шляхом комбінування базових ассетів;
- PCG Editor Tool: Користувацький інтерфейс, що дозволяє дизайнерам
контролювати вхідні Правила Генерації (Grammars).
Ігровий Контент та Правила: Включає всі 3D-моделі, текстури, звуки, музику, а
також Набори Правил Генерації (правила, граматики, шаблони), які є вхідними даними
для PCG. Важливо, що в цьому проєкті Правила є продуктом, який розробляється та
тестується, а не просто контентом.
Управлінські та QA-системи: Це Методологічна частина продукту, що включає
розроблену PM-методологію, Функцію Фітнесу (програмний модуль автоматичної
оцінки якості) та систему автоматичного логування помилок генерації.
Очікувані результати є кількісним вираженням досягнення цілей і мають бути
валідовані на ключових віхах проєкту. Усі результати мають демонструвати, що
застосування PCG та адаптованої методології є ефективним.
- методологічний результат: Розроблена та протестована Адаптована Scrum-Hybride
методологія, яка демонструє підвищення ефективності управління ризиками PCG
і формалізована у вигляді внутрішнього стандарту. Валідація відбувається через
порівняльний аналіз швидкості ітерацій QA-PCG у тестових групах;
- програмний результат: Фінальна версія гри, готова до комерційного
розповсюдження, та повністю функціональний PCG Editor Tool. Валідація
36
відбувається через приймальне тестування (UAT) та тестування продуктивності;
- якісний результат: Звіт про автоматизоване тестування, що підтверджує, що PCG-
модуль відповідає вимогам якості, зокрема 98% згенерованих рівнів є прохідними,
і всі ключові біоми згенеровані. Валідація здійснюється виключно функцією
фітнесу;
- комерційний результат: Продаж не менше 100 000 копій гри протягом перших 6
місяців, що забезпечує повернення інвестицій. Валідація відбувається через аналіз
продажів та ринкового фідбеку.
2.4 Життєвий цикл проєкту (стартапу), перелік ключових віх
Ефективне управління часом та ресурсами у проєкті вимагає чітко визначеного
життєвого циклу, адаптованого до унікальних вимог процедурної генерації. Життєвий
цикл тут є гібридним, оскільки він поєднує послідовну структуру управління (для
контролю фінансів та загального планування) та ітераційний підхід (для розробки та
валідації PCG-алгоритмів).
Вибір гібридної моделі [20] є критично важливим, оскільки чисто ітераційний
підхід (наприклад, чистий Scrum) може призвести до нескінченної розробки PCG-правил
через прагнення дизайнерів до постійного покращення, а послідовний підхід (Waterfall)
не дозволить швидко реагувати на збої генератора на ранніх стадіях. Гібридний цикл
забезпечує:
- чіткі рамки: Послідовні фази Ініціації та Планування фіксують бюджет та вимоги
до PCG-модуля;
- гнучкість у ядрі: Фаза Виконання є циклом коротких спринтів, що дозволяють
швидко тестувати та коригувати алгоритми генерації.
Ключові фази життєвого циклу:
- фаза ініціації (1 місяць): Мета — офіційне визначення та авторизація проєкту.
Складається з розробки Статуту Проєкту (Project Charter) [21], визначення обсягу,
стратегії фінансування та затвердження ключових стейкхолдерів. Ключовий вихід
37
цієї фази — Документ концепції PCG, що фіксує початкові технічні вимоги до
генератора;
- фаза планування (1 місяць): Мета — деталізація робіт та створення PM-плану.
Включає деталізацію WBS (структури робіт), формування PBS (структури
продукту), визначення ключових метрик QA для PCG, планування ресурсів та
ризиків. На цьому етапі розробляється План управління ризиками PCG, що є
найважливішим документом управління;
- фаза виконання (Продакшн, 8 місяців): Це основна фаза, реалізована через серію
ітераційних спринтів (Agile-цикл) [22]. Розробка ігрового функціоналу та
паралельна, ітераційна розробка PCG-модуля та правил генерації відбуваються
одночасно. Кожен спринт завершується автоматизованим QA-тестом
згенерованого контенту, а результати тестування (наприклад, низький показник
Fitness Function) використовуються для корекції наступного спринту;
- фаза тестування (Альфа/Бета, 2 місяці): Мета — валідація стабільності та якості.
Включає широке тестування, фокусування на балансі та унікальності
згенерованих світів, а також контрольне тестування функції фітнесу;
- фаза завершення (1 місяць): Мета — офіційна передача продукту та закриття
проєкту. Включає фінальне полірування, підготовку до релізу, публікацію, а також
створення Фінального Звіту, що містить аналіз ефективності впровадженої PM-
методології.
У фазі Виконання кожен спринт (тривалістю 2-3 тижні) включає унікальний для
PCG-проєктів цикл, що інтегрує дизайн та програмування:
- Дизайн Правил: Гейм-дизайнери створюють нові або коригують наявні Правила
Генерації (граматики, шаблони) за допомогою PCG Editor Tool;
- Кодування: Програмісти адаптують ядро PCG-модуля або створюють нові
алгоритми для підтримки нових правил;
- Автоматизований QA: Після генерації контенту відбувається автоматична
перевірка за допомогою [23] Функції Фітнесу. Ця функція перевіряє, чи відповідає
38
згенерований світ вимогам (прохідність, збалансованість, відсутність артефактів);
- Зворотний Зв'язок: Низький показник Фітнесу слугує технічним боргом, який
негайно додається до backlog наступного спринту, забезпечуючи швидку реакцію
на недосконалість алгоритмів;
- Цей ітераційний цикл дозволяє постійно контролювати випадковість,
перетворюючи невизначеність на керований ризик.
Ключові віхи слугують контрольними точками для Менеджера та Інвесторів,
підтверджуючи прогрес, особливо у найризикованішій частині — PCG. Вони є
вимірними та мають чіткі дати завершення.
Перелік ключових віх проєкту, що забезпечують контрольований рух до релізу:
- МВ 1.1: Схвалення PM-методології: Фінальне затвердження та документація
Адаптованої Scrum-Hybride моделі, включаючи План управління ризиками PCG;
- МВ 2.1: Завершення розробки PCG-ядра: Алгоритми шуму Перліна та WFC є
робочими, здатними генерувати базовий світ та пройшли юніт-тести;
- МВ 3.1: PCG Editor Tool V1.0 (MVP): Інтерфейс для зміни правил генерації
готовий до використання дизайнерами, що дозволяє швидко змінювати
параметри;
- МВ 4.1: Створення функції фітнесу: Програмний модуль автоматичної оцінки
якості згенерованого контенту повністю інтегрований у QA-процес та працює
автономно;
- МВ 5.1: Альфа-версія гри (Feature Complete): Увесь основний функціонал та PCG-
модуль інтегровані, грабельний світ генерується;
- МВ 6.1: Збалансований світ: PCG-модуль пройшов фінальну перевірку функцією
фітнесу, відсоток неграбельного контенту < 2% (Критичний інженерний
майлстоун);
- МВ 7.1: Фінальний реліз: Гра опублікована на обраній платформі дистрибуції.
39
Висновки до Розділу 2
У Розділі 2 кваліфікаційної роботи було розроблено концептуальну основу та
управлінську архітектуру для проєкту створення комп’ютерної гри з процедурною
генерацією вмісту (PCG), що є необхідною передумовою для подальшого детального
планування та успішної реалізації. Ключовим завданням етапу стала адаптація
класичних принципів управління проєктами до специфіки високотехнологічного
продукту, де домінує невизначеність, пов'язана з алгоритмічною генерацією.
Таким чином, у другому розділі обґрунтовано концептуальне рішення, яке чітко
відповідає унікальним технологічним викликам PCG-розробки. Розроблена концепція є
основою для детального планування, що буде здійснено у наступному розділі, та
дозволяє мінімізувати ризики, пов'язані з невизначеністю процедурної генерації,
шляхом впровадження формалізованих критеріїв якості та адаптованої гібридної PM-
методології.
40
3 ПЛАНУВАННЯ ПРОЄКТУ ТА РОЗРОБКА PM-ІНСТРУМЕНТАРІЮ
На основі результатів системного аналізу, який виявив високу технологічну
невизначеність, характерну для проєктів із Процедурною Генерацією Вмісту (PCG), а
також ґрунтуючись на визначеній концепції та життєвому циклі Scrum-Hybride, даний
розділ присвячений детальному плануванню та розробці адаптованого інструментарію
управління.
Ключовим викликом, ідентифікованим в аналітичній частині роботи, є
необхідність перевести стохастичні (випадкові) результати роботи алгоритмів у
прогнозовані та керовані показники. Відповідно, метою цього розділу є не просто
створення класичного планування (графік, бюджет), а інтеграція специфічних PM-
механізмів, які забезпечують:
- контроль обсягу (scope control): запобігання нескінченному додаванню нових
правил генерації, що призводить до розповзання обсягу проєкту;
- управління якістю (quality management): об'єктивізацію оцінки згенерованого
контенту шляхом переходу від суб'єктивного сприйняття до автоматизованих
метрик.
Для досягнення цієї мети планування реалізується через розробку чотирьох
ключових груп артефактів:
- планування обсягу (wbs, obs, raci): формалізація структури робіт та розподіл
відповідальності з урахуванням специфічних ролей, таких як pcg engineer та
technical artist;
- управління часом та вартістю: формування календарного плану з включенням
буферів на r&d-задачі та розрахунком витрат на персонал і технічну
інфраструктуру;
- управління ризиками: ідентифікація та розробка стратегій реагування на
специфічні pcg-ризики, зокрема «ризик одноманітності» та «непрохідність рівня»;
- розробка pm-інструментарію: впровадження механізмів, що знижують
41
невизначеність, таких як розширений definition of done (dod) та функція фітнесу
(fitness function) [38].
Таким чином, наступні підрозділи демонструють, як аналітичні висновки
перетворюються на практичні управлінські рішення.
3.1 Управління змістом проєкту
Управління змістом проєкту є фундаментальною функцією менеджменту, яка
забезпечує, що проєкт включає всю необхідну роботу для успішного завершення
продукту та виключає будь-яку зайву роботу, що призводить до неконтрольованого
розширення (Scope Creep). У контексті проєкту створення комп’ютерної гри з
процедурною генерацією вмісту (PCG), управління змістом є критично важливим для
збереження фокусу команди в умовах ітераційного дизайну та мінімізації ризиків,
пов'язаних із технологічною невизначеністю.
Процес управління змістом у даному проєкті відповідає стандартам PMBOK [24]
та включає: збір вимог, визначення змісту, створення Структури Декомпозиції Робіт
(WBS) [25] та контроль змісту. Успішне управління змістом гарантується створенням
Базового Плану Змісту (Scope Baseline), що складається з Положення про Зміст Проєкту,
WBS та Словника WBS.
Декомпозиція Робіт Проєкту. Одним із ключових інструментів, який забезпечує
комплексну візуалізацію змісту проєкту та створює основу для ефективного контролю,
планування й координації робіт, є Структура Декомпозиції Робіт. Цей інструмент являє
собою впорядковану ієрархічну модель, у межах якої загальний обсяг робіт системно
розбивається на менші, чітко визначені й керовані компоненти — так звані робочі
пакети. Такий підхід дозволяє не лише структурувати всі елементи проєкту, але й
забезпечити їхню прозорість, вимірюваність і узгодженість між собою, що є особливо
важливим для складних інноваційних проєктів у сфері розробки програмного
забезпечення.
WBS для даного проєкту побудована відповідно до гібридного життєвого циклу,
42
який поєднує послідовне традиційне управління у фазах планування та ініціалізації з
ітераційним, адаптивним підходом на етапах виконання. Така комбінація дає змогу
гнучко реагувати на зміни та уточнення вимог, водночас зберігаючи чітку
структурованість і контроль над основними процесами. Структуру деталізовано до трьох
рівнів, що дозволяє досягти оптимального балансу між глибиною розробки плану та
керованістю окремих елементів, не перевантажуючи модель надмірними дрібними
елементами.
Рисунок 3.1 – WBS проєкту (ініціалізація проєкту)
Рисунок 3.2 – WBS проєкту (створення програмного продукту)
43
Рисунок 3.3 – WBS проєкту (програмне тестування)
Рисунок 3.4 – WBS проєкту (завершення проєкту)
Вимоги до Проєкту. Для ефективного управління змістом проєкту вимоги
розділені на два ключові типи: деталізовані функціональні та високорівневі (бізнес-
орієнтовані).
Функціональні Вимоги Системи. Функціональні вимоги (ФВ) деталізують
безпосередню поведінку, функції та дії, які має виконувати система, щоб задовольнити
44
потреби різних категорій користувачів. Вони слугують прямим технічним завданням для
команди розробників і є обов'язковими для реалізації.
У Таблиці 3.1 представлено перелік ключових функціональних вимог системи.
Вона відображає основні Функціональні Вимоги (ФВ), які необхідно реалізувати в
процесі створення PCG-гри. Вимоги структуровані за кодом, описом та прив'язкою до
Типу Користувача (Ролі): Гравець (Г), Гейм-дизайнер (ГД), Програміст/Технічний Лід
(П/ТЛ) та QA-інженер (QA). Така класифікація дозволяє чітко зрозуміти, хто є
споживачем конкретної функції, і забезпечує, що розробка функціоналу, як-от PCG
Editor Tool (ФВ-02) чи Fitness Function (ФВ-04), відповідає потребам відповідної ролі.
Таблиця 3.1 – Функціональні вимоги системи
Код та Опис Опис функціональної вимоги Тип користувача (роль)
Функції
ФВ-01. Система повинна генерувати унікальний Гравець (Г)
Генерація ігровий рівень (карту/локацію) при
унікального кожному новому запуску гри або початку
рівня нової сесії.
ФВ-02. Система має надавати Гейм-дизайнеру Гейм-дизайнер (ГД)
Інтерфейс PCG Editor Tool з графічним інтерфейсом
налаштування для налаштування параметрів (наприклад,
PCG щільності ресурсів, розміру карти,
кількості ворогів, складності).
ФВ-03. PCG Editor Tool повинен відображати Гейм-дизайнер (ГД)
Візуалізація візуалізацію згенерованого
генерації рівня/фрагменту в режимі попереднього
перегляду протягом не більше 5 секунд
після зміни параметрів генератора світу
комп’ютерної гри
45
Продовження таблиці 3.1
ФВ-04. Основний алгоритм генерації має Програміст/Технічний
Автоматичний використовувати Функцію Фітнесу Лід (П/ТЛ)
відбір за якістю (Fitness Function) для автоматичного
відбору згенерованих варіацій, які
відповідають критеріям прохідності та
балансу.
ФВ-05. Система повинна забезпечувати безшовну Програміст/Технічний
Інтеграція PCG з інтеграцію згенерованого контенту з Лід (П/ТЛ)
рушієм базовим ігровим рушієм та механіками.
ФВ-06. Система має автоматично реєструвати та Гравець (Г), QA-
Збереження зберігати сид (seed) згенерованого рівня інженер (QA)
сиду рівня для можливості його повторного
відтворення.
ФВ-07. Система повинна запобігати генерації Програміст/Технічний
Запобігання "неграбельних" зон (наприклад, повністю Лід (П/ТЛ)
неграбельним заблоковані шляхи, ресурси поза
зонам досяжністю) і відхиляти такі результати
до їх передачі в ігровий процес.
ФВ-08. Звітність Система повинна генерувати звіт про QA-інженер (QA)
QA-валідації валідацію для кожного рівня, створеного в
процесі тестування, який містить
результат перевірки Fitness Function.
ФВ-09. Гравець повинен мати можливість Гравець (Г)
Збереження зберігати прогрес гри на будь-якому
прогресу гравця згенерованому рівні та відновлювати його
пізніше.
46
Продовження таблиці 3.1
ФВ-10. Система має підтримувати динамічне Програміст/Технічний
Оптимізація завантаження/вивантаження згенерованих Лід (П/ТЛ)
завантаження фрагментів світу для оптимізації
світу продуктивності.
ФВ-11. Експорт PCG Editor Tool має дозволяти Гейм-дизайнер (ГД)
правил генерації експортувати набори правил генерації у
форматований файл для резервного
копіювання та обміну.
ФВ-12. Система повинна надавати Програмісту Програміст/Технічний
Розширення API або інтерфейс для додавання нових Лід (П/ТЛ)
бази об'єктів типів ігрових об'єктів (наприклад, нові
вороги, ресурси) до бази даних генератора
без зміни основного коду генерації.
Таблиця 3.2 містить розгорнуту та повністю структуровану Структуру
Декомпозиції Робіт (Work Breakdown Structure — WBS) для даного проєкту, яка охоплює
всі чотири основні фази його життєвого циклу. Представлена декомпозиція розроблена
з урахуванням логічної послідовності виконання робіт, специфіки гібридного підходу до
управління та необхідності забезпечення прозорості й керованості кожного етапу.
Роботи деталізовано до третього рівня ієрархії, що дозволяє чітко ідентифікувати Пакети
Робіт (Work Packages) — елементи, які є найменшими, але водночас повністю
самодостатніми компонентами структури, що підлягають оперативному управлінню,
точному плануванню, оцінці трудозатрат та подальшому контролю виконання. У
таблиці для кожного елемента рівня 3 наведено орієнтовну тривалість виконання (у
календарних днях), що забезпечує можливість попередньої оцінки загального обсягу
робіт та розподілу ресурсів, а також визначено відповідальну роль у команді, яка буде
безпосередньо залучена до реалізації відповідного завдання.
47
Таблиця 3.2 – Декомпозиція робіт проекту
Рівень 1 Рівень Рівень Найменування задачі Оцінка Відповідальний
2 3 часу (Роль)
(днів)
1 Ініціалізація та Планування 35 Менеджер
(Управління Проєктом) Проєкту
1.1 Ініціація Проєкту 10 Менеджер
Проєкту
1.1.1 Розробка Статуту Проєкту 3 Менеджер
(Project Charter). Проєкту
1.1.2 Формування ключової 2 Менеджер
команди та ролей. Проєкту,
Засновник
1.1.3 Створення реєстру 1 Менеджер
ключових стейкхолдерів. Проєкту
1.1.4 Оцінка початкового 4 Менеджер
бюджету та термінів. Проєкту,
Фінансист
1.2 Збір та Аналіз Вимог 10 Гейм-дизайнер,
Менеджер
Проєкту
1.2.1 Збір високорівневих бізнес- 2 Менеджер
вимог. Проєкту,
Засновник
1.2.2 Формалізація 4 Гейм-дизайнер,
Функціональних та Технічний Лід
Нефункціональних вимог.
48
Продовження таблиці 3.2
1.2.3 Визначення Критеріїв 4 Гейм-дизайнер,
Прийняття PCG-продукту. Технічний Лід
1.3 Детальне Планування 10 Менеджер
Змісту та Ресурсів Проєкту
1.3.1 Розробка детальної 3 Менеджер
Структури Декомпозиції Проєкту
Робіт (WBS).
1.3.2 Розробка Базового Плану 3 Менеджер
Змісту (Scope Baseline). Проєкту
1.3.3 Формування матриці 4 Менеджер
відповідальності (RAM). Проєкту
1.4 Планування Ризиків та 5 Менеджер
Комунікацій Проєкту
1.4.1 Створення Реєстру Ризиків 3 Менеджер
(PCG, фінанси, команда). Проєкту,
Технічний Лід
1.4.2 Розробка Плану 1 Менеджер
Комунікацій. Проєкту
1.4.3 Визначення Процедури 1 Менеджер
Контролю Змін (CCB). Проєкту
2 Продакшн (Виконання) / 160 Технічний Лід
Створення Програмного
Продукту
2.1 Розробка Базової 20 Технічний Лід
Архітектури програмного
забезпечення
49
Продовження таблиці 3.2
2.1.1 Налаштування середовища 5 Програміст
розробки (двигун,
версіонування).
2.1.2 Розробка модульної 7 Технічний Лід
архітектури інтеграції PCG.
2.1.3 Створення базового 5 Програміст
прототипу ігрового світу.
2.1.4 Інтеграція базових 3 Програміст
бібліотек/API.
2.2 Розробка Ядра Процедурної 60 Програміст
Генерації (PCG Core)
2.2.1 Кодування ключових 20 Програміст
алгоритмів генерації
(наприклад, WFC).
2.2.2 Створення системи 15 Гейм-дизайнер,
управління наборами даних Програміст
(Data Sets).
2.2.3 Реалізація механізмів 15 Програміст
рандомізації та унікальності.
2.2.4 Створення внутрішнього 10 Технічний Лід
API для доступу до
генератора.
2.3 Розробка Інструментарію 30 Програміст,
(PCG Editor Tool) Гейм-дизайнер
2.3.1 Дизайн та реалізація 10 Дизайнер,
графічного інтерфейсу Програміст
50
Продовження таблиці 3.2
2.3.2 Розробка функціоналу для 10 Програміст
швидкої ітерації параметрів.
2.3.3 Інтеграція функції 5 Програміст
візуалізації та симуляції
генерації.
2.3.4 Навчання гейм-дизайнерів 5 Технічний Лід
роботі з інструментом.
2.4 Розробка Системи Оцінки 50 Технічний Лід,
Якості (Fitness Function) QA-інженер
2.4.1 Кодування метрик 15 Програміст
прохідності
(Reachability/Pathfinding).
2.4.2 Впровадження метрик 15 Програміст,
балансу ресурсів та Гейм-дизайнер
складності.
2.4.3 Розробка автоматизованого 10 QA-інженер
звітування QA.
2.4.4 Валідація Функції Фітнесу 10 QA-інженер
на тестових наборах даних.
3 Тестування та Валідація 45 QA-інженер
(Програмне Тестування)
3.1 Внутрішнє Тестування 15 QA-інженер,
(Alpha) Програміст
3.1.1 Проведення модульних 5 Програміст
тестів (Unit Tests) PCG Core.
3.1.2 Інтеграційне тестування. 5 QA-інженер
51
Продовження таблиці 3.2
3.1.3 Верифікація роботи Fitness 3 QA-інженер
Function (коректність
оцінки).
3.1.4 Фіксація критичних багів та 2 Програміст
звіт про стабільність.
3.2 Зовнішнє Тестування (Beta) 20 QA-інженер,
Гейм-дизайнер
3.2.1 Набір фокус-групи для бета- 5 Менеджер
тестування. Проєкту
3.2.2 Збір відгуків про ігровий 5 Гейм-дизайнер
досвід.
3.2.3 Аналіз логів і показників 5 QA-інженер
продуктивності.
3.2.4 Фіксація та пріоритезація 5 Програміст
багів (Bug Fixing).
3.3 Валідація Критеріїв 10 Менеджер
Прийняття Проєкту,
Технічний Лід
3.3.1 Проведення фінального 4 QA-інженер
прогону Fitness Function.
3.3.2 Підготовка QA-звіту. 3 QA-інженер
3.3.3 Перевірка відповідності 3 Менеджер
високорівневим вимогам. Проєкту
4 Завершення Проєкту 10 Менеджер
Проєкту
4.1 Фіналізація Продукту 5 Технічний Лід
52
Продовження таблиці 3.2
4.1.1 Фінальне полірування та 2 Програміст
оптимізація коду.
4.1.2 Створення фінального білду 1 Програміст
(Master Build).
4.1.3 Підготовка супровідної 2 Технічний Лід,
документації. Гейм-дизайнер
4.2 Оцінка та Передача 3 Менеджер
Проєкту
4.2.1 Проведення фінальної 1 Менеджер
зустрічі з Проєкту
Інвестором/Замовником.
4.2.2 Передача всіх активів та 1 Менеджер
документації. Проєкту
4.2.3 Проведення фінансового 1 Менеджер
аудиту. Проєкту
4.3 Оцінка Ефективності 2 Менеджер
Проєкту
4.3.1 Збір уроків (Lessons 1 Менеджер
Learned). Проєкту
4.3.2 Оцінка ефективності 1 Менеджер
впровадженої методології. Проєкту
ВСЬОГО: 250
Таблиця 3.3 фіксує ключові бізнес-орієнтовані та якісні цілі проєкту. Ці вимоги,
такі як Фінансова успішність (№1) та Якість процедурної генерації (№3), є критичними
для стратегічного успіху стартапу. Наявність формалізованих Критеріїв Прийняття
(наприклад, ROI не менше 250% або <2% неграбельних зон) забезпечує об'єктивний
53
механізм оцінки фінального продукту. Ця таблиця слугує основним документом для
контролю за досягненням цілей, визначених у Розділі 2, та для підтвердження успішного
завершення проєкту.
Таблиця 3.3 – Високорівневі вимоги до кінцевого результату проєкту (теж хоча б 10,
колонки: №, Назва вимоги, Опис, Критерій прийняття)
№ Назва вимоги Опис Критерій прийняття
1 Фінансова Проєкт повинен Досягнення показника ROI
успішність продемонструвати високий (Return on Investment) не менше
потенціал повернення 250% протягом 18 місяців після
інвестицій для інвесторів релізу.
протягом перших 18 місяців
після комерційного
запуску.
2 Комерційна Фінальний продукт має Пройдено внутрішнє QA,
готовність бути повноцінною, отримано фінальний Master
продукту стабільною, комерційно Build, який відповідає технічним
готовою версією гри, вимогам дистриб'юторів
готовою до публікації на (наприклад, Steam).
основних платформах
дистрибуції.
3 Якість Згенерований ігровий вміст Відсоток неграбельних
процедурної має бути високої якості, (непрохідних, заблокованих,
генерації (PCG) щоб забезпечити критично незбалансованих)
унікальний і збалансований згенерованих зон не повинен
ігровий досвід. перевищувати 2%, підтверджено
фінальним звітом Fitness
Function.
54
Продовження таблиці 3.3
4 Висока оцінка Продукт повинен отримати Середня оцінка
користувачів позитивне сприйняття користувачів/критиків
серед цільової аудиторії, (наприклад, Metacritic, Steam
підтверджуючи успішність Reviews) має бути не нижче 85%
ігрового дизайну. позитивних відгуків протягом
перших трьох місяців.
5 Надійність та Система PCG та ігровий Кількість критичних збоїв
відсутність збоїв рушій повинні працювати (Crash/Bug) не має перевищувати
стабільно під 1 на 100 годин сумарного
навантаженням. ігрового часу, зафіксованого під
час Beta-тестування.
6 Технологічна Розроблено та повністю Повністю функціональний та
унікальність інтегровано власний задокументований PCG Editor
(ToolSet) інструментарій для Tool використовується гейм-
управління генерацією. дизайнерами та відповідає вимозі
ФВ-03 (швидкість візуалізації < 5
секунд).
7 Прозорість Створено та протестовано Проведена фінальна оцінка
розробки внутрішній стандарт ефективності Адаптованої Scrum-
управління проєктами, Hybride Методології (Lessons Learned),
(Методологія)
підтверджено скорочення QA-PCG
адаптований до PCG-
циклу (заплановано на 20%).
розробки.
8 Належна Усі ключові технічні Підготовлено повний комплект
документація рішення, архітектура коду внутрішньої документації: Технічний
дизайн (Tech Design) PCG-системи та
та правила генерації мають
Гейм-дизайн документ (GDD) з
бути задокументовані для
фінальними правилами генерації.
подальшого розвитку.
55
Продовження таблиці 3.3
9 Оптимізація Гра має працювати плавно Мінімальний показник FPS
продуктивності на цільових апаратних (кадрів на секунду) має бути не
конфігураціях, незважаючи нижче 30 на цільовій апаратній
на складність генерації. конфігурації у найбільш
насичених згенерованих зонах.
10 Повторне Створена PCG-система має Ядро PCG (PCG Core Module) має
використання бути модульною та легко бути реалізовано як окрема
коду (IP) інтегруватися в майбутні бібліотека/плагін, що дозволяє
проєкти компанії. 90% повторного використання
коду.
3.2 Організаційна структура проєкту
Організаційна структура проєкту визначає ієрархію, відносини підпорядкування
та функціональні обов'язки членів команди, необхідні для ефективного досягнення цілей
проєкту. Враховуючи інноваційний та вузькоспеціалізований характер проєкту
створення гри з процедурною генерацією вмісту (PCG), було обрано Проєктну
організаційну структуру (Projectized Organization) [27].
Обґрунтування вибору структури. Проєктна структура є оптимальною для
стартапів, що працюють над унікальними продуктами, оскільки вона забезпечує:
- високу автономність та фокус: уся команда підпорядковується безпосередньо
менеджеру проєкту (pm) та працює виключно над цим проєктом, що запобігає
розсіюванню ресурсів на сторонні функціональні завдання;
- гнучкість та швидкість реагування: у високоризикових фазах, таких як розробка й
тестування алгоритмів pcg, pm може оперативно ухвалювати рішення без
тривалих погоджень із функціональними відділами;
- ефективне використання спеціалізованих знань: команда складається з вузьких
експертів (pcg-розробник, геймдизайнер), чиї компетенції повною мірою
56
спрямовані на розв’язання складних технологічних завдань.
Візуальне представлення ієрархії взаємозв'язків між ключовими ролями
відображено на Рисунку 3.5.
Рисунок 3.5 – Структурна схема організації управління проєктом створення
комп’ютерної гри з процедурною генерацією вмісту ігрового середовища
Команда проєкту є компактною та міжфункціональною. Вона складається з
чотирьох основних ролей, які покривають усі пакети робіт WBS.
Менеджер Проєкту (Project Manager, PM). PM є єдиною точкою відповідальності
за весь проєкт, ключова відповідальність (accountable): успішне завершення проєкту в
57
рамках встановленого змісту, бюджету та термінів. Основні завдання:
- розробка та контроль виконання базового плану змісту (scope baseline), wbs;
- управління бюджетом (оцінка, фінансування, контроль витрат);
- комунікація зі стейкхолдерами (інвестор, замовник);
- ідентифікація, аналіз та розробка планів реагування на ризики, зокрема
технологічні;
- управління командою та забезпечення дотримання методології.
Провідний Розробник PCG (PCG Lead Developer). Ця роль є ключовою для
технічної реалізації унікального продукту, ключова відповідальність (accountable):
технічна якість та працездатність ядра процедурної генерації. Основні завдання:
- розробка модульної архітектури pcg core та внутрішніх api;
- кодування ключових алгоритмів генерації (наприклад, клітинні автомати або wave
function collapse);
- інтеграція pcg core з ігровим рушієм (unity/unreal);
- технічна підтримка інструментарію pcg editor tool;
- контроль версій та підготовка технічної документації.
Гейм-дизайнер (Game Designer, GD). GD відповідає за контент та кінцевий ігровий
досвід, сформований системою процедурної генерації. Ключова відповідальність
(accountable): якість та баланс згенерованого ігрового контенту. Основні завдання:
- формалізація правил генерації та створення необхідних наборів даних (data sets)
для pcg core;
- визначення функціональних вимог до pcg editor tool і робота з ним (налаштування
параметрів, тестування ітерацій);
- співпраця з qa-інженером для визначення метрик, що входять до fitness function;
- документування гейм-дизайн документа (gdd).
QA-інженер (QA Engineer). QA-інженер забезпечує валідацію якості в умовах
стохастичної природи pcg. Ключова відповідальність (accountable): валідація
згенерованого вмісту та гарантування відсутності критичних багів або неграбельних зон.
58
Основні завдання:
- розробка й впровадження fitness function як інструмента автоматичного відбору
якісних рівнів;
- проведення інтеграційного та системного тестування pcg-системи;
- ведення реєстру багів і контроль їх виправлення;
- підготовка фінального звіту про валідацію, що підтверджує відповідність
критеріям прийняття (наприклад, <2% неграбельних зон).
Обрана організаційна структура проєкту є проєктною (Projectized), що забезпечує
максимальну концентрацію ресурсів на єдиній меті. Таблиця 3.4 відображає розширений
склад основної команди, необхідний для виконання всіх пакетів робіт WBS.
Таблиця 3.4 – Трудові ресурси
№ Назва команди Посада
1 Керівництво та управління Менеджер Проєкту (PM)
2 Технічна реалізація Провідний Розробник PCG (Lead Dev)
3 Технічна реалізація Розробник (Game/Tool Programmer)
4 Дизайн та контент Гейм-дизайнер (GD)
5 Дизайн та контент Дизайнер рівнів (Level Designer)
6 Контроль якості QA-інженер
7 Контроль якості Тестувальник (Tester)
Для чіткого розподілу ролей, обов’язків та рівня залученості учасників до
виконання окремих завдань проєкту доцільно застосувати матрицю відповідальності
RACI. [28] Вона дозволяє визначити, хто саме відповідає за виконання конкретної
діяльності (Responsible), хто затверджує результати (Accountable), хто консультує або
надає підтримку (Consulted) та хто має бути поінформований про хід виконання робіт
(Informed).
Такий підхід забезпечує прозорість управління, підвищує ефективність командної
59
взаємодії й мінімізує ризики дублювання або пропуску завдань. Матрицю розподілу
відповідальності для даного проєкту наведено у таблиці 3.5.
Позначення:
- R (Responsible) – відповідальний за виконання;
- A (Accountable) – особа, що затверджує результат (відповідальний перед
замовником);
- C (Consulted) – залучений експерт або консультант;
- I (Informed) – поінформований про виконання.
Таблиця 3.5 – Матриця відповідальності (RACI) для проєкту з розробки мобільного
додатку
№ Назва задачі/етапу Менед Провід Розроб Гейм- Дизайн QA- Тестува
жер ний ник дизайн ер інжене льник
Проєкт Розроб (Game/ ер Рівнів р
у ник Tool) (GD)
PCG
1 Розробка Статуту A/R C I C I I I
Проєкту
2 Формування ключової A/R C I C I C I
команди
3 Оцінка початкового A/R C I I I I I
бюджету
4 Збір бізнес-вимог A/R C I C I I I
5 Формалізація A R C R C C I
Функціональних вимог
6 Визначення Критеріїв A C I R C R I
7 Розробка WBS та Scope A/R C I C I I I
Baseline
8 Створення Реєстру A/R C I C I C I
Ризиків
60
Продовження таблиці 3.5
9 Налаштування A R R I I I I
середовища розробки
10 Розробка модульної A R C I I I I
архітектури
11 Створення базового A R R C C I I
прототипу світу
12 Кодування алгоритмів A R C C I I I
генерації (Core)
13 Створення системи Data A A R R C I I
Sets
14 Реалізація механізмів I A R C I C I
рандомізації
15 Створення I A/R R I I C I
внутрішнього API
16 Реалізація GUI I A R C C I I
редактора (Editor Tool)
17 Функціонал швидкої I A R R C I I
ітерації
18 Модуль візуалізації I A R C I I I
генерації
19 Навчання дизайнерів I A R R R I I
роботі з Toolset
20 Кодування метрик I A R C I R I
прохідності
21 Впровадження метрик I A R R C C I
балансу
22 Розробка I I C I I A/R C
автоматизованого
звітування QA
23 Валідація Функції A C I C I A/R R
Фітнесу
61
Продовження таблиці 3.5
24 Проведення модульних I A R I I C I
тестів (Unit Tests)
25 Інтеграційне A R R I I A R
тестування PCG
26 Фіксація критичних A R R I I A R
багів
27 Набір фокус-групи для A/R I I C I C R
бета-тесту
28 Збір відгуків про A I I R R C R
ігровий досвід
29 Аналіз логів та I R R I I A R
продуктивності
30 Пріоритезація багів A R R C I R I
(Bug Fixing)
31 Фінальний прогін A I I I I A/R I
Fitness Function
32 Підготовка QA-звіту A I I I I A/R C
33 Фінальне полірування A R R C R I I
та оптимізація
34 Створення фінального A R R I I C I
Master Build
35 Підготовка супровідної A R C R C R I
документації
36 Передача всіх активів A/R I I I I I I
інвестору
37 Збір уроків (Lessons A/R C C C C C C
Learned)
38 Закриття проєкту A/R I I I I I I
62
Матриця відповідальності (RACI) є життєво важливим інструментом для
управління даним проєктом, оскільки він поєднує інноваційну технологічну розробку
(PCG Core) із творчим процесом (гейм-дизайн). Чітке визначення ролей Responsible (R)
та Accountable (A) дозволяє уникнути "розмивання" відповідальності, що часто
трапляється у міжфункціональних командах. Зокрема, у завданнях, що стосуються
Формалізації Функціональних вимог (завдання 5) та Створення системи Data Sets
(завдання 13), спільна відповідальність Гейм-дизайнера (R) та Провідного Розробника
PCG (R/A) гарантує, що технічна реалізація відповідатиме творчому баченню. Роль
Менеджера Проєкту (A) у більшості етапів планування та завершення підтверджує його
кінцеву відповідальність перед Інвестором за затвердження фінальних результатів.
Ефективне використання ролей Consulted (C) та Informed (I) значно підвищує
якість комунікацій та знижує ризики. Наприклад, у фазі Розробки автоматизованого
звітування QA (завдання 22) QA-інженер є відповідальним (R), але Провідний
Розробник PCG та Розробник виступають як консультанти (C), забезпечуючи інтеграцію
системи звітності з ігровим рушієм. Роль Тестувальника (R) у завданнях, пов'язаних зі
Збором відгуків про ігровий досвід (завдання 28) та Набором фокус-групи (завдання 27),
підкреслює його безпосередню роль у взаємодії з користувачами. Завдяки цій матриці
кожен член команди чітко розуміє, у яких завданнях він має брати активну участь (R, C)
і коли він має лише контролювати процес (I).
3.3 Розробка календарного плану проєкту
Обмеження проєкту:
Т (час) ≤ 18 міс.;
С (кошти) ≤ 85000 $;
Користувачі – обмеження відсутні.
Допущення проєкту:
ΔТ = 2 місяці;
ΔС = 8 000 $.
63
Розробка календарного плану проєкту ґрунтується на структурі декомпозиції робіт
(WBS), логічній послідовності завдань (Predecessor) та оцінці їхньої тривалості.
Виходячи з обмеження проєкту Т ≤ 18 місяців (приблизно 375 робочих днів) та сумарної
оцінки часу виконання робіт 250 робочих днів (з Таблиці 3.2), ми маємо значний буфер,
що дозволяє реалізувати проєкт із вбудованим часовим резервом (ΔТ = 2 місяці).
План розроблено, виходячи з 5-денного робочого тижня та 250 робочих днів для
завдань, що складає приблизно 11,5 календарних місяців, без урахування резерву. Таким
чином, проєкт завершується в межах встановленого обмеження (18 місяців).
Для ефективного управління проєктом та забезпечення контролю за його
прогресом, життєвий цикл проєкту створення комп’ютерної гри з процедурною
генерацією вмісту ігрового середовища поділено на чотири послідовні фази (Як
показано в таблиці 3.6). Тривалість кожної фази визначає обсяг робіт, а критерії
переходу слугують воротами якості (Go/No Go Gates), які підтверджують готовність
проєкту до наступного етапу, забезпечуючи перехід до наступного етапу лише після
досягнення необхідних результатів.
Проєкт розпочинається з Фази 1: Ініціалізація та Планування, яка триває 35
робочих днів. Ця фаза є фундаментом проєкту, сфокусована на мінімізації
невизначеності, деталізації змісту, часу та коштів, а також на зборі вимог та визначенні
Критеріїв Прийняття для PCG-продукту [26]. Перехід до Фази 2 можливий лише після
того, як буде фіналізовано та затверджено Статут Проєкту, детальна Структура
Декомпозиції Робіт (WBS) та Базовий План Змісту (Scope Baseline), а також створена
Матриця RAM та зафіксований Реєстр Ризиків.
Наступною є Фаза 2: Створення Програмного Продукту, яка є найдовшою та
найскладнішою, займаючи 130 робочих днів. Вона орієнтована на розробку
технологічного ядра, включаючи кодування ключових алгоритмів процедурної генерації
(PCG Core), розробку інструментарію (PCG Editor Tool) для гейм-дизайнерів, а також
паралельне створення Fitness Function — системи автоматизованої оцінки якості
згенерованого контенту. Для переходу до тестування (Фаза 3) необхідно, щоб було
64
повністю реалізовано та протестовано на рівні модулів Ядро PCG Core та PCG Editor
Tool, а Fitness Function була інтегрована в систему і підтверджена її працездатність.
Далі слідує Фаза 3: Тестування та Валідація, тривалістю 60 робочих днів. Її мета
— переконатися, що створений продукт відповідає Критеріям Прийняття та є стабільним
через інтенсивне внутрішнє (Alpha) та зовнішнє тестування фокус-групами (Beta).
Ключовим критерієм для переходу до фінальної фази є усунення всіх критичних та
мажорних багів, а також отримання фінальних звітів QA та Гейм-дизайнерів, які
підтверджують, що контент, згенерований PCG Core, повністю відповідає встановленим
вимогам.
Проєкт завершується Фазою 4: Завершення Проєкту, що займає 25 робочих днів.
Ця фаза сфокусована на адміністративному закритті проєкту: фінальне полірування,
створення остаточного білду (Master Build) та підготовка всієї супровідної документації.
Для офіційного закриття проєкту (Критерії Закриття) необхідно, щоб було підписано акт
передачі-приймання Master Build та повного комплекту Технічної та Супровідної
Документації, проведено фінальний фінансовий аудит та зустріч для збору "Уроків,
отриманих в процесі" (Lessons Learned).
Таблиця 3.6 – Фази стартапу та їх тривалість
№ Назва фази (згідно Критерії переходу на іншу фазу Оцінка
фази WBS) тривалості
(робочі дні)
1 Ініціалізація та Затверджений Статут Проєкту, WBS та 35
Планування Scope Baseline. Фіналізований Реєстр
Ризиків та Матриця RAM.
2 Створення Реалізоване Ядро PCG Core та PCG 130
Програмного Editor Tool. Розроблена та інтегрована
Продукту Fitness Function. Проведено навчання
дизайнерів.
65
Продовження таблиці 3.6
3 Тестування та Проведено Alpha та Beta тестування. 60
Валідація Усунено всі критичні та мажорні баги.
Fitness Function підтверджує
відповідність контенту критеріям
прийняття.
4 Завершення Передано Master Build та повний 25
Проєкту комплект Технічної та Супровідної
Документації. Проведений фінальний
аудит та зустріч "Уроки, отримані в
процесі" (Lessons Learned).
СУМА Всього: 4 фази 250
(приблизно 12
місяців)
Всього робочих годин (за 8-годинного 2000
робочого дня)
Для підвищення наочності та забезпечення ефективного контролю за ходом
виконання робіт, календарний план проєкту було візуалізовано за допомогою
інструменту Microsoft Project [29]. Цей інструмент дозволяє автоматично розрахувати
критичний шлях, відобразити залежності та представити графік у двох ключових
форматах: табличному (Календарний план) та графічному (Діаграма Ганта).
Серія рисунків 3.6 – 3.8 демонструє детальну табличну частину Календарного
плану, згенеровану Microsoft Project:
- рисунок 3.6 (Початок Плану): Відображає структуру декомпозиції робіт (WBS)
для Фази 1 (Ініціалізація та Планування), а також початок Фази 2 (Створення
Програмного Продукту). На цьому рисунку видно ID завдань, їхні назви,
тривалість у робочих днях, дати початку та завершення, а також ключові
66
залежності (попередники). Важливою є коректність розрахунку початкових і
кінцевих дат, які ґрунтуються на логічній послідовності (наприклад, завдання 1.1.2
не може початися раніше завершення 1.1.1);
- рисунок 3.7 (Центральна Частина Плану): Відображає основну частину Фази 2,
зосереджену на розробці Ядра PCG Core та Інструментарію (PCG Editor Tool). Ця
частина плану є найдовшою за тривалістю і містить найбільш комплексні
залежності. Зокрема, тут відображено паралельне виконання завдань 2.2 (Розробка
Ядра PCG) та 2.4 (Розробка Системи Оцінки Якості), які мають спільні точки
інтеграції;
- рисунок 3.8 (Завершення Плану): Демонструє Фазу 3 (Тестування та Валідація) та
Фазу 4 (Завершення Проєкту). На цьому рисунку чітко видно інтеграційні
завдання (наприклад, фіксація багів після Beta-тестування) та адміністративні
завдання закриття проєкту (фінансовий аудит, збір уроків), що ведуть до фінальної
дати завершення.
Серія рисунків 3.9 – 3.11 має графічне відображення Календарного плану у вигляді
Діаграми Ганта [30], де тривалість завдань зображена горизонтальними смугами:
- рисунок 3.9 (Початок Діаграми Ганта): Графічно ілюструє послідовність
виконання завдань Фази 1. Короткі смуги завдань планування та ініціації швидко
переходять до більш тривалих блоків Фази 2;
- рисунок 3.10 (Основна Розробка): Відображає інтенсивний період Фази 2
(Створення Програмного Продукту). Це найбільш насичена частина діаграми, що
демонструє паралельність виконання робіт (розробка PCG Core, Editor Tool та
Fitness Function). Невеликі ромбики позначають контрольні точки (Milestones);
- рисунок 3.11 (Тестування та Завершення): Ілюструє перехід до Фази 3 та Фази 4.
Графічно показано, як тестування (Alpha/Beta) та фіксація багів (Bug Fixing)
займають значну частину часу перед переходом до адміністративного закриття
проєкту. Чіткість залежностей у цій частині є ключовою для підтвердження того,
що продукт передається лише після успішної валідації.
67
Рисунок 3.6 – Календарний план проєкту в Microsoft project (Перша частина)
Рисунок 3.7 – Календарний план проєкту в Microsoft project (Друга частина)
68
Рисунок 3.8 – Календарний план проєкту в Microsoft project (Третя частина)
Рисунок 3.9 – Діаграма Ганта проєкту в Microsoft project (Перша частина)
69
Рисунок 3.10 – Діаграма Ганта проєкту в Microsoft project (Друга частина)
Рисунок 3.11 – Діаграма Ганта проєкту в Microsoft project (Третя частина)
70
3.4 Планування бюджету проєкту
Планування бюджету є ключовим процесом для визначення, контролю та
затвердження фінансових ресурсів, необхідних для успішного завершення проєкту.
Основна мета цього розділу – встановити Базовий план витрат (Cost Baseline), який
слугуватиме еталоном для моніторингу фінансової ефективності протягом усього
життєвого циклу.
Процес оцінки бюджету виконується методом "знизу-вгору" (Bottom-up
Estimating) [31], що забезпечує високу точність, оскільки вартість розраховується на
рівні найдрібніших пакетів робіт і потім агрегується до загальної вартості фаз. Такий
підхід є особливо важливим для складного R&D-проєкту з процедурною генерацією, де
помилка в оцінці ресурсів може призвести до значних відхилень.
Таблиця 3.7 відображає деталізований розрахунок фонду оплати праці (ФОП) на
основі ролей, специфічних для проєкту процедурної генерації контенту. Розрахунок
здійснено методом "знизу-вгору", агрегуючи тривалість активної участі фахівця (з
Календарного плану) та його денну ставку.
Ключові аспекти витрат:
- основна Розробка (PCG Core): Найбільша частка витрат (26 000 USD) припадає на
двох Програмістів PCG Core, оскільки вони задіяні протягом усієї Фази 2 (130
робочих днів), що є критично важливою для створення інноваційного ядра
продукту;
- технічне лідерство: Висока денна ставка та тривалість залучення Технічного
Ліда/Архітектора (6 000 USD) обґрунтовані необхідністю постійного нагляду за
архітектурною цілісністю складних алгоритмів генерації;
- управління та Якість: Менеджер проєкту (22 500 USD) забезпечує безперервну
координацію протягом 250 робочих днів. Залучення Гейм-дизайнера/QA-
аналітика та QA-інженера на 60 робочих днів є обов'язковим для валідації якості
згенерованого контенту та уникнення несподіваних ігрових ситуацій (bad seeds);
71
- загальний ФОП становить 70 600 USD, що підтверджує, що трудові ресурси є
основною статтею витрат для цього типу R&D-проєкту.
Таблиця 3.7 – Оцінка витрат на трудові ресурси проєкту
Роль Тривалість участі в Ставка Загальні витрати на
проєкті (робочі дні) (USD/день) оплату праці (USD)
Менеджер проєкту 250 90 22 500
Бізнес-аналітик/Власник 35 90 3 150
продукту
Технічний 50 120 6 000
Лід/Архітектор
Програміст PCG Core (1) 130 100 13 000
Програміст PCG Core (2) 130 100 13 000
Розробник 50 85 4 250
Інструментарію/UI
Гейм-дизайнер/QA- 60 75 4 500
аналітик
QA-інженер 60 70 4 200
РАЗОМ 70 600
Таблиця 3.8 присвячена розподілу відповідальності саме у сфері фінансів, тому
логічно, що в ній не представлені ролі, які відповідають виключно за технічну реалізацію
продукту — такі як Програмісти, Інженери з процедурної генерації чи фахівці з
контролю якості (QA). Їхня діяльність безпосередньо пов’язана зі створенням
функціоналу, розробкою інструментів та перевіркою якості, і хоча вона суттєво впливає
на загальний бюджет, ці ролі не здійснюють прийняття рішень у фінансовій площині. У
зв’язку з цим у таблицю включено лише ті позиції, які мають повноваження планувати,
затверджувати або контролювати використання фінансових ресурсів.
72
Таблиця 3.8 – Розподіл ролей та відповідальності за бюджет у проєкті
Роль Основна Завдання у сфері управління бюджетом
відповідальність
Власник продукту Затвердження – Визначення джерел фінансування
/ Спонсор фінансової стратегії (інвестиції, власні кошти).
та загального – Затвердження Базового плану витрат.
бюджету – Прийняття рішень щодо ключових змін
бюджету (фінансові Change Requests).
Менеджер Планування, – Формування детального бюджетного
проєкту контроль та звітність плану проєкту.
по використанню – Контроль відповідності фактичних
бюджету витрат запланованим.
– Погодження витрат на персонал,
обладнання та послуги.
– Підготовка фінансових звітів для
Власника продукту.
Технічний Контроль бюджету на – Оцінка вартості необхідного
Лід/Архітектор технологічні ресурси програмного забезпечення та обладнання.
– Забезпечення використання найбільш
економічно ефективних технічних рішень.
Фінансовий Ведення обліку, – Ведення бухгалтерського обліку
менеджер аудит та звітність по проєкту.
(Зовнішній витратах – Формування щомісячних фінансових
консультант) звітів.
– Підготовка документів для податкових
та інвестиційних органів.
73
Таблиця 3.9 представляє деталізовану оцінку витрат, пов'язаних із придбанням,
орендою або ліцензуванням матеріальних та програмних ресурсів, необхідних для
виконання проєкту. Ці витрати є капітальними (CAPEX) та операційними (OPEX) [32] і
покривають інфраструктурні та інструментальні потреби команди протягом 12 місяців
(загальна тривалість проєкту).
Ключові статті витрат проєкту охоплюють основні категорії матеріальних ресурсів
та інфраструктурних сервісів, без яких повноцінна розробка програмного продукту —
зокрема з використанням процедурної генерації контенту — є неможливою. До таких
статей належать:
- хмарна інфраструктура (AWS, MongoDB): Загальна вартість оренди хостингу
(VPS) та хмарного сховища (MongoDB Atlas) складає 1 320 USD за 12 місяців. Це
операційні витрати, критично важливі для підтримки роботи бекенду та зберігання
даних, необхідних для процедурної генерації;
- робочі станції: Найбільшою одиничною капітальною інвестицією (3 600 USD) є
забезпечення чотирьох ключових розробників (Програмісти PCG Core, Розробник
Інструментарію та Технічний Лід) високопродуктивними робочими станціями,
необхідними для швидкої компіляції та тестування ресурсоємного контенту;
- ліцензії та сервіси: Витрати на Unity Pro (1 800 USD) є обов'язковими, оскільки це
основний ігровий рушій. Сервіси CI/CD (GitHub Actions/Docker Hub) [48] та
Jira/Confluence (або їхні аналоги) забезпечують автоматизацію розгортання та
ефективне управління завданнями;
- Загальна сума витрат на матеріальні ресурси та ліцензії становить 7 080 USD.
У підсумку загальна сума витрат на матеріальні ресурси та програмні ліцензії становить
7 080 USD, що формує фінансовий базис інфраструктури проєкту. Ці витрати є
фундаментальними для забезпечення стабільної роботи команди, надійності середовища
розробки та можливості повноцінної реалізації процедурної генерації контенту
відповідно до вимог проєкту.
74
Таблиця 3.9 – Оцінка вартості матеріальних ресурсів проєкту
№ Категорія Найменування / Одиниця Кількість Вартість Загальна
постачальник виміру за вартість,
одиницю, $
$
1 Серверне VPS-хостинг міс. 12 60 720
обладнання (AWS EC2
t3.medium) [33]
2 СУБД / MongoDB Atlas міс. 12 50 600
хмарне (M10 Cluster)
сховище
3 Сервіс GitHub Actions / міс. 12 20 240
CI/CD Docker Hub
4 Робочі Ноутбуки од. 4 900 3 600
станції розробників
(Dell / HP)
5 Ліцензії на Unity Pro міс. 12 150 1 800
ПЗ (ліцензія)
6 Додаткове Jira/Confluence міс. 12 10 120
ПЗ (або аналоги)
РАЗОМ 7 080
Таблиця 3.10 виступає підсумковим елементом розділу управління витратами,
оскільки вона узагальнює всі попередні розрахунки (трудові ресурси, матеріальні
витрати) та резерв на непередбачені ризики, подаючи їх у розрізі чотирьох фаз
життєвого циклу проєкту. Вона забезпечує цілісне бачення структури витрат та дозволяє
оцінити вкладення в етапи планування, розробки, інтеграції та фінального тестування.
75
Ключові висновки та аналіз:
- загальний бюджет: Оцінка загальної вартості проєкту (Baseline Cost) становить 85
448 USD;
- дисбаланс витрат: Найбільш ресурсоємною фазою є Фаза 2: Створення
Програмного Продукту (67 320 USD, або 78.8% загального бюджету). Це повністю
відповідає характеру R&D-проєкту, де основні зусилля та час припадають на
розробку інноваційного ядра (PCG Core) ;
- резервування: Включення Резерву на непередбачувані обставини у розмірі 7 768
USD (10% від базових витрат) є обов'язковим через високу технічну складність
процедурної генерації, яка несе значні ризики перевитрат часу та коштів.
Таблиця 3.10 – Оцінка вартості проєкту за фазами
№ Фази Назва Фази Тривалість Трудові Матеріальні Резерв Загальна
(робочі дні) ресурси ресурси (USD) вартість
(USD) (USD) Фази
(USD)
1 Ініціалізація 35 9 850 590 1 044 11 484
та Планування
2 Створення 130 56 600 4 600 6 120 67 320
Програмного
Продукту
3 Тестування та 60 4 150 1 490 630 6 270
Валідація
4 Завершення 25 0 400 120 520
Проєкту
ВСЬОГО Загальний 250 70 600 7 080 7 768 85 448
Бюджет
Проєкту
76
Окрім кількісної оцінки, у цьому розділі також визначається Матриця фінансової
відповідальності (Таблиця 3.8), що встановлює чіткі межі повноважень для управління,
погодження та контролю витрат. Фінальна Оцінка вартості проєкту за фазами (Таблиця
3.10) підсумовує всі розрахунки і формує фінансовий графік проєкту, необхідний для
звітності перед інвестором.
3.5 Управління ризиками проєкту
Управління ризиками є критично важливим [34] для успішного виконання проєкту
"Створення комп'ютерної гри з процедурною генерацією вмісту" через його високу
технічну складність та значний інноваційний компонент (R&D). Ефективне планування
ризик-менеджменту дозволяє не лише мінімізувати потенційні загрози, але й
забезпечити необхідний резерв часу та коштів для реагування.
Таблиця 3.11 детально класифікує вісім основних груп ризиків, з якими може
зіткнутися проєкт, що містить значну інноваційну складову (PCG-алгоритми).
Розширена класифікація дозволяє більш ефективно застосовувати стратегії реагування.
Акцент на критичних ризиках:
- технологічні ризики залишаються найвищими. Вони вимагають превентивного
уникнення через створення надійних прототипів ядра PCG;
- кадрові ризики є значними через унікальність знань, необхідних для роботи з PCG.
Стратегія зниження передбачає обмін знаннями та резервне планування на
випадок втрати ключових розробників;
- ризики Власника продукту / Вимог контролюються за допомогою фіксації меж
MVP [36];
- ризики Якості вимагають безперервного тестування, оскільки PCG-контент є
непередбачуваним; необхідно встановити чіткі критерії "правильної" генерації.
Загалом, ідентифікація цих восьми груп ризиків дозволяє Менеджеру проєкту
застосувати адекватні ресурси та методи реагування (уникнення, зниження, передача,
прийняття)[35], підвищує ймовірність завершення проєкту в межах бюджету та термінів.
77
Таблиця 3.11 – Основні групи ризиків проєкту розробки гри
№ Група ризиків Характеристика Можливі методи реагування
1 Технологічні Проблеми інтеграції – Проведення технічного аудиту та
ігрового рушія (Unity) з створення прототипів PCG Core.
PCG-ядром, несумісність – Модульне тестування,
бібліотек, відмова використання стабільних версій
ключових алгоритмів Unity.
процедурної генерації. – Створення резервного плану на
випадок відмови інноваційного
алгоритму.
2 Організаційні Неузгодженість у роботі – Впровадження методології
команди, нечіткий Scrum/Agile, регулярні стендапи та
розподіл повноважень, ретроспективи.
відсутність комунікації – Чітке документування ролей
між розробниками PCG та (Матриця відповідальності).
UI.
3 Кадрові Звільнення ключового – Регулярне взаємне навчання та
(Людський фахівця (Програміста PCG обмін знаннями (Knowledge
фактор) Core або Технічного Ліда), Transfer).
низька продуктивність, – Залучення зовнішнього
вигорання або хвороба консультанта як резерву на
членів команди. критичних етапах.
– Впровадження системи мотивації
та управління ризиками вигорання.
4 Ризики Нестабільність вимог, – Затвердження жорсткого MVP
Власника зміна ключових фіч гри (Minimum Viable Product) на Фазі 1.
продукту / або нечітке розуміння – Жорсткий процес контролю змін
78
Вимог кінцевого продукту (scope (Change Request Process).
creep), що веде до – Пріоритизація функціоналу
перевитрати часу. (MoSCoW/Kano) [51].
5 Фінансові Перевищення бюджету, – Використання Резерву на
непередбачені витрати на непередбачені обставини.
інфраструктуру або – Кількісний аналіз ризиків та
недостатній обсяг застосування Методу освоєного
фінансування для Фази обсягу (EVM).
3/4. – Пошук додаткових джерел
фінансування/грантів.
6 Ризики Якості Помилки в роботі PCG- – Постійна інтеграція та
(QA) алгоритму (генерація автоматизоване модульне
"неправильного" або тестування.
неграбельного контенту – – Жорстке визначення критеріїв
bad seeds), низька якість якості (Definition of Done) для PCG-
коду, пропущені критичні контенту.
баги. – Раннє залучення QA-інженера та
Гейм-дизайнера.
7 Інфраструктурні Відмова хмарного – Резервування даних (Backups) та
сховища (MongoDB) або налаштування автоматичного
VPS-хостингу, проблеми з перемикання на резервний сервер.
CI/CD-пайплайном, що – Моніторинг працездатності
зупиняє процес збірки. інфраструктури (SLA).
8 Ринкові Вихід конкурента з – Активний моніторинг ринку та
(Комерційні) аналогічним продуктом до швидке реагування на зміни.
релізу, зміна трендів у – Залучення Маркетолога до Фази
геймдеві, низький попит 1 для валідації концепції.
79
Аналіз результатів оцінювання ризиків виявив три критичні загрози з рівнем
ризику R ≥ 0.45, які вимагають негайної розробки плану реагування:
Акцент на критичних ризиках:
- технологічні ризики (R=0.63) є найбільш загрозливими. Несумісність PCG-
модулів має високу ймовірність (0.7) і високий вплив (0.9), що безпосередньо
загрожує досягненню цілей Фази 2;
- кадрові ризики (R=0.56): Плинність кадрів серед ключових розробників PCG має
найвищу ймовірність (0.8), оскільки їхні знання є унікальними, а втрата такого
фахівця паралізує розробку;
- фінансові ризики (R=0.48): Ризик Перевищення кошторису виникає через високу
невизначеність R&D-робіт (0.6) і має суттєвий вплив (0.8) на кінцевий обсяг
продукту.
Ризики Витоку ІВ (R = 0.30) та Якості (R = 0.36), хоча й мають високий
потенційний вплив (0.9–1.0), демонструють відносно нижчу ймовірність виникнення
порівняно з іншими критичними загрозами. Це означає, що їх матеріалізація є менш
прогнозованою, однак у разі настання наслідки будуть значними, що потенційно може
вплинути як на безпеку інтелектуальних активів, так і на стабільність всього
виробничого циклу.
Здійснена пріоритезація трьох критичних ризиків дає змогу не лише виділити
найбільш проблемні зони, але й забезпечує структурований підхід до управління
ризиками в межах проєкту.
На основі цієї пріоритезації команда переходить до розроблення Плану реагування
на ризики, у якому для кожної критичної загрози формулюється чітка стратегія роботи
з ризиком — уникнення, зниження, передача або прийняття. Це дозволяє не лише
систематизувати управління ризиками, а й забезпечити готовність команди до
оперативного реагування у разі їх виникнення, що підвищує загальну стійкість проєкту
та зменшує ймовірність фінансових або технічних відхилень.
80
Таблиця 3.12 – Оцінювання основних ризиків проєкту розробки гри
№ Ризик Ймовір Вплив Рівень Очікувані наслідки
ність на ризику
(P) проєкт (R = P
(I) × I)
1 Несумісність PCG- 0.7 0.9 0.63 Критична затримка розробки
модулів або помилки (Фаза 2), необхідність повного
інтеграції з Unity переписування частини ядра.
2 Перевищення 0.6 0.8 0.48 Зменшення обсягу робіт,
кошторису або скорочення функціоналу
затримка фінансування MVP, фінансові санкції.
3 Витік або втрата 0.3 1.0 0.30 Репутаційні збитки, юридична
інтелектуальної відповідальність, втрата
власності (коду PCG) конкурентної переваги.
4 Недостатня 0.8 0.7 0.56 Різке зниження якості коду,
кваліфікація або зрив графіка Фази 2.
плинність кадрів
5 Генерація 0.4 0.9 0.36 Необхідність переробки PCG-
неграбельного алгоритмів, значні затримки у
контенту (Bad Seeds) Фазі 3 (Тестування).
6 Зміна ринкових умов 0.5 0.6 0.30 Зменшення прибутковості,
або зниження попиту втрата частки ринку.
на жанр гри
7 Збій серверної 0.4 0.7 0.28 Простій системи,
інфраструктури або незадоволення команди,
втрати даних затримка збірок.
81
Матриця ймовірностей та наслідків є візуальним інструментом, що дозволяє
швидко визначити пріоритетність ризиків за їхнім місцем розташування:
Акцент на критичних ризиках:
- критичні ризики (Червона зона): Ризики, які знаходяться у верхньому правому
куті, вимагають негайного планування та активних стратегій реагування
(Уникнення або Зниження). До них належать:
1) Несумісність PCG-модулів (P=0.7, I=0.9): Найкритичніший ризик, який
розташований у зоні "Висока Ймовірність / Критичний Вплив". Його
необхідно уникати через ретельне тестування прототипів;
2) Плинність кадрів (P=0.8, I=0.7): Має найвищу ймовірність виникнення.
Вимагає стратегії зниження через впровадження мотиваційних програм та
обміну знаннями;
3) Перевищення кошторису (P=0.6, I=0.8): Висока ймовірність перевитрат
вимагає зниження шляхом посиленого фінансового контролю (EVM);
- ризики, що потребують моніторингу (Жовта зона): Ризики з низькою ймовірністю,
але високим впливом, або навпаки. Вони вимагають розробки плану реагування,
але не є пріоритетними для негайного втручання. Це ризики 3, 5, 6 та 7.
Таблиця 3.13 – Матриця імовірностей та наслідків
Ймовірність /
0-0,2 0,21-0,4 0,41-0,6 0,61-0,8 0,81-1
вплив
0,9 1
0,7 4 1
0,5 6 2
0,3 7 3 5
0,1
82
За результатами аналізу, найбільшу загрозу несуть Технологічні ризики (R=0.63)
через необхідність розробки PCG-ядра, та Кадрові ризики (R=0.56) через високу
залежність від унікальних знань ключових розробників. Наступний крок передбачає
розробку конкретних стратегій реагування для цих критичних загроз, щоб забезпечити
стійкість проєкту.
3.6 Управління якістю проєкту
Управління якістю проєкту "Створення комп'ютерної гри з процедурною
генерацією вмісту (PCG)" є процесом, спрямованим на забезпечення того, що всі
проміжні та кінцеві результати відповідають встановленим стандартам і потребам
зацікавлених сторін. Для R&D-проєкту, де якість коду PCG-ядра та "грабельність"
згенерованого контенту є ключовими,
Уравління якістю проєкту "Створення комп'ютерної гри з процедурною
генерацією вмісту" є процесом, що забезпечує відповідність кінцевого продукту та
проміжних результатів (PCG-ядро, архітектура, документація) встановленим вимогам і
стандартам. Оскільки проєкт є інноваційним, акцент робиться на якості розробки та
внутрішній культурі якості, а не лише на фінальному тестуванні.
Оскільки проєкт має інноваційний характер і базується на використанні концепцій
процедурної генерації, управління якістю передбачає безперервне відстеження впливу
технічних рішень на ігрову логіку, продуктивність і реплікованість результатів
генерації. Це означає, що якість повинна бути інтегрована у всі етапи життєвого циклу
— від формування вимог та побудови архітектури до роботи з інструментарієм
розробника та регулярної ревізії PCG-алгоритмів.
Такий підхід дозволяє не лише забезпечити високу надійність і стабільність
продукту, але й створює умови для раннього виявлення потенційних дефектів, що є
критично важливим у проєктах з високою технічною складністю.
Для оцінки загальної ефективності системи якості проєкту використовується
оцінка за ключовими компонентами, як показано в Таблиці 3.14.
83
Таблиця 3.14 – Компоненти оцінки якості проєкту
Критерій Галузь оцінки Рейтинг
управління (1-10)
Керівництво Ступінь участі керівництва у процесі управління 10
(Лідерство) змінами в проєкті та його вплив на досягнення
високих показників якості.
Політика та Рівень того, наскільки політика й стратегія організації 8
стратегія відображають її зобов'язання щодо якості та
орієнтацію на постійне вдосконалення (включно зі
стандартами кодування та QA).
Управління Оцінка ефективності використання потенціалу 9
строками працівників для підвищення результативності та
безперервного розвитку команди.
Ресурси Аналіз ефективності використання наявних ресурсів 9
(технологічний стек Unity, CI/CD, людські ресурси)
для реалізації обраної політики та стратегії
підприємства.
Контроль PCG- Встановлення чітких метрик для оцінки якості 10
контенту згенерованого контенту (кількість "Bad Seeds",
унікальність, баланс).
Управління Процедура документування та затвердження вимог 9
вимогами до MVP, а також контроль за "повзучою
функціональністю" (Scope Creep).
Зворотний зв’язок Ефективність механізмів отримання та використання 8
зворотного зв’язку від Тестувальників та Гейм-
дизайнерів для коригування роботи PCG-алгоритму.
84
Таблиця 3.14 встановлює ключові критерії оцінки якості, які є основою для
розробки Плану управління якістю.
Акцент на критичних критеріях:
- керівництво (Рейтинг 10) та Контроль PCG-контенту (Рейтинг 10): Ці компоненти
мають найвищий пріоритет. Високий рейтинг керівництва свідчить про повну
підтримку культури якості менеджментом. Встановлення високої якості контролю
PCG-контенту є критичним, оскільки це безпосередньо впливає на унікальність та
грабельність фінального продукту;
- управління строками (Рейтинг 9) та Ресурси (Рейтинг 9): Ці компоненти
підкреслюють важливість ефективного використання кадрового та технологічного
потенціалу. Якість коду та архітектури залежить від правильно розподіленого часу
та відповідних ресурсів (наприклад, використання автоматизованих інструментів
тестування);
- політика та стратегія (Рейтинг 8) та Зворотний зв’язок (Рейтинг 8): Ці критерії,
хоча й мають трохи нижчий рейтинг, є важливими для постійного вдосконалення.
Ефективний зворотний зв'язок (особливо з ігровими дизайнерами) забезпечує
ітераційне покращення PCG-алгоритмів, що є необхідним для R&D-проєкту.
Наступний крок передбачає розробку конкретних метрик та інструментів (Таблиця
3.15) для вимірювання цих критеріїв, щоб перетворити якісні цілі на кількісні показники.
Таблиця 3.15 встановлює взаємозв'язок між основними зацікавленими сторонами
проєкту (внутрішніми та зовнішніми) та їхніми специфічними вимогами до якості.
Визначення цих вимог на ранньому етапі є ключовим для формування метрик
успішності проєкту.
Визначення цих показників дозволяє перетворити абстрактне поняття "якість" на
конкретні вимірювані цілі, які будуть інтегровані в План забезпечення якості. Ці
показники надалі інтегруються у План забезпечення якості, формуючи основу для
системного контролю і стандартизованого підходу до перевірки всіх етапів реалізації
проєкту.
85
Таблиця 3.15 – Вимоги зацікавлених сторін до якості гри з процедурною генерацією
№ Зацікавлена Основні очікування Критерій якості / Очікуваний
сторона щодо якості Показники оцінки результат
1 Замовник / Висока Рівень утримання Окупність
Інвестор прибутковість, користувачів інвестицій (ROI)
успішний реліз, (Retention Rate), [53], створення
створення дотримання унікального
унікальної ІВ бюджету, продукту, що
(Intellectual відсутність масштабується.
Property). критичних багів у
релізі.
2 Гейм-дизайнер Баланс ігрового Коефіцієнт Забезпечення
процесу, висока реіграбельності довгострокової
реіграбельність, (Replayability Score), цінності продукту,
відсутність відсоток успішної відповідність
"поганих зерен" генерації контенту (> ігровим механікам.
(Bad Seeds) у PCG. 95%), середній час
сесії.
3 Команда PCG- Стабільність Швидкість генерації Можливість
Core алгоритмів, рівня (ms), покриття швидкого
(Розробники) масштабованість, коду тестами (Code внесення змін,
швидкість генерації, Coverage > 80%) низький технічний
чистота архітектури [39], кількість борг (Technical
коду. системних збоїв на Debt), висока
1000 генерацій продуктивність.
процедурних рівнів
комп’ютерної гри
86
Продовження таблиці 3.15
4 QA-інженер Зручність Кількість Висока
(Тестувальник) тестування, пропущених стабільність
відтворюваність критичних багів фінальної версії,
багів, відповідність (Severity 1), середня мінімізація
гри технічним кількість знайдених післярелізних
вимогам (FPS, багів на тест-кейс, патчів.
пам'ять). продуктивність
(Target FPS).
5 Кінцеві Захоплюючий Оцінка в магазинах Позитивний імідж
користувачі ігровий досвід, додатків (User продукту,
(Гравці) інтуїтивний Score), коефіцієнт зростання
інтерфейс (UI/UX), чистої лояльності спільноти гравців.
відсутність лагів. (NPS), середній час
відгуку інтерфейсу.
Висновки до розділу 3
Проведений аналіз та планування у розділі 3 дозволили трансформувати
концептуальну ідею розробки інноваційного продукту з процедурною генерацією вмісту
(PCG) у структурований, керований проєкт. Розроблений план охоплює всі ключові
сфери управління, визначаючи часові, фінансові, кадрові, ризикові та якісні параметри,
необхідні для успішної реалізації.
Планування проєкту, представлене в розділі 3, забезпечує комплексну основу для
його виконання. Чітка фіксація часових меж, деталізація бюджету та ресурсів, а також
проактивний план управління ризиками та якістю створюють необхідну контрольовану
середу для розробки інноваційного продукту. Проєкт готовий перейти до етапу
виконання з усвідомленням ключових ризиків (особливо технологічних) та чітко
визначеними критеріями успіху, що підвищує ймовірність його успішного завершення.
87
4 МОДЕЛЮВАННЯ ВИКОНАННЯ ПРОЄКТУ
4.1 Опис моделювання продукту проєкту
Моделювання продукту проєкту "Створення комп'ютерної гри з процедурною
генерацією вмісту (PCG)" має на меті візуалізувати та зафіксувати ключові
функціональні характеристики кінцевого ігрового світу, який буде генеруватися PCG-
ядром, а також визначити, як виглядатиме взаємодія гравця з цим світом. Моделювання
фокусується на найбільш інноваційному аспекті — процедурній генерації.
PCG-ядро є центральним елементом проєкту і відповідає за генерацію контенту,
який забезпечує високу реіграбельність. Його робота моделюється на основі
багатошарового підходу:
- генерація "Зерна" (Seed Generation): Кожен ігровий світ генерується на основі
унікального хешу (Seed) [46], який є єдиною змінною, необхідною для відтворення
ігрового світу;
- шари Генерації: Генерація відбувається послідовно, від макро- до мікрорівня,
включаючи генерацію кліматичних зон (макро), структури ігрових рівнів
(середній) та розміщення луту (мікро);
- моделювання Грабельності (Playability Constraint): Головним принципом
моделювання є забезпечення того, що кожен згенерований світ є грабельним,
тобто гравець завжди матиме доступ до необхідних ресурсів та зможе досягти
цілей, незалежно від унікальності генерації. ;
- алгоритми: Для створення ландшафту використовуються алгоритми на кшталт
Perlin Noise [40], а для розміщення контенту - метод Wave Function Collapse [41].
- Моделювання ігрового процесу (Game Flow) визначає очікувану поведінку гравця
у згенерованому світі та його взаємодію з системою:
- цикл PCG-гри: Гравець розпочинає нову сесію, отримує унікальний Seed,
досліджує унікально згенеровану карту, взаємодіє зі згенерованими об'єктами та
ворогами, досягає цілі сесії та повертається до головного меню;
88
- інтерфейс та UX: Інтерфейс (UI/UX) моделюється як мінімалістичний [47], щоб не
перевантажувати гравця інформацією та підкреслити атмосферу дослідження;
- сценарії взаємодії: Моделюються ключові сценарії, які безпосередньо залежать від
PCG, такі як пошук ресурсів на новій локації та унікальні бої з процедурно
налаштованими ворогами.
Ключові показники (Key Generation Metrics) є основою для подальшого тестування
якості та моделюють успіх роботи PCG-ядра:
- коефіцієнт унікальності: Вимірюється різноманітність двох послідовно
згенерованих світів. Очікуваний результат: мінімальна схожість між двома
світами має перевищувати 80% за ключовими параметрами (ландшафт,
розташування POI, тип ворогів);
- відсоток "Поганих зерен" (Bad Seeds Rate): Кількість згенерованих світів, які є
неграбельними. Очікуваний показник: Bad Seeds Rate не має перевищувати 5% під
час фінального тестування;
- швидкість генерації: Час, необхідний для генерації нового світу. Очікуваний
результат: час генерації нового рівня не має перевищувати 5 секунд для
забезпечення позитивного користувацького досвіду.
- Моделювання продукту на цьому етапі дозволяє команді розробників та гейм-
дизайнерам мати спільне бачення кінцевого результату та чіткі критерії для оцінки
успіху роботи інноваційного PCG-ядра.
4.2 Опис процесу реалізації проєкту
Успішна реалізація проєкту розробки гри з процедурною генерацією вмісту (PCG)
вимагає чіткої структуризації як самого процесу розробки, так і логіки функціонування
кінцевого продукту. Цей підрозділ деталізує архітектуру та динаміку гри,
використовуючи UML-діаграми [42] для моделювання ключових компонентів: логіки
переходів між ігровими сценами, активності PCG-ядра, послідовності завантаження
світу та внутрішньої структури класів Unity [44].
89
Діаграма станів (State Diagram) [43] описує логіку переходу між ключовими
екранами та сценами, демонструючи, як гравець пересувається від початкового
завантаження до генерації світу та ігрового процесу (Рисунок 4.1). Це є основою для
архітектури ігрового клієнта на Unity.
Рисунок 4.1 – Діаграма переходів між сценами гри з процедурною генерацією вмісту
ігрового середовища
Таблиця 4.1 надає детальну характеристику кожної ключової сцени (екрану)
ігрового клієнта, розкриваючи її основне призначення, базові функціональні можливості
та інтеграцію у загальний процес процедурної генерації контенту (PCG) і ігровий цикл.
Для кожного екрану наведено інформацію про взаємодію користувача з інтерфейсом,
елементи управління, логіку відображення контенту та зв’язок із алгоритмами генерації,
що забезпечують динамічне формування ресурсів. Такий підхід дозволяє наочно оцінити
архітектурну структуру клієнта, а й створює основу для системного тестування.
90
Таблиця 4.1 – Опис сцен гри з процедурною генерацією вмісту ігрового середовища
№ Назва сцени Призначення Основні функції Пов'язані
сцени
1 SplashScreen Початкове Завантаження Main Menu
(Заставка) завантаження гри, основних асетів та
ініціалізація Unity та скриптів; перевірка
перевірка цілісності ліцензії;
ресурсів. відображення
логотипу студії.
2 Main Menu Центральний Доступ до: "Нова Generation
(Головне меню) навігаційний екран, Гра", "Продовжити", Settings, Load
що забезпечує вхід до "Налаштування", Game, Settings
ігрових режимів та "Вихід"; перегляд
налаштувань. збережених ігор.
3 Generation Надання гравцеві Введення числового Main Menu,
Settings можливості Seed; вибір Loading Screen
(Налаштування налаштувати складності; вибір
генерації) параметри нового біома;
світу або ввести підтвердження та
унікальне Seed. запуск генерації
світу.
4 Loading Screen Відображення Відображення Generation
(Екран прогресу виконання прогрес-бару Settings,
завантаження) ресурсомісткого генерації; виведення InGame
процесу процедурної підказок/лорів;
генерації світу. обробка даних,
отриманих від PCG-
91
Продовження таблиці 4.1
5 InGame (Ігровий Основна сцена, де Обробка вхідних Pause Menu,
процес) відбувається даних гравця (рух, Inventory
взаємодія гравця зі взаємодія); Panel,
згенерованим рендеринг PCG- GameOver
ігровим світом. світу; логіка бою та
інвентарю; виклик
меню паузи.
6 Pause Menu Panel Призупинення "Продовжити", InGame,
(Меню паузи) ігрового процесу для "Налаштування гри" Settings, Main
внесення змін або (зміна звуку, Menu
виходу з гри. графіки), "Зберегти
та Вийти", "Вихід без
збереження".
7 Inventory Panel Відображення Перегляд, InGame
(Панель предметів, зібраних використання та
інвентарю) гравцем у PCG-світі. керування
предметами;
відображення
статистики гравця.
8 Settings Panel Зміна загальних Налаштування Main Menu,
(Налаштування) параметрів гри (звук, гучності, яскравості; Pause Menu
графіка, управління). перепризначення Panel
клавіш; зміна якості
графіки.
9 GameOver Екран, смерті що Відображення Main Menu
(Кінець гри) відображається результатів сесії;
92
Діаграма активності (Рисунок 4.2) відображає послідовність дій та умови,
необхідні для успішного виконання інноваційного компонента — процедурної генерації
ігрового світу.
Рисунок 4.2 – Діаграма активності для процесу генерації нового світу
Діаграма (Рисунок 4.3) послідовності деталізує взаємодію між програмними
об'єктами під час завантаження нового світу, включаючи об'єкти Unity та PCG-Core.
93
Рисунок 4.3 – Діаграма послідовності для процесу завантаження PCG-світу
Діаграма на Рисунку 4.4 ілюструє основні інтерфейси користувача (панелі UI), які
будуть доступні гравцеві під час взаємодії з ігровим клієнтом, а також показує їхній
взаємозв’язок і логіку переходів між екранами. На діаграмі відображено структуру
елементів управління, їхню функціональну роль у підтримці геймплею та зв’язок із
ключовими компонентами процедурної генерації контенту (PCG), що забезпечують
динамічне наповнення ігрового світу. Таке графічне представлення дозволяє команді
розробників і дизайнерів наочно оцінити узгодженість навігації між панелями,
взаємозалежність функціональних блоків та логіку відображення інформації для гравця.
94
Рисунок 4.4 – Діаграма уявлення інтерфейсів додатку
Діаграма класів на Рисунку 4.5 детально ілюструє основні компоненти архітектури
Unity та PCG-ядра, включаючи їхні властивості, методи та взаємозв’язки між об’єктами.
Особлива увага приділяється демонстрації принципу слабкого зв’язку [45], який
забезпечує мінімальну залежність між окремими модулями та сприяє підвищенню
гнучкості, масштабованості й простоти тестування системи.
На діаграмі відображено, як ключові класи взаємодіють один з одним у процесі
генерації контенту, управління ігровими об’єктами та обробки даних, що дозволяє
розробникам отримати цілісне уявлення про архітектурну структуру проєкту. Такий
підхід забезпечує не лише прозорість внутрішніх зв’язків компонентів, але й створює
основу для подальшої оптимізації, розширення функціоналу та інтеграції нових модулів.
Крім того, діаграма слугує важливим інструментом у процесі комунікації між
членами команди, дозволяючи швидко визначати відповідальні компоненти за конкретні
функції, планувати тестування, оцінювати вплив змін на інші модулі та забезпечувати
узгодженість архітектурних рішень із загальними цілями проєкту.
95
Рисунок 4.5 – Діаграма класів гри на Unity
4.3 Аналіз отриманих результатів
Аналіз результатів моделювання, проведеного в підрозділах 4.1 та 4.2, дозволяє
зробити висновки щодо архітектурної стійкості, ефективності процесу розробки та
відповідності продукту високорівневим вимогам проєкту.
Аналіз Діаграми класів гри на Unity (Рисунок 4.5) підтверджує застосування
модульного підходу, що є критично важливим для R&D-проєктів з PCG-ядром:
- принцип слабкого зв'язку: Виділення PCG_Core в окремий програмний пакет зі
слабким зв'язком із GameManager є основним досягненням, що дозволяє командам
96
PCG-розробників та Гейм-дизайнерів працювати незалежно;
- чітка ієрархія генерації: Структура класів PCG_Core (TerrainGenerator,
StructureGenerator) забезпечує послідовну та контрольовану генерацію контенту,
що значно спрощує відлагодження унікальних помилок (Bad Seeds);
- розширюваність: Модульна архітектура спрощує майбутній розвиток, дозволяючи
додавати нові генератори без порушення роботи основного ядра, що відповідає
довгостроковій стратегії проєкту.
Аналіз Діаграми активності (Рисунок 4.2) та Діаграми послідовності (Рисунок 4.3)
демонструє, що процес PCG-генерації є оптимізованим для мінімізації ризиків
неграбельних світів:
- контроль якості "на льоту": Включення етапу "Фінальна Перевірка Грабельності"
(Playability Constraint Check) безпосередньо в цикл генерації забезпечує
автоматичне відхилення неякісних світів (Bad Seed Rate < 5%);
- явна обробка помилок (Failure Path): Діаграма послідовності чітко моделює гілку
alt/else для випадку "Bad Seed", що є прямим зниженням Технологічного ризику
(Несумісність PCG-модулів) та забезпечує стабільність системи;
- мінімізація затримок: Послідовність операцій оптимізована для паралельного
виконання, наскільки це можливо, для досягнення цільової швидкості генерації
(до 5 секунд).
Вивчення Діаграми переходів між сценами (Рисунок 4.1) та Опису сцен гри
(Таблиця 4.1) показує, що ігровий досвід (UX) був спроєктований з акцентом на
простоту та занурення:
- фокус на грі: Мінімальна кількість проміжних сцен та швидкий перехід до InGame
підкреслює орієнтацію на безперервний ігровий процес;
- чітка навігація: Усі функціональні панелі (Inventory Panel, Pause Menu Panel)
доступні лише зі сцени InGame, що забезпечує логічний потік та запобігає
заплутуванню гравця;
- контроль генерації: Виділення окремої сцени Generation Settings надає гравцеві
97
необхідний контроль над унікальними параметрами світу, що є ключовою
перевагою PCG-ігор.
Моделювання підтверджує, що архітектура проєкту є стійкою, модульною та ефективно
керує головним ризиком — створенням неграбельного контенту. Моделі станів та
активностей забезпечують чіткий план імплементації, що знижує ймовірність помилок
на етапі кодування.
Висновки до розділу 4
У Розділі 4 було проведено комплексне моделювання продукту та процесу
реалізації проєкту, що дозволило деталізувати внутрішню логіку гри з процедурною
генерацією вмісту (PCG) та формалізувати архітектуру ігрового клієнта, таким чином
підтверджуючи технічну життєздатність проєкту та його готовність до Фази виконання:
- підтверджено технічну архітектуру: Діаграма класів (Рисунок 4.5) формалізувала
модульну архітектуру, чітко розділяючи інноваційне PCG-Core від стандартних
компонентів ігрового рушія (Unity), що забезпечує гнучкість розробки та легкість
майбутнього масштабування;
- забезпечено контроль якості PCG: Моделювання продукту встановило ключові
показники якості генерації, включаючи цільовий коефіцієнт унікальності (понад
80%) та граничний показник "Поганих зерен" (Bad Seeds Rate до 5%), що є
основою для розробки Fitness Function та знижує ризик створення неграбельного
контенту;
- оптимізовано процес генерації: Діаграми активності (Рисунок 4.2) та
послідовності (Рисунок 4.3) деталізували багатошаровий процес PCG-генерації та
включили в нього автоматичні перевірки на грабельність, що мінімізує вплив
технологічних ризиків на користувацький досвід;
Таким чином, результати моделювання свідчать про те, що проєкт має
структуровану, стійку та ефективно сплановану архітектуру, готову до безпосереднього
переходу до Фази виконання.
98
ВИСНОВКИ
У представленій кваліфікаційній роботі на тему «Управління проєктом створення
комп’ютерної гри з процедурною генерацією вмісту ігрового середовища» було
досягнуто мети дослідження, що полягала у теоретичному обґрунтуванні та розробці
методичних рекомендацій з управління інноваційним проєктом, ключовою особливістю
якого є використання Процедурної Генерації Вмісту (PCG).
Актуальність роботи була підтверджена зростаючими вимогами ігрової індустрії
до масштабності контенту та наявністю специфічних управлінських викликів
(технологічна невизначеність, ризики непередбачуваності алгоритмів), які не можуть
бути ефективно вирішені класичними методологіями.
У процесі дослідження були послідовно виконані всі поставлені завдання:
- проаналізовано та систематизовано методології управління проєктами GameDev
та їхні обмеження стосовно PCG-проєктів:
1) Аналіз конкурентних проєктів дозволив обрати для стартапу Гібридний
підхід до PCG-генерації. Цей підхід поєднує масштабованість процедурних
алгоритмів із високим контролем якості за допомогою використання
заздалегідь розроблених, перевірених модульних блоків.
2) Було встановлено, що управління таким проєктом вимагає перенесення
фокусу контролю з кінцевого результату на управління правилами,
параметрами та обмеженнями генерації.
- розроблено адаптовану концепцію та PM-методологію:
1) Обґрунтовано застосування Гібридного життєвого циклу (Scrum-Hybrid)
[49], який використовує послідовну (Waterfall) структуру для фінансового
контролю та фаз ініціації/завершення, а також ітераційний (Agile-Scrum)
підхід для основної Фази виконання (Продакшн).
2) Центральним управлінським рішенням стала трансформація суб'єктивних
вимог гейм-дизайнерів у кількісні параметри — Функцію Фітнесу (Fitness
99
Function), яка дозволяє алгоритмічно контролювати якість та естетику
згенерованого контенту.
- розроблено детальний план та адаптований PM-інструментарій:
1) Створено повний пакет планувальних документів: Структура Декомпозиції
Робіт (WBS), Матриця відповідальності (RACI) та Календарний план, що
фіксує термін реалізації проєкту в 12 місяців.
2) Планування бюджету визначило Фазу 2 (Створення програмного продукту)
як найбільш ресурсомістку, на яку припадає найбільше фінансове та кадрове
навантаження.
3) Розроблено адаптовану модель управління ризиками. За допомогою
Матриці ймовірностей та наслідків ідентифіковано критичні загрози:
Технологічні ризики (R=0.63), пов'язані з розробкою PCG-ядра, та Кадрові
ризики (R=0.56), пов'язані із залежністю від унікальних знань ключових
розробників. Розроблено превентивні стратегії реагування.
- сформульовано критерії оцінки якості (QA) та метрики ефективності (KPI):
1) Система управління якістю надає найвищий пріоритет (Рейтинг 10)
Контролю PCG-контенту.
2) Встановлені ключові показники якості: цільовий коефіцієнт унікальності
згенерованих світів понад 80% та граничний показник «Bad Seeds Rate» до
5%. Ці метрики перетворюють суб'єктивне поняття «грабельність» у
вимірювані показники.
Практична цінність роботи полягає у розробці чітких та адаптованих методичних
рекомендацій та шаблонів, які можуть бути безпосередньо використані менеджерами
проєктів у малих та середніх GameDev-студіях для зниження фінансових та часових
ризиків при створенні та масштабуванні ігрового світу за допомогою процедурної
генерації.
100
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Shaker N., Togelius J., Nelson M. J. Procedural Content Generation in Games. Springer,
2016. 218 p.
2. Project Management Institute. A Guide to the Project Management Body of Knowledge
(PMBOK Guide). 7th ed. PMI, 2021. 274 p.
3. Бушуєв С. Д., Бушуєва Н. С. Управління проектами: Основи професійних знань та
система оцінки компетентності проектних менеджерів (National Competence
Baseline, NCB UA Version 4.0). К.: ІРІДІУМ, 2018. 208 с.
4. Newzoo. Global Games Market Report 2024. URL:
https://newzoo.com/resources/trend-reports/global-games-market-report-2024 (дата
звернення: 25.11.2025).
5. Short T. X. Procedural Generation in Game Design. CRC Press, 2017. 326 p.
6. Togelius J., Yannakakis G. N., Stanley K. O., Browne C. Search-based procedural
content generation: A taxonomy and survey. IEEE Transactions on Computational
Intelligence and AI in Games. 2011. Vol. 3, no. 3. P. 172–186.
7. Cohn M. Agile Estimating and Planning. Prentice Hall, 2005. 368 p.
8. Murray S. Building Worlds with Noise in No Man's Sky. GDC 2017. URL:
https://www.gdcvault.com/play/1024265/Building-Worlds-with-Noise-in (дата
звернення: 25.11.2025).
9. Kasavin G. Writing for a Game You Play Over and Over: The Narrative Design of
Hades. GDC 2021. URL: https://www.youtube.com/watch?v=R2jT8-0_f9w (дата
звернення: 25.11.2025).
10. Perlin K. An Image Synthesizer. ACM SIGGRAPH Computer Graphics. 1985. Vol. 19,
no. 3. P. 287–296.
11. Porter M. E. Competitive Strategy: Techniques for Analyzing Industries and
Competitors. New York: Free Press, 2008. 432 p.
12. Unity Technologies. Unity Real-Time Development Platform. URL: https://unity.com/
101
(дата звернення: 25.11.2025).
13. Фатхутдінов Р. А. Стратегічний менеджмент: Підручник. М.: Справа, 2008. 448 с.
14. Compton K. So you want to build a generator. Kate Compton’s Blog. URL:
http://galaxykate0.tumblr.com/post/139774965871/so-you-want-to-build-a-generator
(дата звернення: 25.11.2025).
15. Freeman R. E. Strategic Management: A Stakeholder Approach. Cambridge University
Press, 2010. 292 p.
16. Mendelow A. L. Environmental Scanning: The Impact of the Stakeholder Concept. ICIS
1981 Proceedings. 1981. P. 407–418.
17. Doran G. T. There’s a S.M.A.R.T. way to write management’s goals and objectives.
Management Review. 1981. Vol. 70, no. 11. P. 35–36.
18. Lagae A. et al. A Survey of Procedural Noise Functions. Computer Graphics Forum.
2010. Vol. 29, no. 8. P. 2579–2600.
19. Gumin M. Wave Function Collapse Algorithm. GitHub Repository. 2016. URL:
https://github.com/mxgmn/WaveFunctionCollapse (дата звернення: 25.11.2025).
20. Cooper R. G. Agile-Stage-Gate Hybrids: The Next Generation of Product Development
Models. Journal of Product Innovation Management. 2016. Vol. 33, no. 5. P. 513–526.
21. Verzuh E. The Fast Forward MBA in Project Management. Wiley, 2015. 528 p.
22. Schwaber K., Sutherland J. The Scrum Guide. Scrum.org, 2020. 14 p.
23. Yannakakis G. N., Togelius J. Artificial Intelligence and Games. Springer, 2018. 329 p.
24. ISO 21500:2012. Guidance on project management. International Organization for
Standardization, 2012.
25. Norman E. S., Brotherton S. A., Fried R. T. Work Breakdown Structures: The
Foundation for Project Management Excellence. Wiley, 2008. 304 p.
26. Wiegers K., Beatty J. Software Requirements. 3rd ed. Microsoft Press, 2013. 672 p.
27. Organizational Project Management Maturity Model (OPM3). 3rd ed. PMI, 2013.
28. Smith M. L., James J. The Power of RACI Matrices in Software Development. Project
Management Journal. 2019. Vol. 12. P. 45–52.
102
29. Lewis J. P. Project Planning, Scheduling, and Control. McGraw-Hill Education, 2010.
544 p.
30. Gantt H. L. Work, Wages, and Profits. Engineering Magazine Company, 1910.
31. Fleming Q. W., Koppelman J. M. Earned Value Project Management. PMI, 2010. 238
p.
32. Drury C. Management and Cost Accounting. Cengage Learning, 2018. 832 p.
33. Amazon Web Services. AWS Economics Center. URL:
https://aws.amazon.com/economics/ (дата звернення: 25.11.2025).
34. ISO 31000:2018. Risk management — Guidelines. International Organization for
Standardization, 2018.
35. Hillson D. The Risk Management Handbook: A Practical Guide to Managing the
Multiple Dimensions of Risk. Kogan Page, 2016. 328 p.
36. Ries E. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to
Create Radically Successful Businesses. Crown Business, 2011. 336 p.
37. Chapman C., Ward S. Project Risk Management: Processes, Techniques and Insights.
Wiley, 2003. 408 p.
38. Rubin K. S. Essential Scrum: A Practical Guide to the Most Popular Agile Process.
Addison-Wesley, 2012. 500 p.
39. Myers G. J., Sandler C., Badgett T. The Art of Software Testing. Wiley, 2011. 240 p.
40. Ebert D. S. et al. Texturing and Modeling: A Procedural Approach. Morgan Kaufmann,
2002. 624 p.
41. Karth I., Smith A. M. WaveFunctionCollapse: Content Generation via Constraint
Solving. Proceedings of the 12th International Conference on the Foundations of Digital
Games. 2017.
42. Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling Language.
Addison-Wesley, 2003. 208 p.
43. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User Guide.
Addison-Wesley, 2005. 496 p.
103
44. Gregory J. Game Engine Architecture. 3rd ed. CRC Press, 2018. 1240 p.
45. Martin R. C. Clean Architecture: A Craftsman's Guide to Software Structure and
Design. Prentice Hall, 2017. 432 p.
46. Adams E. Fundamentals of Game Design. New Riders, 2013. 700 p.
47. Hodent C. The Gamer's Brain: How Neuroscience and UX Can Impact Video Game
Design. CRC Press, 2017. 266 p.
48. Duvall P. M., Matyas S., Glover A. Continuous Integration: Improving Software
Quality and Reducing Risk. Addison-Wesley, 2007. 336 p.
49. Wysocki R. K. Effective Project Management: Traditional, Agile, Extreme. Wiley,
2019. 688 p.
50. Loch C. H., DeMeyer A., Pich M. T. Managing the Unknown: A New Approach to
Managing High Uncertainty and Risk in Projects. Wiley, 2006. 290 p.
51. Clegg D., Barker R. Case Method Fast-Track: A Radically New Approach to
Applications Development. Addison-Wesley, 1994.
52. Cormen T. H., Leiserson C. E., Rivest R. L., Stein C. Introduction to Algorithms. 3rd
ed. MIT Press, 2009. 1312 p.
53. Phillips J. J. Return on Investment in Training and Performance Improvement Programs.
Butterworth-Heinemann, 2003. 336 p.
54. IT Ukraine Association. Ukraine IT Report 2024. URL: https://itukraine.org.ua/ (дата
звернення: 25.11.2025).
55. Richter J. CLR via C#. 4th ed. Microsoft Press, 2012. 896 p.
104
ДОДАТОК А
Затверджую
Зав. кафедри КНСА.
_______Юрій ТРИУС
«__»________2025р
УПРАВЛІННЯ ПРОЄКТОМ СТВОРЕННЯ КОМП’ЮТЕРНОЇ ГРИ З ПРОЦЕДУРНОЮ
ГЕНЕРАЦІЄЮ ВМІСТУ ІГРОВОГО СЕРЕДОВИЩА
Специфікація
482. ЧДТУ. 42301-03
Листів 2
Розробник Андрій ПУСТОВІТ
Керівник Микола ПІДГОРНИЙ
Черкаси 2025
105
482. ЧДТУ. 42301-03
Позначення Найменування Примітка
Документація
Проект в Microsoft
Project
106
ДОДАТОК Б
Вміст проекту створення комп’ютерної гри з процедурною генерацією вмісту
ігрового середовища в Microsoft project
Рисунок Б.1 – Календарне планування (Частина 1)
Рисунок Б.2 – Календарне планування (Частина 2)
107
Рисунок Б.3 – Календарне планування (Частина 3)
-
Рисунок Б.4 – Календарний план проєкту в Microsoft project (Перша частина)
108
Рисунок Б.5 – Календарний план проєкту в Microsoft project (Друга частина)
Рисунок Б.6 – Календарний план проєкту в Microsoft project (Третя частина)
109
Рисунок Б.7 – Діаграма Ганта проєкту в Microsoft project (Перша частина)
Рисунок Б.8 – Діаграма Ганта проєкту в Microsoft project (Друга частина)
110
Рисунок Б.9 – Діаграма Ганта проєкту в Microsoft project (Третя частина)