Tworzenie gier z AI w Unity

Updated 2026-09-05

Użyj istniejącego projektu Unity, wprowadź jedną zmianę rozgrywki możliwą do przeglądu i przeprowadź ją przez kompilację, testy, grę oraz kompilację docelową.

Zacznij od kontraktu istniejącego projektu

Przed przyznaniem agentowi dostępu do zapisu zidentyfikuj wybrany edytor Unity, ścieżkę projektu, platformę docelową, pakiety i konfigurację renderowania. Zachowaj wersję projektu i blokady zależności w rejestrze eksperymentu. Potwierdź, że operator ma wymagany dostęp do edytora i modułów docelowych; dostęp do modelu nie zapewni tych warunków wstępnych.

Zdefiniuj jedną małą grywalną scenę zgodnie z konwencjami projektu. Jeśli zespół ma już kontroler postaci lub abstrakcję wejścia, poproś agenta o ich inspekcję przed zaproponowaniem zamiennika. Dzięki temu wygenerowane zmiany są możliwe do przeglądu, a pozornie odizolowany prototyp nie omija systemów, od których zależy reszta gry.

Zmiany gry możliwe do przeglądu przechodzą przez wykonanie silnika, pełną rozgrywkę i test eksportu docelowego.
Zastosuj tę samą pętlę akceptacji do istniejącego projektu Unity.

Traktuj automatyzację edytora jako osobne połączenie

Projekt Unity MCP firmy CoplayDev udostępnia operacje edytora zgodnym klientom. Jego przewodnik instalacji opisuje pakiet edytora i połączenie serwera. Usługa modelu agenta jest osobną zależnością: zmiana danych modelu nie naprawi niedostępnej instancji edytora.

Zacznij od inspekcji projektu tylko do odczytu i potwierdź, która otwarta instancja otrzymuje żądanie. Ogranicz zgody na mutacje do sceny tymczasowej lub jawnie posiadanej funkcji. Pomyślna odpowiedź narzędzia oznacza zakończenie operacji na jego własnej granicy; wynikowa scena może nadal mieć błędne referencje lub nie działać podczas gry. Dedykowany przewodnik MCP opisuje kontrole połączenia i zapisywanie wersji.

Proś o ograniczone zmiany z widocznymi wynikami

Po każdym niepowodzeniu proś o korektę kontrolera, jedno przejście menu lub małą funkcję trwałości, a nie o przepisanie całej sceny. Określ, co ma zrobić gracz, jaki stan powinien się zmienić i jak będzie obserwowany wynik. Zachowaj poprzedni działający stan przed zaakceptowaniem wygenerowanych modyfikacji.

Użyj poniższego przykładowego briefu do zdefiniowania ograniczonej zmiany i kryteriów przeglądu. W scenach i prefabach sprawdzaj referencje obiektów i zapisany stan obok diffów skryptów; sam plik źródłowy może nie zawierać konfiguracji decydującej o rozgrywce. Przed edycją poproś agenta o wskazanie dotkniętych obiektów.

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

Poczekaj na kompilację przed interpretacją wyników gry

W dzienniku obserwacji rozdziel kompilację kodu, gotowość edytora i rozgrywkę. Jeśli kompilacja zawiedzie, przechwyć najwcześniejszy istotny błąd oraz kontekst zmienionego źródła. Nie proś o strojenie ruchu, gdy edytor nie może załadować właściwych skryptów; spowoduje to dodatkowe zmiany na nieprawidłowej bazie.

Po kompilacji sprawdź oczekiwane komponenty i referencje przed wejściem do gry. Po poprawce odtwórz tę samą akcję gracza. Konsola bez błędów jest użytecznym dowodem, ale gra nadal musi osiągnąć zamierzony stan. Powtarzające się zmiany, które nie zmieniają objawu, powinny uruchomić mniejszą reprodukcję, a nie większą wymianę.

Świadomie używaj frameworka testów projektu

Unity Test Framework dokumentuje wybór testów z wiersza poleceń i wyjście wyników. Przykład zakłada, że framework jest już skonfigurowany, a katalog wyników istnieje. UNITY_BIN i PROJECT to przykładowe zmienne shell wskazujące istniejący edytor i projekt. Dopasuj dokumentację referencyjną do zainstalowanej wersji pakietu.

