Що таке Unity 3d

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

розроблений Unity Technologies. За допомогою даного движка можна розробляти не

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

Android), ігрових приставок і інших девайсів.

Поговоримо трохи про характеристики движка. По-перше, варто відзначити те, що в

середу розробки Unity інтегрований ігровий движок, іншими словами, ви можете

протестувати свою гру не виходячи з редактора. По-друге, Unity підтримує імпорт

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

самі моделі в більш зручному додатку, а Unity використовувати за прямим

призначенням - розробки продукту. По-третє, написання сценаріїв (скриптів)

здійснюється на найбільш популярних мовах програмування - C # і JavaScript [1].

Таким чином, Unity3d є актуальною платформою, за допомогою якої ви можете

створювати свої власні додатки і експортувати їх на різні пристрої, будь то

мобільний телефон або приставка Nintendo Wii.

Для того щоб створити свою гру, вам, як мінімум, потрібно володіти однією з

доступних (на Unity) мов програмування: C #, JavaScript або Boo.

Буде чудово, якщо ви володієте, наприклад, 3Ds max ом, це вам сильно допоможе

при створенні гри. Що стосується мене, то мені довелося освоїти 3Ds max на

базовому рівні, бо ніде не міг знайти потрібну мені модель будинку. У будь-якому

випадку вам знадобиться встановлений 3Ds max на вашому комп'ютері, якщо ви

збираєтеся імпортувати готові 3D моделі. Бо, в більшості своїй, необхідні моделі

мають формат проекту, тобто необхідно буде зарендеритити їх у відповідний для

Unity3d формат, наприклад, в * .3DS, і тільки після цього робити імпорт в Unity, в

іншому випадку останній видасть помилку.

Початок роботи

Колайдери

Що це таке - коллайдер? Колайдер - це область простору, при взаємодії з якою

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

підходите до автоматично відкриваються двері універмагу. За пару метрів від

дверей, спрацьовує датчик і двері розчиняються перед вами, але якщо ви пройдете за

три метри, то нічого не станеться. Як раз та зона, в якій діє датчик руху,

відповідальний за відкривання дверей, і є коллайдер. Ви входите в зону - двері

відкриваються, виходьте із зони - і датчик вже ніяк не реагуватиме на вашу

присутність. Точно так само і в грі.

Так от, про коллайдерах. Припустимо, ми імпортували в наш проект автомобіль і

хочемо згенерувати для нього коллайдер. Можна згенерувати автоматично

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

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

коллайдер. Це абсолютно не оптимально. Безумовно, нам не потрібно генерувати

таку велику кількість коллайдерів, достатньо обмежитися одним!

Оптимальна робота зі сценами

Поговоримо про оптимізацію сцен, про самих же сценах буде мова вестися далі.

Уявіть таку ситуацію: у нас є сцена «home» - коли гравець знаходиться в будівлі і

сцена «street» - коли гравець виходить з будівлі на вулицю. Природно, з другої сцени

ми можемо бачити будинок, тобто частину першої сцени, і навпаки (якщо, звичайно,

у будівлі є вікна). У такому випадку оптимальним є наступна побудова сцен. У

першій сцені все, що стосується вулиці (тобто того місця, куди ми не можемо

потрапити без переходу на іншу сцену) треба максимально спростити. Іншими

словами, нам потрібно залишити тільки зовнішній вигляд виду з вікна, а всю

начинку - розпатрати. Тобто всі колайдери видалити, дозвіл і тому подібне звести до

мінімуму. Дійсно, навіщо процесору напружуватися з обробкою тієї місцевості, яку

ми не можемо відвідати? Аналогічним чином поступаємо з другої сценою («street»).

В даному випадку ми можемо взагалі все видалити з дому і залишити тільки його

«коробку».

Ви хочете створити міні мапу? Будь ласка, тільки позбудьтеся всіх коллайдеров і

знизьте дозвіл, в такому випадку ваша гра буде оптимальна.

Саме таким чином робота зі сценами стає оптимальною. Ще раз зазначу, що це не

тонкощі, це серйозні речі, які вимагають уваги творця.

Сцени

Готова гра - це набір сцен, з'єднаних між собою (точно так само, як і життя - це набір

днів). Про оптимальне проектування гри ми зараз і поговоримо.

Перш ніж створити свій проект - подумайте, що він повинен в себе включати (які

сцени). Складіть список сцен (на листочку), обміркуйте, що кожна сцена буде в собі

містити. Тепер постарайтеся кожну сцену розбити на підсцени, чим більше їх буде,

тим легше буде вашому центральному процесору. Звичайно, не варто робити багато

сцен. Припустимо, що ваш гравець знаходиться в будівлі і з неї

ніколи не виходить, в будівлі є, наприклад, пару поверхів, дах, а на кожному поверсі

є три кімнати. В даному випадку, на мою думку, було б оптимально «розбити»

будівлю на дві сцени - два поверхи і дах. Дроблення ж кожного поверху на сцени з

кімнатами - не оптимальне. Це просто не потрібно, якщо кожна з кімнат слабо

завантажена. Іншими словами, треба грамотно витрачати пам'ять процесора, але і

забувати про отримання задоволення від гри теж не варто.

Налагодження

Пам'ятайте, що хороший творець повинен враховувати те, що його гра, або додаток,

буде використовуватися на різних платформах, а це означає, що свій контент

необхідно налагодити так, щоб він міг використовуватися на різних пристроях.

Найбільш очевидний і важливий момент налагодження - оптимізація програми під

різні дозволи екранів. Це важливий момент і творець гри обов'язково повинен

звернути на нього свою увагу, в іншому випадку, результатом своєї роботи зможе

бути задоволений тільки він один.

Структурування

При конструюванні гри важливо пам'ятати про структуруванні даних - важливому

аспекті. Мається на увазі, що все має бути на своєму місці. Створюєте скрипти? –

Створіть папку для скриптів, там і зберігайте їх, з великою ймовірністю, у вас буде

не один скрипт, розкидати їх по всьому проекту не є добре, самі потім будете

мучитися. З власного досвіду можу сказати, що вам точно знадобиться створити

папки зі скриптами, звуковими файлами, з GUI текстурами, матеріалами,

анімаціями, можливо, префабов і власними моделями (імпортовані з 3Ds Max'а

об'єкти краще зберігати саме в останній папці, щоб не розкидати всі моделі по

проекту в хаотичному порядку). Коли ви створюєте той чи інший скрипт, пам'ятайте

про те, що назва змінних, класів й іншого повинні говорити все самі за себе. Якщо

ви хочете створити скрипт для інвентарю (підняти предмет, використовувати

предмет), то краще все скрипти одноманітних дій (наприклад, підняття) починати з

ключового слова, наприклад: Catch <ім'я предмета>; Use <ім'я предмета>, в такому

випадку вам буде легше орієнтуватися в проекті, та й виглядає так набагато

симпатичніше.