Як правильно структурувати проєкт в Unity: що треба і не треба робити

Всім привіт! Мене звати Максим, я Unity Developer в Pingle Game Studio. У цій статті я хочу поговорити про структуру проєкту в Unity.

Добре структурований проєкт має ряд переваг. У першу чергу — зручність. Зручність для розробника, який його почав, для команди, яка буде підтримувати продукт через 3 роки, команди техартів, яким треба оптимізувати текстури під нову платформу, геймдизайнерам, що коригують баланс гри, та багатьом іншим людям, причетним до розробки. Тобто, якщо ви читаєте про структуру проєкту «як для програміста», зазвичай все зводиться до ООП, інтерфейсів, патернів та подібного. При розробці на Unity важливо усе, тому що саунд-дизайнер чи художник навряд оцінить красу коду — а ось те, що картинки та звуки розміщуються в логічному місті, а ієрархія на сцені дозволяє легко та без головного болю додавати чи заміняти контент, приймуть з радістю. Іншими словами, зручна структура веде до економії часу, грошей, та нервових клітин.

Що ми розуміємо під структурою проєкту? Я б виділив 3 розділи:

• Структура коду;
• Структура папок проєкту;
• Структура в ієрархії сцени.

І далі йдемо докладніше

Структура коду

Є базові поради та найголовніша з них...не тупити :) База тому і називається базою, що важко порекомендувати щось НЕ очевидне. Далі мої особисті поради:

• Завжди залишати коментарі. Це зараз зрозуміло, що зробити цим кодом. А через рік? А чи зрозуміють інші розробники?
• Не забувати про ООП та SOLID. Звісно бувають ситуації коли важко писати «чистий код». Але дотримання цих принципів надалі полегшить роботу над проєктом і зменшить вірогідність появи багів.
• GIT або інший репозиторій — це найкращий друг) За можливості треба робити коміти якнайчастіше. Якщо необхідно, використовувати різні гілки. Таким чином, можна побачити, як самі мислили та куди це привело код, і також як розмірковували інші. Наприклад, якщо щось зламалось у системі аутлайнів, хоча раніше вони працювали.

Але все це загальні поради, які підходять до майже будь-якої мови програмування. Тому перейдемо до більш специфічних для Unity. Що ж, почнемо з самого початку... з папок проєкту.

Папки проєкту

На початку проєкту зазвичай є лише ідея, у кращому випадку — ще хоч якийсь дизайн-документ. Тому, на перших етапах розробки, можна бачити творчий бедлам у проєкті. Папки створюються, змінюються, переносяться, перейменовуються і так далі. Звісно, цей хаос несе проблеми, які з’їдають час та нерви. Але з досвідом, кількома великими проєктами, та з десяток малих геймджем/інді-ігор позаду, формуються звички, корисні для старту нового проєкту. Серед них, наприклад, створення папок Images, Scripts, Scenes, Sound, Prefabs по дефолту. Більш того, картинка, яка показує, скільки залишилося здоров’я, не піде відразу до папки Images, її шлях має бути трошки складнішим, по типу Images/Character/UI/HPBar. Звісно, так само треба робити з іншими префабами проєкту.

Це все цікаво, але на біса воно нам треба? Ви звісно скажете «Добре, я не буду пхати усі файли у кореневу папку, та дійсно поділю скрипти окремо, а картинки окремо. Але нащо мені створювати 5-6 папок, одна в одній?» І ось тут ми й приходимо до основного питання необхідності архітектури. А точніше, що буде, якщо її ігнорувати. Це призведе до втрати інтуїтивності. Коли нова людина знайомиться з проєктом та хоче подивитись, як у ньому реалізована клієнт-серверна архітектура, звісно, вона полізе її шукати в окремій папці. Зазвичай, це не один файл, скоріш — низка файлів, де ми можемо бачити реалізації для клієнта, хоста, особливості стіма та окремі — для консолей.

Кажучи про коректне ведення папок, неможливо не згадати про неймінг. Звісно, тут працюють правила з неймінгом для назв у програмуванні. Назва повинна відображати те, чим являється файл і таке інше...Але це все в ідеальному світі. Існує проблема у великих проєктах: наприклад, є аватарки юнітів (припустимо, це 50 картинок розміром 34 на 34 пікселі). Вони знаходяться у папці Assets/Images/Units/MiniAvatar та пронумеровані 1, 2, 3...49, 50.