Uruchamiaj kontrole EditMode dla właściwej izolowanej logiki, a PlayMode dla zachowania wymagającego wykonania. Kategorie te nie zastępują praktycznego przeglądu sterowania i prezentacji. Zachowaj liczbę testów, błędy i pliki wyników przy testowanej rewizji. Przebieg, który nie wykryje żadnych testów, nie dowodzi, że gra je zalicza.

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

Sprawdź wejścia budowania przed utworzeniem gracza

Budowanie powinno używać przejrzanej selekcji scen i konfiguracji docelowej projektu. Nie zakładaj, że scena aktualnie otwarta w edytorze zostanie dołączona przy starcie. Zachowaj tożsamość budowania i logi, aby późniejsze awarie dało się przypisać dokładnemu artefaktowi.

CLI Unity obsługuje wywołanie istniejącej statycznej metody edytora przez -executeMethod. Ta flaga nie tworzy implementacji budowania: projekt musi zawierać prawdziwą metodę z jawnym zachowaniem budowania i obsługą awarii. Preferuj istniejący punkt wejścia budowania zespołu zamiast wymyślonych metod przykładowych, które wyglądają na uruchamialne, ale nie istnieją w projekcie.

Waliduj rozgrywkę poza edytorem

Przetestuj dostarczonego gracza w zadeklarowanym systemie operacyjnym, z oczekiwanym sterowaniem i czystym stanem początkowym. Wejdź z pierwszego ekranu, ukończ rundę, zrestartuj, zmień ustawienia i uruchom ponownie. Porównaj trwałość i przejścia z briefem akceptacji, zamiast sprawdzać tylko, czy otwiera się okno.

Zapisz autentyczne zrzuty i krótką sekwencję sterowaną wejściem z tego artefaktu. Jeśli gra w edytorze działa, a kompilacja nie, sprawdź dołączenie scen, zależności zasobów i zachowanie platformowe, zanim poprosisz agenta o przepisanie głównej rozgrywki. Zmieniona granica jest użyteczną wskazówką przyczyny.

Śledź pracę człowieka i nierozwiązane zależności

W rejestrze interwencji zachowaj ręczne zmiany inspektora, edycje zasobów, dodane instrukcje i naprawy środowiska. Są częścią wysiłku produkcyjnego, nawet jeśli nie generują użycia modelu. Przy ocenie kosztu odróżnij wywołania kodowania tekstowego od generowania obrazów, pracy silnika i testów urządzenia docelowego.

Ten oparty na dokumentacji przewodnik należy zweryfikować dla wybranych wersji edytora i pakietów. W przekazaniu zachowaj najmniejszy kompletny proces: połączenie, zmianę, kompilację, grę i eksport. Gdy inny deweloper będzie mógł go powtórzyć, użyj tej bazy dla kolejnej funkcji i wracaj do kontroli po każdej zmianie zależności lub celu budowania.

Częste pytania

Czy Unity MCP wybiera mój model?

Nie. Zapewnia połączenie narzędzi z edytorem. Klient agenta osobno określa dostęp do modelu i uwierzytelnianie.

Czy testy z wiersza poleceń mogą zastąpić przegląd rozgrywki?

Obejmują testy faktycznie wykryte i wykonane. Sterowanie gracza, czytelność wizualna i zachowanie na platformie docelowej nadal wymagają właściwych kontroli czasu działania.

Dlaczego nie podać uniwersalnego polecenia budowania?

Budowania zależą od scen projektu, ustawień celu i dostępnych punktów wejścia. Wymyślony cel executeMethod nie sprawiłby, że przykład byłby uruchamialny.

Czy mogę użyć konfiguracji Unity dla innej wersji edytora?

Ponownie sprawdź zgodność pakietów i zachowaj poprzedni działający stan. Aktualizacja zmienia środowisko eksperymentu i wymaga własnej weryfikacji.

Co sprawdzić, gdy gra w edytorze działa, a kompilacja nie?

Porównaj wybór sceny startowej, spakowane zasoby, konfigurację celu i logi platformy. Odtwórz tę samą akcję gracza w dokładnie wyeksportowanym artefakcie.