Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9745| Назва: | Програмне забезпечення гри-симулятора соціальної взаємодії |
| Автори: | Куницька, Світлана Юріївна Ткаченко, Владислав Анатолійович |
| Ключові слова: | SIMULATION;UNITY;C#;2D;OOP;CROSS PLATFORM;SIMULATION;UNITY;C#;2D;OOP;CROSS PLATFORM |
| Дата публікації: | 17-чер-2026 |
| Короткий огляд (реферат): | АНОТАЦІЯ
Кваліфікаційна робота бакалавра на тему «Програмне забезпечення гри-симулятора соціальної взаємодії» містить 97 сторінок, 7 таблиць, 23 рисунків, список використаних джерел з 23 найменувань, 4 додатків.
Метою виконання кваліфікаційної роботи бакалавра є демонстрація набутих навичок розробки програмного забезпечення в обраній області.
Головні завдання при проєктуванні інформаційної системи
Створити масштабовану та гнучку архітектуру додатку.
Досягти максимально можливого рівня оптимізації для симуляції.
Об'єктом роботи є cимуляція соціальної взаємодії.
Предметом розробки є крос-платформений додаток, що дозволяє симулювати соціальну поведінку віртуальних персонажів в межах населеного пункту.
Вирішено наступні поставлені задачі
Створено додаток, що має розважальну мету та потенційну комерційну реалізацію. ANNOTATION This bachelor's thesis on the topic "Software for a Social Interaction Simulation Game" contains 97 pages, 7 tables, 23 figures, a bibliography of titles, and 4 appendices. The purpose of this bachelor’s thesis is to demonstrate the acquired software development skills in the chosen field. Main tasks in designing the information system Create a scalable and flexible application architecture. Achieve the highest possible level of optimization for the simulation. The subject of the work is Simulation of social interaction. The subject of development is A cross-platform application that allows simulating the social behavior of virtual characters within a settlement. The following tasks have been completed An application has been created that serves an entertainment purpose and has potential for commercial implementation. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9745 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавраТкаченко Владислав Анатолійович.pdf Restricted Access | 3.01 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ГРИ-СИМУЛЯТОРА
СОЦІАЛЬНОЇ ВЗАЄМОДІЇ»
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності 121 «Інженерія програмного
забезпечення»
Студент Ткаченко В. А.
(прізвище та ініціали)
Керівник Куницька С. Ю.
(прізвище та ініціали)
Рецензент Захарова М. В.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
Сергій ГОЛУБ
« » 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Ткаченку Владиславу Анатолійовичу
(прізвище, ім’я, по батькові)
1. Тему проєкту (роботи) «Програмне забезпечення гри-симулятора соціальної взаємодії»
Керівник проєкту (роботи) Куницька Світлана Юріївна, к.т.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «12»
березня 2026 року № 56/03-03
2. Строк подання студентом проєкту (роботи) 2026 року
3. Вхідні дані до проєкту (роботи) стандарти програмного забезпечення; вимоги до проєкту:
правові вимоги; технічні вхідні дані
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Існуючі методи та засоби розв‘язання поставлених завдань; Проєктування та моделювання
програмного забезпечення; Розробка та тестування програмного забезпечення; Висновки; Список
використаних джерел; Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проєкту);
6. Консультанти розділів роботи
Прізвище, ініціали та Підпис, дата
Розділ
посади консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання грудень 2025 р
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
етапів
№ п/п Назва етапів випускної роботи Примітки
кваліфікаційної
роботи
1 Постановка задачі. Затвердження завдання 12.04.2026 виконано
1 етап
1 Аналіз шляхів вирішення поставленої задачі 20.04.2026 виконано
2 Вибір кінцевого варіанту проектного рішення 25.04.2026 виконано
3 Оформлення первісної редакції роботи 02.05.2026 виконано
2 етап
1 Узгодження прийнятих проектних рішень з керівником 12.05.2026 виконано
2 Оформлення пояснювальної записки 17.05.2026 виконано
3 Попередній захист роботи 21.05.2026 виконано
4 Затвердження роботи 25.05.2026 виконано
5 Рецензування роботи 28.05.2026 виконано
6 Захист роботи 01.06.2026
Студент Ткаченко В. А.
(підпис) (прізвище та ініціали)
Керівник роботи Куницька С. Ю.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Кваліфікаційна робота бакалавра на тему «Програмне забезпечення гри-
симулятора соціальної взаємодії» містить 97 сторінок, 7 таблиць, 23 рисунків,
список використаних джерел з 23 найменувань, 4 додатків.
Метою виконання кваліфікаційної роботи бакалавра є демонстрація набутих
навичок розробки програмного забезпечення в обраній області.
Головні завдання при проєктуванні інформаційної системи
Створити масштабовану та гнучку архітектуру додатку.
Досягти максимально можливого рівня оптимізації для симуляції.
Об'єктом роботи є cимуляція соціальної взаємодії.
Предметом розробки є крос-платформений додаток, що дозволяє симулювати
соціальну поведінку віртуальних персонажів в межах населеного пункту.
Вирішено наступні поставлені задачі
Створено додаток, що має розважальну мету та потенційну комерційну
реалізацію.
Ключові слова: SIMULATION, UNITY, C#, 2D, OOP, CROSS PLATFORM
ANNOTATION
This bachelor's thesis on the topic "Software for a Social Interaction Simulation
Game" contains 97 pages, 7 tables, 23 figures, a bibliography of titles, and 4 appendices.
The purpose of this bachelor’s thesis is to demonstrate the acquired software
development skills in the chosen field.
Main tasks in designing the information system
Create a scalable and flexible application architecture. Achieve the highest possible
level of optimization for the simulation.
The subject of the work is Simulation of social interaction.
The subject of development is
A cross-platform application that allows simulating the social behavior of virtual
characters within a settlement.
The following tasks have been completed
An application has been created that serves an entertainment purpose and has
potential for commercial implementation.
Key words: SIMULATION, UNITY, C#, 2D, OOP, CROSS PLATFORM
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ................................................................. 8
ВСТУП ...................................................................................................................... 9
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ............................................................................... 11
1.1. Аналіз технічної інформації ...................................................................... 11
1.2. Актуальність задачі .................................................................................... 13
1.3. Аналіз існуючих програмних засобів ....................................................... 14
1.4. Аналіз способів вирішення задачі ............................................................. 16
1.5. Постановка задачі ....................................................................................... 19
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ .......................................................... 22
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЄКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ .......................................................................... 23
2.1. Моделювання предметної області ............................................................. 23
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області ........................................................................ 23
2.1.2. Елементи моделювання предметної області .................................... 27
2.1.3. Робоча область моделювання ............................................................ 27
2.2. Формування та аналіз вимог ...................................................................... 28
2.2.1. Формування вимог про програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги .............................................................................. 29
2.2.2. Формування вимог за допомогою діаграми прецедентів ................ 31
2.3. Проєктування логічної структури програмного комплексу .................... 32
2.3.1. Діаграми класів ................................................................................... 33
2.3.2. Діаграми пакетів ................................................................................. 35
2.4. Архітектурне проєктування ....................................................................... 38
2.4.1. Діаграма компонентів ........................................................................ 38
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ................................................................................................... 40
2.5. Моделювання поведінки системи ............................................................. 41
2.5.1. Діаграма діяльності ............................................................................ 42
2.5.2. Діаграма послідовності ...................................................................... 43
Програмне забезпечення гри-симулятора
соціальної взаємодії
2.5.3. Діаграма комунікації .......................................................................... 45
2.5.4. Діаграма скінченного автомата ......................................................... 47
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ ............................................................ 50
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ................................................................................................. 51
3.1. Розробка програмного комплексу ............................................................. 51
3.1.1. Обґрунтування вибору засобів реалізації ......................................... 51
3.1.2. Опис структурної (функціональної) схеми ...................................... 52
3.1.3. Опис логічної схеми системи ............................................................ 55
3.1.4. Розробка бази даних ........................................................................... 57
3.1.5. Розробка інтерфейсу користувача ..................................................... 58
3.1.6. Опис розробки програмних компонентів ......................................... 61
3.2. Тестування системи .................................................................................... 64
3.2.1. Модульне тестування ......................................................................... 64
3.2.2. Інтеграційне тестування ..................................................................... 65
3.2.3. Системне тестування .......................................................................... 66
3.2.4. Приймальне тестування ..................................................................... 67
3.3. Приклади впровадженого програмного комплексу ................................. 71
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ .......................................................... 76
ВИСНОВКИ ........................................................................................................... 77
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................... 79
ДОДАТОК А ........................................................................................................... 82
ДОДАТОК Б ........................................................................................................... 84
ДОДАТОК В ........................................................................................................... 81
ДОДАТОК Г ........................................................................................................... 84
ЧДТУ 262264.025 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
ШІ Штучний інтелект. Здатність комп'ютерних систем імітувати
когнітивні функції, такі як планування, розпізнавання
перешкод та автономне прийняття рішень на основі аналізу
потреб.
JSON (JavaScript Object Notation) Текстовий формат обміну даними,
який легко читається людиною та обробляється машиною.
Використовується для файлів локалізації та налаштувань.
NavMesh (Navigation Mesh, ua "Навігаційна сітка") Математична
структура даних у вигляді графа, що генерується рушієм
поверх геометрії рівня та визначає зони, доступні для
переміщення агентів.
NPC (Non-Playable Character, ua "Неігровий персонаж")
Віртуальний житель у симуляторі, чия поведінка повністю
керується внутрішніми алгоритмами (ШІ), а не гравцем.
SDF (Signed Distance Field) Технологія рендерингу, що
використовується в пакеті TextMeshPro для математичного
опису меж шрифтів, забезпечуючи їх чіткість при будь-якому
масштабуванні.
UI (User Interface, ua "Користувацький інтерфейс") Сукупність
графічних та інтерактивних елементів (кнопки, вікна, панелі),
через які здійснюється взаємодія користувача з програмним
забезпеченням.
8
ЧДТУ 262264.025 ПЗ
ВСТУП
Актуальність теми. Проєктування програмного забезпечення в області
соціальних симуляторів демонструє стійкий інтерес до симуляції реального світу.
Симулятори соціальної взаємодії займають особливу нішу, оскільки дозволяють не
лише розважати користувача, але й слугувати інструментом для дослідження
соціологічних моделей, урбаністики та психології натовпу. Створення автономних
віртуальних персонажів, які здатні приймати рішення на основі власних параметрів
та взаємодіяти з навколишнім середовищем, є складним алгоритмічним завданням.
Мета і завдання розробки. Метою кваліфікаційної роботи є проєктування та
розробка програмного забезпечення гри-симулятора соціальної взаємодії. Додаток
повинен моделювати поведінку людей на інтерактивній карті, де кожен персонаж має
свої унікальні характеристики, потреби та завдання, взаємодіє з іншими
персонажами та місцями інтересу.
Об'єкт розробки. Процес моделювання та управління життєвим циклом
автономних віртуальних персонажів в умовах симульованого міського середовища.
Предмет розробки. Кросплатформений програмний додаток, що дозволяє
симулювати соціальну поведінку віртуальних персонажів в межах віртуального
населеного пункту.
Методи проєктування та конструювання. Використовувались методи
об'єктно-орієнтованого програмування, патерни проєктування "Singleton", "State",
"Observer", алгоритми пошуку шляху на графі "NavMesh" та архітектурні принципи
побудови ігрових рушіїв, такі як Entity-Component-System та
MonoBehaviour-архітектура.
Опис отриманих результатів. У процесі виконання кваліфікаційної роботи
було спроектовано та реалізовано програмний комплекс гри-симулятора соціальної
взаємодії на базі ігрового рушія Unity. Основними отриманими результатами є:
розробка модульної архітектури, що забезпечує гнучкість при додаванні нових типів
9
ЧДТУ 262264.025 ПЗ
ігрових агентів та локацій; впровадження системи ієрархічного планування завдань
(Task Scheduler), яка дозволяє NPC здійснювати автономний вибір дій на основі
пріоритетів потреб; створення власної бінарної підсистеми серіалізації для швидкого
збереження та завантаження стану складної симуляції. Система підтвердила свою
працездатність при тестуванні в умовах моделювання роботизованої взаємодії сотень
агентів у реальному часі, зберігаючи стабільні показники частоти кадрів.
Практичне значення отриманих результатів. Розроблене програмне
забезпечення має високий потенціал практичного застосування у кількох напрямках.
Насамперед, проект може бути використаний як базовий прототип для створення
інтерактивних розважальних продуктів у жанрі симуляторів життя. Крім того,
архітектура системи, побудована на принципах модульності та автономної поведінки
агентів, робить її придатною для використання в якості дослідницького
інструментарію в соціологічних експериментах та урбаністичному моделюванні, де
необхідно вивчити вплив різних факторів на поведінку групи людей у межах певного
населеного пункту. Можливість швидкого портування на мобільні та десктопні
платформи розширює коло потенційних користувачів, охоплюючи як фахівців, так і
аматорів.
Особистий внесок автора. Особистий внесок автора полягає у проведенні
комплексного аналізу технічної документації та методів розробки ігрових ШІ, на
основі чого було розроблено концептуальну модель предметної області. Автором
було самостійно спроєктовано об'єктно-орієнтовану архітектуру програмного
продукту, реалізовано алгоритмічну базу для планувальника завдань та системи
навігації агентів. Також автором було розроблено кастомну підсистему серіалізації
даних, спроектовано графічний інтерфейс користувача з підтримкою адаптивності,
виконано повний цикл налагодження та тестування системи, включно з проведенням
профілювання продуктивності та оптимізацією критичних вузлів програмного коду.
10
ЧДТУ 262264.025 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1. Аналіз технічної інформації
Розробка складної програмної системи, якою є гра-симулятор соціальної
взаємодії, вимагає попереднього глибокого аналізу існуючої технічної документації,
специфікацій інструментальних засобів та архітектурних стандартів. Цей етап є
критично важливим для мінімізації ризиків на етапі безпосереднього програмування,
а також для вибору оптимальних алгоритмів та патернів проєктування [1].
Аналіз технічної документації в рамках даної кваліфікаційної роботи можна
розділити на три основні напрямки: вивчення документації базового ігрового рушія
та мови програмування, аналіз специфікацій алгоритмів штучного інтелекту (ШІ) та
дослідження стандартів збереження і серіалізації даних.
Оскільки основним середовищем розробки виступає ігровий рушій Unity,
першочерговим завданням став аналіз офіційної документації Unity User Manual та
Unity Scripting API. Особлива увага приділялася розділам, що описують життєвий
цикл об'єктів (життєвий цикл MonoBehaviour), оскільки неправильне використання
методів оновлення екрану (наприклад, Update проти FixedUpdate чи Coroutines) може
призвести до критичного падіння продуктивності при симуляції великої кількості
автономних агентів [2].
Крім того, було детально опрацьовано документацію підсистеми просторової
навігації Unity Navigation System (NavMesh) [3]. Технічні специфікації компонентів
NavMeshAgent та NavMeshSurface визначають обмеження щодо обчислення
найкоротших шляхів на місцевості. Аналіз цих документів дозволив зрозуміти, як
ефективно делегувати ресурсомісткі математичні обчислення алгоритму A*
нативному ядру рушія, замість написання власних менш оптимізованих аналогів.
Базовою мовою логіки системи є C#. Відповідно, було проведено огляд
офіційної технічної документації від Microsoft (Microsoft C# Documentation), зокрема
11
ЧДТУ 262264.025 ПЗ
розділів щодо управління пам'яттю (Garbage Collection), роботи з узагальненими
колекціями (Generics) та використання технології LINQ (Language Integrated Query)
для ефективної фільтрації ігрових об'єктів (наприклад, пошуку найближчої точки
інтересу на карті) [4].
Специфікації алгоритмів штучного інтелекту та моделювання поведінки
Наступним кроком став аналіз технічної та академічної літератури у сфері
ігрового штучного інтелекту. Симуляція поведінки людей вимагає впровадження
систем прийняття рішень. Було проаналізовано технічні описи реалізації скінченних
автоматів (Finite State Machines, FSM), дерев поведінки (Behavior Trees) та систем
планування на основі цілей (Goal-Oriented Action Planning, GOAP) [5].
На основі документації було визначено, що для симулятора соціальної
взаємодії мікро-рівня найбільш оптимальним є поєднання FSM для управління
базовими фізичними станами (Рух, Очікування, Виконання дії) та евристичного
планувальника завдань (Task Scheduler) для динамічного вибору пріоритетів на
основі поточних потреб агента (голод, енергія, соціалізація).
Гра-симулятор генерує великі масиви динамічних даних, які необхідно
зберігати у файлову систему пристрою. Аналіз документації щодо форматів обміну
даними (зокрема специфікацій JSON — JavaScript Object Notation стандарту
ECMA-404) показав, що текстові формати зручні для локалізації та налаштувань,
проте занадто повільні для збереження тисяч ігрових змінних у реальному часі [6].
У зв'язку з цим було опрацьовано документацію платформи .NET щодо
бінарної серіалізації (System.IO.BinaryWriter та BinaryReader). Аналіз цих класів
дозволяє спроєктувати власну підсистему конвертації об'єктів, яка забезпечує
швидкий доступ до файлової системи з мінімальним навантаженням на процесор.
Отже, проведений аналіз технічної документації, специфікацій API та
архітектурних керівництв забезпечив повне розуміння технічних обмежень та
можливостей обраного стеку технологій. Це дозволило сформувати чітке бачення
архітектури майбутнього симулятора, уникнути типових помилок при роботі з
12
ЧДТУ 262264.025 ПЗ
підсистемами навігації та ШІ, а також підготувати надійне підґрунтя для етапу
безпосереднього проєктування та розробки програмного продукту.
1.2. Актуальність задачі
Проєктування програмного забезпечення для симуляторів соціальних систем та
ігрова індустрія в жанрі "симулятори життя" є надзвичайно широкою та
багатогранною областю досліджень. Основний фокус цієї предметної області
зосереджений на розробці алгоритмів автономної поведінки віртуальних персонажів,
які функціонують у динамічному віртуальному середовищі.
Історично симуляція соціальної поведінки бере свій початок з клітинних
автоматів, таких як "Гра Життя" Джона Конвея та ранніх академічних моделей
поширення впливу. Однак із розвитком обчислювальних потужностей стало
можливим створення складних систем, де кожен окремий індивід моделюється як
унікальна сутність із власними внутрішніми станами.
У сучасних іграх-симуляторах кожен персонаж має набір атрибутів, що
визначають його фізіологічний та психологічний стан. До базових характеристик
належать вік, стать, риси характеру (менталітет), а також динамічні потреби (голод,
енергія, емоційний стан тощо). Саме потреби є головним рушієм ігрового процесу.
Коли певний показник падає нижче критичного рівня, персонаж повинен самостійно
прийняти рішення щодо його відновлення.
Процес прийняття рішень базується на системах штучного інтелекту.
Найчастіше використовуються скінченні автомати, які дозволяють персонажу
перебувати в одному з визначених станів. Більш складні системи використовують
дерева поведінки або алгоритми планування цілей, що дозволяє персонажам
динамічно будувати ланцюжки дій для досягнення бажаного результату в мінливому
середовищі [7].
Невід'ємною частиною симулятора є просторове середовище (карта). У
контексті цієї розробки карта являє собою двовимірну проекцію населеного пункту
13
ЧДТУ 262264.025 ПЗ
(наприклад, реального міста чи села), що містить навігаційну сітку та множину
інтерактивних об'єктів.
1.3. Аналіз існуючих програмних засобів
Жанр симуляторів життя та управління є одним із найпопулярніших в ігровій
індустрії. Існує кілька видатних комерційних та академічних прикладів систем
симуляції поведінки, аналіз яких дозволяє виділити найкращі практики та типові
помилки.
"The Sims" є найвідомішим та найуспішнішим комерційним прикладом
симулятора соціальної взаємодії. Гра фокусується на управлінні життя окремих
сімей. Персонажі мають складну систему емоцій, бажань та потреб, таких як голод,
гігієна, спілкування, енергія. Штучний інтелект у The Sims побудований на концепції
"розумних об'єктів". Ігрові об'єкти самі транслюють у простір інформацію про те, які
потреби вони можуть задовольнити, а персонажі обирають об'єкт із найвищим
пріоритетом.
Переваги: неперевершена глибина симуляції мікрорівня, детальна система
емоцій та соціальних зв'язків.
Недоліки: гра є закритою системою, орієнтованою суто на розвагу. Вона не
дозволяє імпортувати власні карти міст або масштабувати симуляцію на рівень
макроекономіки цілого населеного пункту.
"Cities: Skylines" це класичний містобудівний симулятор, який моделює життя
мегаполісу на макрорівні. Гра відрізняється неймовірно складною симуляцією
трафіку. Кожен житель міста (яких може бути сотня тисяч) має своє місце
проживання, роботу та маршрути пересування. Рушій гри постійно рахує найкоротші
шляхи для автомобілів та пішоходів.
Переваги: здатність обробляти величезні обсяги даних, відмінна оптимізація
маршрутизації.
14
ЧДТУ 262264.025 ПЗ
Недоліки: відсутність індивідуальності. персонажі в "Cities: Skylines" – це
лише статистичні одиниці, що переміщуються між точками A і B. Вони не мають
психологічних рис чи складної соціальної взаємодії між собою.
"RimWorld" – симулятор управління космічною колонією, де кожен персонаж
має свої унікальні риси характеру, історію, навички та потреби. Система штучного
інтелекту в "RimWorld" використовує потужний планувальник завдань, який задає
пріоритети роботи (рубка дерев, будівництво, лікування) залежно від налаштувань
гравця та поточних потреб колоніста.
Гра також славиться своїм генератором подій – "Оповідачем", який створює
драматичні ситуації.
Переваги: дуже гнучка архітектура штучного інтелекту, модульність, глибока
система генерації персонажів.
Недоліки: надто сильний вплив випадкових подій, високий поріг входу та
інтенсивне управління.
У наукових дослідженнях для моделювання соціальних процесів часто
використовують платформу "NetLogo". Вона дозволяє створювати моделі з багатьма
персонажами для вивчення поведінки (наприклад, моделювання сегрегації Томаса
Шеллінга або поширення вірусів).
"MATSim" використовується для масштабного моделювання транспортних
потоків на основі щоденного розкладу людей.
Переваги: наукова точність, відкритий вихідний код.
Недоліки: повна відсутність якісного графічного інтерфейсу та ігрових
елементів, що робить їх непридатними для використання звичайними користувачами.
Аналіз наведених аналогів (див. таблиця 1.1) показує, що на ринку є певна
прогалина. Бракує системи, яка б поєднувала глибину індивідуальної симуляції (як у
"The Sims" або "RimWorld") із можливістю застосовувати ці механіки до реальних
мап населених пунктів та мала б відкриту, гнучку архітектуру для подальшого
розширення розробниками.
15
ЧДТУ 262264.025 ПЗ
Таблиця 1.1
Порівняльний аналіз аналогів за критеріями
Критерій The Sims Cities: Skylines RimWorld Програмний
комплекс
(Симулятор)
Глибина Висока Низька Висока Висока
симуляції
Масштабо- Низька Висока Середня Середня
ваність
Наявність Висока Висока Висока Висока
розвиненого UI
Відкритість для Низька Середня Висока Висока
додавання карт
1.4. Аналіз способів вирішення задачі
Розробка гри-симулятора соціальної взаємодії супроводжується значною
кількістю технічних, архітектурних та алгоритмічних викликів. Системи такого
класу є обчислювально складними, оскільки вимагають постійного оновлення станів
безлічі об'єктів у реальному часі.
Основною проблемою симуляторів є навантаження на центральний процесор.
Якщо на карті знаходиться 1000 персонажів, і кожен з них у кожному кадрі гри (60
разів на секунду) викликає метод "Update" для перевірки своїх потреб та пошуку
16
ЧДТУ 262264.025 ПЗ
найближчої цілі, продуктивність системи суттєво впаде. Проблема вирішується
шляхом переходу від класичного об'єктно-орієнтованого програмування до
архітектури "Data-Oriented Design" [8] (наприклад, використання "Entity Component
System" [9]) або ж за допомогою використання корутин ("Coroutines") у Unity, які
дозволяють розділити важкі обчислення на кілька кадрів.
Реалізація реалістичного планувальника вимагає тонкого налаштування
пріоритетів. Наприклад, якщо персонаж хоче спати, але раптом починається пожежа,
його пріоритети мають миттєво змінитися. Окрім того, виникають проблеми
синхронізації та конкуренції за ресурси. Якщо два персонажі одночасно вирішать
задовольнити потребу в їжі і попрямують до одного холодильника, система повинна
коректно обробити цю ситуацію. Один персонаж повинен зайняти ресурс, а інший –
або стати в чергу, або знайти альтернативне джерело.
Забезпечення коректного переміщення сотень персонажів по карті міста є
складним алгоритмічним завданням. Використання класичного алгоритму для
кожного кроку кожного персонажа є занадто "важким". Необхідно використовувати
заготовлені навігаційні сітки, які дозволяють швидко прокладати маршрут.
Ігровий стан у симуляторі складається з тисяч параметрів. Позиція кожного
персонажа, його поточні потреби, активне завдання, відстань до цілі тощо.
Використання стандартних засобів серіалізації часто є занадто повільним для
великих збережень і створює проблеми зі "сміттєзбирачем" (Garbage Collector).
Оскільки гравець не керує персонажами напряму, а лише створює умови,
поведінка системи формується в ході виконання, як результат взаємодії простих
правил. Проблема полягає у балансуванні цих правил. Якщо потреби спадають
занадто швидко, персонажі будуть лише бігати за їжею і сном, не маючи часу на
соціальну взаємодію.
Проєктування математичної моделі балансу вимагає тривалого ітеративного
тестування.
17
ЧДТУ 262264.025 ПЗ
Для розв'язання поставлених завдань і подолання описаних проблем
застосовується набір спеціалізованих ігрових технологій та методологій розробки
програмного забезпечення.
Основним інструментом реалізації обрано кросплатформний ігровий рушій
Unity. Цей вибір обґрунтований кількома ключовими факторами.
По-перше, Unity має величезну екосистему та розвинену документацію, що
суттєво прискорює процес розробки. По-друге, рушій надає потужні вбудовані
підсистеми: фізичний рушій (Physics2D), систему користувацького інтерфейсу
("Unity UI" / "TextMeshPro" [10]) та найголовніше – оптимізовану систему навігації
"NavMesh" [11], яка бере на себе складні математичні обчислення алгоритмів пошуку
шляху.
Мовою програмування проєкту виступає C#. Це сучасна, об'єктно-орієнтована
мова з суворою типізацією, яка ідеально підходить для написання складної
бізнес-логіки. Для проєктування архітектури використовуються загальноприйняті
правила проєктування, адаптовані під парадигму компонентів Unity –
MonoBehaviour:
– Singleton (Одинак) – використовується для створення глобальних
менеджерів (GameManager, SoundManager), які існують в єдиному
екземплярі протягом усього життєвого циклу програми [12];
– State Machine (Скінченний автомат) – застосовується для моделювання
поведінки персонажів ("Idle", "Moving", "Working") [13];
– Observer (Спостерігач) – використовується для створення інтерфейсу
користувача. Наприклад, коли потреба персонажа змінюється, інтерфейсна
панель автоматично оновлює відповідний повзунок без необхідності
постійного опитування [14];
– Factory Method (Фабричний метод) – застосовується при генерації нових
персонажів на основі заданих параметрів [15].
18
ЧДТУ 262264.025 ПЗ
Для створення користувацького інтерфейсу застосовуються інструменти "Unity
Canvas". Використання пакету "TextMeshPro" дозволяє відображати текст за
допомогою "Signed Distance Fields" [10], що гарантує високу чіткість шрифтів при
будь-якому масштабуванні карти. Для організації збереження даних розробляється
власна модульна система конвертації, яка працює з абстрактними потоками байтів.
Розробка ведеться з дотриманням принципів "SOLID" та "Clean Code" [16]. Це
передбачає розбиття системи на малі, незалежні компоненти, що відповідають за
одну конкретну функцію. Такий підхід значно спрощує подальше тестування та
розширення функціоналу симулятора.
1.5. Постановка задачі
На основі проведеного аналізу предметної області, дослідження аналогів та
вивчення технічних викликів було сформульовано конкретні завдання для
кваліфікаційної роботи. Кінцевою метою є створення робочого прототипу
гри-симулятора соціальної взаємодії, який дозволить гравцю спостерігати за життям
автономних персонажів на різноманітних картах.
Програмний комплекс повинен задовольняти наступні вимоги та виконувати
такі завдання:
– проєктування архітектури ігрового циклу та менеджменту сцен. Реалізація
глобального керування станами гри (Головне меню, Режим симуляції,
Режим паузи);
– розробка модуля ігрового середовища. Забезпечення завантаження
2D-малюнків карт реальних населених пунктів (Черкаси, Київ, Хацьки) з
підтримкою візуальних тем (світла або темна). Інтеграція навігаційної сітки
для коректного переміщення об'єктів;
– створення модуля генерації та управління персонажами. Реалізація гнучкої
системи характеристик, таких як стать та менталітет. Візуалізація
персонажів за допомогою набору заготовлених зображень (обличчя, одяг);
19
ЧДТУ 262264.025 ПЗ
– розробка системи штучного інтелекту. Створення алгоритму, який аналізує
поточні потреби персонажа (енергія, соціалізація) та динамічно формує
чергу завдань. Налаштування пріоритетів виконання завдань. Наприклад,
сон має вищий пріоритет за прогулянку;
– реалізація підсистеми переміщення. Інтеграція компонента штучного
інтелекту з NavMeshAgent для плавного переміщення спрайтів по карті з
уникненням перешкод;
– розробка користувацького інтерфейсу. Створення адаптивних панелей.
Головне меню, екран створення нової симуляції, панель з відображенням
повідомлень про події та картка детальної інформації про обраного
персонажа;
– проєктування системи збереження. Розробка оптимізованих класів для
бінарної серіалізації з метою швидкого збереження та завантаження стану
всієї симуляції у файлову систему пристрою;
– оптимізація та тестування. Проведення профілювання продуктивності для
забезпечення стабільних 60 кадрів в секунду при одночасній симуляції
базової кількості (до 50) активних персонажів. Виявлення та усунення
"витоків пам'яті".
Таким чином, предметна область охоплює інтеграцію архітектури ігрового
рушія, алгоритмів пошуку шляху, систем прийняття рішень та управління даними
для створення ілюзії "живого" соціуму на екрані користувача.
Важливою складовою реалізації даного проекту є перехід від статичних
ігрових сценаріїв до емерджентної поведінки, що виникає як наслідок взаємодії
простих правил, закладених у логіку штучного інтелекту кожного агента. Така
концепція дозволяє уникнути передбачуваності, притаманної лінійним ігровим
проектам, та створює унікальний досвід для кожного циклу симуляції. Відтак,
програмна архітектура будується з акцентом на децентралізоване управління, де
кожен персонаж оперує як незалежна інтелектуальна одиниця, що самостійно
20
ЧДТУ 262264.025 ПЗ
адаптується до зовнішніх обставин у межах віртуального міського середовища.
Окрему увагу в ході розробки приділено оптимізації ресурсомістких операцій,
зокрема алгоритмам пошуку шляху та обробці масивів даних у реальному часі.
Використання сучасних підходів до програмування в межах ігрового рушія Unity
дозволяє забезпечити стабільну роботу системи навіть при значній кількості
одночасно активних сутностей.
Виконання поставлених завдань дозволить створити надійну та масштабовану
програмну платформу, яка може бути використана не лише в розважальних цілях, але
й як основа для подальших науково-дослідних експериментів у галузі соціології та
моделювання міського середовища.
21
ЧДТУ 262264.025 ПЗ
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було проведено детальний системний аналіз предметної
області розробки симуляторів життя та комп’ютерного моделювання соціальної
взаємодії. Досліджено еволюцію багатоагентних систем та принципи побудови
автономних віртуальних персонажів (NPC) з власною системою потреб та прийняття
рішень.
Порівняльний аналіз існуючих аналогів (The Sims, Cities: Skylines, RimWorld)
дозволив виявити їхні переваги та недоліки. Встановлено, що на ринку бракує
гнучкої платформи, яка б поєднувала глибоку індивідуальну симуляцію потреб з
можливістю легкої інтеграції власних карт реальних населених пунктів. Визначено
ключові технічні проблеми, що виникають при розробці подібних систем:
оптимізація обчислень ШІ для великої кількості агентів, маршрутизація, та
серіалізація масивів даних. На основі цих досліджень було сформульовано мету,
функціональні вимоги та конкретні завдання кваліфікаційної роботи.
Застосування модульних рішень та принципів чистої архітектури сприятиме
підвищенню стійкості коду, спрощуючи при цьому процес інтеграції нових типів
соціальних взаємодій та розширення функціональних можливостей платформи без
порушення цілісності існуючої системи.
22
ЧДТУ 262264.025 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЄКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
2.1. Моделювання предметної області
Цей підрозділ зосереджений на концептуальному моделюванні ігрової системи.
Тут визначаються ключові сутності симулятора (персонажі, завдання, карта),
описуються їхні атрибути, взаємозв'язки та наводиться словник термінів, необхідний
для однозначного розуміння логіки під час об'єктно-орієнтованого проєктування.
2.1.1. Предметна область моделювання. Модель предметної області. Словник
предметної області.
Предметна область моделювання фокусується на трансформації абстрактних
психологічних та біологічних параметрів персонажів у конкретні ігрові події,
переміщення та взаємодії, що сумарно формують ілюзію самостійного соціуму в
межах розробленого програмного забезпечення.
Предметом моделювання тут є не просто переміщення, а прийняття рішень у
ситуаціях вибору. Ми моделюємо конфлікт між різними потребами (наприклад,
потреба в їжі проти потреби у спілкуванні) через застосування евристичних функцій.
Таким чином, область моделювання включає алгоритмічну логіку, яка перетворює
«дефіцит потреби» на конкретний вектор руху агента до вибраного об'єкта.
Модель предметної області симулятора соціальної взаємодії відображає
логічну структуру та архітектуру ігрової системи. Її головне завдання полягає у
визначенні ключових концептуальних сутностей, їхніх внутрішніх характеристик та
принципів взаємодії у віртуальному просторі.
Оскільки розроблюваний програмний продукт є системою, що моделює життя,
модель предметної області повинна відтворювати соціальні, фізіологічні та
23
ЧДТУ 262264.025 ПЗ
просторові аспекти поведінки автономних персонажів. Далі наводяться основні
компоненти моделі предметної області.
Сутності персонажів. Це центральні об'єкти симуляції. Кожен персонаж є
унікальною програмною одиницею, яка має власні параметри. До статичних
параметрів належать ім’я, прізвище, вік, тип менталітету, стать та унікальний
ідентифікатор. До динамічних характеристик, що формують ядро ігрового процесу,
відносяться показники потреб, наприклад, енергія, голод, рівень соціалізації;
Психологічні моделі. Важливим аспектом моделювання є те, що персонажі не
повинні поводитися ідентично. Сутність менталітету визначає шаблони прийняття
рішень та схильність персонажа до певних видів діяльності. Наприклад, персонаж з
менталітетом "Екстраверт" матиме швидше падіння соціальних потреб і частіше
ініціюватиме взаємодію з іншими персонажами;
Просторове середовище. Це ігрова сцена, яка обмежує переміщення
персонажів та містить навігаційну інформацію. Просторове середовище не є
статичним фоном, воно містить координатні сітки та множину інтерактивних зон;
Завдання та активності. Це сутності, що описують дії, які персонаж може
виконувати. Кожне завдання має свою тривалість, умови виконання та вплив на
характеристики персонажа. Планувальник завдань динамічно генерує та призначає ці
об'єкти персонажам на основі їхнього поточного стану та пріоритетів;
Система збереження стану. Окремим компонентом моделі є абстрактні
структури даних, які відповідають за фіксацію динамічного стану всіх персонажів та
середовища для запису у файлову систему пристрою.
Словник предметної області
Розглянемо основні елементи словника предметної області:
– UI – (User Interface, ua. "Користувацький інтерфейс") сукупність графічних
та інтерактивних елементів (кнопки, вікна, панелі), через які здійснюється
взаємодія користувача з програмним забезпеченням;
24
ЧДТУ 262264.025 ПЗ
– NPC – (Non-Playable Character, ua. "неігровий персонаж") віртуальний
житель у симуляторі, чия поведінка повністю керується внутрішніми
алгоритмами, а не гравцем;
– Coroutine – (Cooperative Routine, ua) Спеціальний тип методу в рушії Unity,
який дозволяє призупиняти своє виконання і повертати контроль системі,
продовжуючи роботу в наступних кадрах. Використовується для
оптимізації важких обчислень;
– MonoBehaviour – Базовий клас у рушії Unity, від якого успадковуються
скрипти для прикріплення до ігрових об'єктів. Надає доступ до життєвого
циклу об'єкта (методи Start, Update тощо);
– спрайт – Двовимірне растрове зображення (графічний об'єкт), що
використовується в комп'ютерній графіці для візуалізації персонажів,
предметів оточення та елементів інтерфейсу;
– ШІ – Здатність комп'ютерних систем імітувати когнітивні функції, такі як
планування, розпізнавання перешкод та автономне прийняття рішень на
основі аналізу потреб;
– JSON – Текстовий формат обміну даними, який легко читається людиною
та обробляється машиною. Використовується для файлів локалізації та
налаштувань;
– скрипт – (Script, ua. "Сценарій") Програмний код (у межах цієї роботи –
написаний мовою C#), який містить інструкції для виконання специфічних
завдань і визначає логіку та поведінку компонентів системи;
– патерн – (Pattern, ua. "Шаблон") Шаблон проєктування; повторювана
архітектурна конструкція (наприклад, Singleton, State, Factory), яка є
ефективним стандартизованим рішенням типової проблеми програмування;
– потреба – (Need) кількісний показник (наприклад, від 0 до 100), що
відображає певний фізіологічний чи соціальний стан персонажа (Голод,
Втома, Настрій). Падіння потреби стимулює персонажа до дії;
25
ЧДТУ 262264.025 ПЗ
– завдання – (Task) одиниця діяльності персонажа. Має власну логіку
виконання, тривалість та вплив на потреби. Приклади: "Спати", "Їсти",
"Спілкуватися";
– планувальник завдань – (Task Scheduler) головний компонент штучного
інтелекту персонажа, який у реальному часі аналізує потреби та призначає
найактуальніше завдання;
– навігаційна сітка – (NavMesh) математична структура даних (граф),
згенерована поверх ігрової карти, що визначає зони, якими персонажі
можуть переміщуватись;
– агент – Автономна обчислювальна сутність, яка спостерігає за навколишнім
середовищем та самостійно приймає рішення для досягнення заданих
цілей;
– агент переміщення – програмний компонент, який обчислює найкоротший
шлях до цілі на NavMesh та керує рухом відображення персонажа;
– менталітет – набір коефіцієнтів та модифікаторів, що впливають на
швидкість зміни потреб і вибір завдань, роблячи поведінку кожного
персонажа унікальною;
– карта – ігрова локація, представлена графічно (малюнками), яка містить
точки інтересу;
– точка інтересу – (point of interest) координата на Карті, де персонаж може
виконати певне завдання (наприклад, ліжко для відпочинку);
– глобальний менеджер – (global manager) об’єкт в єдиному екземплярі, що
контролює життєвий цикл гри, переходи між сценами та ініціалізує
симуляцію;
– панель історії – елемент інтерфейсу, який у реальному часі відображає
текстові повідомлення про зміну станів (наприклад, "Персонаж А почав дію
Сон").
26
ЧДТУ 262264.025 ПЗ
2.1.2. Елементи моделювання предметної області
Елементи моделювання предметної області включають сутності, атрибути та
відносини між ними.
Відповідно до архітектури Unity ("Component-Based Architecture" [17]), ці
елементи часто впроваджені як окремі файли виконання ("MonoBehaviour"), що
кріпляться до ігрових об'єктів.
У нашій системі основними сутностями є "Character" (Персонаж), "Task"
(Завдання), "Map" (Карта) та "GameManager" (Управлінець гри). Також існують
сутності даних, такі як "GlobalData" та "CharacterData", що використовуються
виключно для збереження даних.
Сутність "Character" має такі ключові атрибути: "id" (ідентифікатор), "gender"
(стать), "mentality" (менталітет), "currentTask" (поточне активне завдання) та масив
"needs" (поточні значення потреб). Сутність "Task" містить атрибути: "type" (тип
завдання), "duration" (базовий час виконання) та "targetPosition" (координати для
переміщення).
Один "Map" містить множину об'єктів "Character" (відношення один до
багатьох). Кожен "Character" у певний момент часу виконує рівно одне активне
"Task" (відношення один до одного), але при цьому володіє власним примірником
"TaskScheduler" (відношення один до одного). "CharacterAgent" тісно пов'язаний з
"NavMesh" для здійснення переміщення.
2.1.3. Робоча область моделювання
Робоча область моделювання в межах даної роботи являє собою комплексне
віртуальне середовище, що базується на інтеграції ігрового рушія Unity 3D з
допоміжними інструментами візуалізації та аналізу даних.
Ця область визначає технічні межі, у яких відбувається імітація соціальних
процесів, і складається з трьох рівнів.
27
ЧДТУ 262264.025 ПЗ
Рівень геометричного моделювання. Це візуальний простір карти, де кожен
населений пункт (Черкаси, Київ, Хацьки) представлений як набір спрайтів, що
накладені на двовимірну сітку. Робоча область тут обмежена межами навігаційної
сітки, яка визначає допустимі шляхи переміщення для агентів. Моделювання на
цьому рівні передбачає постійний зв'язок між візуальною геометрією та логічною
навігацією.
Рівень обчислювальної логіки. Це простір виконання C#-скриптів, де
функціонують класи TaskScheduler, CharacterAgent та GameManager. Робоча область
цього рівня обмежується циклом оновлення рушія (Update / FixedUpdate), у межах
якого здійснюються математичні обчислення пріоритетів завдань та оновлення стану
потреб агентів.
Рівень даних та серіалізації. Робоча область моделювання також охоплює
файлову структуру, що формується в процесі роботи симулятора. Це область, де
динамічний стан об'єктів перетворюється на статичні бінарні дані. Тут відбувається
моделювання життєвого циклу інформації: від збору полів об'єктів CharacterData до
їх запису в індивідуальні .save файли.
Таким чином, робоча область моделювання не є пасивним середовищем, а
виступає активним інструментом, що забезпечує зворотний зв'язок між логікою ШІ
та візуальним представленням результатів симуляції. Вона забезпечує середовище
для профілювання продуктивності та валідації прийнятих агентами рішень, що є
основою для подальшої корекції поведінкових моделей у системі.
2.2. Формування та аналіз вимог
У цьому підрозділі здійснюється перехід від загальних потреб користувача до
технічних специфікацій. Будуть сформовані первинні, функціональні та
нефункціональні вимоги до продуктивності й архітектури, а також наведено діаграму
прецедентів для візуалізації варіантів взаємодії гравця з ігровим середовищем.
28
ЧДТУ 262264.025 ПЗ
2.2.1. Формування вимог про програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні вимоги.
Формування вимог про програмного забезпечення
Процес розробки симулятора починається зі збору первинних вимог (вимог
замовника), які описують систему з точки зору кінцевого користувача (гравця).
Первинні і детальні вимоги
Основними первинними вимогами є:
– можливість створення нової симуляції з вибором локації (карти) та
налаштуванням початкових параметрів середовища;
– наявність зручного інтерфейсу генерації персонажів, де гравець може
додавати нових жителів, обираючи їхню стать, зовнішній вигляд та
характер;
– спостереження за автономним життям створених персонажів у режимі
реального часу, можливість відстежувати їхні поточні дії та рівень
задоволення потреб;
– наявність системи збереження та завантаження ігрового прогресу, щоб
користувач міг перервати симуляцію та продовжити її пізніше;
– звуковий та візуальний супровід дій (анімації відображень, зміна
кольорової теми, фонова музика).
Вимоги замовника і розробника
На основі первинних вимог формуються детальні вимоги розробника (технічні
специфікації).
Архітектурні вимоги. Система має бути побудована на базі рушія Unity 3D з
використанням мови C#.
Код має бути поділений на незалежні менеджери та компоненти для
забезпечення низького рівня зв'язності.
29
ЧДТУ 262264.025 ПЗ
Вимоги до штучного інтелекту. Кожен персонаж повинен мати власний
екземпляр планувальника завдань, який реалізує функцію для вибору найважливішої
потреби та ініціює відповідну активність.
Вимоги до навігації. Переміщення спрайтів має здійснюватися через
підсистему NavMesh. Слід унеможливити ситуації, коли персонажі проходять крізь
стіни або будинки.
Вимоги до збереження даних. Серіалізація має уникати використання
повільного JsonUtility там, де це можливо. Стан має конвертуватися в масив байтів
через розроблену систему "DataConverter".
Вимоги до інтерфейсу. Всі текстові елементи інтерфейсу повинні бути
реалізовані через "TextMeshPro" для підтримки динамічного масштабування та
різних мовних локалізацій.
Функціональні та нефункціональні вимоги
Функціональні вимоги визначають, що саме має робити система. Для нашого
симулятора вони включають:
– підсистема ініціалізації, завантаження обраної сцени, ініціалізація
глобальних змінних, генерація сітки навігації;
– підсистема управління персонажем, створення нових екземплярів
персонажів, ініціалізація їхніх початкових потреб, запуск ігрового циклу;
– підсистема поведінки, обчислення падіння потреб із часом, пошук вільної
точки інтересу на карті, запуск процесу переміщення, відтворення анімації
виконання завдання, відновлення показника потреби після завершення
завдання;
– підсистема інтерфейсу: Обробка кліків миші по зображенням персонажів
для відкриття панелі розширених відомостей, відображення повідомлень та
запитів на підтвердження, виведення дій в панель історії.
Нефункціональні вимоги визначають якісні характеристики системи:
30
ЧДТУ 262264.025 ПЗ
– симулятор має підтримувати стабільні 60 кадрів на секунду при одночасній
активності до 50 персонажів на сучасних персональних комп'ютерах.
Обчислення алгоритмів пошуку шляху не повинні викликати помітних
мікрофрізів;
– архітектура коду повинна дозволяти розробникам додавати нові типи
завдань або нові локації без модифікації існуючого ядра системи;
– інтерфейс користувача повинен бути інтуїтивно зрозумілим, мати
адаптацію для підтримки різних роздільних здатностей екрану;
– система повинна коректно обробляти помилки (наприклад, неможливість
знайти шлях до об'єкта) без критичного завершення програми. Персонаж у
такому випадку має скидати поточне завдання та шукати альтернативу.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів є одним із основних інструментів, який дозволяє
візуалізувати взаємодію акторів із системою. У нашому випадку головним актором є
Користувач (Гравець), а також можна виділити системного актора – "Ігровий цикл",
який автоматично генерує події.
Діаграма (рисунок 2.1) прецедентів описує такі основні сценарії використання:
– користувач взаємодіє з головним меню, натискає кнопку "Нова гра", обирає
параметри карти і система завантажує відповідну ігрову сцену;
– у режимі симуляції користувач відкриває панель створення персонажа,
вводить дані, обирає спрайт і підтверджує створення. Система інстанціює
префаб і додає його на карту;
– користувач натискає на створеного персонажа. Система обробляє клік миші
у двовимірному просторі просторі і відображає вікно розширеної
інформації про персонажа з поточними потребами та повідомленнями
активності;
31
ЧДТУ 262264.025 ПЗ
– користувач викликає меню паузи і обирає "Зберегти гру". Система ініціює
збір даних з усіх об'єктів та передає їх до "SaveParser" для запису на диск.
Рисунок 2.1 – Діаграма прецедентів
На наведеній вище діаграмі прецедентів можна побачити, що всі основні дії
ініціюються гравцем через модулі інтерфейсу, які, у свою чергу, надсилають команди
до GameManager та відповідних контролерів сцен.
2.3. Проєктування логічної структури програмного комплексу
Цей підрозділ присвячено високорівневому проєктуванню кодової бази
симулятора. За допомогою UML-діаграм класів та пакетів буде проілюстровано
розподіл логіки між глобальними менеджерами, компонентами штучного інтелекту
та структурами даних, забезпечуючи низьку зв'язність і високу модульність коду [18].
32
ЧДТУ 262264.025 ПЗ
2.3.1. Діаграми класів
Діаграма класів (рисунок 2.2) є центральним елементом об'єктно-орієнтованого
проєктування. Вона демонструє статичну структуру системи, наявні класи, їхні
атрибути, методи та взаємозв'язки (спадкування, асоціація, агрегація).
Рисунок 2.2 – Діаграма класів без атрибутів
33
ЧДТУ 262264.025 ПЗ
Основними класами нашої системи є:
– GameManager, що керує глобальним станом та містить публічні методи
Initialize(), PauseSimulation(), ResumeSimulation();
– Character, що зберігає дані конкретного персонажа, атрибути id, gender,
mentality та має посилання на класи TaskScheduler та CharacterAgent;
– TaskScheduler, що відповідає за ШІ, містить масив поточних потреб та
методи EvaluateNeeds(), CreateTask(TaskType), ExecuteCurrentTask();
– CharacterAgent, що відповідає за рух, є обгорткою над Unity NavMeshAgent
та має метод MoveTo(Vector3 position);
– UI-класи (CharacterDetails, LogConsole, MainMenu), що відповідають за
відображення даних та взаємодіють із GameManager через шаблон
"Observer" (підписка на події/делегати);
– класи серіалізації (SaveParser, ByteData), що є статичними утилітами для
збереження масивів даних.
Діаграма класів (див. рис 2.3) ілюструє, як клас Character виступає
"контейнером", делегуючи завдання обчислення штучного інтелекту класу
"TaskScheduler", а завдання руху – класу "CharacterAgent". Такий поділ
відповідальності робить код чистим і легким для тестування.
У контексті розробки на базі Unity, більшість логічних класів є нащадками
базового класу "MonoBehaviour" [19], що дозволяє їм взаємодіяти з ігровим циклом
(методи "Start", "Update") та кріпитися до ігрових об'єктів.
Кріплення ігрових об’єктів виконується через "Інспектор", який оновлює
власний вміст на основі обраного об’єкту в ієрархії або на сцені проєкту в межах
рушія.
Важливо, що для відображення параметрів класу, він обов’язково має
наслідуватися від "MonoBehaviour".
34
ЧДТУ 262264.025 ПЗ
Рисунок 2.3 – Діаграма класів
2.3.2. Діаграми пакетів
Зважаючи на велику кількість скриптів у проекті, їх необхідно логічно
групувати у простори імен або пакети. Діаграма пакетів в UML візуалізує цю
високорівневу організацію коду та залежності між модулями.
35
ЧДТУ 262264.025 ПЗ
Структура проєкту (на основі файлової структури репозиторію) поділена на
такі основні пакети:
– пакет "Character" містить скрипти, пов'язані з персонажами (Character.cs,
CharacterAgent.cs, TaskScheduler.cs);
– пакет "World" містить скрипти, що описують ігрове середовище та
взаємодію з ним (Map.cs, Chore.cs, Task.cs);
– пакет "UI" включає всі скрипти для роботи з інтерфейсом (MainMenu.cs,
CharacterCreator.cs, LogConsole.cs, SegmentedLabel.cs, LoadingScreen.cs).
Залежить від пакету "Data" для відображення інформації;
– пакет "Data": Відповідає за структури даних і серіалізацію
(CharacterData.cs, GlobalData.cs, підпакет SaveObjects з ByteData.cs,
IntegerData.cs);
– пакет "Static": Містить глобальні менеджери (GameManager.cs,
SceneLoader.cs, SoundManager.cs, Timer.cs) та утиліти (SaveParser.cs);
– пакет "Enums": Зберігає переліки (TaskType, Gender, Mentality, Language),
які використовуються у всіх інших пакетах.
Отже, кожен пакет розділений за певними логічно-структурними критеріями,
що дозволяє відносно інтуїтивно розуміти розміщення певного скрипта в межах
файлової системи проєкту.
На діаграмі пакетів (рисунок 2.4) можна побачити, що пакет "Static" виступає
сполучною ланкою.
Пакет "UI" має односторонню залежність від "Character" та "World", оскільки
інтерфейс лише читає та відображає дані, але ігрові об'єкти не повинні нічого знати
про реалізацію інтерфейсу (принцип інверсії залежностей).
Таким чином, логіка залишається прямолінійною, а будь які логічні помилки чи
помилки відображення самі собою вказують на область їх виникнення.
36
ЧДТУ 262264.025 ПЗ
Рисунок 2.4 – Діаграма пакетів
37
ЧДТУ 262264.025 ПЗ
2.4. Архітектурне проєктування
Тут розглядається фізична архітектура програмного рішення в контексті
ігрового рушія. За допомогою діаграм компонентів та розгортання буде описано
взаємодію префабів, ресурсних файлів, підсистеми збереження даних та середовища
виконання (Unity Runtime) на кінцевому пристрої користувача.
2.4.1. Діаграма компонентів
Діаграма компонентів використовується для моделювання фізичної архітектури
системи. У контексті гри на Unity компонентами можуть виступати "префаби",
сцени, файли даних та скомпільовані бібліотеки.
Наша гра-симулятор складається з наступних ключових компонентів:
– сцена MainMenu.unity, яка є стартовим компонентом програми, включає
префаби UI та залежить від компонента SceneLoader для переходу до
основної гри;
– сцена Simulation.unity, яка є головним компонентом ігрового процесу,
містить NavMesh (підготовлену навігаційну геометрію), камери та
освітлення;
– префаб Character.prefab, який є динамічним компонентом, який
інстанціюється в сцені під час виконання програми, містить
спрайт-рендерер, скрипти поведінки та колайдери;
– модуль збереження, що представлений статичним класом "SaveParser", який
взаємодіє з файловою системою операційної системи для запису/читання
бінарних файлів збережень;
– ресурси (Resources), що є папками з JSON-файлами локалізації (наприклад,
Data/StaticTexts/BTN_EXIT.json), зображеннями карт (CherkasyDark.png,
KyivLight.png) та іконками, які динамічно завантажуються через
"ResourceLoader".
38
ЧДТУ 262264.025 ПЗ
Рисунок 2.5 – Діаграма компонентів
Діаграма (рисунок 2.5) відображає архітектуру завантаження ресурсів. Замість
того, щоб зберігати всі зображення міст та текст у пам'яті (що призводить до
надмірного споживання оперативної пам’яті), компоненти використовують метод
"Resources.Load()" для доступу до необхідних ассетів лише тоді, коли гравець ініціює
відповідну локацію або змінює мову.
39
ЧДТУ 262264.025 ПЗ
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Оскільки розроблюваний симулятор є незалежним застосунком (комп’ютерною
або мобільною грою, а не веб-сервером), діаграма розгортання є відносно простою,
але критично важливою для розуміння взаємодії гри з ресурсами операційної
системи пристрою.
Архітектура розгортання включає один основний "Вузол" – клієнтський
пристрій (Персональний комп'ютер на базі операційної системи Windows, Linux,
macOS або мобільний пристрій). На цьому вузлі розгортається виконуваний файл гри
(наприклад, Simulator.exe або .apk) [19].
Усередині виконуваного файлу функціонує "Рушій Unity" (Unity Engine
Runtime), який обробляє графічні обрахунки, аудіо та фізику. Ігрова логіка (C#
скрипти) компілюється в керовані DLL-бібліотеки (наприклад, Assembly-CSharp.dll),
які виконуються середовищем Mono або IL2CPP.
Важливим аспектом діаграми розгортання (рисунок 2.6) є взаємодія застосунку
з файловою системою пристрою – "Persistent Data Path".
Компонент "SaveParser" здійснює ввід або вивід операції, створюючи папку
збережень та записуючи туди файли ігрового прогресу. Будь-які помилки доступу до
файлової системи (наприклад, відсутність прав на запис) повинні оброблятися на
рівні ігрового рушія для запобігання втраті даних.
Відповідна діаграма стосується будь-якого пристрою, адже принцип
розгортання залишається аналогічним як для персонального комп’ютера, так і для
мобільного пристрою.
В подальшому, мобільний пристрій буде використовувати .apk файл для
встановлення додатку, а розгортання в межах персонального комп’ютера буде
відбуватися шляхом розпакування стиснутого архіву.
40
ЧДТУ 262264.025 ПЗ
Рисунок 2.6 – Діаграма розгортання
2.5. Моделювання поведінки системи
Даний підрозділ деталізує динамічні аспекти роботи системи. Буде
змодельовано алгоритм прийняття рішень автономними агентами через діаграми
діяльності, описано життєвий цикл персонажів за допомогою скінченних автоматів
та проілюстровано процес збереження ігрового прогресу діаграмами послідовності.
41
ЧДТУ 262264.025 ПЗ
2.5.1. Діаграма діяльності
Діаграма діяльності (див. Рис 2.6) використовується для моделювання
алгоритмів, бізнес-процесів та потоків управління. Вона є ідеальним інструментом
для опису складної логіки прийняття рішень штучним інтелектом.
Розглянемо потік діяльності "Вибір та виконання завдання персонажом":
– початок, де викликається метод EvaluateNeeds() у кожному циклі оновлення
(Update);
– система сканує масив поточних потреб персонажа;
– чи є потреба, рівень якої впав нижче критичного порогу (наприклад, <
30%)? Якщо ні, то персонаж продовжує 'Idle' (випадкові блукання або
очікування). Якщо так, то відбувається сортування потреб за пріоритетом.
Наприклад, якщо одночасно низький рівень енергії та соціалізації,
пріоритет віддається енергії (виживанню);
– формується нове завдання відповідного типу;
– персонаж шукає найближчу відповідну точку інтересу на карті;
– персонаж викликає CharacterAgent.MoveTo(POI.position);
– рішення чи досягнуто цілі? Поки ні – продовжуємо рух. Якщо так –
переходимо до наступного кроку;
– анімація виконання дії, запуск таймера виконання;
– по завершенню таймера, відповідна потреба відновлюється;
– кінець, де завдання видаляється з черги, персонаж повертається до стану
перевірки.
Ця діаграма (див. Рис 2.7) чітко демонструє циклічну природу ігрового
штучного інтелекту, де кожен акт прийняття рішення є реакцією на внутрішні
стимули (потреби) та зовнішнє середовище (координати POI). Кожен переход між
етапами має власну логічну систему, що дозволяє задавати параметри переходу та
42
ЧДТУ 262264.025 ПЗ
описувати загальний цикл прийняття рішень на основі вказаних параметрів або
змінних.
Рисунок 2.7 – Діаграма діяльності
2.5.2. Діаграма послідовності
Діаграма послідовності (див. рис 2.8) відображає взаємодію об'єктів у часі.
Вона деталізує, які саме повідомлення (методи) викликаються об'єктами один в
одного при виконанні певного сценарію.
43
ЧДТУ 262264.025 ПЗ
Рисунок 2.8 – Діаграма послідовності
44
ЧДТУ 262264.025 ПЗ
Змоделюємо сценарій "Збереження ігрового процесу":
– об'єкт "UI_SettingsMenu" (Актор) надсилає повідомлення "SaveGame()" до
об'єкта "GameManager";
– "GameManager" тимчасово призупиняє ігровий цикл (Time.timeScale = 0),
щоб уникнути зміни стану під час збереження;
– "GameManager" викликає метод "GetSaveData()" у всіх активних об'єктів
"Character" на сцені;
– кожен "Character" формує об'єкт "CharacterData" (збираючи свої поточні
координати, потреби, активні завдання) та повертає його;
– "GameManager" агрегує отримані дані в об'єкт "GlobalData";
– "GameManager" надсилає об'єкт "GlobalData" до статичного класу
"SaveParser" через метод "SerializeAndSave(GlobalData)";
– "SaveParser" використовує кастомні класи "ByteData", "IntegerData" для
перетворення об'єкта в потік байтів і записує файл на диск;
– після успішного запису "SaveParser" повертає повідомлення "Success" до
"GameManager";
– "GameManager" ініціює відображення вікна "Збережено успішно" через
"MessagePopUp" та відновлює плин часу.
Діаграма послідовності допомагає виявити "вузькі місця" системи. Наприклад,
якщо збір даних з 1000 персонажів займає багато часу, саме на етапі 3-4 відбудеться
"зависання" основного потоку, що вимагатиме перенесення цієї операції в
асинхронний потік.
2.5.3. Діаграма комунікації
Для розроблюваної системи моделювання соціальної взаємодії діаграму
комунікації (рисунок 2.9) побудовано для базового, критично важливого сценарію –
«Аналіз внутрішніх станів автономного агента, вибір пріоритетного завдання та
переміщення до точки інтересу». Цей сценарій відображає роботу ядра штучного
45
ЧДТУ 262264.025 ПЗ
інтелекту програми. На діаграмі відображено взаємодію між основними керуючими
компонентами та сутностями ігрової сцени.
Рисунок 2.9 - Діаграма комунікації
46
ЧДТУ 262264.025 ПЗ
Потік повідомлень у межах даної комунікації організовано за такою логікою:
Глобальний менеджер часу Timer ініціює черговий такт симуляції, надсилаючи
повідомлення "UpdateTime()" до головного контролера GameManager.
GameManager здійснює широкомовне сповіщення всіх активних сутностей на
сцені, викликаючи метод "TickNeeds()" у об'єкта Character. Це призводить до
лінійного зменшення фізіологічних та соціальних показників автономного агента.
Компонент Character перенаправляє запит до свого внутрішнього «мозку» –
планувальника TaskScheduler за допомогою команди "EvaluateNeeds()".
Планувальник аналізує масив потреб і, виявивши падіння показника нижче
критичного рівня, звертається до об'єкта Map із запитом "FindNearestPOI(TaskType,
currentPos)" для пошуку географічних координат найближчої вільної точки інтересу
(ліжка, кафе, парку).
Після отримання цільових координат від карти, TaskScheduler ініціює процес
просторового переміщення, надсилаючи команду "MoveTo(targetPosition)"
компоненту керування рухом CharacterAgent.
Компонент CharacterAgent безпосередньо взаємодіє з нативною навігаційною
сіткою рушія Unity, передаючи кінцеву координату через повідомлення
"SetDestination(coords)".
Побудована діаграма комунікації підтверджує дотримання архітектурного
принципу низької зв'язності кодової бази. Об'єкти взаємодіють через строго
визначені інтерфейси та методи, а сам персонаж виступає в ролі єдиної захисної
оболонки для своїх внутрішніх підсистем навігації та штучного інтелекту, що
спрощує подальше розширення та модернізацію коду.
2.5.4. Діаграма скінченного автомата
Поведінка автономних персонажів у симуляторі є класичним прикладом
реалізації патерну "State Machine". Діаграма станів (рисунок 2.10) візуалізує всі
можливі стани об'єкта та події, які спричиняють переходи між ними.
47
ЧДТУ 262264.025 ПЗ
Рисунок 2.10 – Діаграма скінченного автомата
48
ЧДТУ 262264.025 ПЗ
Для сутності "Character" життєвий цикл можна описати наступними станами:
"Ініціалізація", "Очікування", "Переміщення", "Виконання" та "Взаємодія".
Стан "Ініціалізація" – початковий стан при створенні, де виконується
налаштування спрайтів, генерація потреб.
Стан "Очікування" – базовий стан персонажа. У цьому стані персонаж не має
активних завдань. Тригером для переходу в цей стан слугуює "OnTaskAssigned" (коли
TaskScheduler знаходить критичну потребу).
Стан "Переміщення" – персонаж прямує до цілі. Тригером для переходу є подія
"OnDestinationReached" (коли відстань до цілі стає меншою за допустиму похибку).
Якщо ціль стала недоступною (наприклад, шлях заблоковано), спрацьовує тригер
"OnPathFailed", і автомат повертається в стан 'Idle';
Стан "Виконання" – персонаж знаходиться в точці інтересу і відтворює
відповідну анімацію. Стан триває протягом часу, заданого в "Task.duration". Тригер
для переходу: "OnTaskCompleted";
Стан "Взаємодія" – специфічний стан виконання, коли персонаж комунікує з
іншим персонажом. Вимагає синхронізації станів двох різних автоматів.
Моделювання за допомогою скінченних автоматів гарантує передбачуваність і
детермінованість ШІ [20]. Персонаж не може одночасно перебувати в стані
"Переміщення" та "Виконання", що унеможливлює виникнення помилок (наприклад,
сну під час ходьби). Використання чітких подій для перемикання станів дозволяє
створити надійну архітектуру, яка легко розширюється новими типами поведінки.
49
ЧДТУ 262264.025 ПЗ
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ
У другому розділі здійснено комплексне об'єктно-орієнтоване проєктування
архітектури гри-симулятора. Розроблено модель предметної області та визначено
ключові сутності системи: Персонаж, Потреба, Завдання, Карта та Планувальник
завдань.
За допомогою інструментарію UML було візуалізовано логічну структуру та
поведінку системи. Діаграми прецедентів дозволили окреслити сценарії взаємодії
користувача з додатком. Побудовано діаграми класів, які ілюструють поділ
архітектури на компоненти логіки (MonoBehaviour) та компоненти збереження даних
(Data-класи). Застосування патерну «Скінченний автомат» для моделювання
поведінки NPC дозволило формалізувати переходи між станами агентів (Очікування,
Переміщення, Виконання дії). Окрім цього, спроєктовано алгоритм збереження
ігрового прогресу, що був деталізований за допомогою діаграми послідовності.
50
ЧДТУ 262264.025 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
В цьому розділі буде описано етап безпосередньої програмної реалізації
гри-симулятора соціальної взаємодії з детальним обґрунтуванням використання
обраних технологічних засобів, зокрема ігрового рушія Unity та мови програмування
C#.
Крім цього, буде приділено увагу практичному опису ключових розроблених
підсистем: модулів серіалізації даних, користувацького інтерфейсу та ігрового
штучного інтелекту, після чого буде наведено результати модульного, інтеграційного
та системного тестування з оглядом проведеної оптимізації продуктивності.
3.1. Розробка програмного комплексу
У цьому підрозділі висвітлюється процес практичного написання коду та
збірки гри-симулятора.
Буде наведено опис структури глобальних менеджерів, кастомної системи
серіалізації даних для файлових збережень, створення адаптивного користувацького
інтерфейсу та реалізацію алгоритмів штучного інтелекту в планувальнику завдань
агентів.
3.1.1. Обґрунтування вибору засобів реалізації
Процес розробки гри-симулятора соціальної взаємодії вимагає ретельного
підбору технологічного стеку, здатного забезпечити високу продуктивність,
модульність та кросплатформність.
Основним середовищем розробки було обрано Unity 2D. Цей вибір зумовлений
кількома критичними факторами.
По-перше, Unity надає потужну підсистему навігації (NavMesh [11]). Оскільки
симулятор передбачає автономне переміщення десятків або сотень персонажів по
складній геометрії міських карт, розробка власного алгоритму пошуку шляху з нуля
зайняла б невиправдано багато часу та обчислювальних ресурсів.
51
ЧДТУ 262264.025 ПЗ
NavMesh дозволяє підготувати прохідні зони та делегувати обчислення
маршрутів нативному (C++) коду рушія, що гарантує максимальну швидкодію.
По-друге, мовою програмування у середовищі Unity виступає C#. Ця мова,
розроблена компанією Microsoft, є строго типізованою та об'єктно-орієнтованою.
Завдяки механізмам абстракції, інтерфейсам та делегатам (Delegates/Events), C#
дозволяє будувати гнучку архітектуру ШІ.
Крім того, наявність LINQ (Language Integrated Query) значно спрощує операції
з пошуку та фільтрації даних у колекціях (наприклад, пошук найближчої Точки
Інтересу на карті) [19].
Для реалізації користувацького інтерфейсу було обрано інтегрований
інструмент TextMeshPro (TMP) [9]. На відміну від стандартного Unity Text, який
відображає текст як растрові текстури, TMP використовує технологію Signed Distance
Field (SDF).
Це дозволяє масштабувати текст без втрати якості та розмиття, що особливо
важливо для екранів "історії" та панелей деталей персонажів. Як формат серіалізації
конфігураційних файлів та локалізації було обрано JSON (JavaScript Object Notation)
[6].
3.1.2. Опис структурної (функціональної) схеми
Програмна архітектура симулятора базується на парадигмі
компонентно-орієнтованого програмування, що є стандартом для Unity
(MonoBehaviour) [19]. Проте, для уникнення хаосу та надмірного зв'язування
об'єктів, логіку було розділено між Керуючими Менеджерами (Managers) та
персонажами.
52
ЧДТУ 262264.025 ПЗ
Рисунок 3.1 – Структурна схема
53
ЧДТУ 262264.025 ПЗ
Рисунок 3.2 – Функціональна схема
Керуючі Менеджери реалізовані за допомогою патерну "Singleton" (Одинак),
що гарантує їхню присутність в єдиному екземплярі на всю систему (рисунок 3.1)
[12]. До них належать:
– GameManager, що є ядром системи та відповідає за ініціалізацію ігрового
циклу, керування паузою та синхронізацію глобальних подій;
54
ЧДТУ 262264.025 ПЗ
– SceneLoader, що керує асинхронним завантаженням сцен (MainMenu,
Simulation) та використовує корутини для відображення екрану
завантаження (LoadingScreen);
– SoundManager, що централізовано обробляє відтворення аудіо (музики та
ефектів), контролюючи гучність через Unity Audio Mixer;
– ResourceLoader, що динамічно завантажує ресурси (спрайти, конфігурації) з
папки 'Resources' під час виконання гри (Runtime) та оптимізує споживання
оперативної пам'яті;
– Timer, що моделює ігровий час (дні, години), від показників якого залежить
швидкість падіння потреб персонажів.
3.1.3. Опис логічної схеми системи
Ядром симуляції є алгоритми штучного інтелекту автономних персонажів.
Розробка цих компонентів вимагала імплементації складної логіки прийняття рішень
та управління потребами. Базовою одиницею, що представляє NPC, є клас
"Character.cs". Цей скрипт агрегує всі дані персонажа: його унікальний ID, гендер,
менталітет, а також посилання на модулі "CharacterAgent" (рух) та "TaskScheduler"
(розум).
Компонент "CharacterAgent.cs" є обгорткою над стандартним компонентом
Unity "NavMeshAgent". Його завдання – приймати координати цілі (Vector2) і
побудувати оптимальний маршрут, оминаючи статичні перешкоди на карті (будівлі,
дерева).
Найважливішим модулем є "TaskScheduler.cs". Цей скрипт імплементує
скінченний автомат та евристичний планувальник. У кожному циклі оновлення (або з
певною затримкою через корутини для оптимізації продуктивності), планувальник
перевіряє масив потреб персонажа. Потреби постійно зменшуються з плином
ігрового часу.
55
ЧДТУ 262264.025 ПЗ
Рисунок 3.3 – Логічна структура проєкту
56
ЧДТУ 262264.025 ПЗ
Коли одна або кілька потреб падають нижче визначеного критичного порогу,
"TaskScheduler" ініціює алгоритм вибору завдання. Вибір базується не лише на
найнижчому показнику, але й враховує менталітет персонажа. Доступні типи завдань
описані в Enum "TaskType".
Інтерфейс користувача (UI) у симуляторі відіграє ключову роль, забезпечуючи
взаємодію гравця зі складною логікою гри. Для його реалізації використовувалася
система Unity Canvas. Взаємодія побудована на системі подій (Event System [21]), де
кожен натиск на кнопку (Button.onClick) або взаємодія з полями вводу
(InputField.onValueChanged) активує відповідні методи у контролерах.
Так, скрипт "MainMenu.cs" відповідає за перемикання станів головного меню
(відкриття панелі налаштувань "SettingsMenu", ініціалізацію панелі створення нової
гри "NewSimulationMenu" або вихід з гри).
Для виведення системної інформації реалізовано "LogConsole.cs" – спливаюче
вікно, яке підписується на глобальні події через делегати (C# Delegates [22]). Коли
персонаж змінює стан (наприклад, починає нове завдання), він викликає відповідну
подію, яку "чує" консоль і виводить текстове повідомлення ("Персонаж X розпочав
дію").
3.1.4. Розробка бази даних
Оскільки симулятор містить величезну кількість динамічних даних, стандартні
підходи збереження (наприклад, PlayerPrefs) є непридатними. Зберігання складних
ієрархій об'єктів у форматі JSON також може бути занадто повільним. Тому була
розроблена власна кастомна підсистема серіалізації, побудована навколо концепції
абстрактних об'єктів збереження.
Основним класом-утилітою є "SaveParser". Він відповідає за переведення стану
гри в потік байтів і запис його у файл. Кожен об'єкт, який потрібно зберегти, формує
відповідний клас даних. Наприклад, стан глобальних змінних зберігається у класі
"GlobalData", а стан окремого NPC – у "CharacterData".
57
ЧДТУ 262264.025 ПЗ
Для оптимізації роботи з різними типами даних (переважно примітивами) були
створені класи-обгортки: "ByteData", "IntegerData", "StringData", які наслідують
базовий клас "SaveObjectData". Це дозволяє швидко серіалізувати масиви значень,
уникаючи надмірного використання Reflection.
Така архітектура гарантує, що процес збереження та завантаження симуляції
відбувається за частки секунди, що критично важливо для забезпечення плавного
ігрового досвіду.
3.1.5. Розробка інтерфейсу користувача
Оскільки симулятор може запускатися на пристроях із різною роздільною
здатністю та співвідношенням сторін екрану (від ноутбуків 16:9 до ультра широких
моніторів 21:9), було необхідно забезпечити адаптивність UI. Для цього активно
застосовувався компонент "Canvas Scaler".
У налаштуваннях Canvas Scaler обрано режим 'Scale With Screen Size' із
базовою роздільною здатністю 1920x1080 (Reference Resolution). Параметр 'Match'
встановлено на 0.5 (або адаптивно залежно від платформи), що дозволяє елементам
інтерфейсу пропорційно збільшуватися або зменшуватися без спотворень.
Додатково для кожного UI-елемента (кнопки, панелі, вікна) налаштовувалися
"Якорі" (Anchor Presets). Наприклад, панель "Timer" міцно прив'язана до правого
верхнього кута екрана (Top-Right), а "LogConsole" розтягується вздовж лівого краю.
Це гарантує, що при зміні розміру вікна елементи не перекриватимуть один одного.
У додатку реалізовано систему налаштування, яка дозволяє користувачеві
змінювати візуальний стиль (світла або темна тема) та мову локалізації. Ці функції
доступні через "SettingsMenu.cs".
Подібна система налаштувань використовується майже в усіх сучасних іграх і
дозволяє значно покращити досвід користувача. Додатково, це стає чинником
доступності (в випадку з мовою), що дозволяє більшій кількості користувачів мати
змогу користуватися продуктом.
58
ЧДТУ 262264.025 ПЗ
Рисунок 3.4 – Адаптація під розширення 640х480
Рисунок 3.5 – Адаптація під мобільний пристрій (Google Pixel 5)
Рисунок 3.6 – Адаптація під розширення 5120х1140
59
ЧДТУ 262264.025 ПЗ
Рисунок 3.7 - Адаптація під розширення 1280х720
Система локалізації побудована на основі JSON-файлів. Усі текстові рядки
винесено за межі коду в теку "Resources/Data/StaticTexts" (наприклад,
"BTN_EXIT.json", "BTN_NEW_SIM.json"). При старті програми або зміні
налаштувань, "ResourceLoader" парсить ці файли (використовуючи структуру
"TranslationData.cs" або "TextData.cs") і застосовує текст до всіх об'єктів
"TextMeshProUGUI" на сцені залежно від обраної мови ("Enum Language").
Перемикання тем реалізовано через скрипт "ThemePart.cs". Усі графічні
елементи інтерфейсу (фони, плашки) підписані на подію зміни теми. При зміні
глобального стану, скрипт автоматично змінює колір компонента Image відповідно до
заздалегідь визначеної палітри кольорів у класі "Constants.Colors.cs" (наприклад,
перемикання між Color.white та темним відтінком сірого). Тематичні зміни також
стосуються карт: користувач може вибрати спрайти "KyivLight" або "KyivDark".
60
ЧДТУ 262264.025 ПЗ
3.1.6. Опис розробки програмних компонентів
Для забезпечення підтримуваності та розширюваності коду була розроблена
чітка файлова структура проєкту в Unity, що відповідає парадигмам чистого коду
(Clean Code) [23].
– Основна директорія "Assets/" поділена на логічні підпапки:
– "Scenes/", що зберігає ігрові сцени ("MainMenu.unity", "Simulation.unity");
– "Scripts/", що містить увесь вихідний код C#, поділений на пакети;
– "Animators/", що містить скрипти для плавних анімацій (UI/камери);
– "Character/", що містить логіку ШІ та переміщення персонажа;
– "Constants/", що зберігає статичні змінні та налаштування кольорів;
– "Data/", що містить класи для збереження стану;
– "Enums/", що містить перелічувані типи, які використовуються для
типізації;
– "Interfaces/", що містить контракти для дотримання принципів SOLID;
– "Static/", що містить ядро системи та синглтони;
– "UI/", що містить обробники подій інтерфейсу;
– "World/", що містить об'єкти середовища та дій;
– "Resources/", що є спеціальною папка в Unity, де поміщені файли, які
потрібно динамічно підвантажувати;
– "TextMesh Pro/", що є папкою з необхідними ресурсами (шрифтами,
матеріалами) для якісного відображення тексту.
Середовищем розробки було обрано редактор Unity (версії 2022.3 LTS або
новіше).
Як інтегроване середовище розробки для написання C# скриптів
використовувався Microsoft Visual Studio, оскільки це середовище має глибоку
інтеграцію з Unity, забезпечуючи автодоповнення коду, рефакторинг та можливості
покрокової відлагодження.
61
ЧДТУ 262264.025 ПЗ
Для коректної роботи симулятора в "Project Settings" були налаштовані певні
параметри. У "TimeManager" був відкалібрований показник Fixed Timestep для
забезпечення стабільності фізичних обчислень. У "NavMeshAreas" були прописані
спеціальні зони прохідності, щоб персонажі могли коректно обходити водні
перешкоди або стіни будівель на картах міст.
Для збереження історії розробки, можливості відкату змін та забезпечення
безпеки сирцевого коду, проект було інтегровано з системою контролю версій Git
(репозиторій розміщено на платформі GitHub).
Особливістю проектів на Unity є генерація великої кількості тимчасових та
скомпільованих файлів. Щоб ці файли не засмічували репозиторій, у корені проєкту
було створено та налаштовано файл ".gitignore". До нього були додані директорії
"/Library/", "/Temp/", "/Obj/", "/Logs/" та файли ".sln", ".csproj".
Водночас критично важливо було забезпечити версіювання файлів з
розширенням ".meta". У цих файлах Unity зберігає метадані (унікальні GUID,
посилання на компоненти, налаштування імпорту текстур). Втрата ".meta" файлів
призводить до повного руйнування зв'язків у сценах та префабах. Тому "Edit ->
Project Settings -> Version Control" було встановлено у режим "Visible Meta Files".
Заключний підрозділ описує методологію перевірки якості створеного ігрового
продукту. Тут будуть наведені результати модульного та інтеграційного тестування
ключових алгоритмів, описано процес стрес-тестування системи за допомогою Unity
Profiler та впроваджені архітектурні рішення для оптимізації продуктивності
обчислень.
Оскільки симулятор розроблявся у 2D-просторі, постала необхідність
створення значної кількості графічних ассетів: спрайтів персонажів, карт-локацій та
елементів інтерфейсу. Для створення та редагування растрової графіки
використовувався веб-орієнтований графічний редактор Photopea.
Процес створення спрайтів персонажів полягав у роботі з багатошаровими
PSD-документами (Photoshop Document). Кожен персонаж складався з базового
62
ЧДТУ 262264.025 ПЗ
контуру, шару з кольором шкіри, шару одягу та зачіски. Завдяки такому розділенню,
шляхом перефарбовування окремих шарів можна було швидко згенерувати десятки
унікальних варіацій зовнішності. Після завершення редагування, усі спрайти
експортувалися у форматі PNG з підтримкою прозорості.
Аналогічним чином створювалися іконки. Для карт населених пунктів
малювалися великі схематичні плани з чітким розмежуванням прохідних зон (доріг,
тротуарів) та перешкод (будівель). Це було критично важливо для подальшої
правильної генерації навігаційної сітки.
Рисунок 3.8 – Процес створення в Photopea
Після експорту PNG-файлів з Photopea, їх необхідно було правильно
імпортувати в Unity. Оскільки це 2D-проект і піксельна чіткість є важливою для UI та
спрайтів, у налаштуваннях імпорту (Texture Import Settings) параметр "Texture Type"
змінювався на "Sprite (2D and UI)".
63
ЧДТУ 262264.025 ПЗ
Для уникнення небажаного розмиття (особливо при масштабуванні), параметр
"Filter Mode" часто встановлювався в "Point (no filter)" або "Bilinear" залежно від
роздільної здатності ассету. Для оптимізації ваги білда застосовувалося стиснення у
формат DXT5 або ASTC. Спрайти карт встановлювалися на фон (Background) за
допомогою компонента "SpriteRenderer", а іконки UI використовувалися в
компонентах "Image" на Canvas.
3.2. Тестування системи
Тестування розробленого програмного забезпечення є критично важливим
етапом, що гарантує стабільність симуляції, відсутність критичних помилок та
відповідність нефункціональним вимогам (FPS, споживання пам'яті). Оскільки
проект розроблено на рушії Unity, тестування проводилось як мануально (через Play
Mode), так і автоматизовано за допомогою Unity Test Framework.
3.2.1. Модульне тестування
Модульне тестування (Unit Testing) спрямоване на перевірку ізольованих
шматків коду, переважно класів, що не успадковують MonoBehaviour, або
математичних алгоритмів. У нашій системі модульному тестуванню підлягали
алгоритми серіалізації ("SaveParser") та логіка планувальника завдань
("TaskScheduler").
Для тестування серіалізації (DataSerialization) були написані тести, що
створюють об'єкт "CharacterData" з випадковими значеннями (id, потреби),
конвертують його в байтовий масив, а потім десеріалізують назад. Тест (Assert)
перевіряє, чи повністю збігаються початкові та відновлені дані. Успішне
проходження цих тестів гарантувало відсутність втрати даних (Data Corruption) при
збереженні гри.
Модульні тести для "TaskScheduler" перевіряли правильність сортування
потреб. У тест передавався масив фіктивних потреб, і перевірялося, чи метод
64
ЧДТУ 262264.025 ПЗ
"GetLowestNeed()" повертає коректний результат з урахуванням вагових коефіцієнтів
менталітету.
Рисунок 3.9 – Результат модульного тестування
3.2.2. Інтеграційне тестування
Інтеграційне тестування (Integration Testing) перевіряє коректність взаємодії
кількох модулів між собою. Важливим етапом була перевірка взаємодії
"CharacterAgent" та "NavMesh".
Було створено тестову сцену з перешкодами. персонажу задавалася координата
за перешкодою. За допомогою "Debug.DrawLine" візуалізувався маршрут, який
прокладав рушій. Тест вважався успішним, якщо персонаж досягав цілі, не
проходячи крізь колайдери (стіни) і не застрягаючи у 'мертвих зонах' (NavMesh Edge
cases).
Іншим важливим інтеграційним тестом була перевірка роботи підсистеми
локалізації та завантаження ресурсів ("ResourceLoader"). Тест імітував перемикання
мови в налаштуваннях (Language.cs). Система повинна була успішно знайти та
завантажити відповідний JSON-файл (наприклад, 'StaticTexts/BTN_EXIT.json') і
оновити всі текстові поля на сцені без виникнення помилок NullReferenceException.
65
ЧДТУ 262264.025 ПЗ
3.2.3. Системне тестування
Системне тестування оцінює поведінку всієї системи в цілому. Головним
інструментом на цьому етапі був Unity Profiler, який дозволив оцінити
продуктивність симулятора.
Стрес-тест полягав у створенні на сцені (на карті "Київ" або "Черкаси")
максимально можливої кількості персонажів. Було зафіксовано, що при 100 активних
персонажах частота кадрів падала нижче 30. Аналіз через Profiler показав, що
"вузьким місцем" є масовий виклик алгоритмів пошуку шляху в методі "Update()"
кожного персонажа.
Для вирішення цієї проблеми було застосовано оптимізацію: логіку ШІ було
винесено в Корутини, що викликаються раз на 0.5-1 секунду замість кожного кадру.
Окрім того, обчислення важких математичних дистанцій (Vector3.Distance) замінили
на більш швидкі порівняння квадратів дистанцій (Vector3.sqrMagnitude). Додатково,
потрібно порівняти отримане значення з піднесеним у другу степінь значенням, адже
описана реалізація прибирає з обчислень квадратний корінь, що в певній мірі може
зменшити навантаження на центральний процесор при обрахунках.
Після оптимізації симулятор стабільно утримував 60 FPS навіть при 150
персонажах.
Рисунок 3.10 – Результат тестування через Unity Profiler
66
ЧДТУ 262264.025 ПЗ
3.2.4. Приймальне тестування
Приймальне тестування проводилося з точки зору кінцевого користувача. Було
складено сценарій, який імітував повний цикл використання програми:
– запуск програми, завантаження головного меню;
– перехід до налаштувань, перемикання мови, перевірка застосування змін;
– створення 'Нової симуляції', вибір карти "CherkasyLight", дочекатися
завантаження сцени;
– виклик меню "CharacterCreator", введення даних, додавання 5 різних
персонажів на карту;
– спостереження за симуляцією протягом 10 хвилин. Відстеження того, чи
персонажі коректно розходяться по точках інтересу та не стоять на місці
при падінні потреб;
– клік на кількох персонажів для перевірки відображення панелі деталей та
коректності заповнення Progress Bars;
– виклик меню, натискання кнопки "Зберегти". Закриття програми;
– повторний запуск, виклик "Завантажити симуляцію". Перевірка того, що всі
персонажі опинилися на тих самих позиціях з тими ж показниками потреб.
Система успішно пройшла всі пункти тестового сценарію, не видавши жодної
критичної помилки. Візуальні баги та незручності інтерфейсу, виявлені під час цього
етапу (наприклад, перекриття вікон), були оперативно виправлені.
Таблиця 3.1
Тестування підсистеми серіалізації даних
Тест-кейс № 1
Назва Серіалізація та десеріалізація об'єктів (SaveParser)
67
ЧДТУ 262264.025 ПЗ
Продовження таблиці 3.1
Передумови Об'єкт CharacterData з наповненими тестовими полями
Кроки 1. Serialize(); 2. Збереження; 3. Deserialize(); 4. Порівняння
значень
Очікуваний Повне відновлення даних без втрати точності полів
результат
Фактичний Дані відновлено коректно, Assert-перевірки пройдено
результат
Статус Пройдено
Таблиця 3.2
Тестування підсистеми пріоритезації потреб
Тест-кейс № 2
Назва Пріоритезація потреб ШІ (TaskScheduler)
Передумови Ініціалізований TaskScheduler (Голод=10%, Енергія=80%)
Кроки 1. Виклик EvaluateNeeds(); 2. Перевірка обраного типу
завдання
Очікуваний Вибір завдання типу TaskType.Eat як найпріоритетнішого
результат
Фактичний Планувальник обрав коректне завдання згідно з вагами
результат
68
ЧДТУ 262264.025 ПЗ
Продовження таблиці 3.2
Статус Пройдено
Таблиця 3.3
Тестування підсистеми навігації
Тест-кейс № 3
Назва Динамічна навігація (CharacterAgent + NavMesh)
Передумови Карта з запеченою сіткою NavMesh та перешкодами
Кроки 1. Задання цілі за перешкодою; 2. Виклик MoveTo(); 3. Трекінг
координат
Очікуваний Рух в обхід перешкоди та точне досягнення цілі
результат
Фактичний Агент успішно оминув статичні об'єкти, досягнувши цілі
результат
Статус Пройдено
Таблиця 3.4
Тестування локалізації ресурсів
Тест-кейс № 4
Назва Завантаження ресурсів локалізації (ResourceLoader)
Передумови Наявність JSON-файлів у Resources/Data/StaticTexts
69
ЧДТУ 262264.025 ПЗ
Продовження таблиці 3.4
Кроки 1. Зміна мови в налаштуваннях; 2. Тригер оновлення UI
Очікуваний Оновлення всіх текстів без помилок NullReference
результат
Фактичний Локалізація застосована для всіх UI-елементів
результат
Статус Пройдено
Таблиця 3.5
Стрес-тестування продуктивності
Тест-кейс № 5
Назва Профілювання продуктивності (Unity Profiler)
Передумови Сцена Simulation, наявність 150 агентів
Кроки 1. Масовий спавн агентів; 2. Замір FPS та навантаження CPU
Очікуваний Стабільні 60 FPS після впровадження оптимізації
результат
Фактичний Після впровадження корутин продуктивність стабільна
результат
Статус Пройдено
70
ЧДТУ 262264.025 ПЗ
Таблиця 3.6
Наскрізне приймальне тестування
Параметр 6
Назва Наскрізний сценарій сесії (End-to-End)
Передумови Скомпільований Build (.exe)
Кроки 1. Створення NPC; 2. Симуляція; 3. Збереження; 4. Перезапуск
і Load
Очікуваний Цілісність даних та автономність поведінки після
результат завантаження
Фактичний Всі етапи сесії пройдено, стан збережено коректно
результат
Статус Пройдено
3.3. Приклади впровадженого програмного комплексу
В цьому підрозділі описується поетапна взаємодія з додатком, що дозволяє
опанувати вець впроваджений функціонал. Це включає запуск додатку та головний
екран, перехід до екрану налаштувань, їх зміна, створення симуляції та вибір
параметрів на власний розсуд, запуск симуляції, створення персонажів та керування
навколишнім середовищем симуляції. При запуску гри-симулятора користувач
потрапляє на екран Головного меню ("MainMenu"). Інтерфейс максимально
мінімалістичний і зосереджений на основних функціях. У центрі екрана розташовані
кнопки "Нова симуляція" ("New Simulation"), "Завантажити симуляцію" ("Load
Simulation"), "Налаштування" ("Settings") та 'Вихід' ("Exit").
71
ЧДТУ 262264.025 ПЗ
Рисунок 3.11 – Головне меню
Перехід до меню "Налаштування" відкриває вікно конфігурації. Тут користувач
може змінити загальну мову інтерфейсу (наприклад, з англійської на українську), що
миттєво оновить усі текстові елементи за допомогою підсистеми "TranslationData".
Також доступний перемикач тем (Світла / Темна), який інвертує кольорову палітру
UI для більш комфортного сприйняття в різний час доби.
Натискання кнопки "Нова симуляція" відкриває діалогове вікно підготовки.
Користувачу необхідно вибрати карту-середовище (наприклад, Черкаси, Київ або
Хацьки) та підтвердити вибір. Після екрану завантаження ("LoadingScreen")
відкривається основна ігрова сцена.
Рисунок 3.12 – Меню налаштувань
72
ЧДТУ 262264.025 ПЗ
Щоб населити карту жителями, необхідно скористатися модулем 'Створення
персонажа' ("CharacterCreator"). Натискання відповідної іконки на бічній панелі HUD
відкриває форму. Користувач вводить ім'я персонажа у текстове поле ("InputField"),
обирає стать (Male / Female) за допомогою "SegmentedLabel" та задає менталітет
(Mentality), який впливатиме на поведінку ШІ. Праворуч на формі
("CharacterPreview") у реальному часі відображається портрет майбутнього
персонажа. Натискання кнопки 'Створити' закриває форму та інстанціює нового NPC
на карті.
Рисунок 3.13 – Панель створення персонажа
У режимі симуляції користувач виступає в ролі спостерігача. Він може вільно
переміщувати камеру по карті, наближаючи та віддаляючи зображення. Над кожним
персонажем відображається плашка з його ім'ям ("LabelCharacter").
Якщо користувач натисне на спрайт персонажа, праворуч з'явиться вікно
детальної інформації (див. Рис 3.4). У цьому вікні відображаються поточні
характеристики персонажа (вік, стать, менталітет), а головне – динамічні показники
його потреб (наприклад, Енергія, Голод, Настрій). Під показниками потреб
знаходиться текстове поле, що описує поточне завдання персонажа (наприклад, "Йде
додому відпочивати" або "Спілкується").
73
ЧДТУ 262264.025 ПЗ
Додатково на екрані присутній віджет консолі ("LogConsole"), де
прокручується стрічка всіх важливих глобальних подій у симуляторі (хто куди пішов,
хто закінчив завдання), що дозволяє гравцю легко відстежувати загальну картину
життя соціуму.
Рисунок 3.14 – Панель детальної інформації про персонажа
Однією з головних переваг рушія Unity є можливість компіляції (Building)
одного і того ж вихідного коду під різні операційні системи (Кросплатформність).
Процес підготовки додатку до релізу відбувається у вікнах "Build Settings" та "Player
Settings".
У "Player Settings" задається ім'я компанії-розробника, назва продукту,
встановлюється іконка додатку (яка буде відображатися на робочому столі або
лаунчері смартфона) та налаштовуються параметри екрану. Було обрано режим
"Fullscreen Window" для десктопних версій та "Auto Rotation" для мобільних
пристроїв. Важливою частиною конфігурації був вибір Scripting Backend. Для
досягнення кращої продуктивності та захисту коду від декомпіляції перевага
надавалася компілятору IL2CPP замість стандартного Mono.
Для складання (Build) симулятора під десктопні операційні системи (Windows,
Linux, macOS) у вікні "Build Settings" вибирався "Target Platform: PC, Mac & Linux
Standalone".
74
ЧДТУ 262264.025 ПЗ
Архітектура встановлювалася на x86_64 (64-bit), оскільки 32-бітні системи вже
не відповідають сучасним вимогам пам'яті для симуляцій. Інтерфейс введення (Input
System) оптимізувався під клавіатуру та мишу: кліки лівою кнопкою
використовувались для виділення персонажів (оброблялися через Physics2D.Raycast),
а колесо миші – для масштабування камери (Camera Zoom). Після компіляції
створювався виконуваний файл (".exe" для Windows) разом із текою "_Data", яка
містила всі необхідні ресурси та скомпільовані бібліотеки ("Assembly-CSharp.dll").
Для портування додатку на мобільні пристрої Android необхідно було змінити
"Target Platform" на "Android" та встановити Android SDK/NDK інструменти.
Оскільки симулятор розроблено з адаптивним UI, графічний інтерфейс автоматично
переналаштовувався під пропорції екранів смартфонів. Однак, масштабування
камери було переписано з використанням алгоритму обробки двох дотиків.
Також, при створенні додатку для обох платформ потрібно було враховувати
налаштування якості, які в більшості залишилися за замовчуванням для забезпечення
правильної роботи.
Головна відмінність полягала в системі управління. Стандартні кліки мишею в
Unity автоматично транслюються у дотики, тому виділення персонажів пальцем
працювало без серйозних змін у коді. Однак, масштабування камери було переписано
з використанням алгоритму обробки двох дотиків . Результатом компіляції ставав
файл ".apk" або ".aab", готовий до розповсюдження.
Кінцевий етап підготовки до дистрибуції включав налаштування ключа підпису
(Keystore) для Android та вибір відповідних архітектурних версій (ARM64 для
сучасних смартфонів). У свою чергу, для Windows-версії було налаштовано іконку
застосунку та маніфест дозволів. Автоматизація цих процесів у Unity дозволила
швидко генерувати актуальні версії для тестування, зберігаючи при цьому
стабільність ігрової логіки незалежно від цільової операційної системи.
75
ЧДТУ 262264.025 ПЗ
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі описано практичну реалізацію та тестування
спроєктованого програмного комплексу. Обґрунтовано вибір ігрового рушія Unity 3D
та мови C# як оптимального стеку технологій для забезпечення кросплатформності
та високої продуктивності.
Реалізовано ключові модулі системи: TaskScheduler для оцінки потреб та
вибору завдань (ігровий ШІ), CharacterAgent для переміщення на базі NavMesh, та
глобальні синглтони-менеджери для керування ігровим циклом. Для забезпечення
швидкодії розроблено кастомну підсистему бінарної серіалізації, яка замінює
стандартні повільні методи. Інтерфейс користувача адаптовано під різні екрани за
допомогою Unity Canvas Scaler та TextMeshPro.
Проведено повний цикл тестування: від модульних тестів алгоритмів
серіалізації до стрес-тестування продуктивності за допомогою Unity Profiler.
Оптимізація коду шляхом використання корутин (Coroutines) дозволила досягти
стабільних 60 FPS при симуляції до 150 агентів. Здійснено успішну збірку (Build)
додатку під десктопні ОС (Windows) та мобільну платформу (Android).
76
ЧДТУ 262264.025 ПЗ
ВИСНОВКИ
У результаті виконання кваліфікаційної роботи було успішно спроєктовано та
розроблено програмне забезпечення гри-симулятора соціальної взаємодії.
Поставлена мета досягнута в повному обсязі.
1 Було розроблено модульну архітектуру на основі принципів
об'єктно-орієнтованого програмування, адаптовану до компонентного
підходу рушія Unity. Система побудована на принципі низької зв'язності, де
кожен функціональний вузол – від менеджерів станів до агентів – взаємодіє
через чітко визначені інтерфейси. Це забезпечило гнучкість системи,
дозволяючи легко масштабувати проект, додавати нові типи ігрових
сутностей та замінювати підсистеми (наприклад, алгоритми серіалізації)
без суттєвої переробки ядра.
2 Реалізовано інтелектуальний планувальник TaskScheduler, який виконує
роль «мозкового центру» кожного персонажа. Підсистема успішно вирішує
проблему пріоритезації дій: шляхом аналізу динамічних показників потреб
(голод, енергія, настрій) та застосування модифікаторів менталітету агента,
планувальник автоматично формує послідовність завдань. Впровадження
цієї підсистеми дозволило досягти емерджентної поведінки персонажів, де
їхні дії є логічним наслідком поточного внутрішнього стану, а не жорстко
прописаного сценарію.
3 Було розроблено набір алгоритмів, що дозволяють агентам взаємодіяти не
лише з ігровим оточенням (точками інтересу), а й між собою. Система
соціальної взаємодії реалізована через механізм синхронізації станів, що
дозволяє персонажам виконувати спільні дії. Цей функціонал додав
симуляції соціальної глибини, оскільки поведінка одного NPC тепер
безпосередньо залежить від наявності та стану інших агентів у радіусі його
видимості.
77
ЧДТУ 262264.025 ПЗ
4 Створено повністю інтерактивне ігрове середовище на базі навігаційних
сіток, що забезпечує коректне переміщення персонажів міськими картами з
урахуванням перешкод. Паралельно було розроблено багатошаровий
графічний інтерфейс на базі TextMeshPro, який забезпечує гравцеві доступ
до всіх інструментів керування: від створення нових NPC до моніторингу
їхніх внутрішніх станів та логування подій. Адаптивна верстка дозволила
зробити інтерфейс зручним як для настільних, так і для мобільних
платформ.
В процесі роботи було вирішено ряд складних архітектурних та алгоритмічних
завдань. По-перше, розроблено евристичний планувальник завдань, який дозволяє
віртуальним агентам приймати незалежні рішення на основі їхнього віку, статі,
менталітету та поточних потреб. По-друге, імплементовано надійну підсистему
динамічної навігації на базі NavMesh, що забезпечує коректне переміщення великої
кількості об'єктів без колізій.
Важливим технічним досягненням проєкту є реалізація власної системи
бінарної серіалізації збережень, що вирішило проблему надмірного споживання
пам'яті та забезпечило миттєве завантаження ігрових сесій. Користувацький
інтерфейс, побудований з використанням TextMeshPro, підтримує адаптивність,
зміну кольорових тем та гнучку систему локалізації на базі JSON-файлів. Створено
зручний редактор генерації персонажів.
Отриманий програмний продукт має високий потенціал для подальшого
масштабування. Його можна використовувати не лише як розважальний додаток у
жанрі Life Simulation, але й як базовий інструмент для наукових чи урбаністичних
досліджень, моделювання транспортних та пішохідних потоків або вивчення
поведінки натовпу на прикладі реальних карт міст України. Дотримання принципів
чистого коду та патернів проєктування закладає надійний фундамент для інтеграції
нових механік у майбутньому.
78
ЧДТУ 262264.025 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Гама Е., Хелм Р., Джонсон Р., Вліссідес Дж. Патерни об'єктно-орієнтованого
проєктування. Київ: Фабула, 2020. 464 с.
2 Optimizing Script Performance in Unity [Електронний ресурс] // Unity Manual. –
Режим доступу до ресурсу: https://docs.unity3d.com/Manual/Understanding
Performance.html (Дата звернення 20.04.2026).
3 Unity Navigation System [Електронний ресурс] // Unity Manual. – Режим
доступу до ресурсу: https://docs.unity3d.com/Manual/nav-NavigationSystem.html
(Дата звернення 20.04.2026).
4 C# Documentation [Електронний ресурс] // Microsoft Docs. – Режим доступу до
ресурсу: https://learn.microsoft.com/en-us/dotnet/csharp/ (Дата звернення
20.04.2026).
5 Goal-Oriented Action Planning (GOAP) [Електронний ресурс] // AI and Games. –
Режим доступу до ресурсу: https://alumni.media.mit.edu/~jorkin/goap.html (Дата
звернення 20.04.2026).
6 What is JSON and how to use it in Unity [Електронний ресурс] // Unity Answers. –
Режим доступу до ресурсу: https://answers.unity.com/questions/json-serialization.
html (Дата звернення 20.04.2026).
7 Коваленко О. І. Архітектура систем штучного інтелекту в комп'ютерних іграх //
Вісник НТУУ "КПІ". Інформатика, управління та обчислювальна техніка. –
2021. – № 73. – С. 45-52.
8 Design Patterns in C# [Електронний ресурс] // Refactoring.Guru. – Режим
доступу до ресурсу: https://refactoring.guru/design-patterns/csharp (Дата
звернення 20.04.2026).
9 Entity Component System (ECS) Overview [Електронний ресурс] // Unity
Documentation. – Режим доступу до ресурсу: https://docs.unity3d.
79
ЧДТУ 262264.025 ПЗ
com/Packages/[email protected]/manual/index.html (Дата звернення
20.04.2026).
10 TextMesh Pro Documentation [Електронний ресурс] // Unity Documentation. –
Режим доступу до ресурсу: https://docs.unity3d.com/Packages/com.unity.
[email protected]/manual/index.html (Дата звернення 20.04.2026).
11 How to Use NavMesh in Unity [Електронний ресурс] // RayWenderlich. – Режим
доступу до ресурсу: https://www.raywenderlich.com/3168812-navmesh-in-unity-
tutorial (Дата звернення 20.04.2026).
12 Singleton Pattern in Unity [Електронний ресурс] // Unity Community Wiki. –
Режим доступу до ресурсу: https://wiki.unity3d.com/index.php/Singleton (Дата
звернення 20.04.2026).
13 State Machine Pattern in Game Development [Електронний ресурс] // Game
Programming Patterns. – Режим доступу до ресурсу: https://gameprogramming
patterns.com /state.html (Дата звернення 20.04.2026).
14 Nystrom R. Game Programming Patterns. Genever Benning, 2014. 354 p.
15 Фрімен Е., Робсон Е. Head First. Патерни проєктування. Київ: Фабула, 2020. 672
с.
16 Мартін Р. Чиста архітектура: мистецтво розробки програмного забезпечення.
Київ: Фабула, 2019. 368 с.
17 Component Based Architecture in Unity [Електронний ресурс] // Unity Learn. –
Режим доступу до ресурсу: https://learn.unity.com/tutorial/component-based
-architecture (Дата звернення 20.04.2026).
18 Фаулер М. UML. Основи. Короткий посібник зі стандартної мови об'єктного
моделювання. Львів: Магнолія, 2018. 200 с.
19 Unity Documentation [Електронний ресурс] // Unity – User Manual. – Режим
доступу до ресурсу: https://docs.unity3d.com/Manual (Дата звернення
20.04.2026).
80
ЧДТУ 262264.025 ПЗ
20 Behavior Trees for AI: How they work [Електронний ресурс] // Game Developer. –
Режим доступу до ресурсу: https://www.gamedeveloper.com/programming/
behavior-trees-for-ai-how-they-work (Дата звернення 20.04.2026).
21 Альбхахарі М. C# 10. Довідник. Повний опис мови. Київ: Діалектика, 2022.
1088 с.
22 Шилдт Г. C# 4.0: повне керівництво. Київ: Вільямс, 2011. 1056 с.
23 Мартін Р. Чистий код: створення, аналіз, рефакторинг. Київ: Фабула, 2019. 464
с.
81
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
Голуб С.В.
„ ” 2026 р.
«ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ГРИ-СИМУЛЯТОРА
СОЦІАЛЬНОЇ ВЗАЄМОДІЇ»
Специфікація
ЧДТУ 262264.025
Листів 2
Розробник Ткаченко В. А.
Керівник Куницька С. Ю.
2026
ЧДТУ.242264.025 2
Позначення Найменування Примітка
Документація
482.ЧДТУ 262264 12 01 Текст програми
482.ЧДТУ 262264 34 01 Інструкція користувачеві
482.ЧДТУ 262264 90 01 Графічні матеріали
70
ДОДАТОК Б
«ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ГРИ-СИМУЛЯТОРА
СОЦІАЛЬНОЇ ВЗАЄМОДІЇ»
Текст програми
482.ЧДТУ 262264 12 01
Листів 10
Розробник Ткаченко В. А.
2026
482.ЧДТУ 262264 12 01 2
using System.Collections;
using UnityEngine.TestTools;
public class NewTestScript
{
[Test]
public void TaskScheduler_ShouldSelectEatTask_WhenHungerIsLow()
{
// Створюємо тимчасовий об'єкт для ШІ
GameObject go = new GameObject();
TaskScheduler scheduler = go.AddComponent<TaskScheduler>();
// Імітуємо низький рівень голоду
scheduler.hunger = 10;
scheduler.energy = 90;
// Викликаємо логіку вибору завдання
scheduler.EvaluateNeeds();
// Перевіряємо, чи обрано завдання "Їсти"
Assert.AreEqual(TaskType.Eat, scheduler.currentTask.type);
Object.DestroyImmediate(go);
}
[UnityTest]
public IEnumerator Character_ShouldMoveToTargetPosition()
{
GameObject charGo = new GameObject();
CharacterAgent agent = charGo.AddComponent<CharacterAgent>();
Vector3 targetPos = new Vector3(10, 0, 10);
agent.MoveTo(targetPos);
// Чекаємо 2 секунди, поки агент рухається
yield return new WaitForSeconds(2.0f);
// Перевіряємо, чи агент наблизився до цілі (дистанція < 1)
float distance = Vector3.Distance(charGo.transform.position, targetPos);
Assert.Less(distance, 1.0f);
Object.Destroy(charGo);
}
72
482.ЧДТУ 262264 12 01 3
[Test]
public void DataConverter_ShouldSerializeAndDeserializeCorrectly()
{
CharacterData originalData = new CharacterData { id = 1, gender =
Gender.Male, hunger = 50 };
// Серіалізація
byte[] serializedData = SaveParser.Serialize(originalData);
// Десеріалізація
CharacterData deserializedData =
SaveParser.Deserialize<CharacterData>(serializedData);
// Перевірка цілісності
Assert.AreEqual(originalData.id, deserializedData.id);
Assert.AreEqual(originalData.hunger, deserializedData.hunger);
}
}
using System.Collections.Generic;
using Data;
using Entities;
using TMPro;
using UnityEngine;
using UnityEngine.Events;
public class GameManager : MonoBehaviour
{
[Header("World")]
[SerializeField] private Map[] maps;
[SerializeField] private Transform charactersParent;
[SerializeField] private Character characterPrefab;
[Header("UI")]
[SerializeField] private CharacterDetails characterDetails;
[SerializeField] private TextMeshProUGUI timeScaleLabel;
private List<Character> characters = new();
public static GameManager Instance { get; private set; }
public IReadOnlyCollection<Character> Characters => characters.AsReadOnly();
public Map CurrentMap => maps[SceneLoader.Instance.GlobalData.currentMap];
public CharacterDetails CharacterDetails => characterDetails;
73
482.ЧДТУ 262264 12 01 4
public UnityEvent OnTick { get; private set; } = new();
private void Awake()
{
if (Instance == null)
{
Instance = this;
}
else if (Instance != this)
{
Destroy(gameObject);
}
InitializeCharacters();
Timer.Create(transform, OnTick.Invoke, 1, true);
}
private void InitializeCharacters()
{
foreach (var data in SceneLoader.Instance.GlobalData.charactersData)
{
CreateCharacter(data);
}
}
public void CreateCharacter(CharacterData data)
{
Character newCharacter = Instantiate(characterPrefab, charactersParent);
characters.Add(newCharacter);
newCharacter.Init(data);
}
public void SlowerTime()
{
Time.timeScale = Mathf.Clamp(Time.timeScale - 1f, 0, 5);
timeScaleLabel.text = Time.timeScale.ToString() + 'x';
}
public void FasterTime()
{
Time.timeScale = Mathf.Clamp(Time.timeScale + 1f, 0, 5);
timeScaleLabel.text = Time.timeScale.ToString() + 'x';
74
482.ЧДТУ 262264 12 01 5
}
}
using Data;
using UnityEngine;
using Mechanics;
namespace Entities
{
public abstract class Character : MonoBehaviour
{
[Header("References")]
[SerializeField] protected CharacterPreview preview;
[SerializeField] protected CharacterAgent agent;
public TaskScheduler TaskScheduler { get; private set; }
public CharacterPreview Preview => preview;
public CharacterAgent Agent => agent;
public CharacterData Data { get; private set; }
public uint ID { get; private set; } = 0;
protected void Start()
{
TaskScheduler = new(this);
UpdateInterfaces();
LogConsole.Instance.AddCharacterLine(gameObject.name, "Created in this
world!");
}
public void Init(CharacterData data)
{
Data = data;
}
public void UpdateInterfaces()
{
// preview.Apply(Data);
// agent.Apply(Data);
}
public void UpdateTasks()
{
75
482.ЧДТУ 262264 12 01 6
if (TaskScheduler.IsExecuting)
{
return;
}
/*
if (Data.Hunger < 30)
{
//TaskScheduler.AddTask(new FindFood());
}
if (Data.Boredom < 30)
{
//TaskScheduler.AddTask(new Entertain());
}
if (Data.Sociality < 30)
{
//TaskScheduler.AddTask(new FindSociality());
}
if(Random.Range(0, 100) < 30)
{
TaskScheduler.AddTask(new Relax());
}
else if(Random.Range(0, 100) < 30)
{
TaskScheduler.AddTask(new Talk());
}
*/
}
}
}
using System;
using UnityEngine;
using System.Collections;
using UnityEngine.Events;
[RequireComponent(typeof(CanvasGroup))]
public class FadingAnimator : MonoBehaviour
76
482.ЧДТУ 262264 12 01 7
{
public UnityAction OnFadeOut { get; set; }
[SerializeField] private bool visibleOnStart = true;
[SerializeField][Range(0, 1)] private float scaleCoefficient = 1f;
[SerializeField] private float fadingSpeed = 0.5f;
public bool Visible { get; private set; } = false;
private CanvasGroup canvasGroup;
private Transform objectTransform;
private Coroutine currentCoroutine;
private Vector3 startScale;
private Action endAction;
private void Awake()
{
canvasGroup = GetComponent<CanvasGroup>();
objectTransform = transform;
startScale = objectTransform.localScale;
if (visibleOnStart == false)
{
FadeOutInstantly();
}
}
public void FadeIn()
{
FadeIn(null);
}
public void FadeIn(Action endAction = null)
{
if (currentCoroutine != null)
{
StopCoroutine(currentCoroutine);
}
this.endAction = endAction;
if (gameObject.activeInHierarchy)
{
77
482.ЧДТУ 262264 12 01 8
currentCoroutine = StartCoroutine(FadeInRoutine());
}
else
{
FadeInInstantly();
}
}
public void FadeOut()
{
FadeOut(null);
}
public void FadeOut(Action endAction = null)
{
OnFadeOut?.Invoke();
if (currentCoroutine != null)
{
StopCoroutine(currentCoroutine);
}
this.endAction = endAction;
if (gameObject.activeInHierarchy)
{
currentCoroutine = StartCoroutine(FadeOutRoutine());
}
else
{
FadeOutInstantly();
}
}
public void FadeInInstantly()
{
canvasGroup.interactable = true;
canvasGroup.blocksRaycasts = true;
objectTransform.localScale = startScale;
canvasGroup.alpha = 1;
Visible = true;
}
78
482.ЧДТУ 262264 12 01 9
public void FadeOutInstantly()
{
canvasGroup.interactable = false;
canvasGroup.blocksRaycasts = false;
objectTransform.localScale = startScale * scaleCoefficient;
canvasGroup.alpha = 0;
}
private IEnumerator FadeInRoutine()
{
if (canvasGroup.alpha >= 1)
{
yield break;
}
objectTransform.localScale = startScale * scaleCoefficient;
while (canvasGroup.alpha < 1 - (0.05f * fadingSpeed))
{
canvasGroup.alpha = Mathf.Lerp(canvasGroup.alpha, 1, fadingSpeed *
Time.unscaledDeltaTime * 50);
objectTransform.localScale = Vector3.Lerp(objectTransform.localScale,
startScale, fadingSpeed * Time.unscaledDeltaTime * 50);
yield return null;
}
objectTransform.localScale = startScale;
canvasGroup.alpha = 1;
endAction?.Invoke();
endAction = null;
currentCoroutine = null;
canvasGroup.interactable = true;
canvasGroup.blocksRaycasts = true;
Visible = true;
}
private IEnumerator FadeOutRoutine()
{
if (canvasGroup.alpha <= 0)
{
79
482.ЧДТУ 262264 12 01 10
FadeOutInstantly();
yield break;
}
canvasGroup.interactable = false;
canvasGroup.blocksRaycasts = false;
objectTransform.localScale = startScale;
while (canvasGroup.alpha > 0.05f * fadingSpeed)
{
canvasGroup.alpha = Mathf.Lerp(canvasGroup.alpha, 0, fadingSpeed *
Time.unscaledDeltaTime * 50);
objectTransform.localScale = Vector3.Lerp(objectTransform.localScale,
objectTransform.localScale * scaleCoefficient, fadingSpeed *
Time.unscaledDeltaTime * 50);
yield return null;
}
objectTransform.localScale = startScale * scaleCoefficient;
canvasGroup.alpha = 0;
endAction?.Invoke();
endAction = null;
currentCoroutine = null;
Visible = false;
}
}
80
ДОДАТОК В
«ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ ГРИ-СИМУЛЯТОРА
СОЦІАЛЬНОЇ ВЗАЄМОДІЇ»
Інструкція користувачеві
482.ЧДТУ 262264 34 01
Листів 3
Розробник Ткаченко В. А.
2026
482.ЧДТУ 262264 34 01 2
Рисунок В.1 – Головне меню
Рисунок В.2 – Екран завантаження
82
482.ЧДТУ 262264 34 01 3
Рисунок В.3 – Сцена симуляції
Рисунок В.4 – Меню паузи
83
ДОДАТОК Г
«РОЗРОБКА WEB-ЗАСТОСУНКУ ДЛЯ СТВОРЕННЯ РЕЗЮМЕ»
Графічні матеріали
482.ЧДТУ 262264 90 01
Листів 14
Розробник Ткаченко В. А.
2026
482.ЧДТУ 262264 90 01 2
Рисунок Г.1 – Тема роботи
Рисунок Г.2 – Вступ
85
482.ЧДТУ 262264 90 01 3
Рисунок Г.3 – Мета та завдання
Рисунок Г.4 – Стек технологій
86
482.ЧДТУ 262264 90 01 4
Рисунок Г.5 – Архітектура системи
Рисунок Г.6 – Архітектура системи
87
482.ЧДТУ 262264 90 01 5
Рисунок Г.7 – Логіка роботи планувальника
Рисунок Г.8 – Демонстрація розробленої системи
88
482.ЧДТУ 262264 90 01 6
Рисунок Г.9 – Висновки та практичне значення
Рисунок Г.10 – Аналіз вимог до системи
89
482.ЧДТУ 262264 90 01 7
Рисунок Г.11 – Діаграма прецедентів
Рисунок Г.12 – Діаграма класів
90
482.ЧДТУ 262264 90 01 8
Рисунок Г.13 – Діаграма пакетів
Рисунок Г.14 – Діаграма діяльності
91
482.ЧДТУ 262264 90 01 9
Рисунок Г.15 – Діаграма послідовності
Рисунок Г.16 – Діаграма комунікації
92
482.ЧДТУ 262264 90 01 10
Рисунок Г.17 – Діаграма скінченного автомата
Рисунок Г.18 – Обгрунтування засобів реалізації
93
482.ЧДТУ 262264 90 01 11
Рисунок Г.19 – Структурна схема
Рисунок Г.20 – Функціональна схема
94
482.ЧДТУ 262264 90 01 12
Рисунок Г.21 – Логічна схема системи
Рисунок Г.22 – Модульне та інтеграційне тестевання
95
482.ЧДТУ 262264 90 01 13
Рисунок Г.23 – Системне та приймальне тестування
Рисунок Г.24 – Відео прикладів успішного провадження
96
482.ЧДТУ 262264 90 01 14
Рисунок Г.25 – Висновки та практичне значення
97