Це не складе великої проблеми для розробника, якщо цей номер прив’язаний до id юніта. Деякі навіть пишуть мініплагіни, де такий неймінг чудово підходить. Наприклад, автоматом заповнити скриптабл обджект, який буде своєрідною базою даних від 1 до 50. Та навіть вручну поставити не проблема. Але ось приклад з практики — приходить додаткова задача для техартів: юніту Gandalf повністю переробити три види зображень, анімацію, звук тощо. А юніта Saruman взагалі випиляти з гри, включаючи з баз даних.

На цьому моменті я бажаю розробнику везіння. І це пів біди, що витрачається час на пошук. Коли стане ясно, що Gandalf на мініаватарці йде під номером 18, то, звісно, з легкістю можна змінити звук юніта під номером 18. Звучить непогано, крім одного моменту: звуки, які зробила інша команда півтора року тому, були пронумеровані від 0 до 49. І те, що щось пішло не так, може виявитись через кілька днів, а то й на релізі. А це може вплинути на стартові оцінки, негативні коментарі, втрачені гроші. І лише через те, що ніхто не наполіг на НОРМАЛЬНИХ назвах. Наприклад, вбити у пошук Unity Gandalf, чи навіть використати додаткові фільтри, щоб мінімізувати людську помилку.

Неймінг допомагає оптимізувати пошук

Що ж, перейдемо до ще одного моменту, який хотів би освітити з цією темою. Зазвичай не має значення, яку назву має папка. Але існує ряд папок, назви яких зарезервовані рушієм. Наприклад, папка Resources. Її назва дуже логічна. Бачите, у чому справа: якщо потрібно, щоб при натисканні миші з’являвся об’єкт/префаб, можна просто помістити посилання на нього у скрипті, протягнувши, наприклад, з папки префабів. Тобто, після того, як зібрано білд, рушій бачить, що є посилання на цей об’єкт, а значить, його потрібно засунути у білд. Але все це можна зробити іншим шляхом. Цей об’єкт можна викликати з папки ресурсів командою Resources.Load<Sprite>("Sprites/sprite01«). Ефект буде той самий, він піде у білд, але не через те, що рушій бачить посилання на нього, а через те, що він буде у папці ресурсів. З одного боку, папка ресурсів дає гнучкість, динамічно змінює посилання через скрипт. З іншого, дуже легко зробити з неї «Сміттярку», забувши видалити зайві файли.

Повернемось до минулого прикладу. Ми видалили посилання на Saruman та в грі його ніколи не побачимо. Але забули знищити файли у папці ресурсів, тому усі арти з ним та аудіо файли, які там були, пішли у білд та займають місце. Як уникнути такого «сміття»? Насправді одночасно дуже легко, та дуже важко. Просто треба підтримувати архітектуру, що була запланована. Це знизить вірогідність проблем. Ось тільки якщо одночасно працює багато людей: програмісти, художники, звуковики, друга команда на аутсорсі — контролювати цей момент дуже важко.

Власне, перейдемо до сцени та її ієрархії.

Наприклад, неймінг об’єктів. Рушій сам дає дефолтні імена, та зазвичай прийнято їх перейменовувати. Інколи розробники не бачать у цьому сенсу. Для прикладу, бачимо здоров’я юніта. Складається з бекграунду, лінії та тексту. Так, є головний об’єкт, що має конкретну назву, а інші — дефолтні назви. Але, як з кодом, важко не створити об’єкт, важко його підтримувати. При задачі замінити зображення його ще потрібно знайти. Чи ось коли об’єкт складається з багатьох частин?

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

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

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

Хотілося б додати ще кілька порад:

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

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

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

Головне. Якщо доведеться працювати з кодом інших людей, чи буде їх архітектура ідеальною? Звісно, ні!) Але це не означає, що не треба прагнути до порядку у проєкті. Як вже казав, добра архітектура веде до економії часу та розуміння. Більш того, вірогідно, спеціаліст не займається архітектурою цілого проєкту, а лише малого префабу чи плагіну. Та навіть при цій тасці, скіл в архітектурі допоможе без зайвих нервів інтегрувати функціонал, змінювати у процесі розробки об’єкти так, щоб QA не прийшли з фразою «Максим/Сергій/Влад ти все зламав, учора все працювало!».

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини