Вибуховою GameDev. Історія створення моєї гри

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

Про ідеї
Найцікавіша частина історії полягає в тому, що початкова ідея абсолютно не збіглася з підсумкової реалізацією. Чому? Та все просто. Спочатку в мене була ідея створення головоломки з використанням машини Тюрінга.

Щоб було зрозуміліше, напишу приклад. Уявімо, що у нас є трохи всіх набридлі Angry birds. Механіка гри проста, ми беремо птицю, націлюємо її на свиню і запускаємо. А тепер приробимо сюди машину Тюрінга. Приміром, внизу екрану є меню, що відбиває порядок дій. Ми не просто запускаємо птицю, а пишемо в чергу дій, з якою швидкістю і під яким кутом запускаємо її. При цьому рівень буде пройдено, коли всі дії будуть виконані правильно.



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

Після цього, в один прекрасний момент я переграв у fruit slice, після чого зайшов у unity і зробив так, щоб наявні у мене ящики просто вилітали з усіх боків. Загалом, хвилин 10 я спостерігав за цією картинкою…

Так і сформувалася кінцева ідея.

Однак ми всі знаємо, що написати чистий клон гри не достатньо, щоб зуміти її просунути. Ідея додати в гру фрукти була вислана терміновим рейсом з усіма своїми валізами відразу, як тільки вона з'явилася. Ідея розрізати ящики навпіл була відправлена туди-ж. Мені потрібні були вибухи! Яскраві картинки повинні залучати користувачів. Але ідея просто підривати ящики і отримувати за це окуляри вважалася мінімум недоробленою до свого ідеалу. Щоб в гру було дійсно цікаво грати, після вибуху ящика має щось відбуватися. Крім того, було б цікаво, якби час від часу діяли якісь події, дув вітер або зникала гравітація.

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

Тепер саме час розглянути варіанти реалізації всього того, що я написав вище.

Про гру
Самий перший розроблений концепт виглядав так:



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

Наступна версія гри виглядала ось так:



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

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

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

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

Дерево умінь.

Пізніше було додано дерево умінь. Ось скрін:



Скрін дерева умінь взяв в одній з останніх збірок ігри, раніше воно виглядало по-іншому.
На мою скромну думку – ігри з деревом умінь живуть довше ігор без нього.
Загалом, ігровий процес вийшов досить оригінальний. У назві гри виявилося все простіше. Наприклад: є гра fruit slice. Що там треба робити? Різати фрукти, звичайно! Є моя гра, в якій потрібно підривати все, що є на екрані. звідси і назва — Explode It!

З ідеєю закінчили, приступимо до цікавих моментів, які виникли у міру реалізації.

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

Гра створювалася на Unity. На мій погляд – це один з кращих, якщо не просто кращий. У движка є величезна кількість плюсів. Він простий в освоєнні, він багатоплатформовий, у движка є величезна працює екосистема, яка включає в себе форум, assetstore і багато чого іншого.

Ну і найголовніше – він безкоштовний. Зараз, наскільки я знаю, існують такі речі, як unreal engine 4 і source 2, які теж зробили безкоштовними, але коли я починав знайомство з темою, ці движки ще не були випущені, так що вибір був очевидний.

UI
От не подобається мені стандартний UI в Unity. Повільний, можливостей мало, прив'язки до сторін екрану немає (зараз, наскільки я знаю, є). Основна його проблема – финкция OnGUI, яка може спрацьовувати декілька разів за кадр, що для мобільних пристроїв неприйнятно.

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

NGUI
Принцип роботи NGUI наступний: всі GUI-елементи є простими об'єктами, що мають свій матеріал і без проблем відмальовує навіть мобільниками без шкоди продуктивності. Тут виникає один момент: Доводиться виводити окремі функції для обробки подій, таких, як натискання на кнопку і їй подібні.
NGUI платний. При купівлі у assetstore остання версія коштує 95$ і вимагає наявність Unity версії 4.5.5 і вище. Однак, хто шукає, той завжди знайде. NGUI поширюється безкоштовно, більш того, він розповсюджується безкоштовно на офіційному сайті, посилання от: www.tasharen.com/forum/index.php?topic=526.0 Також його можна знайти на офіційному форумі Unity: forum.unity3d.com/threads/ngui-free-edition.124032

В кінці посту написана одна важлива деталь: «У чому підступ? NGUI 2 застарів у вересні 2013 в момент виходу NGUI 3. Це попередня версія, в якій немає новітніх особливостей, присутніх у третій версії. Більш того, в ній відсутня саппорт. Є ще одне обмеження, яке накладається на комерційне використання цієї версії. Вона потрапляє під умови комерційного використання Unity Free. Free версія Unity не може бути ліцензована для комерційного використання, у тому випадку, якщо загальний дохід вашої організації не перевищує 100000 доларів США (за підсумками попереднього фінансового року)».

Англійський оригінал читайте під спойлером:

