Tworzenie gier z AI w Godot

Zdefiniuj granicę projektu przed edycją

Zacznij od posiadanego katalogu projektu i pisemnej listy dozwolonych zmian. Zrób inwentaryzację istniejących scen, skryptów, zasobów i pluginów, aby agent rozszerzał bieżącą strukturę zamiast tworzyć drugą implementację. Zachowaj możliwość odtworzenia stanu początkowego i zapisz, który binarny plik silnika go otwiera.

Wybierz skromny grywalny wycinek z jawnymi przejściami. Na przykład ekran tytułowy prowadzący do jednego pokoju i z powrotem przez wygraną lub przegraną daje powtarzalny test. Ustal, kto sprawdza kompozycję wizualną i sterowanie, ponieważ ani poprawne parsowanie, ani komunikat ukończenia modelu nie dowodzą spójności doświadczenia.

Zidentyfikuj plik wykonywalny i obsługiwane argumenty

Stabilna dokumentacja CLI Godot dostarcza poniższych poleceń. GODOT_BIN i PROJECT to zmienne shell wybrane dla przykładu, a nie ustawienia Godot; zastąp ścieżki zastępcze istniejącym plikiem wykonywalnym i projektem. Ścieżka projektu musi zawierać project.godot.

Przed skryptowaniem dodatkowych flag zapisz wersję i wyjście pomocy. Unikniesz założenia, że polecenie dostępne w aktualnej dokumentacji online istnieje w zainstalowanej kompilacji. Zapisz tożsamość pliku binarnego razem z późniejszymi wynikami testów i utrzymuj ją stabilną podczas badania awarii. Te przykładowe polecenia używają udokumentowanych form CLI.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

Oddziel import, parsowanie i prawdziwą rozgrywkę

Import bez interfejsu sprawdza granicę przetwarzania zasobów. Kontrola parsera bada skrypt. Zwykłe uruchomienie dociera do gry i może ujawnić problemy z połączeniem scen oraz problemy czasu działania. Trzymaj te wyniki osobno w rejestrze przeglądu, zamiast podsumowywać je jako zaliczone testy.

Przykładowa ścieżka skryptu poniżej musi już istnieć w projekcie. Kontrola parsera jest celowo wąska: nie potwierdza działających kolizji, responsywnego wejścia ani poprawnej trwałości. Po edycji odtwórz zmieniane zachowanie oraz przejście bezpośrednio przed nim i po nim. Często daje to więcej informacji niż tworzenie wielu izolowanych kontroli wygenerowanych funkcji pomocniczych.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

Świadomie wybierz narzędzia CLI albo MCP

Agent z dostępem do shella może obsłużyć przejrzaną sekwencję CLI. Godot MCP to dodatkowy interfejs narzędzi utrzymywany przez projekt, którego konfigurację opisano na osobnej stronie. W obu przypadkach operator powinien znać docelowy projekt przed zatwierdzeniem zapisu lub uruchomienia procesu.

Ustawienia dostawcy modelu agenta trzymaj osobno od narzędzi silnika. Działające połączenie lokalne nie potwierdza dostępności konkretnego modelu ani obsługi każdej funkcji zgodnego gatewaya. Najpierw ustanów najmniejszy dozwolony odczyt, następnie odwracalną zmianę sceny, a dopiero potem pełny cykl rozgrywki w autoryzowanym eksperymencie.

Daj awariom wystarczający kontekst sceny

Gdy interakcja zawiedzie, przechwyć odpowiednie drzewo sceny, skrypt, akcję wejścia i pierwszy istotny błąd czasu działania. Wyjaśnij oczekiwane przejście i zaobserwowany stan. Raport o niemożności poruszania się gracza powinien wskazywać, czy gra ma fokus, czy wykryto wejście i czy zmienia się pozycja gracza.

Wymagaj niewielkiej proponowanej poprawki z wyjaśnieniem związanym z tym dowodem. Po zastosowaniu powtórz tę samą akcję i sprawdź regresje restartu oraz przejść scen. Nie akceptuj poprawki tylko dlatego, że błąd zniknął; wyłączenie funkcji może usunąć błąd, pozostawiając pierwotne wymaganie niespełnione.

Jawnie przygotuj wymagania eksportu

Eksport wymaga zgodnego presetu i zainstalowanych szablonów eksportu. Przed budowaniem przejrzyj export_presets.cfg i uwzględnianie zasobów. Dane uwierzytelniające eksportu zachowaj prywatnie. Nazwa presetu w przykładzie jest ilustracyjna i musi pasować do projektu; katalog wyjściowy musi już istnieć.

Brakujący szablon lub preset traktuj jako problem środowiska, nie dowód błędu wygenerowanej logiki gry. Zachowaj logi eksportu i hash artefaktu, aby ustalenia dotyczące platformy odnosiły się do konkretnej kompilacji. Udany eksport jest ważnym punktem kontrolnym, ale nie dowodzi, że dostarczony gracz uruchomi się lub ukończy rundę.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

Uruchom miniprzebieg dostarczenia na celu

Uruchom wyeksportowaną grę w systemie operacyjnym, który zamierzasz obsługiwać. Sprawdź start, wejście, pełną rundę, restart, ustawienia i trwałość po ponownym uruchomieniu. Dla każdego wyniku zachowaj tożsamość artefaktu, kontekst urządzenia i obserwowany rezultat. Eksport utworzony na macOS sam nie weryfikuje zachowania Windows.

Dla celu webowego sprawdź także ładowanie przeglądarki i błędy czasu działania oraz użyj prawdziwego wejścia na canvasie. Zweryfikuj docelową konfigurację hostingu, zamiast zakładać, że uruchomienie w lokalnym edytorze obejmuje ładowanie zasobów przeglądarki i ograniczenia platformy.

Projekt źródłowy i natywne ujęcie do inspekcji

Lokalny przykład Switchyard zawiera trzy-pokojową łamigłówkę Godot, automatyczne kontrole rozgrywki, kontrole zapisu i ponownego otwarcia, surowe logi, ZIP źródeł i PCK Godot. Jego natywne ujęcia pokazują faktycznie działający projekt w dwóch rozmiarach viewportu. Powtórzenie udokumentowanych poleceń jest silniejszą kontrolą niż ocenianie projektu wyłącznie na podstawie zrzutu.

Projekt używał Godot 4.5.1 w przebiegu Codex, którego dokładny model generowania nie został zweryfikowany. Pokazuje więc lokalny proces silnika, a nie benchmark Astra. Eksport przeglądarkowy był zablokowany przez brak szablonów eksportu, a PCK nie jest samodzielnym plikiem wykonywalnym Windows. Te granice zapisano wraz ze źródłami, aby kolejny deweloper wiedział, co pozostało do sprawdzenia.

Zamknij pętlę przekazaniem możliwym do przeglądu

Przekazanie powinno wymieniać grywalny zakres, tożsamość źródeł, wersje silnika i szablonów, instrukcje budowania, zaakceptowane wyniki i nierozwiązane defekty. Dołącz autentyczne ujęcia przetestowanego artefaktu i pochodzenie dostarczanych zasobów. Zachowaj próby naprawy oraz ręczne interwencje, zamiast przedstawiać tylko końcowy zrzut wygenerowanego kodu.

Po zaakceptowaniu podstawowej pętli dodaj zasoby i lokalizację przez ich własne kontrole importu i rozgrywki, zanim rozważysz wysłanie na platformę. Ten przewodnik opiera się na dokumentacji silnika; zastosuj go do zainstalowanej wersji i zachowaj rzeczywiste wyniki. Prowadź krótką listę nierozwiązanych problemów z krokami odtworzenia, aby następna sesja zaczynała się od tego samego znanego stanu.

Częste pytania