ЗМІС

Т
Вступ.............................................................................................................................5
1 ЗАГАЛЬНИЙ РОЗДІЛ..........................................................................................6
1.1 Неевклідова геометрія....................................................................................6
1.1.1 Геометрія Лобачевського............................................................................6
1.1.2 Геометрія Римана.........................................................................................8
1.1.3 Сферична геометрія.....................................................................................9
1.2 Неевклідова геометрія у відеоіграх.............................................................10
1.2.1 Antichamber.................................................................................................12
1.2.2 Monument Valley.........................................................................................14
1.2.3 SuperLiminal............................................................................................15
2 ІНСТРУМЕНТИ РЕАЛІЗАЦІЇ...........................................................................19
2.1 Unity3d...........................................................................................................19
2.2 C#....................................................................................................................21
2.2.1 Портативність.........................................................................................22
2.2.2 Типування...............................................................................................22
2.2.3 Метапрограмування...............................................................................23
2.2.4 Методи та функції..................................................................................24
2.2.5 Доступ до пам'яті....................................................................................24
2.2.6 Мовний інтегрований запит (LINQ).....................................................25
2.2.7 Категорії типів даних.............................................................................25
2.2.8 Бокс і розпакування................................................................................26
2.3 Visual Stusio Code..........................................................................................27
2.4 Blender............................................................................................................28

Змн. Арк. № докум. Підпис Дата

Розроб. Літ. Арк. Акрушів
Перевір. . 4 55
Реценз.
Н.Контроль ОККТ
Затвердив
 5

Вступ

У наш час ігри є невід’ємною частиною людського життя. Хтось

відпочиває після роботи, хтось – після навчання. А багатьом людям відеоігри це
засіб заробляти, граючи в них професійно, чи створюючи їх, самому, з друзями,
чи у великій кампанії під видавництвом мега корпорації.
На ринку відеоігр останні роки можна знайти що завгодно, різної якості
та різних концепцій та жанрів, від гри де величезну кількість часу ти клікаєш на
печиво, купуєш апгрейди, і клацаєш на печиво ще більше до ігор в які можуть
іграти разом сотні людей з усього світу, змагаючись за звання кращого гравця.
Але у ігор є ще одна сторона медалі, не дивлячись на перспективи праці в
сфері геймдеву розробникам платять дуже мало відносно інших існуючих сфер
на ринку праці, а умови праці розробників у великих корпораціях змушують
хоча б замислитися над своїм майбутнім. А ті, що ризикують та роблять ігри
самостійно, без рекламної кампанії від видавців, можуть витратити декілька
тисяч годин праці щоб нічого з своєї праці не отримати. Але якщо таке і
робити, а така гра сподобається людям, то гра може отримати статус
«культової». І… все одно може не вистачити на нормальне існування
розробників, але це все інша історія.
Також на ринку відеоігор можна знайти ігри які робилися як
експеримент, чи те, що великі розробники ніколи б не пустили під своє крило,
наприклад Ready or not, від якої видавець відмовівся після виходу гри у ранній
доступ.
А деякі ігри навіть не доходять до рук видавців, бо ніхто не хоче
спонсувати ігри з сумнівною якістю, наприклад Rimworld, гарна гра яка вийшла
у світ без допомоги стороннього видавця, розробку гри підтримували через
карудфандинг[1] та за допомогою сервісу Steam.
Також важливо уточнити, що багато ігор які роблять самостійно майже
ніколи не виходять у світ, але це вже не проблема видаців, а лише проблема у
розробнику, якому не вистачає амбіцій на завершення своїх проектів, знайти
грошей, чи попросити їх у звичайних людей, тощо.
 6

1 ЗАГАЛЬНИЙ РОЗДІЛ

1.1 Неевклідова геометрія

Неевклідова геометрія – у буквальному значенні – будь-яка геометрія,

яка відрізняється від Евклідової геометрії. Однак, термін «Неевклідова
геометрія», при використанні у вужчому сенсі, мається на увазі лиш дві
геометричні системи: Геометрію Лобачевського, та сферичну геометрію (або
геометрію Римана, дуже схожу на останню).

1.1.1 Геометрія Лобачевського

Геометрія Лобачевського, також відома як гіперболічна геометрія, є

геометричною теорією, заснованою на тих же аксіомах, що й евклідова
геометрія, проте вона заперечує аксіому про паралельні прямі. Аксіома
паралельних прямих заявляє про те, що «На площині через точку, що не лежить
на даній прямій, можна провести лише одну пряму, паралельну даній». На
противагу чому в геометрії Лобачевського приймається за аксіому, що «Через
точку, що не лежить на даній прямій, проходять принаймні дві прямі, що
лежать з даною прямою в одній площині та не перетинають її»[2].
Ця аксіома являє собою повне заперечення Евклідової аксіоми, оскільки
випадок, коли через точку, що не лежить на даній прямій, не проходить жодної
прямої, що лежить з даною прямою в одній площині і не перетинає її,
виключається з інших аксіом. Таким чином, наприклад сферична геометрыя, та
геометрія Римана, у яких дві паралельні прямі перетинаються, отже, не
виконується ні аксіома Евкліда, ні аксіома Лобачевського, не сумісні з
абсолютною геометрією.
Моделювання геометрії Лобачевського (рис. 1.1) дало доказ її
несуперечності, точніше, що геометрія Лобачевського настільки ж несуперечна,
 7

як і геометрія Евкліда. Геометрія Лобачевського має широке застосування як у

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

Рисунок 1.1 – Наочне зображення геометрії Лобачевського: через точку M

проведено три прямі, що не перетинають пряму D

Всі теореми, які не залежать від аксіоми про паралельні, є загальними

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

Серед ненаукового суспільства існує міф про те, що у геометрії

лобачевського «паралельні прямі пересікаються», але це зовсім не так,
паралельні прямі не пересікаються ні в якій геометрії[3].
1.1.2 Геометрія Римана

Геометрія Римана – Одна з неевклідових геометрій постійної кривини

(інші дві – сферична геометрія та геометрія Лобачевського). Якщо геометрія
Евкліда реалізується у просторі з нульовою гаусовою кривизною,
Лобачевського з негативною, то геометрія Рімана реалізується у просторі з
постійною позитивною кривиною (у двомірному випадку — на проектній
площині та локально у сфері). У геометрії Рімана пряма визначається двома
точками, площина - трьома, дві площини перетинаються по прямій і іше, але в
геометрії Рімана немає паралельних прямих[4].
У геометрії Рімана, як і у сферичній геометрії, справедливе твердження:
сума кутів трикутника більше ніж двох прямих, виражена формулою Σ=π + S ∕ R 2,
де Σ – сума кутів трикутника, а R – радіус сфери, на якій реалізована геометрія.
Двовимірна геометрія Рімана схожа на сферичну геометрію, але відрізняється
тим, що будь-які дві «прямі» мають не дві, як у сферичній, а лише одну точку
перетину (рис. 1.2).

Рисунок 1.2 – Ототожнення протилежних точок сфери в геометрії Рімана

 9

При ототожненні протилежних точок сфери виходить проектна

площина, геометрія якої задовольняє аксіоми геометрії Рімана.

1.1.3 Сферична геометрія

Сферична геометрія – розділ геометрії, який розглядає усі геометричні

фігури на поверхні сфери. Утворилась сферична геометрія одночасно з тим,
коли вона знадобилась для разрахунків у географії та астрономії. У сферичній
геометрії існує ряд понять:
1. Велике коло – коло, що ділить кулю(сферу) на дві рівні половини(рис.
3). Центр великого кола збігається з центром сфери. На глобусі, наприклад, усі
меридіани є великими колами. Серед паралелей лише екватор є великим колом,
усі інші паралелі – це малі кола (рис. 1.3).
2. Великі кола на поверхні сфери відіграють роль, аналогічну ролі
прямих у планіметрії. Найкоротший шлях між будь-якими двома точками
пройде лінією великого кола.
3. Через будь-які дві точки на поверхні сфери, крім діаметрально
протилежних, можна провести єдине велике коло. Через діаметрально
протилежні точки на сфері можна провести скільки завгодно великих кіл.
4. Будь-які два великі кола перетинаються по прямій, що проходить
через центр сфери, а кола великих кіл перетинаються у двох діаметрально
протилежних точках.
 10

Рисунок 1.3 – Велике коло завжди поділяє сферу на дві рівні половини

Співвідношення між елементами сферичного трикутника вивчає

сферична тригонометрія (рис. 1.4).

Рисунок 1.4 – Мале коло поділяє сферу на дві нерівні частини. Центр малого
кола не збігається із центром сфери

Однак в іграх та серед гравців використовується інше визначення

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

1.2 Неевклідова геометрія у відеоіграх

 11

Що торкається теми неевклідової геометрії, то майже не єдина сфера де

вона зустрічається це Indie индустрія. Indie ігри, де назва походить від
Independent, тобто незалежна відеогра – це створені окремими людьми або
малими командами розробників без фінансового і технічного забезпечення від
відеовидавців, На відміну від більшості ігор типу "AAA" (triple-A). Однак
термін «інді» може застосовуватися і до інших сценаріїв, коли розробка гри має
певну міру незалежності від видавця, навіть якщо видавець допомагає
фінансувати та розповсюджувати гру, наприклад свободу творчості. Через свою
незалежність і свободу розвитку інді-ігри часто зосереджені на інноваціях,
експериментальному геймплею та ризику, який зазвичай не прийнятий в іграх
AAA, і можуть досліджувати середовище для створення унікальних вражень у
мистецьких іграх. Інді-ігри, як правило, продаються через цифрові канали
розповсюдження(зокрема багато інді проектів можна знайти у steam та
придбати гру за гроші, або на itch.io, де всі ігри розробники викладають для
безкоштоного використання), а не в роздріб через відсутність підтримки
видавців. Цей термін є синонімом незалежної музики чи незалежного кіно в цих
відповідних середовищах.
Інді-розробка ігор базується на тих самих концепціях програмування для
аматорів і любителів, які виросли з появою персональних комп’ютерів і простої
комп’ютерної мови BASIC у 1970-х і 1980-х роках. Так звані спальні кодери,
зокрема у Сполученому Королівстві та інших частинах Європи, створювали
власні ігри та використовували замовлення поштою для розповсюдження своєї
продукції, а пізніше перейшли до інших методів розповсюдження програмного
забезпечення з появою Інтернету в 1990-х роках, таких як умовно-безкоштовне
та інші методи розповсюдження файлів, хоча на той час інтерес до
програмування для любителів зменшився через зростання вартості розробки та
конкуренції з боку видавців відеоігор і домашніх консолей.
Сучасний погляд на сцену інді-ігор призвів до поєднання багатьох
факторів на початку 2000-х років, зокрема технічних, економічних і соціальних
концепцій, які зробили інді-ігри менш дорогими у створенні та
розповсюдженні, але більш помітними для більшої аудиторії та пропонували
 12

нетрадиційний ігровий процес із поточних основних ігор. Кілька інді-ігор того

часу отримали великий успіх, що викликало більше інтересу до цієї області.
Відтоді з’явилися нові можливості у цій галузі, зокрема нові цифрові вітрини,
краудфандинг та інші інді-фінансові механізми, які допомагають новим
командам запускати свої ігри, недорогі інструменти розробки з відкритим
вихідним кодом, доступні для невеликих команд на всіх ігрових платформах,
малі інді видавці ігор, які залишають творчу свободу розробникам, і галузеве
визнання інді-ігор поряд із масовими на великих заходах з нагородження ігор.
Приблизно у 2015 році збільшення кількості опублікованих інді-ігор
призвело до побоювання «інді-покаліпсису», маючи на увазі надлишок ігор,
який зробить увесь ринок збитковим. Попри те, що ринок не зазнав краху,
можливість такого випадку залишається проблемою для більшості незалежних
розробників, оскільки багато ігор не є фінансово прибутковими. Приклади
успішних інді-ігор включають серію Touhou Project, Cave Story, Braid, Super
Meat Boy, Minecraft, Fez, Shovel Knight, Undertale і Cuphead.
Зокрема в інді-іграх і є багато прикладів використання «Неевклідової
геометрії», бо великі видавці зазвичай не хочуть ризикувати з не одразу
зрозумілою моделлю фізики або простору у своїх іграх. Але, все ж деякі інді-
ігри мали успіх, про деякі з них обов’язкого треба розказати, так як вони майже
не єдине втілення неевклідового простору у «реальному житті».

1.2.1 Antichamber

Antichamber – це гра головоломка-платформер від першої особи, яка

була створена австралійським розробником Олександром «Демрутом» Брюсом
самостійно. Багато головоломок засновані на явищах, які відбуваються у
просторі неевклідової геометрії, наприклад проходах, які ведуть гравця до
різних місць залежно від того, куди вони дивляться, та структурах, які інакше
здаються неможливими у звичайному тривимірному просторі (рис. 1.5).
Гра містить елементи психологічного дослідження через короткі
повідомлення з порадами, які допомагають гравцеві розв’язати головоломки, а
 13

також приказки із реального життя. Приказки у грі несуть у собі характер

цільного оповідання (гра починається з приказки «Кожна подорож складається
із виборів. Перший – це початок подорожі» і закінчується приказкою «Кожна
подорож добігає кінця»), опису пройденого шляху(«вибір не важливий, якщо
результат той самий»), або підказок для подальшого шляху («Занурення у
невідоме може призвести до великих нагород»).

Рисунок 1.5 – Кімната-галерея в Antichamber

Основною фішкою що продає гру є незвичайна побудова рівнів та

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

Рисунок 1.6 – Сходи, які незалежно від того, куди гравець піде, униз, чи уверх,
повертають його на самий початок

З графічним рішенням в Antichamber все склалося як можна краще.

Через статичне освітлення та відсутності тіней у гравця з’являється почуття
того, що нічого з того, що він бачить, насправді працює не так, як він вважає,
чи може вважати, на перший погляд (щонайменше у головоломках що залежать
напряму від зору).
1.2.2 Monument Valley

Monument Valley – це ще одна гра-головоломка, розроблена та

опублікована Ustwo Games. Гравець веде принцесу Іду через лабіринти
оптичних ілюзій (рис. 1.7) і неможливих об’єктів, маніпулюючи навколишнім
світом, щоб досягти різних платформ. Monument Valley розроблявся протягом
десяти місяців, починаючи з початку 2013 року, на основі концептуальних
малюнків художника компанії Кена Вонга. Його візуальний стиль був
натхненний японськими принтами, мінімалістською скульптурою та інді-іграми
Windosill, Fez і Sword & Sworcery. Критики порівнювали його з малюнками
Мауріца Корнеліса Ешера та стилем гри Echochrome.

Рисунок 1.7 – Відтворення імп-арту Ешера «водоспад» у грі Monument Valley

 15

Графічну частину було розроблено таким чином, щоб кожен кадр був
гідний публічного показу. Після закритого бета-тестування її було випущено
для iOS 3 квітня 2014 року, а пізніше було перенесено на Android і Windows
Phone. Гра отримала по більшу частину лише схвальні відгуки. Критики високо
оцінили графічне та звукове оформлення, але відзначили відсутність складності
та коротку тривалість. У 2014 році вона отримала нагороду Apple Design Award,
була визнана найкращою грою Apple для iPad 2014 року, і до січня 2015 року
було продано понад два мільйони копій; до травня 2016 року продажі гри
перевищили 26 мільйонів. Ця мобільна головоломка щонайменше повністю
використовує концепцію «неможливих фігур», перетворюючи кожну відому
фігуру в окремий рівень. Гравці виділяють приємне аудіосупроводження, що
заставляє розслабитись, та геймплей, що мотивує до повертання у цю гру знову
та знову. Також серед гравців відокремлюється думка, що ця гра занадто
коротка (10 рівнів), і з цим складно не погодитись, з цим погодились навіть
розробники, тому через деякий час виходить вже друга частина цієї гри, але про
неї сказати на жаль вже нічого, тому єдине, що можна тут зробити це перейти
до ще однієї яскравої гри з використанням Неевклідової геометрії.

1.2.3 SuperLiminal

Superliminal – це сюрреалістична відеогра-головоломка 2019 року,

випущена компанією Pillow Castle Games. Гра, у яку грають від першої особи,
включає елементи ігрового процесу навколо оптичних ілюзій і вимушеної
перспективи; Зокрема, підібрані об’єкти можна переміщати до гравця або від
нього, але коли вони поміщені далеко, вони зменшуються до розміру, яким їх
бачив гравець, що дозволяє гравцеві розгадувати головоломки, щоб завершити
гру.
Гра була випущена для Microsoft Windows і MacOS у листопаді 2019
року, а для Linux – у листопаді 2020 року. Порти для PlayStation 4, Xbox One і
Nintendo Switch були випущені в липні 2020 року. Гравець-персонаж є
 16

учасником програми терапії сновидіннями, але під час дослідження персонаж

потрапляє в пастку повторюваного циклу сновидінь і керується голосом
наглядача дослідження, доктора Гленна Пірса, про те, як втекти зі сну.
Більшість головоломок включають проходження серії кімнат, щоб
дістатися до виходів. Вихідні двері можуть бути закриті, і для їх відкриття
потрібно натиснути кнопку, або перебувати на вищій платформі поза межами
досяжності, або їх не видно одразу. Щоб дістатися до виходу, гравець може
маніпулювати певними об’єктами в ігровому світі. Більшість таких взаємодій
базується на використанні вимушеної перспективи: гравець може взяти куб
заввишки до талії, який потім зберігається в його очевидному поточному
розмірі з точки зору гравця. Потім гравець може дивитися в інше місце по
кімнаті, залишаючи куб у тій самій точці огляду, і кинути цей куб у це місце (на
найвіддаленішу відстань), де куб буде збільшуватися або зменшуватися в
розмірі залежно від нової перспективи. Якщо під час падіння кубик висотою до
талії дивитися вниз на підлогу, куб зменшиться в розмірі, а якщо дивитися
вгору до стелі та кидати, то він збільшиться. Цей процес можна повторюватися
нескінченно, дозволяючи гравцеві маніпулювати цими масштабованими
об’єктами, щоб створювати платформи для досягнення виходу або усувати
перешкоди, які вони блокують.
Пізніші частини гри вводять нові механіки. Деякі об’єкти існують як
ілюзії trompe-l’œil із сегментами двовимірного мистецтва на різних стінах і
поверхнях, і гравець повинен знайти відповідний кут, щоб побачити об’єкт і
зробити так, щоб він виглядав цілим (рис. 1.9), щоб потім мати можливість
схопити його. Superliminal був розроблений командою Pillow Castle із шести
осіб на чолі з Альбертом Ши, студентом Центру розважальних технологій
(ETC) Університету Карнегі-Меллона.
 17

Рисунок 1.9 – Зображений об’єкт стане фізичнім лише коли з перспективи

гравця він почне виглядати цілим
Ши розробив основу гри, бувши студентом ETC приблизно у 2013 році,
виконуючи завдання з програмування, шукаючи «яку цікаву гру від першої
особи я можу створити, просто пересуваючи кубики?». Він покращив
концепцію під час своєї дипломної роботи, створивши Pillow Castle у січні 2014
року та отримавши допомогу від чотирьох інших студентів ETC для створення
гри. Ши був натхненний такими успішними іграми, як Risk of Rain і
Antichamber, створеними невеликими командами для продовження його роботи
над Superliminal. Antichamber особливо вплинув на Shih, оскільки він направляв
і заохочував гравця мислити нестандартно, щоб знайти розв’язки головоломок,
ідею, яку він хотів відновити в Superliminal. Подібним чином Ши порівняв
масштабні головоломки Superliminal із головоломками на основі порталу в
Portal, розробляючи головоломки, щоб створити моменти прозріння для гравця.
Основна концепція Superliminal базується на примусовій перспективі,
при цьому Ши посилається на звичайні туристичні фотографії людей, які
використовують примусову перспективу, щоб виглядати так, ніби вони
штовхають або тримають Пізанську вежу. За словами Ши, досягнення
механізму масштабування у движку Unity було простим. Коли гравець бере
предмет, гра відстежує його розмір і відстань. Потім, поки гравець озирається,
гра обчислює нову відстань до найдальшої точки прямо перед гравцем і
масштабує розмір об’єкта пропорційно до зміни початкової відстані. Більш
складним фактором, який виявив Ши, було врахування складних форм деяких
об’єктів і того, де гравець очікував, що буде центральна точка огляду. Інші
 18

головоломки в грі, пов’язані з проектуванням і видаленням проектування 3D-

об’єктів на 2D-площини, використовували об’єкти камери та проектора Unity з
єдиною проблемою, пов’язаною з глибиною камери, що, за словами Ши, не
підтримується Unity належним чином, але програміст Філ Фортьє розв’язав цю
проблему. Виявилося, що головоломки масштабування викликають певні
проблеми під час тестування, оскільки гравці могли придумати можливі
рішення, які зрештою не працювали, і гра не могла надати зворотний зв’язок,
чому. Замість того, щоб гравці могли стрибати, що було непослідовним через
масштабування, вони натомість дозволяли гравцям підійматися на виступи,
щоб легше було направляти гравців до рішення.
Гра була представлена як «Музей технологій моделювання» як технічна
демонстрація. Демо вперше було представлено на Tokyo Game Show 2013 під
час Sense of Wonder Night, події, присвяченої, інді-іграм. Демонстрація
отримала нагороду «Найкраща технологія» та «Приз глядацьких симпатій».
 19

2 ІНСТРУМЕНТИ РЕАЛІЗАЦІЇ

2.1 Unity3d

Звісно, що ніяка відеогра не може не мати ігрового движка, тому для

утворення своєї відеогри я використовував стандартний Unity3d для роботи з
ігровим простором. Unity (unity у перекладі з англ. «єдність», вимовляється як
«юніті») — міжплатформне середовище розробки комп'ютерних ігор,
розроблене американською компанією Unity Technologies. Unity дозволяє
створювати додатки, що працюють на більш ніж 25 різних платформах, що
включають персональні комп'ютери, ігрові консолі, мобільні пристрої,
інтернет-програми та інші. Випуск Unity відбувся у 2005 році і з того часу
триває постійний розвиток.
Основними перевагами Unity є наявність візуального середовища
розробки, міжплатформної підтримки та модульної системи компонентів. До
недоліків відносять появу складнощів при роботі з багатокомпонентними
схемами та утруднення при підключенні зовнішніх бібліотек.
На Unity написані тисячі ігор, програм, візуалізації математичних
моделей, які охоплюють безліч платформ і жанрів. При цьому Unity
використовується як великими розробниками, так і незалежними студіями.
Редактор Unity має простий Drag&Drop інтерфейс (рис. 2.1), а також
встановлення плагінів KALI, який легко налаштовувати, що складається з
різних вікон, завдяки чому можна проводити налагодження гри прямо в
редакторі. Двигун використовує написання скриптів C#. Розрахунки фізики
здійснює фізичний двигун PhysX від NVIDIA для 3D фізики і Box2D для 2D
фізики. Графічний API – DirectX. Завдяки наданим інструментам у Unity
можливо створити будь-яку гру у 3д чи 2д просторі. Від простих платформерів
та візуальних новел до повноцінної гри з відкритим світом.
У Unity також є магазин ассетів, який дозволяє використовувати у своїх
проектах. Від безкоштовних «плейсхолдерів» та низкоякісних моделей для
вільного використування до платних повноцінних карт та HD 3д об’єктів. Усі з
них можна придбати та завантажити з офіційного вебсайту Unity Store. Цей
магазин можна знайти за посиланням https://assetstore.unity.com/, де все, що
потрібно для отримання матеріалів це зареєструватися, обрати моделі,
текстури, або матеріали, та імпортувати їх до свого проекту.
 20

Рисунок 2.1 – Інтерфейс unity3d

Проект в Unity ділиться на сцени (рівні) - окремі файли, що містять свої

ігрові світи зі своїм набором об'єктів, сценаріїв та налаштувань. Сцени можуть
містити як власне об'єкти (моделі), і порожні ігрові об'єкти — об'єкти, які не
мають моделі («пустушки»). Об'єкти, у свою чергу, містять набори
компонентів, з якими і взаємодіють скрипти. Також об'єкти мають назву (в
Unity допускається наявність двох і більше об'єктів з однаковими назвами в
одній сцені), може бути тег (мітка) і шар, на якому він повинен відображатися.
Так, у будь-якого об'єкта на сцені обов'язково присутній компонент Transform
— він зберігає координати розташування, повороту і розмірів об'єкта по всіх
трьох осях.
Також Unity підтримує фізику твердих тіл та тканин, а також фізику типу
Ragdoll (ганчіркова лялька). У редакторі є система наслідування об'єктів;
дочірні об'єкти будуть повторювати всі зміни позиції, повороту та масштабу
батьківського об'єкта. Скрипти у редакторі прикріплюються до об'єктів як
окремих компонентів.
Як недоліки наводяться обмеження візуального редактора під час роботи
з багатокомпонентними схемами, тому у складних сценах візуальна робота
погіршується та ускладнюється. Другим недоліком називається відсутність
підтримки Unity посилань на зовнішні бібліотеки, роботу з якими програмістам
доводиться налаштовувати самостійно, і це також ускладнює командну роботу.
Ще один недолік пов'язаний із використанням шаблонів екземплярів
(англійскою prefabs). З одного боку, ця концепція Unity пропонує гнучкий
підхід візуального редагування об'єктів, але з іншого боку, редагування таких
шаблонів є складним. Також, WebGL-версія движка в силу специфіки своєї
архітектури (трансляція коду з C # С++ і далі в JavaScript), має ряд невирішених
 21

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

пристроях.
Unity дозволяє створювати ігри як на мобільні так і на Десктопні
пристрої, без проблем можна збудувати ігру на Androd, MacOS, Linux та
Windows.
Unity 3D підтримує систему Level Of Detail, суть якої полягає в тому, що
на дальній відстані від гравця високодеталізовані моделі замінюються на менш
деталізовані, і навпаки, а також систему Occlusion culling, суть якої в тому, що у
об'єктів, камери, що не потрапляють у поле зору, не візуалізується геометрія та
колізія, що знижує навантаження на центральний процесор і дозволяє
оптимізувати проект. При компіляції проекту створюється виконуваний (.exe)
файл гри (для Windows), а в окремій папці - дані гри (включаючи всі ігрові рівні
та бібліотеки, що динамічно підключаються).
Двигун підтримує безліч популярних форматів. Моделі, звуки, текстури,
матеріали, скрипти можна запаковувати у формат .unitypackage та передавати
іншим розробникам, або викладати у вільний доступ. Цей формат
використовується у внутрішньому магазині Unity Asset Store, в якому
розробники можуть безкоштовно і за гроші викладати в загальний доступ різні
елементи, потрібні при створенні ігор. Щоб використовувати Unity Asset Store,
необхідно мати обліковий запис розробника Unity.
UNet (бібліотека для реалізації мультиплеєра в іграх на Unity) була
вилучена, починаючи з версії 2018.4; рішення «з коробки» для мультиплеєра
відсутнє. Також можна використовувати відповідний користувачеві спосіб
контролю версій. Наприклад, Tortoise SVN, Git чи Source Gear.

2.2 C#

C# — мова програмування загального призначення з кількома

парадигмами. C# охоплює статичну типізацію, жорстку типізацію, лексичну
область видимості, імперативну, декларативну, функціональну, загальну,
об’єктно-орієнтовану (на основі класів) і компонентно-орієнтоване
програмування.
Мова програмування C# була розроблена Андерсом Хейлсбергом із
Microsoft у 2000 році та пізніше була затверджена як міжнародний стандарт
Ecma (ECMA-334) у 2002 році та ISO/IEC (ISO/IEC 23270) у 2003 році.
Microsoft Надала C# разом із .NET Framework і Visual Studio, обидва з яких
були закритими. У той час у Microsoft не було продуктів з відкритим кодом.
Через чотири роки, у 2004 році, розпочався безкоштовний проект з відкритим
вихідним кодом під назвою Mono, що надає кросплатформний компілятор і
середовище виконання для мови програмування C#. Через десять років
 22

Microsoft випустила Visual Studio Code (редактор коду), Roslyn (компілятор) і

уніфіковану платформу .NET (фреймворк програмного забезпечення), які
підтримують C# і є безкоштовними, з відкритим кодом і кросплатформенними.
Mono також приєднався до Microsoft, але не був об’єднаний із .NET.
Станом на липень 2022 року найновішою стабільною версією мови є C# 10.0,
яка була випущена в 2021 році в .NET 6.0.
Деякі помітні особливості C#, які відрізняють його від мов C, C++ і Java
зазначено нижче

2.2.1 Портативність

За задумом C# є мовою програмування, яка найбільш прямо відображає

базову інфраструктуру спільної мови (CLI). Більшість його внутрішніх типів
відповідають типам значень, реалізованим фреймворком CLI. Однак
специфікація мови не вказує на вимоги компілятора до генерації коду: тобто в
ній не вказано, що компілятор C# повинен бути спрямований на середовища
виконання спільної мови, генерувати загальну проміжну мову (CIL) або
генерувати будь-який інший конкретний формат. Теоретично компілятор C#
може генерувати машинний код, як традиційні компілятори C++ або Fortran.

2.2.2 Типування

C# підтримує чітке, неявно типізоване оголошення змінних за допомогою

ключового слова var і неявно типізовані масиви за допомогою ключового слова
new[], за яким іде ініціалізатор колекції.
C# підтримує суворий логічний тип даних bool. Інструкції, які приймають
умови, такі як while і if, вимагають виразу типу, який реалізує істинний
оператор, наприклад типу Boolean. Хоча C++ також має логічний тип, його
можна вільно перетворювати в цілі числа та з них, а такі вирази, як if (a),
вимагають лише того, щоб a було конвертованим у bool, дозволяючи a бути int
або покажчиком. C# забороняє цей підхід «ціле число, що означає істину або
хибність», на тій підставі, що примушування програмістів використовувати
вирази, які повертають саме bool, може запобігти певним типам програмних
помилок, наприклад if (a = b) (використання присвоєння = замість рівності == ).
C# є більш безпечним для типів, ніж C++. Єдиними неявними
перетвореннями за замовчуванням є ті, які вважаються безпечними, наприклад,
розширення цілих чисел. Це примусово виконується під час компіляції, під час
JIT і, в деяких випадках, під час виконання. Не відбувається неявних
 23

перетворень між логічними значеннями та цілими числами, а також між

членами перерахування та цілими числами (за винятком літералу 0, який можна
неявно перетворити на будь-який перерахований тип). Будь-яке перетворення,
визначене користувачем, має бути явно позначене як явне або неявне, на
відміну від конструкторів копіювання та операторів перетворення C++, які за
замовчуванням є неявними.
C# має явну підтримку коваріантності та контраваріантності в загальних
типах, на відміну від C++, який має деякий ступінь підтримки
контраваріантності просто через семантику типів повернення віртуальних
методів.
Члени переліку розміщуються у власній області.
Мова C# не допускає глобальних змінних або функцій. Усі методи та
члени мають бути оголошені в класах. Статичні члени публічних класів можуть
замінювати глобальні змінні та функції.
Локальні змінні не можуть закривати змінні охоплюючого блоку, на
відміну від C і C++.

2.2.3 Метапрограмування

Метапрограмування можна досягти кількома способами:

Відображення підтримується через .NET API, які дозволяють сценарії,
такі як перевірка метаданих типу та динамічний виклик методу.
Дерева виразів представляють код як абстрактне синтаксичне дерево, де
кожен вузол є виразом, який можна перевірити або виконати. Це дозволяє
динамічно модифікувати виконуваний код під час виконання. Дерева виразів
вносять певну гомоіконічність у мову.
Атрибути — це метадані, які можна приєднати до типів, членів або цілих
збірок, еквівалентно анотаціям у Java. Атрибути доступні як для компілятора,
так і для коду через рефлексію. Багато з цих атрибутів дублюють функціональні
можливості директив препроцесора GCC і Visual C++, залежних від платформи.
Платформа компілятора .NET (Roslyn) надає API-доступ до служб
компіляції мови, дозволяючи компілювати код C# із програм .NET. Він надає
API для синтаксичного (лексичного) аналізу коду, семантичного аналізу,
динамічної компіляції в CIL і видачі коду.
Генератори коду, функція компілятора Roslyn C#, дозволяють
метапрограмувати під час компіляції. Під час процесу компіляції розробники
 24

можуть перевірити код, що компілюється, за допомогою API компілятора та

передати додатковий згенерований вихідний код C# для компіляції.

2.2.4 Методи та функції

Метод у C# є членом класу, який може бути викликаний як функція

(послідовність інструкцій), а не просто здатність утримувати значення
властивості класу. Як і в інших синтаксично подібних мовах, таких як C++ і
ANSI C, сигнатура методу – це оголошення, що містить у порядку: будь-які
додаткові ключові слова доступності (наприклад, private), явну специфікацію
його типу повернення (наприклад, int або ключове слово void, якщо значення не
повертається), ім’я методу та, нарешті, послідовність специфікацій параметрів,
розділених комами, у дужках, кожна з яких складається з типу параметра, його
офіційної назви та, за бажанням, значення за замовчуванням, яке
використовується, якщо жодне не надається. Деякі конкретні типи методів,
наприклад ті, які просто отримують або встановлюють властивість класу
шляхом повернення значення або призначення, не вимагають повного підпису,
але в загальному випадку визначення класу включає повний декларація підпису
його методів.
Подібно до C++ і на відміну від Java, програмісти C# повинні
використовувати ключове слово модифікатора області видимості virtual, щоб
дозволити підкласам замінювати методи.
Методи розширення в C# дозволяють програмістам використовувати
статичні методи так, якби вони були методами з таблиці методів класу,
дозволяючи програмістам додавати методи до об’єкта, який, на їхню думку,
повинен існувати в цьому об’єкті та його похідних.
Динамічний тип дозволяє зв’язувати метод під час виконання,
дозволяючи виклики методів, подібних до JavaScript, і композицію об’єктів під
час виконання.
У C# є підтримка строго типізованих покажчиків на функції через делегат
ключового слова. Подібно до сигналу та слота псевдо-C++ фреймворку Qt, C#
має семантику, що спеціально оточує події стилю публікації-підписки, хоча C#
використовує для цього делегати.
C# пропонує синхронізовані виклики методів, подібні до Java, за
допомогою атрибута [MethodImpl(MethodImplOptions.Synchronized)] і
підтримує взаємовиключні блокування за допомогою ключового слова lock.
 25

2.2.5 Доступ до пам'яті

У C# показники адреси пам’яті можна використовувати лише в межах

блоків, спеціально позначених як небезпечні, а програми з небезпечним кодом
потребують відповідних дозволів для запуску. Більшість доступу до об’єктів
здійснюється через безпечні посилання на об’єкти, які завжди або вказують на
«живий» об’єкт, або мають чітко визначене нульове значення; неможливо
отримати посилання на «мертвий» об'єкт, або на випадковий блок пам'яті.
Небезпечний покажчик може вказувати на екземпляр «некерованого» типу
значення, який не містить жодних посилань на об’єкти зібраного сміття, масив,
рядок або блок пам’яті, виділеної стеком. Код, який не позначено як
небезпечний, усе ще може зберігати та маніпулювати покажчиками через тип
System.IntPtr, але він не може їх розіменувати.
Керовану пам'ять не можна явно звільнити; натомість автоматично
збирається сміття. Збирання сміття вирішує проблему витоків пам’яті,
звільняючи програміста від відповідальності за звільнення пам’яті, яка в
більшості випадків більше не потрібна. Код, який зберігає посилання на об’єкти
довше, ніж потрібно, все одно може споживати більше пам’яті, ніж необхідно,
однак, коли звільняється останнє посилання на об’єкт, пам’ять стає доступною
для збирання сміття.

2.2.6 Мовний інтегрований запит (LINQ)

C# має можливість використовувати LINQ через .NET Framework.

Розробник може запитувати різноманітні джерела даних, якщо в об’єкті
реалізовано інтерфейс IEnumerable<T>. Це включає документи XML, набір
даних ADO.NET і бази даних SQL.
Використання LINQ у C# надає такі переваги, як підтримка Intellisense,
потужні можливості фільтрації, безпека типів із можливістю перевірки помилок
компіляції та узгодженість для запитів даних із різних джерел. Існує кілька
різних мовних структур, які можна використовувати з C# і LINQ, і це вирази
запитів, лямбда-вирази, анонімні типи, неявно типізовані змінні, методи
розширення та ініціалізатори об’єктів.

2.2.7 Категорії типів даних

Екземпляри типів значень не мають ані посилальної ідентичності, ані

посилальної семантики порівняння. Порівняння рівності та нерівності для типів
значень порівнює фактичні значення даних у примірниках, якщо відповідні
 26

оператори не перевантажені. Типи значень є похідними від System.ValueType

завжди має значення за замовчуванням і завжди може бути створено та
скопійовано. Деякі інші обмеження на типи значень полягають у тому, що вони
не можуть походити один від одного (але можуть реалізовувати інтерфейси) і
не можуть мати явний конструктор за замовчуванням (без параметрів).
Прикладами типів значень є всі примітивні типи, такі як int (32-розрядне ціле
число зі знаком), float (32-розрядне число з плаваючою комою IEEE), char (16-
розрядний код Unicode) і System.DateTime ( визначає конкретний момент часу з
точністю до наносекунд). Іншими прикладами є enum (перерахування) і struct
(визначені користувачем структури).
Навпаки, посилальні типи мають поняття посилальної ідентичності, тобто
кожен екземпляр посилального типу за своєю суттю відрізняється від будь-
якого іншого екземпляра, навіть якщо дані в обох екземплярах однакові. Це
відображається в порівняннях рівності та нерівності за умовчанням для
еталонних типів, які перевіряють посилальну, а не структурну рівність, якщо
відповідні оператори не перевантажені (наприклад, у випадку System.String).
Деякі операції не завжди можливі, наприклад створення екземпляра еталонного
типу, копіювання існуючого екземпляра або виконання порівняння значень
двох існуючих екземплярів. Хоча певні типи посилань можуть надавати такі
послуги, відкриваючи відкритий конструктор або реалізовуючи відповідний
інтерфейс (наприклад, ICloneable або IComparable). Прикладами посилальних
типів є object (основний базовий клас для всіх інших класів C#), System.String
(рядок символів Unicode) і System.Array (базовий клас для всіх масивів C#).
Обидві категорії типів можна розширити за допомогою типів, визначених
користувачем.

2.2.8 Бокс і розпакування

Бокс — це операція перетворення об’єкта типу значення у значення

відповідного еталонного типу. Бокс у C# неявний.
Розпакування — це операція перетворення значення посилального типу
(раніше упакованого в коробку) у значення типу значення. Розпакування в C#
вимагає явного приведення типу. Об’єкт типу T у коробці може бути лише
розпакований до T (або T з можливістю нульового значення). Приклад:

int foo = 42; // Тип значення.

панель об’єктів = foo; // foo поміщається в рамку.
int foo2 = (int)bar; // Розпаковано назад до типу значення.
 27

2.3 Visual Stusio Code

Звісно для редагування коду потрібно використовувати засіб для вільного

редагування коду на мові програмування C#. Звісно якщо мови С були
розроблені та розповсюджуються кампанією Microsoft, було б розумно
використовувати розроблений цією компанією засіб для редагування коду.
Звісно мова йде про Visual studio code. Visual Studio Code – це текстовий
редактор, розроблений Microsoft для Windows, Linux та macOS. Позиціонується
як «легкий» редактор коду для кросплатформної розробки веб та хмарних
програм. Включає в себе відладчик, інструменти для роботи з Git,
підсвічування синтаксису, IntelliSense та засоби для рефакторингу. Має широкі
можливості для кастомізації: теми користувача (див. на рис. 2.2), поєднання
клавіш і файли конфігурації. Поширюється безкоштовно, розробляється як
програмне забезпечення з відкритим вихідним кодом, але готові збірки
поширюються під проприетарною ліцензією. Visual Studio Code заснований на
Electron і як правило реалізується через веб-редактор Monaco, розроблений
Visual Studio Online.

Рисунок 2.3 – Інтерфейс програми Visual Studio Code

VS Code також дозволяє замінювати кодову сторінку під час збереження

документа, символи перекладу рядка та мову програмування поточного
документа. З 2018 з'явилося розширення Python для Visual Studio Code з
 28

відкритим вихідним кодом. Воно надає розробникам широкі можливості для

редагування, налагодження та тестування коду. Також VS Code підтримує
редагування та виконання файлів типу Блокнот Jupyter безпосередньо з коробки
без встановлення зовнішнього модуля в режимі візуального редагування і в
режимі редагування вихідного коду. На березень 2019 року за допомогою
вбудованого в продукт інтерфейсу користувача можна завантажити і
встановити кілька тисяч розширень тільки в категорії «programming languages».
Також розширення дозволяють отримати більш зручний доступ до програм,
таких як Docker, Git та інші. У розширеннях можна знайти лінтери коду, теми
для редактора та підтримку синтаксису окремих мов.

2.4 Blender

Для створення 3D моделей та анімацій я використовував безкоштовну

спеціалізовану програму Blender. Blender — це безкоштовний набір
інструментів для 3D-комп’ютерної графіки з відкритим кодом, який
використовується для створення анімаційних фільмів, візуальних ефектів,
мистецтва, 3D-друкованих моделей, анімованої графіки, інтерактивних 3D-
додатків, віртуальної реальності та, раніше, відеоігор. Функції Blender
включають 3D-моделювання, ультрафіолетове відображення, текстурування,
цифрове малювання, редагування растрової графіки, такелаж і скінінг,
симуляцію рідини та диму, моделювання частинок, моделювання м’яких тіл,
скульптуру, анімацію, рендерингу, анімаційної графіки, редагування відео та
компонування.
Blender підтримує різноманітні геометричні примітиви, включаючи
багатокутну сітку, криві Безьє, поверхні NURBS, метакулі, ікосфери, текст і
систему моделювання n-кутників під назвою B-сітка. Існує також вдосконалена
система полігонального моделювання, до якої можна отримати доступ у режимі
редагування. Він підтримує такі функції, як екструзія, фаска та поділ. Blender
має систему геометричних вузлів для процедурного та недеструктивного
створення та маніпулювання геометрією. Вперше його було додано до Blender
2.92, який зосереджений на розсіюванні об’єктів та інстансуванні. Він приймає
форму модифікатора, тому його можна накладати на інші різні модифікатори.
Система використовує атрибути об’єктів, які можна змінювати та
перевизначати за допомогою введення рядків. Атрибути можуть включати
положення, нормалі та UV-мапи. Усі атрибути можна переглянути в редакторі
електронних таблиць атрибутів. Утиліта Geometry Nodes також має можливість
створювати примітивні сітки. У Blender 3.0 підтримку створення та зміни
об’єктів кривих було додано до вузлів геометрії. У Blender 3.0 робочий процес
Геометричних вузлів (див. Рисунок 2.4) був повністю перероблений із полями,
щоб зробити систему більш інтуїтивно зрозумілою та працювати як з вузлами
шейдерів.
 29

Але основним призначенням Blender у цій роботі було створення 3Д об’єктів та

анімацій для них, адже Unity не має у себе повноцінного інструменталу для
створювання таких об’єктів

Рисунок 2.4 – Редактор геометричних вузлів у Blender 3.2

У Blender є чотири механізми рендерингу готової роботи:

 Внутрішній механізм візуалізації з рендерингом розгортки,
непрямим освітленням і оклюзією навколишнього середовища,
який можна експортувати в різноманітні формати;
 Механізм візуалізації трасувальника шляху під назвою Cycles, який
може використовувати переваги GPU для рендерингу. Cycles
підтримує Open Shading Language, починаючи з Blender 2.65;
 Cycles Hybrid Rendering, що можливий для використання у версії
2.92 з Optix. Плитки розраховуються за допомогою GPU в
поєднанні з CPU;
 EEVEE – новий фізичний рендерер реального часу. Він працює і як
рендерер для кінцевих кадрів, і як двигун, що керує вікном
перегляду Blender у реальному часі для створення ресурсів.
Більшість команд доступні за допомогою гарячих клавіш. Є також
вичерпні графічні меню. Цифрові кнопки можна "перетягувати", щоб
змінювати їх значення безпосередньо без необхідності націлюватися на певний
віджет, а також налаштовувати за допомогою клавіатури. І повзунки, і цифрові
кнопки можуть бути обмежені різними розмірами кроку за допомогою
модифікаторів, таких як клавіші Ctrl і Shift. Вирази Python також можна
вводити безпосередньо в поля введення чисел, дозволяючи математичним
виразам указувати значення.
 30

Blender включає в себе багато режимів для взаємодії з об’єктами, два

основних – це режим об’єкта та режим редагування, які перемикаються за
допомогою клавіші Tab. Режим об’єктів використовується для маніпулювання
окремими об’єктами як одиницею, тоді як режим редагування
використовується для маніпулювання фактичними даними об’єкта. Наприклад,
режим об’єкта можна використовувати для переміщення, масштабування та
обертання цілої багатокутної сітки, а режим редагування можна
використовувати для маніпулювання окремими вершинами однієї сітки. Є
також кілька інших режимів, наприклад, Vertex Paint, Weight Paint і Sculpt
Mode.
Графічний інтерфейс Blender будує свою мозаичну систему вікон поверх
одного або кількох вікон, наданих основною платформою. Одне вікно
платформи (часто має розмір, щоб заповнити екран) розділене на розділи та
підрозділи, які можуть мати будь-який тип перегляду Blender або типу вікна.
Користувач може визначити кілька макетів таких вікон Blender, які
називаються екранами, і швидко перемикатися між ними, вибираючи з меню
або за допомогою комбінацій клавіш. Власними елементами графічного
інтерфейсу вікна кожного типу можна керувати за допомогою тих самих
інструментів, які маніпулюють 3D-виглядом. Наприклад, можна збільшувати та
зменшувати масштаб кнопок графічного інтерфейсу за допомогою подібних
елементів керування, а також збільшувати та зменшувати масштаб у вікні 3D.
Вікно перегляду графічного інтерфейсу користувача та макет екрана повністю
налаштовуються користувачем. Можна налаштувати інтерфейс для виконання
певних завдань, таких як редагування відео, ультрафіолетове відображення або
текстурування, приховавши функції, які не використовуються для завдання.
Cycles — це механізм візуалізації з трасуванням шляху(рис. 2.5),
розроблений як інтерактивний і простий у використанні, але при цьому
підтримує багато функцій. Він був включений у Blender з 2011 року, з випуском
Blender 2.61. Cycles підтримують розширення AVX, AVX2 і AVX-512, а також
прискорення процесора в сучасному обладнанні.
Cycles підтримує візуалізацію GPU, яка використовується для
прискорення часу візуалізації. Є три режими візуалізації GPU: CUDA, який є
кращим методом для старих відеокарт Nvidia; OptiX, який використовує
апаратні можливості трасування променів архітектури Nvidia Turing і Ampere; і
OpenCL, який підтримує рендеринг на відеокартах AMD Radeon (з доданою
підтримкою Intel Iris і Xe у 2.92). Програмний набір інструментів, пов’язаний із
цими режимами візуалізації, не входить до складу Blender і потребує окремої
інсталяції та конфігурації відповідно до відповідних інструкцій джерела.
Також підтримуються кілька графічних процесорів, які можна
використовувати для створення ферми візуалізації, однак наявність кількох
графічних процесорів не збільшує доступну пам’ять, оскільки кожен графічний
 31

процесор може отримати доступ лише до своєї власної пам’яті. Починаючи з

версії 2.90, це обмеження SLI-карт було порушено завдяки NVlink Nvidia.
Metal API від Apple отримав свою початкову реалізацію в blender 3.1 для
комп’ютерів Apple з чіпами M1 і відеокартами AMD.
Тест Blender 3.2 демонструє великі переваги довготривалої підтримки
CUDA проти новішого API OptiX і абсолютно нового HIP для апаратного
забезпечення AMD. Деякі покращення продуктивності будуть доступні для HIP
і OptiX у Blender 3.3 і 3.4.

Рисунок 2.5 – рендер будинку за допомогою Cycles