Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9093Повний запис метаданих
| Поле DC | Значення | Мова |
|---|---|---|
| dc.contributor.advisor | Олексюк, Вадим Володимирович | - |
| dc.contributor.author | Бакалов, Артем Ігорович | - |
| dc.date.accessioned | 2026-03-25T14:34:00Z | - |
| dc.date.available | 2026-03-25T14:34:00Z | - |
| dc.date.issued | 2024 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/9093 | - |
| dc.description.abstract | Бакалов А.І. – кваліфікаційна робота бакалавра « Однокористувацька FPS гра за допомогою рушія Unreal Engine 5». З спеціальності 121 – «Інженерія програмного забезпечення» м.Черкаси 2024 рік. В даній кваліфікаційній роботі бакалавра розроблено програмний додаток з відтворенню керованих відеографічних елементів в рамках використання UE5. Гра надає можливість грати в однокористувацькому режимі спеціальних локацій Програма складається з наступних модулів: 1 Інформаційний пошук методів та засобів розв’язання заданих задач; 2 Конструювання програмного забезпечення відеогри шутеру від першої особи за допомогою рушія UN5; 3 Проектування програмного забезпечення відеогри шутеру від першої особи за допомогою рушія UN5; 4 Тестування усунення недоліків програмного забезпечення; 5 Провадження та супроводження програмного забезпечення. Для розробки програмного забезпечення для персональних комп’ютерів користувачів, в себе включають аналіз предметної області, розробку логічної структури системи, проектування інтерфейсу користувача з використанням компонентів та інструментів рушія UN5, створення бази даних, проведення модульного, інтеграційного, системного та приймального тестування. Об'єктом розробки FPS, шутер від першої особи, для персонального комп’ютера на основі операційної системи windows | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | UE5 | uk_UA |
| dc.subject | проєкт | uk_UA |
| dc.subject | розробка | uk_UA |
| dc.subject | пулл | uk_UA |
| dc.subject | шутер | uk_UA |
| dc.subject | FPS | uk_UA |
| dc.subject | UML | uk_UA |
| dc.title | Однокористувацька FPS гра за допомогою рушія UE5 | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) | |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Бакалов Артем.pdf Restricted Access | 14.17 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ Факультет інформаційних технологій і систем Кафедра програмного забезпечення автоматизованих систем ПОЯСНЮВАЛЬНА ЗАПИСКА до кваліфікаційної роботи бакалавра на тему: «Однокористувацька FPS гра за допомогою рушія UE5» Виконав: студент 4 курсу, групи ПЗС-2144 спеціальності 121 «Інженерія програмного забезпечення» (шифр і назва напряму підготовки) Студент Бакалов А.І. (прізвище та ініціали) Керівник Олексюк В.В. (прізвище та ініціали) Рецензент Сметанін О.Г. (прізвище та ініціали) Черкаси 2024 Черкаський державний технологічний університет (повне найменування вищого навчального закладу) Факультет інформаційних технологій і систем Кафедра програмного забезпечення автоматизованих систем Освітній рівен бакалавр Спеціальність 121 «Інженерія програмного забезпечення» Освітня програма Інженерія програмного забезпечення ЗАТВЕРДЖУЮ Зав. кафедри ПЗАС, професор ____________________ С. Голуб «___» _______________ 2024 року З А В Д А Н Н Я НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ Бакалов Артем Ігорович (прізвище, ім’я, по батькові) 1. Тему проекту (роботи) Однокористувацька FPS гра за допомогою рушія Unreal Engine 5 Керівник проекту (роботи) Олексюк Вадим Володимирович к.т.н., доцент (прізвище, ім’я , по батькові, науковий ступінь, вчене звання) Затверджені наказом Черкаського державного технологічного університету від « 26 » лютого 2024 року №60/04 2. Строк подання студентом проекту (роботи) «3» червня 2024 року 3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління; вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління ресурсами 4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ; Існуючі методи та засоби розв’язання поставлених завдань; Впровадження результатів дослідження у практику проектування програмного забезпечення інформаційних систем; Розробка та тестування програмного забезпечення; Висновки; Список використаних джерел; Додатки. 5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; Слайд №1. Слайд №2. Слайд №3. Слайд №4. Слайд №5. Слайд №6. Слайд №7. Слайд №8. Слайд №9 Слайд №10. Слайд №11. Слайд №12. Слайд №13. Слайд №14. Слайд №15 6. Консультанти розділів роботи Підпис, дата Роз Прізвище, ініціали та Завдання Завдання діл посади консультанта видав прийняв 1 2 3 7. Дата видачі завдання 01 грудня 2023 р. КАЛЕНДАРНИЙ ПЛАН Строк виконання етапів № п/п Назва етапів випускної роботи Примітки кваліфікаційноїроботи 1 Постановка задачі 01.12.2023 виконано 2 Підготовка завдання 07.12.2023 виконано 3 Погодження завдання 10.12.2023 виконано 4 Затвердження завдання 20.12.2023 виконано Основна стадія 1 Підбір матеріалів 01.01.2024 виконано 2 Аналіз шляхів вирішення поставленої задачі 10.02.2024 виконано 3 Розрахунок основних параметрів роботи 17.02.2024 виконано 4 Вибір кінцевого варіанту проектного рішення 30.04.2024 виконано 5 Оформлення первісної редакції роботи 5.05.2024 виконано Заключна стадія 1 Узгодження прийнятих проектних рішень з 10.05.2024 виконано керівником 2 Оформлення пояснювальної записки роботи в 20.05.2024 виконано кінцевій редакції 3 Попередній захист роботи 25.05.2024 виконано 4 Затвердження роботи 30.05.2024 виконано 5 Рецензування роботи 31.05.2024 виконано 6 Захист роботи 13.06.2024 виконано Студент _____________________ Бакалов А.І. (підпис) (прізвище та ініціали) Керівник роботи _____________________ Олексюк В.В. (підпис) (прізвище) ЗМІСТ АНОТАЦІЯ ......................................................................................................... 6 ВСТУП ................................................................................................................. 8 РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ ........................................................................... 10 РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ У ПРАКТИКУ ПРОЕКТУ ВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ ....................................................................... 14 2.1 Моделювання предметної області .................................................. 15 2.1.1 Предметна область моделювання. Модель предметної області. Словник предметної області ............................................................. 16 2.1.2 Елементи моделювання предметної області ................................. 18 2.1.3 Розробка області моделювання ...................................................... 21 2.2 Формування та аналіз вимог .................................................................. 22 2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні вимоги .................................................................................. 23 2.2.2 Формування вимог за допомогою діаграм прецедентів .............. 26 2.3 Проектування логічної структури програмного комплексу ............... 28 2.3.1 Діаграма класів ................................................................................ 29 2.3.2 Діаграма пакетів .............................................................................. 32 2.4 Архітектурне проектування ................................................................... 33 2.4.1 Діаграма компонентів ..................................................................... 33 2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма розгортання ....................................................................................... 35 2.5 Моделювання поведінки системи ......................................................... 37 2.5.1 Діаграма діяльності ......................................................................... 37 2.5.2 Діаграма послідовності ................................................................... 38 2.5.3 Діаграма комунікації ....................................................................... 40 2.5.4 Діаграма скінченного автомату ...................................................... 41 РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ............................................................................................. 44 3.1 Розробка програмного комплексу ......................................................... 44 3.1.1 Обґрунтування вибору засобів реалізації ..................................... 44 3.1.2 Опис структурної (функціональної) схеми ................................... 45 3.1.3 Опис логічної схеми системи ......................................................... 50 3.1.4 Розробка бази даних ........................................................................ 51 3.1.5 Розробка інтерфейсу користувача ................................................. 52 3.1.6 Опис розробки програмних компонентів ...................................... 56 3.2 Тестування системи ................................................................................ 59 3.2.1 Модульне тестування ...................................................................... 59 3.2.2 Інтеграційне тестування .................................................................. 61 3.2.3 Системне тестування ....................................................................... 64 3.2.4 Приймальне тестування .................................................................. 65 3.3 Приклади впровадженого програмного комплексу ............................ 67 ВИСНОВКИ ...................................................................................................... 68 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ....................................................... 70 ДОДАТОК А ..................................................................................................... 70 ДОДАТОК Б ...................................................................................................... 70 ДОДАТОК В ..................................................................................................... 70 ДОДАТОК Г 70 АНОТАЦІЯ Бакалов А.І. – кваліфікаційна робота бакалавра « Однокористувацька FPS гра за допомогою рушія Unreal Engine 5». З спеціальності 121 – «Інженерія програмного забезпечення» м.Черкаси 2024 рік. В даній кваліфікаційній роботі бакалавра розроблено програмний додаток з відтворенню керованих відеографічних елементів в рамках використання UE5. Гра надає можливість грати в однокористувацькому режимі спеціальних локацій Програма складається з наступних модулів: 1 Інформаційний пошук методів та засобів розв’язання заданих задач; 2 Конструювання програмного забезпечення відеогри шутеру від першої особи за допомогою рушія UN5; 3 Проектування програмного забезпечення відеогри шутеру від першої особи за допомогою рушія UN5; 4 Тестування усунення недоліків програмного забезпечення; 5 Провадження та супроводження програмного забезпечення. Для розробки програмного забезпечення для персональних комп’ютерів користувачів, в себе включають аналіз предметної області, розробку логічної структури системи, проектування інтерфейсу користувача з використанням компонентів та інструментів рушія UN5, створення бази даних, проведення модульного, інтеграційного, системного та приймального тестування. Об'єктом розробки FPS, шутер від першої особи, для персонального комп’ютера на основі операційної системи windows Ключові слова: UE5, проєкт, розробка, пулл, шутер, FPS, UML 6 ANNOTATION Bakalov A.I. – "Single-Player FPS Game Using Unreal Engine 5": Bachelor's Qualification Thesis in Specialty 121 – "Software Engineering" Cherkasy, 2024. This bachelor's thesis is dedicated to the development of a software application for playing first-person shooter (FPS) games using the Unreal Engine 5 (UE5). The developed game offers a single-user mode with various levels. The software consists of the following modules: Information search for methods and tools to solve the assigned tasks; Construction of software for a first-person shooter video game using the UN5 engine; Designing software for a first-person shooter video game using the UN5 engine; Testing and troubleshooting software; Implementation and support of software. The development of software for personal computers for users includes the analysis of the subject area, the development of the logical structure of the system, the design of the user interface using the components and tools of the UN5 engine, the creation of a database, and the conduct of module, integration, system and acceptance testing. Keywords: UE5, project, development, pool, shooter, FPS, UML ЧДТУ 242234 001ПЗ ВСТУП Актуальність теми: Актуальність встановлюється потребою в розробці програмного забезпечення інформаційної системи за темою шутеру від першої особи за допомогою рушія UN5 кваліфікаційної роботи бакалавра з відтворенням реалістичної графіки в рамках можливостей рушія: Головні задачі: 1 Інформаційний пошук актуальних методів та засобів розв’язання заданих задач; 2 Проектування та конструювання програмного забезпечення в рамках відеогри шутеру від першої особи за допомогою рушія UN5; 3 Тестування усунення недоліків програмного забезпечення; 4 Провадження та супроводження програмного забезпечення. При розробці програмного забезпечення в сфері персональних комп’ютерів користувачів включають у себе аналіз області предмету розробки, розробку логічно-функціональної структури системи, проєктування інтерфейсу користувача з використанням компонентів та інструментів рушія UN5, створення бази даних, проведення тестувань таких як модульне, інтеграційне, системне та приймальне в рамках етапів їх проходження Об’єктом роботи є процес проєктування, конструювання, розробка та тестування програмного забезпечення інформаційних систем. Мета і завдання розробки: Метою кваліфікаційної роботи є розробка програмного забезпечення для відтворення неймовірного досвіду в рамках інформаційної програми відеогри- шутеру від першої особи за технологіями рушія UE5. Щоб досягнути поставленої мети підняті на вирішення наступні над важливі завдання: 1 Глибокий аналіз актуальних методів та засобів розв'язання поставлених задач; 2 Проєктування програмного забезпечення відеогри шутеру від першої; 9 ЧДТУ 242234 001ПЗ 3 Пошук інформації щодо актуальних методів та засобів розв’язання заданих задач; 4 Конструювання програмного забезпечення відеогри шутеру від першої особи за допомогою рушія UN5; 5 Розробка, тестування та усунення недоліків, що виникли в ході реалізації програмного забезпечення; 6 Деплоймент та супроводження програмного забезпечення. Об'єкт розробки: Об'єктом розробки є FPS, шутер від першої особи, для персонального комп’ютера на основі операційної системи windows. Методи проектування та конструювання: Надалі вступ згадуються сучасні ігрові рушії, такі як Unreal Engine 5, що використовуються, як і для розробки ігор, створення високоякісної 3D-графіки в реальному часі, та навіть для інженіренгу складних систем. Даний рушій забезпечує розробника потужними інструментами для моделювання, текстурування, анімації, програмування логіки та візуалізації графічних об’єктів з використанням планів 1D, 2D та 3D. Такий ігровий рушій як UE5 надає можливість створити імерсивні ігрові світи з використанням сучасних технологій з використання фотореалістичною графікою та складними фізичними симуляціями. Опис отриманих результатів: Результатом проєктування та розробки є гра шутер від першої особи у видуманій реальності з ценарієм пандемії що призводить до створення ходячих мерців та мутантів. В ході розробки було спроєктовано та розроблено гнучкі модулі системи, які можна використовувати при продальшому розширені проєкту, або використовувати в подальших проєктах. Розроблені логічні системи підбору та спавну предметів, лістинг ворогів на основі ідексування бази даних, акторів гри базованих на парадигмах Об’єктно-орієнтоване програмування (ООП), також за допомогою даних 10 ЧДТУ 242234 001ПЗ парадигм було розроблено систему підбору зброї та ігрових предметів. Також результатів можна внести повністю функціональний інтерфейс, та системи збереження прогресу користувацьких налаштувань системи. Особистий внесок автора: Базуючись на зібраних мною даних, та побажань аудиторії мною було розроблено систему для кваліфікаційної роботи бакалавра, яких на даний момент відеоігровий ринок не може надати. В ході роботи переді мною постали наступні задачі: - кодування логічних структур системи; - розробка та імплементація інтерфейсу; - розробки систем спавну ворогів; - розробка логіки подій спавну предметів; - анімування зброї персонажа; - створення системи відтворення звукових ефектів для імплементації її в проєктну частину проєкту. 11 ЧДТУ 242234 001ПЗ РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ pgAdmin - це безкоштовний та відкритий інструмент управління БД(базами даних), що підтримує PostgreSQL. Цей інструмент має широкий спектр функцій, включаючи управління таблицями, стовпцями, зв'язками, процедурами, функціями та подіями, що може допомогти при роботі з структурами даних проєкту, інвентарем та іншого. Окрім цього, pgAdmin також надає можливість використовувати вбудований редактор SQL для створення, редагування та виконання SQL-запитів. Переваги pgAdmin - безкоштовність; - широкий спектр функцій; - підтримка множинного числа баз даних для різних проєктів; - легкий для розуміння інтерфейс користувача. Недоліки pgAdmin - іноді може бути повільним; - деякі функції можуть бути складними у використанні. Mixamo - це безкоштовний інструмент з надання 3D моделей персонажів для подальшої їх імплементації в проєкт. Також сайт надає прессети готових персонажів та їх анімації для створення проєкту. Переваги Mixamo - безкоштовний; - надає об’єкті, текстури, скелети, та анімації на які б пішли десятки годин; - простота у використанні; - гарне сучасне оформлення сайту; Недоліки Mixamo - малий пул персонажів; - не всі анімації підходять до проєкту; 12 ЧДТУ 242234 001ПЗ - не очевидна імплементація при використанні технології металюди; Freesounds – це інструмент по наданню як комерційних так і повністю безкоштовних звуків для використання та імплементації їх в проєкт. Даний сервіс надає численну бібліотеку звуків.. Переваги Freesounds - широкий спектр звуків різної якості; - сортування за ліцензійним використанням; Недоліки Freesounds - не відповідний запиту пошук - немає сортування по низькоякісним звукам Metahuman - це комерційний інструмент для керування створення використання фотореалістичних людей, а точніше 3D макетів реально існуючих людей для відеогри, відео, та іншого. Переваги Metahuman - неймовірний підхід при створені об’єктів людей; - системне повноцінне надання функціоналу; - підтримка імплементації кастомних анімації пероснажа; - надання інструменту з ретаргетінгу анімації для підтримки UE4, UE5, Mixamo та інших скелетів. Недоліки Metahuman - зобов’язання при використанні функціоналу; - складність у використанні, через не популярність та новизну технології. Ігровий рушій Unreal Engine 5 (UE5) – розроблений Epic Games. Він був випущений у 2021 році як наступник попередньої версії, Unreal Engine Unreal Engine (UE) — серія тривимірних ігрових движків комп’ютерної графіки, розроблених Epic Games, Сама концепція рушія не новою та була закладена ще у 1998 році. Першочергово розроблювався суто для ПК-шутерів від першої особи, згодом UE розшири свій функціонал що дало змогу створенню різноманітних жанрів відеоігор. А також при подальшому маштабуванні був 13 ЧДТУ 242234 001ПЗ прийнятий в інших галузях, особливо в кіно та телеіндустрії. UE написаний на C++ і має високий ступінь імплементації в існуючи системи, підтримуючи широкий спектр існуючих девайсів такі як ПК, мобільних пристроїв , консолей і платформ VR тощо . Переваги UE5 - масштабність функціоналу - величезна бібліотека даних - можливість візуального програмування - технології з відтворенню та створення анімації - неймовірний дизайн згідно всіх стандартів сучасності Недоліки UE5 - ціна готових ассетів, текстур анімації - малий список безкоштовних елементів Постановка задачі Підчас розглядів аналогів було виявлено що ринок відеоігор відступився від розробки так званих м’ясних зомбі шутерів від першої особи існуючі аналоги розроблюємого проєкту застарілі, тому при розробці кваліфікаційної роботи бралось до уваги відсутність красивої фотореалістичної графіки, на доопрацювання існуючих механік проєктів брались механіки стрільби, системи луту, інтерфейсу Так як з основу береться більш розробки актуалізація картинки системи то логічним результатом такого підходу стає обмеженість роботи на старих обчислювальних системах користувачів. Від самої системи вимагається - сучасна графіка - імплементація сучасних механік шутерів - розробка та імплементація зручного звичного інтерфейсу - забезпечення оптимізації під різні інтерфейси - забезпечення налаштувань графіки для різних систем 14 ЧДТУ 242234 001ПЗ ВИСНОВОК ДО РОЗДІЛУ 1 При розробці однокористувацької гри шутеру від першої особи потрібно врахувати та згідно розрахунків розробити модульну систему для подальшої імплементації та розвитку проєкту на основі вже створеного коду, тим самим мінімізувати можливих та спланованих подальших змін в систему. Гра повинна мати сучасний дизайн створення коду та використовувати передові технології розробки. Цільова аудиторія гри повинна бути визначена згідно рейтингу Pan European Game Information (PEGI). У документі наведено огляд різних інструментів для подальшої імплементації в проєкт що допомагає скоротити час розробки, покращити якість вихідного проєкту, та зменшити фінансові затрати при реалізації. З усіма зазначеними перевагами та недоліками інструментів. Це безпосередньо вплине на розробку при використанні названого пулу інструментів. Також надано коротку інформацію про ігрові рушії Unreal Engine його особливості та історію застосування у різних галузях, переваги і недоліки що надають розуміння тематики з приводу використання цього рушія. Отже, основний висновок полягає в тому, що для виконання кваліфікаційної роботи бакалавра необхідно продумати модульну та надійну систему для подальшого розвитку проєкту з імплементацією нових предметів та об’єктів які будуть базуватись на розроблених методиках закладених при проєктуванні та безпосередній розробці проєкту. 15 ЧДТУ 242234 001ПЗ РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ У ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ Даний розділ підіймає тему результатів досліджень в сфері тематики відеоігрової індустрії а точніше їх реалізація цих досліджень при проєктуванні системи Архітектура системи: Архітектура відеогор сама по собі складна і багато шарова. Різні шари відповідають за свій процес який в результаті і надає існуючу картинку. Наприклад при виконанні такого складного набору процесів як візуалізація 3D графіки та вирахуванні фізики. Потрібно мати сформовану спеціальну систему, індексів та імен до яких при калькуляції будуть посилатись елементи та модулі відтворюваної програми. Такими елементами можуть бути реалізація об’єктів класів. На прикладі одного актору головного гравця можна прийти приблизний шлях по одному з етапів комплексного підходу для відтворення тих чи інших елементів системи. Кожен з цих елементів посилається на свій шар виконання та її логіку. Ці шари візуалізації оброблюються ядрами, що за сутністю своєї є більш глибоким процесом калькуляції в рамках рушія свого роду ці ядра є репліко поведінки обчислень в середині людського мозку де кожна частина відповідає за свої рецептори та функції, при співставленні яких отримується повна картина. Щоб відтворити персонажа ігровий рушій посилається на шаблон об’єкту який в свою чергу посилається на шаблон скелету кісток персонажу, фізичного скелету, скелету анімації, опису реалізації класу персонажу, логіку реалізації анімації в прописаному класі та їх заготовлених шаблонів. Також в цьому процесі викликаються матеріали та текстури. Для правильної калькуляції фізики світла в реальному часі. Таким чином відбувається реалізація візуалізації, що бачить користувач системи не кожен об’єкт класу буде взаємодіяти через створені префаби, або 16 ЧДТУ 242234 001ПЗ шаблонами даних, з ядрами рушія для подачі зображення на монітор користувача. Вибір технології та інструментів: Blueprints це технології з автоматизації написання коду через шаблони надані рушієм, які базуються на мові С++ серед переваг таких шаблонів це свого роду просто та у використані у порівнянні з написанням чистого С++ коду. А також надання середнього рівня оптимізації для проєкту так як програміст використовує правильні з точки зору рушія заготовки коду згідно парадигми ООП в сфері написання коду та підходу до чистоти коду. Автоматизація взаємодії: автоматизацією є візуальне представлення події для подальшої взаємодії з ними, що базується на можливості обрахункові здатності заліза користувача. 2.1 Моделювання предметної області Предметною областю даного програмного продукту є ігри в сфері науково-фантастичні шутери від першої особи. Така тематика є досить популярною серед гравців по всьому світу, оскільки вона пропонує захоплюючий і динамічний ігровий досвід. Ідейними гігантам цього жанру є Doom, Quake та Half-Life. Усі три гри використовують схожу систему рівнів. Зазвичай ці рівні складаються з кількох локацій, які гравець повинен з пункту A в пункт B робивши завдання C, D та I(за вибором гравця), щоб досягти кінцевої цілі. Також у цих трьох ігор є різні монстри, яких гравець повинен перемогти, щоб просунутися далі по рівню та по сюжету в цілому. Ця система рівнів є ефективною та зарекомендувала себе, оскільки вона забезпечує гравцям відчуття прогресу та надає їм відчуття задоволення від перемоги над монстрами. Half-Life дещо відрізняється від Doom і Quake тим, що вона має більш складний і взаємопов'язаний сценарій. Гравець не просто проходить рівні, а й бере участь у сюжеті, який розвивається протягом гри. Це робить Half-Life 17 ЧДТУ 242234 001ПЗ більш захоплюючою та занурюючи користувача глибше в сюжет, на фоні вище згаданих ігор. 2.1.1 Предметна область моделювання. Модель предметної області. Словник предметної області Предметна область моделювання Для таких ігор краще за все підійде спіральна модель життєвого циклу. Сама спіральна модель життєвого циклу продукту, розробляється та зображується у виді спірального об’єкту, яка розпочинається планування проєктованої системи, що розкручується, з кожним проходженням певного умовного кроку. Виходячи з цього, в результаті з чергової віті отримуємо повноцінний прототип проєкту, який доповнює версію проєкту. Версія, що задовольняє всі вимоги та готова до випуску. Перевагами такого підходу це особлива увага до ризиків, додаткові функції програмного продукту, що можуть бути внесені в процесі створення програмного прототипу, або додані у наступний етап, з цього маємо розуміння що спіральна модель є доволі універсальною, що в свою чергу є неймовірним плюсом для проєкту такого масштабу. Модель предметної області Сама гра має наступну модель: Персонаж: Може взаємодіяти з предметами через утримування клавіш, чи через ефект перетинання. Зброя: гра пропонує гравцеві широкий вибір зброї за умови знаходження її підчас місії зброя може падати з ворогів або розставлена по рівню. Світ гри: Це місії в різних локаціях, де гравець може повинен вижити як найдовше Система луту: гравець може підбирати аптечки, патрони, зброю в ході проходження рівня. 18 ЧДТУ 242234 001ПЗ Рисунок 2.1 - Діаграма предметної області Словник предметної області Підготовлено словник з даної предметної області підготовано словник Розробка ігор – процес створення відеоігор від ідеї до реалізації. Включає в себе проектування гри, програмування, дизайн рівнів, створення графіки, звукового супроводу та тестування. Rendering (рендеринг) – візуалізація ігрових об’єктів в рамках роботи рушія у реальному часі в режимі тестування чи в скомпільованому файлі. Використовуються як і при створені ігор так і прои 3д дизайну. Blueprints – візуальна система програмування у Unreal Engine, що дозволяє створювати логіку гри без написання коду. Materials – матеріали визначають зовнішній вигляд об'єктів у грі, включаючи текстури та ефекти. Prefabs (префаб) – це набір файлі та об’єктів які використовуються у відео іграх для наповненя об’єктів в середині грі, такими об’єктами можуть бути актори, зброя і так далі. Asset (ассет) – Елемент або ресурс, такий як текстура, модель чи звук, 19 ЧДТУ 242234 001ПЗ підготований таким чином щоб множинно використовувати в подальшому в у грі. В рамках ігрового рушія система маніпулює первинними ключами та індексом імен для доступу до модулів та об’єктів гри, кожен елемент це прописаний та заготовлений шаблон класу з своїми інструментами для реалізації. Рисунок 2.1 – Діаграма словника предметної області 2.1.2 Елементи моделювання предметної області При побудові моделей діаграм використовувались наступні необхідні елементи та зв’язки UML, які поєднувалися для побудові діаграм. 20 ЧДТУ 242234 001ПЗ Таблиця 2.1 Елементи моделювання Елементи Їх значення представляє роль, яку грає певна сутність (користувач, адміністратор) у взаємодії з системою описує функціональність або послугу, яку система надає акторові опис класу, та похідних об'єктів цього класу з подібною назвою структурою і так далі Набір функціоналу для імплементування в класи, описують структуру взаємодії модуль коду, що описує логіку та дані фізичний елемент, що існує під час виконання при реалізації модульної системи механізм для групування елементів Об'єкти пов'язані з іншими, такими як класи, інтерфейси та інші об'єкти, використовуючи різні типи зв'язків. Таблиця 2.2 Зв’язки елементів моделювання Елементи зв’язку Їх значення Відношення між екземплярами класів 21 ЧДТУ 242234 001ПЗ Продовження таблиці 2.2 Сильна форма агрегації, де частини існують виключно в контексті цілого Відношення "частина-ціле" між класами Відношення між загальним суперкласом та більш спеціалізованими підкласами Відношення між класом або компонентом та інтерфейсом, який вони реалізують Відношення, коли один елемент залежить від іншого Дана UML-діаграма класів моделює предметну область FPS шутеру на рушії UE5. Вона відображає основні сутності, їх атрибути та взаємозв'язки між ними. Рисунок 2.2 – UML діаграма класів предметної області однокористувацької FPS гри 2.1.3 Розробка області моделювання 22 ЧДТУ 242234 001ПЗ Остання крок в аналізі предметної області полягає в розробці та впровадженні концептуального макету або так званої логічно-інформаційної структури проєкту. При звичайних умовах при побудуванні логічно-інформаційно моделі використовують "сутність-зв'язок", але в даному випадку було використано mind-maps переваги мапінгу достатньо різноманітні вони включають в себе наступне: - огляд великої за масштабами теми та дозволяє представити її в більш стислому вигляді; - заохочує бачити ширшу картину проєктуємої системи; - надає можливість щодо вибору ресурсних матеріалів, які потрібні для виконання завдання; - надає вам більш привабливий і приємний вигляд для сприйняття картини. Рисунок 2.3 – Модель предметної області Головний вузол: - гра, це кореневий абстрактний вузол системи, який охоплює всі основні та вторинні модулі гри. Підвузли: - модуль «Список», відповідає за за вивід UI/UX інтерфейсу для гравця 23 ЧДТУ 242234 001ПЗ на якому він може вибрати наявні «данжі. Є реалізації системи вибору в грі системою для вибору режиму гри; - режим гри «Рівні», Режим гри де локація обмежує гравця в просторі та сюжетом локації з основним завданням що гравцю потрібно виконати щоб пройти данж; - рівень (умовна позначка для файлу) no.1 - рівень (умовна позначка для файлу) no.2 - рівень (умовна позначка для файлу) no.3 - модуль «Налаштування», відповідає за налаштування гри під виомги користувача. - графіка (умовна позначка можливих налаштувань) - звук(умовна позначка можливих налаштувань) «Файл збережених налаштувань» це файл в якому буде збережено дані про налаштування користувача в модулі «Налаштування». «Звуки» системні файли гри які будуть встановлені разом з грою «Бібліотеки», умовне позначення підвантажуваних грою файлів які будуть потрібні в ході виконання дій користувачем «Текстури», файли графічного характеру що будуть підвантажені в ході завантаження рівня та будуть з’являтись рендеритись перед корстувачем згідно обраного куда огляду користувача. «Системні файли», умовне позначення підвантажуємих гроб файлів які будуть потрібні в ході виконання дій користувачем 2.2 Формування та аналіз вимог В незалежності від проєкту, що розробляється, формуються та аналізується вимоги до ПЗ. При аналізу вимог до програмного додатку потрібно продумати сферу роботи ПЗ за основу береться головні питання «що повинна зробити програма?», яка область роботи програмного додатку, сценарії використання програмного додатку. Сутність даного розділу в формуванні вимог, які мають функціональних та 24 ЧДТУ 242234 001ПЗ не функціональний формат до програмного додатку на етапі проєктування. Де функціональна точка зору це визначення вимог до поведінки системи наприклад як бізнес логіка, вимоги користувача, опис внутрішньої поведінки та роботи системи, обчислення та тому подібне. Та де не функціональна точка зору це вже вимоги до характеру системи. Такими не функціональними вимогами є визначення бізнес правил, атрибутів якості, вимог до зовнішніх систем в рамках яких програмний додаток буде працювати. Також в це поняття включають системні вимоги до програмних інтерфейсів, надійності, обладнання тощо. Врахувати потрібно також обмеження законодавства країни в якій буде. До прикладу програмні продукти по типу веб сторінки при розумному використанні скриптування та графічних елементів не можуть бути порівнянні з повноцінними системами по виводу стабільного потоку відрендерених в моменті виводу графічних зображень, таким системи якраз і назвають одним словом ігри. На даний момент ігри потребують набагато більше ресурсів, що відеокарти, оперативної пам’яті, що головного процесора системи чим умовна сторінка в браузері. Ще 4 роки тому 6Гб відео пам’ять на відеокарти було достатньо щоб відтворювати над сучасні, на той момент відео ігри, але технологіях не стоять на місці і на ринку вже є відеокарти на 24Гб для надскладних. Згідно цього системні характеристики персонального комп’ютера користувача мають важливу роль при описі продукту, так як слабкій системі програмний додаток може працювати не повноцінно та принесе користувачу тільки негативні емоції. Далі в пунктах буде наведено саме рекомендовані системні характеристики для відтворенню даного програмного продукту. 2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні вимоги Формування вимог до програмного забезпечення 25 ЧДТУ 242234 001ПЗ В даному розділі будуть підняті такі важливі питання як вимоги до проєктуємої системи, вимоги до характеристик систем щоб можуть бути валідні для відображення та відтворення програмного продукту такого як відеогра. Певно одними з основних вимог до кожної розроблюваної системи це питання які функції будуть розроблені або інтегровані в розроблювану систему для таких масштабних проєктів як відеоігри дуже важливо сформувати план розробки і первинності інтеграції механік так як робота яка робиться в даних проєктах потребує участі не однієї людини. В рамках кваліфікаційної роботи бакалавра потрібно сформувати правильний пул вимог до проєкту які будуть вважати проєкт доконаним, що забезпечить відведення більше часу на у процесі відлагодження модулів та системи в цілому. Таким чином при перша версія програмного продукту що буде продемонстрований матиме надійну протестовану систему з виконаними умовами розробки. Прикладом функцій що можна розглянути при розробці це наявність елементів для взаємодії персонажа з всесвітом відеогри. Наприклад, а яким саме чином користувач буде взаємодіяти з підбераємими предметами, який буде key-mapping, чи зможе користувач змінювати налаштування графічних налаштувань під свою систему чи проєкт матиме блокування на зміну, для якого пулі систем буде доступний проєкт, які ОС зможуть виконати файл гри, ці та інші важливі питання будуть підійматися надалі, як частина підпунктів що класифікують відняте питання та забезпечують легку розуміння при піднятті документації по проєкту таким чином щоб всі залучені сторони отримали максимальний зрозумілий контекст в рамках якого проєктується та розроблюється система. Первинні і детальні вимоги Основна вимога до база даних для кваліфікаційна робота бакалавра це наявність наступних даних: - про внутрішньо ігрові предмети; - пул противників. Та мати наступний функціонал в рамках умовностей самого проєкту: - редагування даних. 26 ЧДТУ 242234 001ПЗ Вимоги замовника та розробника Основна вимога до база даних для кваліфікаційна робота бакалавра це наявність наступних даних: - простий зрозуміли та візуально приємний інтерфейс; - різни типи ворогів; - різні типи озброєнь. Та мати наступний функціонал в рамках умовностей самого проєкту та безпеки функціонування проєкту в цілому буде наступним: - використання ігрового рушія UE5; - використання системи автоматизованого програмування. Функціональні та нефункціональні вимоги Функціональні вимоги це тип вимог при які мають наступні характеристики: - детальний опис що програма повинна виконувати, при якому не буде місця для двозначності тих чи інших деталей; - місце для перевірки належного виконання вкладеного логічного процесу описаного документацією; - узгодженість програмного продукту, а саме, програма чи то веб додаток надає очікуваний результат згідно законів логіки та користувацького досвіду; - концептуальної бази додатку який орієнтований на зміну функціоналу в майбутньому, так як в ході життєвого циклу програма зазнає змін, що функціонально, що ui/ux інтерфейсу. Функціональними вимогами для програмного додатку кваліфікаційної бакалаврської роботи це: - програма повинна надати користувачу звичний тип початкового меню; - програма повинна мати модуль зміни налаштувань; - програма повинна надавати гравцю вибір рівня; - програма повинна надавати гравцю інформацію щодо тих чи інших змін в налаштування; 27 ЧДТУ 242234 001ПЗ - програма має надавати можливість для подальшого вненсення додаткового контенту на основі існуючої та розробленої системи. Нефункціональні вимоги Тип вимог при якому описуються функціонального обмеження системи, потреб для функціонування. Для даного програмного продукту нефункціональні вимоги є наступні: Для використання даного продукту потрібно встановлення програмного додаткового програмного забезпечення такого як DirectX. Дане програмне забезпечення все необхідне додаткове програмне забезпечення буде йти у додатку до програми завантажувача однокористувацької гри. Щоб встановити гру потрібно мати файл з автоматизованого становлення та всі необхідні файли з яких можна буде налагодити правильний функціонал. Сам цей фал буде розповсюджений цифровим дистриб’ютором відеоігор та іншого програмного забезпечення Стім, тому користувач повинен мати в першу чергу встановлений Стім з існуючим та дійсним акаунтом в ньому. Операційна система система має бути Windows 10 та вище для запуску даного продукту. Мобільного аналогу та реалізації під макОС існувати не може, так як системні вимоги для таких пристроїв не під ’ємні. Також до не функціональних вимог даного продукту можна віднести наступні пункти: - програмний продукт повинен працювати стабільно з мінімальною кількості помилок, збоїв чи то вилетів; - програмний продукт повинена мати достатню складність, щоб бути захоплюючою, але не занадто складною, щоб бути відштовхуючою; - програмний продукт повинен бути збалансованим таким чином щоб жодна зброя не мала неймовірну перевагу над іншими. сам ворог повинен бути на рівні з гравцем, або через кількість або через якісні характеристики попередньо згаданого. 2.2.2 Формування вимог за допомогою діаграм прецедентів Діаграми прецедентів тип діаграм що дозволяє уявити типи роле та їх 28 ЧДТУ 242234 001ПЗ взаємодії з системою, при цьому не вказуючи послідовність виконання дій. Сутність даних діаграм показати що може систем зробити з точки зору користувача. Роль таких діаграм при формуванні технічної документації проєкту, полягає в надані простої своєрідної план-схеми проєкту з призначенням відображення простого пояснення роботи розроблюваної системи, створення та подальшого узгодження ПЗ. При створенні діаграми використовують основні об’єктів: - «акторів» у формі чоловічка, що передає собою дійову особу в програмному додатку, такими акторами можуть виступати користувачі або інші дійові особи, що потрібні при реалізації тих чи інших функцій програмного додатку; - «прецедентів» у формі овалів, дана фігура представляє собою доступну дію, функцію, або завдання, - що може реалізувати програмний додаток; - «система» у формі прямокутника, дана фігура представляє собою систему в рамках якої описується функціонал. Рисунок 2.3 – Нотація діаграми прецедентів (використання) 29 ЧДТУ 242234 001ПЗ На цій діаграмі прецедентів зображеній на рисунку 2.3 маємо два актори: «Гравець» та «Система». Як і було сказано вище вони мають доступ до певного функціоналу програмного додатку. Система виконує функціонал підкачки даних для користувача який звертається до програмного продукту. - вибір налаштувань, користувач може налаштувати гру під себе наприклад під свої навушники, чи під стерео систему, або до прикладу під свій стиль гри не всім підходить стандартне поле зору; - завантажити рівень, прецедент при якому користувач вибирає потрібний йому режим а згідно вибраного режиму рівень який йому потрібен; - обробити запит, тут ступає в роль актори «Система» який повинен отримати запит від користувача, зберегти результат, та надати актору «користувач» те що йому потрібно. В ході даного виконання запиту Система буде звертатись до відповідних прецедентів таких як: Завантажити ворогів, Завантажити рівень, завантажити лут. Згідно технічної документації по використанню діаграм прецедентів стрілки вказують ініційовану дію від актора до прецедента. 2.3 Проектування логічної структури програмного комплексу Даний тип проектування відповідає за розробку логічної структури програми за допомогою методів проєктування використовуючи всі UML діаграми за для отримання необхідних результатів. Такими результатами в ході проєктування системи будуть діаграми класів та діаграми пакетів що будуть демонструвати логічну структуру проєкту та модулів що до нього входять. Зазвичай на етапі проєктування розглядаються сама логічна структура побудови програми більше ніж глибоке занурення в деталі представлених класів. А також представлення пакетів що входять в логічну структуру програми. На прикладі розроблюємого програмного продукту для кваліфікаційної дипломної роботи бакалавра згідно заданої теми випливають особливості сфери в якій розробляється даний проєкт згідно вище зазначених використаних технологій. 30 ЧДТУ 242234 001ПЗ Більш детально буде описано в пункті «2.3.2 Діаграма пакетів» 2.3.1 Діаграма класів Тема яку підіймають діаграми класів в програмуванні це візуальне відображення взаємозв’язків класів в ході програмування за парадигмою ООП, в ході даної парадигми програмування, структура кодів поділяється на класи, при збільшенню функціоналу програми та наростанні кількості класів стає дедалі важче орієнтуватися в коді тому в ході створення технічної документації проєкту дуже важливим етапом є створення діаграм класів до розроблюваних модулів програми. Діаграми класів, як було заначено вище, мають на меті спростити сприйняття концепції та уточнити взаємозв’язок системи, що при подальшому життєвому циклу програми дозволяє зробити набагато менше потенційних помилок, а також набагато спрощує життя тих програмістів, що в ходять в проєкт на фінальних етапах того ж самого життєвого циклу програмного продукту. Рисунок 2.4 – Діаграма класів рівня зі сюжетом 31 ЧДТУ 242234 001ПЗ На рисунку 2.4 ми можемо побачити взаємодію об’єктів (класів) з гравцем та середовищем, що його оточує. Клас гравець має викликає або взаємодіє з більшістю класів на пряму чи опосередковано Використовуючи зазначені дії такі як відібрати використовувати, вибирати стріляти і так далі. З класом гравець можуть взаємодіяти вороги атакуючи його. В свою чергу з клас ворог при ліквідації може використати клас лут, в ході якого з ворога при ліквідації може випасти або не випасти якийсь предмет. На рисунку одним з головних класів є інвентар так як він його викликає гравець, зброя та предмет підписаний класом «лут». Також в ході проєктування, було розроблено більш ширшу модель з продуманими в ній атрибутами та методами, які були продумані завдяки так званої техніки брейн шторму та завдяки досвіду роботи над проєктами сумісної тематики в минулому. Тому на рисунку 2.5 можна побачити, наявність першочергових необхідних для реалізації програмного продукту атрибутів там методів класів. Наприклад Для гравця з атрибутів було вибрано здоров’я рівень, та наявність інвентарю з методів для даного класу було обрано можливість віддаленого керування через наявні периферійні пристрої під’єднані до персональної машини користувача. Також для класу гравець передбачається реалізація та використання наступних методів таких як взаємодія з предметами, об’єктами то що. Дані взаємодії повинні бути розписані уніфіковано. 32 ЧДТУ 242234 001ПЗ Рисунок 2.5 – Діаграма класів, з наявними атрибутами Також хотілось би розглянути ще один з важливих класів для жанрової ніші даного програмного продукту це наявність класу зброя, а точніше його реалізація, на малюнку продемонстровані одні з можливих варіантів так як при реалізації таких важких додатків потрібно звертати увагу на тип життєвого циклу проєкту у випадку теми кваліфікаційної роботи бакалавра, звісно це питання не так актуальне, але в рамках відкритого світу для даного проєкту потрібно було б обрати як мінімум ітераційний життєвий цикл, як максимум спіральний, для подальшого оновлення, розширення та доопрацювання існуючих механік при досить ранньому релізі, що останнім часом розповсюджена практика. Тому з ключових моментів це наявність назви зброї. її ттх та ттх патронів які використовує дана зброя. 33 ЧДТУ 242234 001ПЗ З базових основних методів для класу зброя це звісно її використання що реалізується за допомогою метода «стріляти» та перезаряджати, що реалізується однойменним методом. 2.3.2 Діаграма пакетів Сутність поняття діаграми пакетів в сфері проєктування та в загальному понятті це відображення пакетів та модулів програми до яких входять згадані вище класи прогами. Діаграми пакетів виступають наступним рівнем розуміння парадигми програмування вході якої ми, як інженери програмісти повинні абстрагуватись на етап взаємодії шарів програмного продукту між собою, в ході опису діаграми пакетів, дані пакети можуть бути наділені позначками, більш професійними стереотипами, що вкажуть на механізм взаємодії шарів між собою. На рисунку 2.6 можна побачити структуру проекту, так як це рушій з цього слідує, Значна частина зв'язків автоматизована хоча в при створені нових об’єктів та папок потребує наявності прописаного шляху до них, що логічно. На рисунку 2.6 можна побачити структуру проєкту, так як це рушій з цього слідує, що значна частина зв'язків автоматизована, так як кожен елемент з вказаної структури взаємодіє в тому випадку і тільки в тому випадку коли відбувається рендеринг об’єктів. Рисунок 2.6 – Діаграма пакетів 34 ЧДТУ 242234 001ПЗ В проектах на UE стандартна структура виглядає подібним чином, вона є абсолютно зручною та звичною для більшості користувачів ОС, так як щоб завантажити рівень ми звертаємось до папки «Level». Під час процесу рендеренгу буде відбуватись наступне згідно заданих шляхів будуть підвантажуватись потрібні елементи в момент часу коли вони будуть викликані. Хоча формулювання дещо складне, але воно описує поняття оптимізації відео гри так як завантажити все одразу буде дуже ресурсозатратно для системи. Згідно рисунку 2.6 ми можемо бачити наступні пакети: FirstPerson, FirstPersonArms, FPWeapon, Level, дані пакети потрібні потрібні для збереження собі даних про об’єкти зазначених в назві, а також файлів для їх повноцінної роботи в системі такі як: текстури, скрипти, аудіо елементи, їх фізичні дані в рушії і так далі. 2.4 Архітектурне проектування Архітектурне проектування це один з етапів проєктування в якому проєктуєма система отримує свій логічний скелет, іншими словами структурну організацію програмного продукту. Це допомагає забезпечити ефективність, масштабованість та гнучкість ПЗ. 2.4.1 Діаграма компонентів Діаграма компонентів є чудовим прикладом логіки пункту архітектурне програмування так як сутність даного типу діаграм показати систему в її статичному вигляді . Сама діаграма показує компоненти та їхні зв'язки в системі між собою. Компоненти можуть виступати як фізичні так і логічні модулі, які можна розглядати як окремі підсистеми. Даний тип діаграми забезпечує загальне уявлення про архітектуру системи допомагаючи зрозуміти, як модулі моделюємої системи взаємодіють між собою. 35 ЧДТУ 242234 001ПЗ Рисунок 2.7 – Діаграма компонентів Опис діаграми компонентів Ця діаграма компонентів представляє архітектуру відеогри, візуалізуючи її основні компоненти та їх взаємозв'язки. Компоненти: - ігровий рушій: Цей компонент є ядром гри і керує загальною логікою, ігровим процесом та взаємодією з іншими компонентами; - користувацький інтерфейс: керує HUD в грі, та UI/UX в рівнях поза ігровою сценою, що і продемонстровано взаємозв’язками; - ігрова логіка: відповідає за статистику в середині гри та взаємодії елементарних одиниць між собою з об’єктів ігрової сцени; - аудіо система: це порядок взаємопов’язаних класів системи виводу звуку для через рушій в ігрову логіку; - фізичний двигун: Цей підкомпонент відповідає за симуляцію фізичних законів у ігровому світі, таких як гравітація, зіткнення та рух об'єктів; - візуалізатор: Цей підкомпонент відповідає за візуалізацію ігрового світу на екрані користувача, використовуючи 3D-графіку та інші візуальні ефекти пов’язаний напряму з ядрами обчислення графіки; Взаємозв'язки: - ігровий рушій: взаємодіє з усіма іншими компонентами, керуючи їхньою роботою та забезпечуючи загальну логіку гри; - гравець як об’єкт імплементований Ігрової логіки взаємодіє з Контролером персонажа, щоб керувати своїм персонажем у грі та маніпулювати його показниками через виконання впливаючих на це дій; 36 ЧДТУ 242234 001ПЗ 2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма розгортання Процес розгортання програмного продукту це частина життєвого циклу проєкту який потрібно розглянути окремо. Сфера деплойменту зазвичай охоплює опис на які системи буде націлений продукт, на яких платформах буде розповсюджуватись. Складні програмні продукти по типу відеоігор, в наші дні зазвичай розповсюджуються або через видавців та дистриб’юторів або через за допомогою платформи дистриб’ютора який заохочує молодих розробників викладати свої програмні продукти, хоча і на превеликий жаль таких платформ не багато. Перед розробником складної системи завжди повстає питання про розповсюдження та оптимізації процесу автоматичного налаштування додатку перед його використанням без критичних багів так як системи користувачів можуть мати різні версії операційних систем, драйверів та подібних тому речей. Також не малозначним фактором при проєктуванні розгортання системи потрібно врахувати яким чином буде розповсюджуватись проєкт, до прикладу, якщо програмний додаток розповсюджується через сайт розробника та має постійне необхідне онлайн підключення то в такому випадку потрібно ще продумати систему захисту користувача від зловмисників. Для демонстрації програмної системи розгортання на апаратних засобах використовують діаграми розгортання. Вони візуалізують систему по якій програмний продукту буде взаємодіяти з системою користувача та система користувача з програмним продуктом. 37 ЧДТУ 242234 001ПЗ Рисунок 2.8 – Діаграма розгортання На рисунку 2.8 можемо побачити візуалізацію системи розповсюдження та взаємодії системи користувача та з програмним продуктом дистриб’ютора та з його серверами. А також з серверами компанії що надає послуги банкових операції для дистриб’ютора Компоненти даної діаграми є ПК_користувача, на якому становлено програмний додаток Steam, хмарний сервер Steam з його базами даних файлів які він надає користувачу при купівлі та встановленню додатку та сервера AWS що проводять підтвердження банкових операції дистриб’ютора з його валсною базою даних проведених операції клієнтами. 38 ЧДТУ 242234 001ПЗ 2.5 Моделювання поведінки системи Якщо попередні пункти проєктування розглядали проєктовану систему як абстрактну модель то моделювання поведінки системи якраз відповідає за роз’яснення роботи тих чи інших модулів програмного продукту в деталях. Дана область базується вже на детальному опису вхідних та вихідних методів та значень між класами в деталях. Моделювання поведінки системи описуючи взаємодію між класами користується діаграмами діяльності, послідовності, комунікації, та скінченного алгоритму. В ході яких логіку роботи програми. Для розуміння наступних пунктів потрібно ознайомитись з простим поясненням наступних процесів проєктування програмного продукту Діаграми діяльності - це в основному блок-схема для представлення потоку від однієї діяльності до іншої. Така діаграма фокусує увагу на потоку виконання системи більше ніж її реалізації Діаграми послідовності в свою чергу орієнтована на часові особливості передачі та прийому даних в модулях системи. Хоча вони частково зачіплюють розуміння та поняття часу, але вони не є саме часовими діаграмами. Діаграми комунікації тип діаграм що звертає та фокусує увагу на процес потоку даних в системі методом ілюстрації та візуалізації. діаграми скінченного автомату або діаграма станів як видно з назви вона описує різні можливі стани об'єкта в системі, як цей об'єкт переходить з одного стану в інший і як об'єкт змінюється. 2.5.1 Діаграма діяльності Як і було зазначено в попередньому пункті діаграми діяльності - це в блок- схема представлення потоку даних від однієї діяльності до іншої. В такому випадку фокус уваги припадає на потоку виконання системи більше ніж її реалізації. 39 ЧДТУ 242234 001ПЗ Рисунок 2.9 – Діаграма діяльності Діаграма діяльності на рисунку 2.9 показує алгоритм дій потоку дій при переході з головного меню на меню вибору локацій в грі за це відповідатиме модуль мапи. Згідно діаграми гравець, переходить на меню вибору режимів, де в нього є вибір перейти на відкриту локацію та закриту локацію або іншими словами данж. В діаграмі було продумано потік даних що буде йти слідом по ходу вибору гравця в системі як можна побачити фігура ромба відповідає за умову виконання наступних етапів потоку. З гідно таких умов подальше виконання програми та подальше завантаження даних буде різне, в залежності від вибору гравця. Кінцевим виконанням потоку даних буде вважатись той момент при якому користувач потрапить в так звану зону евакуації. 2.5.2 Діаграма послідовності Як було зазначено вище, діаграма послідовності відображає систему в часовому просторі орієнтуючись на ітераційне виконання алгоритму програмного 40 ЧДТУ 242234 001ПЗ продукту тим самим описуючи, що відбувається в системі та в якій послідовності. Рисунок 2.10 – Діаграма послідовності Рисунок 2.10 Діаграми діяльності якраз і демонструє взаємодію елементів програмного додатку, його об’єктів між собою. Наприклад об’єкт гравець взаємодіє з об’єктом ворог через атаку, в свою чергу гравець може отримати пошкодження, так як об’єкт ворог також буде атакувати об’єкт гравець. У показаному часовому проміжку об’єкту ворог також є наявність функції самознищення який буде викликатись при умові отримання суми пошкоджень більше ніж кількість здоров’я об’єкту. В цьому часовому проміжку також показано звернення об’єкту ворог до об’єкту лут. Що як і показано викликається у випадку само ліквідації об’єкта. В такому випадку об’єкт гравець може звернутися до функції підібрати що викликає в свою чергу об’єкт інвентар до якого додаються підібрані елементи. До об’єкту інвентарю також звертається також об’єкт гравець у випадках коли використовуються предмети інвентарю через спеціальні елементи керування. 41 ЧДТУ 242234 001ПЗ В описаному сценарії модулю, об’єкт гравець взаємодіє з об’єктом предмета що потрібно покласти в спеціалізованій для цього області та при ліквідації даного об’єкту відбудеться модельована ситуація зі взаємодією з оточенням. 2.5.3 Діаграма комунікації В розділі 2.11 підіймалось питання що таке діаграми комунікації в проєктуванні та моделюванні систем. Якщо детальніше підійти до питання яке підіймають ці діаграми покажуть взаємодію елементів системи такими елементами можуть бути модулі, об’єкти, елементи інтерфейсу що підпадають під ці два терміни. Також діаграми надають візуальне представлення повідомлень які передаються яв ході взаємодії тих чи інших об’єктів системи. Рисунок 2.11 – Діаграма комунікації На рисунку 2.11 можна побачити реалізацію даної діаграми який показує 42 ЧДТУ 242234 001ПЗ взаємодію екземплярів створених елементів. Основною даної діаграми є користувач, який підписаний як гравець, згідно з області проєктування. Даний актор маніпулює екземплярами системи, які у свою чергу звертаються до візуалізованого об’єкту системи що представлена у виді об’єкту гра. Також дана діаграма візуалізує повідомлення що будуть надходити екземплярам системи. 2.5.4 Діаграма скінченного автомату Діаграма скінченного автомату зазвичай використовується для описів станів об’єкта в залежності від поточного стану та інформації отриманні ззовні. Діаграма скінченного автомату кваліфікаційної роботи бакалавра описує введення команд гравця за можливим сценарієм використанням вхідних даних від користувача. Рисунок 2.12 – Діаграма комунікації Сценарії цього скінченного автомату описує дію зчитування даних від 43 ЧДТУ 242234 001ПЗ користувача при яких користувач при виконані записаних а алгоритм дій отримує Ця діаграма є діаграмою діяльності, що зображує послідовність дій та процесів, які виконуються в певній системі. У даному випадку це система або гра, де користувач може взаємодіяти з різними елементами та виконувати різні дії. Переходи між станами описуються наступним чином - «Стан запуску» переводить в стан очікування «головне меню» - «головному меню» переводить на дві можливі події «перехід на список місії» та в «Меню налаштувань» - при події «вибір налаштувань» гравець повернеться на головне меню з кого можливе повторення події закладених алгоритмом або вихід та завершення алгоритму. - При виборі «Список рівні» скінчений автомат надає «Завантажує вибраний рівень» 44 ЧДТУ 242234 001ПЗ ВИСНОВОК РОЗДІЛУ 2 Розділ два підіймає питання моделювання предметної області системи, що є важливим етапом для розуміння та візуалізації концептуальної моделі програмного продукту. При розробці предметної області зачіпляють визначення словника предметної області, елементів моделювання та робочої області модельованої системи. Також наступним кроком даного розділу це формування та аналіз вимог до ПЗ. Ставляться різні типи вимог, такі як функціональні та нефункціональні, вимоги користувача до системи, а також замовника до системи, підіймає питання створення статичних діаграм системи таких як діаграми прецедентів, використання для візуалізації опису системи. При розгляді цього етапу формуються та розроблюються діаграми UML. Діаграми UML допомагають сформувати візуальне представлення проєктуємої системи, візуалізовуючи її структуру та взаємозв'язки між компонентами системи. Архітектурне проектування очевидно також є не менш важливим етапом які попередні та наступні пункти розробки, даний пункт охоплює діаграму компонентів та діаграму розгортання. Діаграма компонентів показує структуру компонентів системи, а діаграма розгортання вже ілюструє, як ці компоненти будуть розгорнуті на апаратних засобах користувачів. Останнім етапом є, моделювання поведінки системи що здійснюється через реалізацію діаграми діяльності мовою UML, діаграми послідовності та діаграми комунікації. Ці діаграми дозволяють візуалізувати динамічну поведінку системи, потік даних та взаємодію між її компонентами. Загалом, цей розділ надає всебічний огляд розробки за допомогою діаграм UML що допомагає в проектування програмного забезпечення інформаційних систем, охоплюючи всі основні етапи процесу проектування, від моделювання предметної області до моделювання поведінки системи. 45 ЧДТУ 242234 001ПЗ РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Даний розділ описує сам етап розробки програмного продукту кваліфікаційної роботи бакалавра та її тестування. Беручи до уваги обґрунтування використаних інструментів в рамках кваліфікаційної роботи з наданням більш детальних даних щодо розробки логічних структур інтерфейсу та баз даних. Також даний розділ захоплює етап тестування його типи та опис алгоритму дій при ньому. 3.1 Розробка програмного комплексу У цьому розділі описуватиметься процес розробки програмного про продукту в ході якого обґрунтовується вибір засобів реалізації, наведена структурна схема системи, описана логічна схема, розглянута розробка бази даних та інтерфейсу користувача. Також буде надано опис розробки програмних компонентів, що входять до складу комплексу. 3.1.1 Обґрунтування вибору засобів реалізації За основу при розробці програмного додатку було взято ігровий рушій UE5, в основному через сучасні підходи в програмуванні з використанням технологій blueprints та мови С++, що надає неймовірні можливості по оптимізації процесу розробки проєкту при цьому не підіймаючи собі вартість проєкту. UE5 як і його прямий конкурент має непогану базу заготовлених асcетів анімації, текстур, мап тощо. Якість таких ассетів має неймовірні рівні так як вони в порівняні від свого конкурента Unity більш ретельно проходять якісну перевірку перед додаванням в магазин ассетів. Технології UE5 варіативні навіть на прикладі підключення баз даних UE5 надає можливість створювати бази даних різних типів таких як методом «важкого» кодування з використанням мапінгу, методом масивів структур даних, чи використанню вбудованих інструментів для отримання баз даних в 46 ЧДТУ 242234 001ПЗ середині рушія, також рушії не забороняє під’єднати стороні плагіни та структури технологій SQL. Ця неймовірна гнучкість продемонстрована прикладом баз даних масштабується на підходи до розробки самого проєкту. Використання мови С++ та blueprints для скриптування в рушії надає неймовірні можливості по оптимізації програмного продукту. Гнучкість ця проявляється в тому що при скриптуванні елементів системи розробник може використовувати та створювати свої шаблони коду на основі мови С++, яка в свою чергу є мовою що дозволяє працювати з пам’яттю на низькому рівні. Технології які надає рушій такі як Lumen, Metahuman, World Partition UE5. - Lumen: ця технологія відповідає за реалістичне освітлення; - MetaHuman: технологія яка дозволяє інтегрувати моделі реальних людей для свого проєкту, в додатках при додаванні цієї технології додаються ассети анімації емоції обличчя для передачі емоційного стану персонажів; - World Partition: дана технологія є дуже важливою при генерації великих світів з використанням потужних технологій рушія так як дана технологія дозволяє поділяти відкритий світ на частини, що допомагає автоматизовано вирішити глобально питання з оптимізації. Підбиваючи підсумки чому саме UE5 це - неймовірна якість вихідної картинки; - неймовірні технології які надає рушій; - популярність на ринку в Україні; - якість вхідних матеріалів; - якісний продуманий дизайн; - використанням модульного скриптування на рівні з мовою С++. 3.1.2 Опис структурної (функціональної) схеми 47 ЧДТУ 242234 001ПЗ ├── Content │ ├── _main/ │ │ ├──_Props/ │ │ │ ├──AmmoPickup/ │ │ │ │ ├── AmmoPickupMaster.bp │ │ │ │ ├── BP_Health.bp │ │ │ │ ├── BP_Prime_ammo.bp │ │ │ │ ├── Enum_PickupItem.enumeration │ │ │ │ └── BP_Secondary_ammo.bp │ │ │ ├──AmmoCastingBP/ │ │ │ │ ├── BP_AmmoCastMaster.bp │ │ │ │ ├── BP_AmmoCastRifle.bp │ │ │ │ └── BP_AmmoCastPistol.bp │ │ │ ├──AmmoCastingBP/ │ │ │ │ ├── BP_AK47_Pickup.bp │ │ │ │ ├── BP_AK48_Pickup.bp │ │ │ │ ├── BP_AR4X1_Pickup.bp │ │ │ │ ├── BP_AR4_Pickup.bp │ │ │ │ ├── BP_Pistol_A_Pickup.bp │ │ │ │ ├── BP_Pistol_B_Pickup.bp │ │ │ │ ├── BP_Rifle_A_Pickup.bp │ │ │ │ ├── BP_Rifle_B_Pickup.bp │ │ │ │ ├── BP_VAL_Pickup.bp │ │ │ │ └── BP_MasterWeaponPickup.bp │ │ │ ├──Animation │ │ │ │ ├── _Anim.bp/ │ │ │ │ │ ├── AK47/ │ │ │ │ │ │ ├── AS_AK47_AIM.as │ │ │ │ │ │ ├── AS_AK47_IdleStatic.as │ │ │ │ │ │ ├── AS_AK47_Walk.as │ │ │ │ │ │ ├── AS_AK47X.bs │ │ │ │ │ │ ├── LS_AK47_AIM.ls │ │ │ │ │ │ ├── LS_AK47_IdleStatic.ls │ │ │ │ │ │ └── LS_AK47_Walk.ls │ │ │ │ │ ├── BP_AR4/ │ │ │ │ │ │ ├── AS_AR4_AIM.as │ │ │ │ │ │ ├── AS_AR4_IdleStatic.as │ │ │ │ │ │ ├── AS_AR4_Walk.as │ │ │ │ │ │ ├── AS_AR4.bs │ │ │ │ │ │ ├── LS_AR4_AIM.ls │ │ │ │ │ │ ├── LS_AR4_IdleStatic.ls │ │ │ │ │ │ └── LS_AR4_Walk.ls │ │ │ │ │ ├── Main_Character/ │ │ │ │ │ ├── Pistol_A/ │ │ │ │ │ ├── Pistol_B/ 48 ЧДТУ 242234 001ПЗ │ │ │ │ │ ├── Rifle_A/ │ │ │ │ │ ├── Rifle_B/ │ │ │ │ │ ├── Enemy/ │ │ │ │ │ │ ├── AnimZomb/ │ │ │ │ │ │ │ ├── Type1_girl/ │ │ │ │ │ │ │ │ ├──AIM_Zombie_Attack.am │ │ │ │ │ │ │ │ ├──AIM_Zombie_Attack1.am │ │ │ │ │ │ │ │ ├──AIM_Zombie_Punching.am │ │ │ │ │ │ │ │ ├──AIM_Zombie_Punching1.am │ │ │ │ │ │ │ │ ├──AIM_Zombie_hitReaction.am │ │ │ │ │ │ │ │ ├──AIM_Zombie_hitReaction 1.am │ │ │ │ │ │ │ │ └──…анімації типу.ls │ │ │ │ │ │ │ │ ├── Type2_Cop/ │ │ │ │ │ │ │ │ ├── …подібна структура Type1 │ │ │ │ │ │ │ │ ├── Type3_Stalker/ │ │ │ │ │ │ │ │ └── …подібна структура Type1 │ │ │ │ │ │ │ ├── APB_Zomb_Girl.ab │ │ │ │ │ │ │ ├── APB_Zomb_Stalker.ab │ │ │ │ │ │ │ ├── APB_Zomb_Cop.ab │ │ │ │ │ │ │ ├── BS_Zomb_Girl_IdleWalkRun.bs1d │ │ │ │ │ │ │ ├── BS_Zomb_Cop_IdleWalkRun.bs1d │ │ │ │ │ │ │ └── BS_Zomb_Stalker_IdleWalkRun.bs1d │ │ │ │ │ │ ├── Mesh/ │ │ │ │ │ │ │ ├── Type1/ │ │ │ │ │ │ │ │ ├── PM_For_Zombie_headshot.pm │ │ │ │ │ │ │ │ ├── PM_For_Zombie_bodyshot.pm │ │ │ │ │ │ │ │ ├── zombie_body_def.texture │ │ │ │ │ │ │ │ ├── zombie_body.texture │ │ │ │ │ │ │ │ ├── zombie_body_normal.texture │ │ │ │ │ │ │ │ ├── zombie_body_specular.texture │ │ │ │ │ │ │ │ ├── zombie_body_mater.material │ │ │ │ │ │ │ │ ├── zombie_body_mater.sk │ │ │ │ │ │ │ │ ├── zombie_body_Physics.pa │ │ │ │ │ │ │ │ └── zombie_body_Skeleton.sk │ │ │ │ │ │ │ ├── Type2/ │ │ │ │ │ │ │ │ └── …подібна структура Type1 │ │ │ │ │ │ │ ├── Type3/ │ │ │ │ │ │ │ │ └── …подібна структура Type1 │ │ │ │ │ │ ├── BP_Child_Zomb_COP.bs │ │ │ │ │ │ ├── BP_Child_Zomb_Stalker.bs │ │ │ │ │ │ ├── BP_MasterZomb.bs │ │ │ │ │ │ ├── S_Fwave.struct │ │ │ │ │ │ ├── Spawner.bp │ │ │ │ │ │ ├── SpawnerMaster.bp │ │ │ │ │ │ └── wavepollData.dt 49 ЧДТУ 242234 001ПЗ │ │ │ │ │ ├── AnimNotify/ │ │ │ │ │ │ ├── AnnimNotyfy_Clip.ls │ │ │ │ │ │ ├── AnnimNotyfy_Insert.ls │ │ │ │ │ │ └── AnnimNotyfy_Reloading.ls │ │ │ │ ├──GameMode/ │ │ │ │ │ └── GM_Waves │ │ │ │ ├──HUD/ │ │ │ │ │ ├── main_screen.texture │ │ │ │ │ ├── ammo_sec_white.texture │ │ │ │ │ ├── ammo_sec.texture │ │ │ │ │ ├── ammo_prim_white.texture │ │ │ │ │ ├── ammo_sec.texture │ │ │ │ │ ├── reload.texture │ │ │ │ │ ├── medkit.texture │ │ │ │ │ ├── WB_Main_menu.wb │ │ │ │ │ ├── WB_Pause_menu.wb │ │ │ │ │ ├── WB_Death_menu.wb │ │ │ │ │ ├── WB_Ammo_Indecator.wb │ │ │ │ │ ├── WB_Wave_Indecator.wb │ │ │ │ │ ├── WB_Options_menu.wb │ │ │ │ │ └── WB_Options_menuGame.wb │ │ │ │ ├──Interfaces/ │ │ │ │ │ ├── BPI_ammo_pickup.bpi │ │ │ │ │ ├── BPI_anim.bpi │ │ │ │ │ ├── BPI_CharacterData.bpi │ │ │ │ │ ├── BPI_Fire.bpi │ │ │ │ │ ├── BPI_Interact.bpi │ │ │ │ │ └── WB_WeaponPickup.bpi │ │ │ │ ├──Levels/ │ │ │ │ │ ├── Test_room.lvl │ │ │ │ │ └── Tokyo.lvl │ │ │ │ ├──Quest_Objectives/ │ │ │ │ │ ├── BP_destroible_OBJ.pb │ │ │ │ │ ├── BPI_destroible_OBJ.bpi │ │ │ │ │ ├── BPI_Repair_OBJ.bpi │ │ │ │ │ └── test_OBJ_Pil.sm │ │ │ │ ├──Sounds/ │ │ │ │ │ ├──Footsteps/ │ │ │ │ │ ├──Location/ │ │ │ │ │ ├──Weapon/ │ │ │ │ │ ├──Zombie/ │ │ │ │ │ ├──Zombie_DeathAttack/ │ │ │ │ │ ├──SA_Main.sa │ │ │ │ │ └──StalkerHitReaction.sc └ └ └ └ └─ 50 ЧДТУ 242234 001ПЗ Рисунок 3.1 демонструє структурну схему, що в свою чергу демонструє взаємодію основних компонентів в рамках розробленої системи для кваліфікаційної роботи бакалавра Рисунок 3.1 - Структурна схема основних компонентів Рисунок 3.2 Функціональна схема роботи Рисунок 3.2 демонструє загальну логіку за допомогою функціональної схеми компонентів розробленої системи. Файлова система проєкту включає в себе опис необхідних файлів для функціонування програми та має наступні елементи: - content/ найголовніша папка вміщує в себе все що знаходиться в проєкті; - _main/ Вміщує всі головні елементи відображення та логіки; - _Props/ вміщує в собі файли налаштування зброї, зброю, систему луту та її похідні; - animation/ вміщує в собі всі анімації до проекту, наприклад як для 51 ЧДТУ 242234 001ПЗ aкторів, так і для предметів шаблону, а саме, зброї; - gameMode/ збирає в собі наявні ігрові режими; - hud зберігає в собі UI/UX елементи гри та картинки; - interfaces/ зберігає в собі наявні інтерфейси, що використовуються при описі ігрової логіки; - levels/ папка в якій зберігаються наявні рівні в грі; - quest_Objectives/ в цій папці зберігаються предмети що можуть бути знищеними противником, та відремонтовані гравцем; - sounds/ набір всіх звуків до проєкту з налаштуваннями діапазонів та каналів відтворення. 3.1.3 Опис логічної схеми системи Рисунок 3.3 - Опис логічної схеми системи S_Fwave – це структура що зберігає в собі мапу шаблонів BP_Zomb_Master. Spawner – це шаблонний компонент який перевіряє місцевість на якій він знаходиться на колізії, перевіряє чи є в вороги в запасі щоб відтворити їх та у випадку успіху відтворює ворогів на активному спавнері. GM_Waves – це компонент ігрового режиму який пов'язаний з даними бази а точніше може викликати запис даних до бази та брати існуючі елементи. Також цей компонент пов’язаний з компонентом Spawner та надає йому лист з 52 ЧДТУ 242234 001ПЗ командою, що потрібно ініціювати перевірку на спавн акторів за наданими шаблонами WavePollData – компонент бази даних що зберігає в собі індекс хвилі, та ворогів що будуть в ній спавниться, у випадку якщо база даних була втрачена або індекс не буде знайдено GM_Waves заповнить рядок самостійно класами нащадками і материнським класом пул ворогів до спавну. 3.1.4 Розробка бази даних Насправді для даного проєкту можна було обійтись і без бази даних що було зроблено при розробці типів патронів та при та системи видачі зброї але в цілому база даний дуже важливі при розробці глобальних проєктів. Оскільки однією з ключових задач було проєктування системи з майбутнім розширенням тому база даних була розроблена саме для пулу ворогів. База даних включає тільки одну таблицю це wavepolldata Рисунок 3.4 - Таблиця «wavepolldata» Таблиця зберігає в собі структурну мапу шаблонного об’єкта BP_Zomb_Master, та його нащадків. З структурою - назва рядка; - шаблонний клас A; - кількість; - шаблонний клас Б; - кількість; 53 ЧДТУ 242234 001ПЗ - шаблонний клас С; - кількість. Оскільки дана база існує в одиничному екземплярі, то і структури до неї немає. Так як основні махінації з нею відбуваються за логікою роботи системи рисунок 3.4 3.1.5 Розробка інтерфейсу користувача Інтерфейс користувача розроблений за допомогою існуючих інструментів рушія UE5. Та побудований з префабів користувацького інтерфейсу, це об'єкти заготовок коду, які можна використовувати та модифікувати існуючі за допомогою наданого інтерфейсу взаємодії з ними. Сам конструктор інтерфейсів подібний тому, що в Unity. Та конструктор надає великий обсяг шаблонів для налаштування. На рисунку 3.5 можна переглянути наданий інструментарії UE5. Наприклад зліва можна побачити інструмент можливих шаблонів, та використані вже елементи UI. Основним елементом при створені UI це елемент canvas він симулює, розтягує і відтворює зображення в свої рамках. Далі в canvas потрібно додати елементи які будь надавати можливість взаємоємодії або просто відображення в рамка покладеної на них задачі. Рисунок 3.5 - Конструктор UI 54 ЧДТУ 242234 001ПЗ Елементи знаходяться в чіткому порядку та мають свій стандартний клас який подібно буде розписати для цього зправа-зверху є два режими «Дизайнер» та «Граф» Рисунок 3.6 - Редагування за допомогою «Граф» Інтерфейс графу надає можливість для кодування сценаріїв поведінки 55 ЧДТУ 242234 001ПЗ елементів UI до прикладу для на рисунку 3.6 продемонстровано технологію blueprint та її інтеграція в інтерфейс користувача елементів керування та відтворення звуків при івенті, такими івентами можуть виступати наведення, натискання, утримання та інші взаємодії з UI/UX користувача. На рисунку 3.7 та 3.8 можна побачити результат проєктування інтерфейсу користувача за допомогою вище зазначених інструментів UE5. Де згідно зазначених умов у розділі 2 було розроблено стартове меню користувача та меню налаштувань гравця. Налаштування користувача також зберігають дані які користувач вносить для збереження. Рисунок 3.7 - UI «Головне меню» Рисунок 3.8- UI «Меню налаштувань» 56 ЧДТУ 242234 001ПЗ Підчас гри користувач може викликати меню яке ставить гру на паузу, в цьому меню користувачу надається можливість перейти в налаштувань користувача, і під час гри змінити параметри які потрібні користувачу. А також надає можливість перейти до головного меню і звісно зняти з паузи Рисунок 3.9 - UI «Меню паузи» Під час ігрового процесу гравець може бачити свої показники здоров’я та рахівник хвиль та ворогів яких залишилось знищити за відведену хвилю зліва- зверху, зправа-знизу в користувача є відображення типу патронів та їх кількість в магазині та скільки патронів залишилось в інвентарі. Рисунок 3.10 - UI гравця 57 ЧДТУ 242234 001ПЗ Також була продумана система луту, цей лут випадає з ворогів з деяким шансом для легшої ідентифікації було розроблено UI елементи, які збігаються з UI елементами гравця зображена на рисунку 3.11. Рисунок 3.11 - UI предметів для гравця Гравець може віднайти зброю по ходу гри в локаціях так і отримати її з ворогів Але для прикладу на рисунку 3.12 для зброї інтерфейс не було пророблено по тій простій причині щоб додати елемент несподіванки при знаходженні наступної по ходу гри. Рисунок 3.12 - Розставлена зброя на карті 3.1.6 Опис розробки програмних компонентів Розробка логіки компонентів дуже важливий етап розробки програмного 58 ЧДТУ 242234 001ПЗ продукту даний етап включає в себе напрацювання минулих розділів та оптимізації її на існуючих та обраних технологіях. До прикладу в кваліфікаційній роботі бакалавра було використано підхід ООП при створені класу головного персонажу Рисунок 3.13 - Розроблена система персонажу частина 1 Кожна гілка це окремий модуль пероснажу кожен об’єкт це шаблон коду що являє собою об’єкт класу який викликається через інструмент проєктування «Граф». Для проєктування в рамках технологій рушія розроблено систему сортування та нотування гілок завдяки коментарям які надають можливість розділяти візуально до якої системи модулів відноситься та чи інша гілка. Коментування в цьому та маркування систем в проєкті вважається хорошим тоном при написанні коду так як при модифікації та розвитку коду таких гілок може стати безліч і дуже важливо промаркувати їх функціонал. 59 ЧДТУ 242234 001ПЗ Рисунок 3.14 - Розроблена система персонажу частина 2 Як можна бачити з рисунків 3.13 та 3.14 кожен колір символізує модулі до системи до яких вони відносяться таки чином. Фіолетовий колір символізує системи зброї такі як перезарядку, зчитування патронів, зміна зброї, підбір зброї, механік стрільби, та режимів стрільби. Жовтим позначено івенти при використані клавіш в системі, модулі такого типу розроблені через спеціальний клас контролер, що наддасть користувачу викликати через меню налаштувань змін клавіш під себе Червоним позначено системи керування камери Чорним система смерті персонажа. 60 ЧДТУ 242234 001ПЗ Більш детальний огляд класів та об’єктів дивитись в додатках. 3.2 Тестування системи У розділі 3.2 розглядається тестування розробленої системи кваліфікаційної роботи бакалавра. Розділ буде описано процеси модульного тестування окремих компонентів, інтеграційного тестування їх взаємодії, а також системного тестування всього комплексу в цілому. Крім того, в процесі буде продемонстровані модулі та їх призначення. Останнім етапом тестування є приймальне тестування, під час якого система перевіряється на відповідність вимогам замовника з поставлених при проєктуванні в першому розділі. 3.2.1 Модульне тестування Модульне тестування це перевірка процедур та підпрограм коду що проводиться для відладки системи щоб та працювала згідно закладеної логіки. При розробці було проведено безліч тестів за допомогою відслідковування потоків даних за допомогою дебаг інструментів рушія які він надає. Одним з таких інструментів є дебаг викликаного об’єкту класу в ході якого можна перевірити як саме виконується програма, також для спрощення відслідковування при перевірці можна виводити через спеціальні дебаг модулі список модулів можна побачити на рисунку 3.15 На рисунку 3.16 можна побачити дебаг модуля, що відповідає за відтворення режиму стрільби в грі при нажаті на клавішу стрільби. На рисунку можна побачити тестування кастомний івент «Full-auto» що симулює автоматичну стрільбу пропускаючи потік даних через безліч функцій що викликаються поступово згідно схеми роботи, затримка між пострілами диктується наявність патронів в магазині та ТТХ зброї прописаної в дочірньому класі мастер класу. Тести описані нижче будь проводиться в спеціальні кімнаті відладчику тестова кімната доступна гравцям в цій кімнаті гравець можу використати любу зброю режим виставлений такий самий як і в основному режимі гри. 61 ЧДТУ 242234 001ПЗ Рисунок 3.15 - Список одних з можливих дебаг інструментів Рисунок 3.16 - Тестування потоку даних Таблиця 3.1 Таблиця модулів Системний модуль Результат BP_Erno Набір модулів пов’язаних з механікою роботи зброї працює належним чино 62 ЧДТУ 242234 001ПЗ Продовження таблиці 3.1 BP_Zombie_Master Модуль отримання пошкодження, видачі луту, рандомізатор ворога та програвання анімації та звуків працює згідно плану. BP_Zombie_COP Зміна вхідних параметрів мастерського класу вхідних параметрів показала результативність. BP_Zombie_Stalker Особливе налаштування ворога та якого анімації показує кращі результати від очікуваних UI_MainMenu Коректне відтворення звуку та переходів по саб меню UI_ammo_sec Коректне відображення показнику патронів резервних та споряджених в активний магазин AmmoPickupMaster Системний модуль заснований на вже розробленому підбору з потрібними внесеними модифікаціями працює коректно BP_AmmoCastMaster Системний модуль відображається при пострілі з зброї та створенню простих колізійно-фізичних предметів які відображають гільзи від патронів APB_Zomb_Girl Файл анімацій кісток тіла ворога заснованих на його скелеті та імпортованих на них анімації демонструє повноцінний функціонал в розробленій системі 3.2.2 Інтеграційне тестування Інтеграційне тестування це тестування взаємодії між модулям програми в даному випадку між компонентами відеогри, напривеликий жаль, що провести тестування повноцінне тестування в такому масштабному проєкті як відеогра потрібно робити відеодемонстрацію та описувати алгоритм дій що були виконані для тестування. У випадку кваліфікаційно роботи бакалавра продемонструвати відео неможливо. Проте можна описати алгоритм дій та продемонструвати результат через рисунки, для прикладу результатом такого 63 ЧДТУ 242234 001ПЗ тестування що може продемонструвати працездатність модулів є механіка підбору патронів, механіка смерті ворога, та візуальне відображення за допомогою UI інтерфейсу гравця результату даного тестування. Таким чином на рисунку 3.14 продемонстровано тест алгоритм тесту за умовами якого персонаж при взаємодії з радіусом підбираємого предмету предмет додається в інвентар та самознищується з ігрової карти результатом даного тесту є рисунок 3.15 Рисунок 3.14 - Тестування потоку даних Результатом пророблених дій стає правильне відображення резервних патронів до зброї таким чином за результатами тестування на рисунку 3.15 тест вважається пройденим. Рисунок 3.15 - Тестування потоку даних Далі тестується взаємодія наступних модулів це модуль інтерфейсу, 64 ЧДТУ 242234 001ПЗ модуль ігрового режиму, модуль спавну, та модуль вираховування патронів з нанесенням пошкоджень ворогам. Очікуваним результатом такого тесту такого тесту стане спавн предмету, зміна числа зверху-зліва в показнику активних ворогів у хвилі, зміна показників патронів в магазині зброї, та смерть ігрового ворога. На рисунку 3.16 можна побачити початкові стани описаних вище модулів. Рисунок 3.16 - Початковий стан UI елементів Після смерті ворога можна побачити що показники патронів та число ворогів було зменшено рисунок 3.17 Рисунок 3.17 - Стан UI елементів після проведення тесту 65 ЧДТУ 242234 001ПЗ Також в ході виконання тестів UI класів можна побачити вторинний результат а саме що ворог після своєї смерті залишає після себе предмет патрони, згідно банеру предмету це саме патрони для основної зброї. Таблиця 3.1 Ітераційне тестування Системний модуль Протестовано Працює Опис дії BP_PickupItem Так Так Підбір предметів. BP_Zombie_Master Так Так Отримання урону. BP_Erno Так Так Підбір патронів з подібної зброї. BP_MainMenu Так Так Коректне відображення BP_MainMenu Так Так Коректне відтворення звуку 3.2.3 Системне тестування Системне тестування це один з фінальних типів тестування ПЗ в рамка якого перевіряється повне функціонування системи. В ході якого перебирається внутрішня структура програми та її безвідмовність в цілому Таблиця 3.2 Системне тестування Системний модуль Протестовано Працює Опис дії BP_Erno Так Так Підбір предметів. BP_Erno Так Так Перезарядка. BP_Erno Так Так Підбір патронів з подібної зброї. BP_Erno Так Так Нанесення пошкоджень ворогам BP_Erno Так Так Кастування спрайтів SFX BP_Zomb_master Так Так Отримання пошкоджень. BP_Zomb_master Так Так Спавн предметів 66 ЧДТУ 242234 001ПЗ Продовження таблиці 3.3 BP_Zomb_master Так Так Система координаціх BP_Zomb_master Так Так Реакція на влучання BP_ZombChildStalker Так Так Rage mod GM_Waves Так Так Каст повідомлення про спавнеру про набір в наступну хвилю Spawner Так Так Відправлення повідомлення про пулл можливих ворогів Spawner Так Так Відправлення повідомлення про пул активних спавнерів GM_Waves Так Так Каст хвилі, відтворення звуку хвилі GM_Waves Так Так Зміна показників хвилі через повідомлення до інтерфейсу UI Так Так Коректне відображення показників 3.2.4 Приймальне тестування Мета: перевірка користувачем працездатність та доконаність комплексу програмного забезпечення для виявлення недоліків програмного продукту. Перевірка механік - перехід між меню та грою: користувач пройшов успішно; - зміна та збереження прессету графіки: користувач пройшов успішно; - проходження першої хвилі: користувач пройшов успішно, коректне відображення та спавн ворогів відбувся згідно плану; - отримання луту: користувач зміг підбирати предмети; Перевірка нефункціональних вимог - стабільність: тестування показало, що можливе відтворення на більш 67 ЧДТУ 242234 001ПЗ слабких ПК ніж зазначалось рекомендованих, але в такому разі немає стабільність показників кадрів; - інтуїтивність інтерфейсу. інтерфейс розроблений за на основі існуючих аналогів що надає йому високу інтуїтивну зрозумілість; - надійність: система показала стресостійкість. Загальна оцінка Система працює без особливих нарікань, виконуючи основні закладені функції які були закладені при проєктувані. Хоча і відчувається недостатня кількість контенту. Для проєкту пропонується додати наступне: - Відкритий світ - Більше режимів - Розширити кількість унікальних звуків - Додати більше скриптових звуків на локаціях - Розширити можливий UI інтерфейс Система потребує в основному плані розширенню існуючого комплексу проробленого функціоналу, нових карт, нових режимів. Таблиця 3.2 Приймальне тестування BP_Zombie_Master Модуль видачі луту, рандомізатор ворога та програвання анімації та звуків працює згідно плану. BP_Zombie_COP Зміна вхідних параметрів мастерського класу вхідних параметрів показала результативність. BP_Zombie_Stalker Особливе налаштування ворога та якого анімації показує кращі результати від очікуваних UI_MainMenu Коректне відтворення звуку та переходів по саб меню UI_ammo_sec Коректне відображення показнику патронів резервних та споряджених в активний магазин AmmoPickupMaster Системний модуль заснований на системою підбору зброї з потрібними внесеними модифікаціями працює коректно 68 ЧДТУ 242234 001ПЗ Продовження таблиці 3.2 BP_AmmoCastMaster Системний модуль відображається при пострілі з зброї та створенню простих колізійно-фізичних предметів які відображають гільзи від патронів APB_Zomb_Girl Файл анімацій кісток тіла ворога заснований на його скелеті та імпортованих на них анімації демонструє повноцінний функціонал в розробленій системі 3.3 Приклади впровадженого програмного комплексу Проєкт планується запустити на сервіс Стім після пропрацювання фідбеку від користувачів та додавання в існуючий додаток даного пропарцювання Стім було обрано не випадково на етапі проєктування. 69 ЧДТУ 242234 001ПЗ ВИСНОВОК РОЗДІЛУ 3 Даний розділ розглядав важливу тему розробки та тестування ПЗ результатом якого стає програмний продукт. Розділ підймав важливі теми пов’язані з вибором технологій, тестування різних типів з залученням об’єктивної точки зору так званої контрольної групи. Результатом розділу 3 є протестований розписаний програмний продукт. 70 ЧДТУ 242234 001ПЗ ВИСНОВКИ Результатом кваліфікаційної роботи бакалавра, можна вважати дослідження предметної області програмного продукту та його фінальна розробка. Метою розробки було створення повноцінного відеоігрового проєкту шутеру від першої особи на базі технологій UE5 на платформу ПК з ОС windows. Розроблений шутер від першої особи має в собі закладений функціонал його модульна система та технології які були використані дозволяють легко додавати нові елементи системи як і планувалось при проєктувані. Інтерфейс що було розроблено має приємний вигляд та не одноразово показував свою інтуїтивну зрозумілість. Головна ідея ігор розважати гравця, і гра з цим справляється на всі 98%. Широкий вибір зброї та можливість інтеграції нової не можливості гравцю звикнути до неї. Розроблені та імплементовані в ігровий процес механіки змушують гравця постійно бути в рухатись по локації щоб не програти. Оптимізація самого проєкту надає можливість гравцям з більш слабкими системами запускати даний проєкт. У підсумка по проробленій роботі можна сказати що робота пророблена згідно запланованого часу, та реалізовує трохи більше механік ніж планувалось на початку задля привнесення максимально приємного досвіду при використанні програмного продукту 71