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

Уся моя розробка Fading Lexicon почалась з назви проекту «animation test» де я пробував спершу зробити гарні анімації particles, а далі — промені слави туман в голові і оце я вже запускаю проект на цій архаічній системі. А в грудні запрацював Google Antigravity і я постійно шкодував, що не використовував його початково. Ну що-ж прийшов час міграції і зробити все по справжньому.

Модель у використанні — Gemini 3.1

Підготовка до міграції: створюємо базу знань

Спершу — глобальні настанови Google Antigravity, а саме як правильно кодити. Налаштування через три крапки праворуч > Advanced Options > Customization.

Готовий файл, що використовую: gitlab.com/...​/blob/main/rules-unity.md

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

1. README.md: Описує візію, основні механіки та критерії готовності.

2. ARCHITECTURE.md: Правила організації коду, менеджмент залежностей та принципи комунікації між об’єктами. Це запобігає появі спагеті-коду в майбутньому.

3. SPECS.md: Технічні специфікації фіч, моделі даних та машини станів. Це живий документ, на основі якого генеруються скрипти.

4. CONTEXT_WINDOW.md: Журнал прийнятих рішень. Тут фіксуються архітектурні вибори та відомі помилки, щоб не наступати на ті самі граблі двічі.

Готовий промпт що використав:

Overview the sctipts and create following files:

Project Blueprint (README.md)

This is the entry point. It defines the high-level vision, core mechanics, and the «Definition of Done.»

Purpose: To give the AI context on the overall goal.

Key Sections: Project Pitch, Core Loop, Target Platform, and Key Constraints.

System Architecture Guide (ARCHITECTURE.md)

This defines how your Unity code is organized. Since Unity can easily become «spaghetti code,» this document prevents the AI from suggesting conflicting patterns.

Purpose: To enforce coding standards and structural patterns.

Key Sections: Dependency Management (e.g., Zenject/Extenject vs. ScriptableObjects), Communication Patterns (Events vs. Interfaces), and Folder Structure.

The Technical Specs (SPECS.md)

A living document where you detail specific features before they are coded.

Purpose: To serve as the prompt-basis for generating actual C# scripts.

Key Sections: Data Models, State Machine logic, and API signatures.

The «Memory» Log (CONTEXT_WINDOW.md)

In a long-term project, AI «forgets» why certain decisions were made.

Purpose: To track major architectural shifts or «known bugs» that shouldn’t be reintroduced.

Key Sections: Revision History, Integration Notes, and Resolved Logic Conflicts.

Стратегія міграції

Маючи такі файли одразу стало зрозуміліше що й до чого, проте, як бути власне з міграцією? Нехай думає ШІ, у нього голова велика:

How do I proceed with the migration over Antigravity? Should I move existing scripts into new project and name them scripts_v1 then direct agent to review them and form a new according to those practices?

Так і сталось, звичайно тут було більше тексту:

Zero Guesswork: Because I have the _Legacy_V1 folder, I won’t hallucinate API endpoint URLs or JSON structures. I can use my view_file and grep_search tools to read exactly how you did it in V1

Такий підхід має дві великі переваги:

— Відсутність вгадування: ШІ бачить оригінальну логіку, тому не помиляється в структурах даних чи API.

— Чистий код, industry standard, best practices...

Ну і звичайно, використовується чистий мапінгу файлової системи за принципом Feature-Based Unity mapping:

Assets/
  ├── Core/                  # Fundamental Singletons, GUEManager, API Client, Event Bus
  │   ├── StateMachines/
  │   └── Network/
  ├── Features/              # Distinct game silos
  │   ├── CombatQuiz/        # Combat math, Quiz managers, Action resolution
  │   ├── Flashcards/        # Interactive card logic, text formatting rules
  │   ├── Questing/          # Overworld nodes, Progression unlocking, Map UI
  │   └── Inventory/         # Potions usage bounds, Server syncs for item consumption
  ├── DataModels/            # Shared DTOs, Enums, Server Return Interfaces
  ├── UIFramework/           # Base UI tools, Navigators, View abstract classes
  │   ├── Master/            # Overlay Canvases, Loading Screens
  │   └── Popups/            # Reusable Dialogue, Settings UI
  ├── Utils/                 # Extensions, JSON parsers, Math helpers
  └── ThirdParty/            # SDKs, external assets

Поїхали в новий проект!

Створив новий проект, геть порожній, переписав згенеровані .md файли та старі скрипти у __v1 .

Маючи оці декілька файлів README.md, ARCHITECTURE.md , CONTEXT_WINDOW.md — запінив (pin!) їх у головному вікні Antigravity щоб ШІ постійно їх перечитував.

Також отримав migrate.md документ де ШІ було логічно прописано кроки, які необхідно зробити саме для міграції, а також — декілька задач (Epic!) оскільки весь проект за один прохід точно не змігрувати, контексту не вистачить.

• Epic 1: Scaffold & The GUEManager Foundation (Core logic machines and DTO definitions)
• Epic 2: Player Profile & Meta-Progression (Handling Avatar fetching and Dashboard state sync)
• Epic 3: Game Mechanics & The QuestManager (Mapping V1 node progressions alongside the scrollview constraints)
• Epic 4: Combat & Flashcards (Decoupling parsing features and enemy HP/Mana combat isolated states)
• Epic 5: Polish & API Offloading (Implementing asynchronous tracking events like «Initiate and forget» callbacks seamlessly).

І знаєте, так воно й сталось!

По часу — планування й підготовка, орієнтовно 5 годин (день 1, щоб переспати з думками).

День 2 — сама міграція 2 години зі створенням основних плейсхолдерів сцен (без наповнення). Ще тиждень займе правки UI та красивості.

Результати та контроль версій

З контролем версій усе стандартно: зв’язка Git-клієнта та репозиторію на GitLab. Плюс правильний .gitignore куди включено:

# Custom ignore for downloadabale assets. Name them with double underscore in main directory or Assets/__anything directory
/__*
/[Aa]ssets/__*

Як все працюватиме зараз

А зараз робочий процес виглядає так: з’являється ідея — створюється новий епік — ШІ виконує завдання — тестування — git push to main branch (навіщо ускладнювати, якщо я один).

Головний висновок: використовуйте ШІ для керування роботою ШІ! ;)

І жодного разу не написав словосполучення-що-не-можна-називати!

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