Оригінал“what's the catch? NGUI 2 has been deprecated in September 2013 when NGUI 3 came out, so it's an older version that won't have all the latest features and optimizations of the current one. It also doesn't come with support. The last restriction is that if used for commercial purposes, it falls under the same restrictions as Unity Free: «free version may not be licensed by a commercial entity with annual gross revenues (based on fiscal year) in excess of US$100,000.

Посилання на FAQ (LICENSING & ACTIVATION) Unity: unity3d.com/unity/faq

Загалом, я поки можу користуватися цією версією.

Основний плюс цієї UI системи в тому, що ми можемо здійснювати прив'язку до різних сторонах екрану, що дозволяє створювати функціональні інтерфейси. Більш того, всі об'єкти інтерфейсу міститися в одному атласі. Атлас – це така величезна текстура, яка містить в собі всі елементи інтерфейсу. Наприклад, текстуру шрифту, кнопок, іконок і всього іншого. На мобільних пристроях бажано обмежувати розмір такої текстури до 2048/2048 з метою оптимізації.

Взагалі, я зараз не буду описувати всі особливості NGUI, на хабре є чудова стаття (спеціально для початківців), в якій вже описана частина його особливостей, посилання: habrahabr.ru/post/211536

Приклад інтерфейсу, написаного на NGUI:



Update vs coroutines
Ще одне питання, що виник у міру розробки проекту, як можна ефективно розраховувати час. Раніше я це справи у функції Update, але тут є одна проблема. Ця функція спрацьовує кожен кадр. Якщо у грі 60 fps, вона спрацює 60 разів в секунду. Для телефонів наявність кількох таких функцій на сцені буде убивчим ударом по продуктивності. Бажано скорочувати кількість виклику цієї функції, або заміняти функцію іншим варіантом.
Хороший приклад розв'язання такої задачі – співпрограми.

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

Це можна зробити двома способами.

За допомогою функції Update, ми повинні нарощувати змінну, подсчитывающую час на величину Time.deltatime.

float currentTimer = 0;
void Update() {
currentTimer += Time.deltaTime;
if (currentTimer >= 1){
//Ваше дію
currentTimer = 0;
}
}

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

Приклад:

IEnumerator Example() {
while(true){
yield return new WaitForSeconds(1);
//Ваше дію 
}
}


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

Якщо з IOs тут все більш-менш зрозуміло, то з Android виникають питання.

Спочатку вся візуальна частина гри підлаштовувалася під дозвіл 16:10.

Щодо наявних дозволів взагалі: тут можна подивитися приблизну(!) таблицю використовуються дозволів екранів на платформі Android: geektimes.ru/post/169141

Ось таблиця дозволів екрану для планшетів:



Також таблиця з дозволами екранів для телефонів:



Після всіх тестів єдиною проблемою залишалася подладка під дозвіл 4:3.

Була пара способів виправити ситуацію:
  • Залишити картинку такою, якою вона є для всіх співвідношень екрану. У коді картинки не міняти, просто подладить в редакторі. Нормальне рішення, якщо немає часу робити окрему збірку під кожне співвідношення і писати купу скриптів, в яких доведеться змінювати початковий розмір картинок.
    Плюси методу: не треба писати ніяких скриптів і робити кілька збірок під різні співвідношення. Чиста економія часу.
    Тут є один мінус. Припустимо, що ми зробили так, що вся картинка поміщається на екран при співвідношенні 4:3 (зазвичай саме на екранах з цим співвідношенням у landscape орієнтації картинка вилазить за краю екрану), однак будемо вважати, що нам вдалося. При цьому гра на співвідношенні сторін 16:10 буде виглядати ще нормально, 16:9 яскраво виражені невикористовувані області з боків.
  • Змінювати розмір зображень в залежності від співвідношення. Я так робив у сцені, що відповідає за дерево умінь. Але взагалі, якщо у вас дефіцит часу – спосіб може здатися не найкращою. Занадто багато всього доводиться міняти. Не тільки окремі текстури, але ще і сам текст (який теж вилазив за екран) і багато чого іншого.
  • Змінювати розмір камери. Спосіб людини, який явно націлився зловити халяву. Він майже ніколи не допомагає, тому що змінюється не тільки ширина камери (мене цікавили невикористовувані області праворуч), але і висота камери, що логічно. Також це не допоможе, якщо ви використовуєте NGUI, і у вас на сцені є скрипт IUDraggablePanel, що відповідає за прокручиваемое меню.
В загальному відразу скажу, що я використовував перший варіант, вийшов приблизно ось такий результат.
4:3


3:2


5:3


16:9


16:10


Як видно з картинок вище, при вирішенні 4:3 меню займає майже весь екран, а ось при вирішенні, наприклад, 16:9 стають видні невикористовувані області з боків.

У дереві умінь не погано допоміг другий варіант, спочатку прокручиваемое меню заїжджало під кнопки, пізніше став редагувати його в момент завантаження рівня.

Тим не менш, вважаю, що з проблемою на своєму рівні впорався.

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

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

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

Старий варіант:



Новий варіант:



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

Старий варіант:



Новий варіант:



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

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.