Tworzenie gier z Astrą: Circuit Shift

Wynik: kompletna pętla rozgrywki w trzech pokojach

Circuit Shift to mała, odgórna gra logiczna zbudowana i przetestowana w Godot 4.5.1 na macOS. Prowadzisz kuriera CS-07 przez trzy pokoje stacji przekaźnikowych, zbierasz po trzy ogniwa energii w każdym pokoju, otwierasz ponumerowane bramy, unikasz ruchomych strażników i docierasz do wyjścia. Końcowy zautomatyzowany przebieg natywny ukończył wszystkie trzy pokoje, wykonał scenariusz przegranej i restartu oraz zapisał postęp kampanii i najlepsze czasy. Osobny proces pomyślnie otworzył ten zapis.

Najważniejszy wniosek dla projektu gry wspieranej przez AI to połączenie ograniczonego briefu, kontroli rozgrywki sterowanych przez silnik i inspekcji wizualnej. Prośba o małą, kompletną pętlę pozwoliła przetestować więcej niż ruch: wyjście musiało pozostać zamknięte przed zebraniem ogniw, ukończenie pokoju musiało odblokować kolejny sektor, a ustawienia musiały przetrwać ponowne uruchomienie. Pobieralny projekt pozwala samodzielnie sprawdzić te zachowania.

Początkowy brief uczynił ukończenie konkretnym

Zadanie określało oryginalną grę o nazwie Circuit Shift, trzy krótkie poziomy, fizykę silnika, przełączniki i bramy, zbierane ogniwa, wygraną/przegraną/restart, menu startowe, ustawienia i zapisany postęp. Wymagało również autentycznych zrzutów, miniprzebiegu rozgrywki w prawdziwym silniku i ponownego otwarcia zapisanego stanu. Godot 4.5.1 był już zainstalowany i został użyty ponownie; development rozpoczął się w nowym katalogu gry z osobnym tymczasowym HOME.

Poniższy fragment pochodzi z rzeczywistego briefu początkowego; dodano w nim podziały wierszy dla czytelności, zachowując oryginalne brzmienie. Pełny plik initial-prompt.txt znajduje się w ZIP-ie źródeł. Własny brief warto oprzeć na obserwowalnych kryteriach ukończenia: określ, co gracz może zrobić i co ma nadal działać po zamknięciu gry.

Task: build an original polished small 2D Godot game called Circuit Shift.
Three short levels; controllable character, enginephysics/collisions,
switches and gates, collectible cells, exit, win/loss/restart,
start menu, smallsettings and savedprogress.

Od promptu przez pliki i feedback silnika do działających pokoi

Agent stworzył dane pokoi, GDScript, menu, ustawienia, lokalne zapisy i harness rozgrywki, a następnie wielokrotnie uruchamiał silnik i sprawdzał wyniki. Ruch korzysta z CharacterBody2D.move_and_slide; ściany i bramy z StaticBody2D; ogniwa, zagrożenia i wyjścia z wyzwalaczy Area2D. Te kontrakty silnika łączą widoczny pokój z kolizjami i zmianami stanu, które harness może obserwować.

Rejestr zawiera 13 uruchomień silnika gry obejmujących import, rozgrywkę, kontrole regresji, natywne zrzuty, ponowne otwarcie, pakowanie i inspekcję pikseli. Sekwencja obejmowała początkową porażkę obecności sceny przed implementacją, rozgrywkę bez interfejsu, natywne zrzuty, ukierunkowaną poprawkę wizualną i końcowe kontrole artefaktów. Grafika gry została narysowana proceduralnie kodem CanvasItem Godot, a pięć efektów PCM syntezowano lokalnie. Zaobserwowana praca obejmowała patche autora agenta, lokalne polecenia, prośby o zgodę na natywne wykonanie i inspekcję zrzutów; nie zaobserwowano dalszego sterowania zadaniem przez człowieka ani ludzkiej naprawy kodu.

Rzeczywisty defekt: fokus klawiatury utrudniał odczyt przycisku

Pierwszy natywny przebieg rozgrywki przeszedł swoje asercje, ale inspekcja zrzutu ujawniła tekst o niskim kontraście na skupionym głównym przycisku. Miało to znaczenie, bo menu stacji obsługuje również nawigację klawiaturą: działająca akcja startu nie gwarantowała czytelności kontrolki startu. Ukierunkowana kontrola regresji zakończyła się następnie niepowodzeniem przy współczynniku kontrastu około 1.36:1.

Poprawka jawnie ustawiła font_focus_color na ciemny kolor pierwszego planu głównego przycisku. Następna kontrola zmierzyła około 10.57:1, a końcowy przebieg natywny zachował pozytywną asercję kontrastu. Surowe wyniki nieudanego i udanego przebiegu pozostają w katalogu dowodów. To konkretny powód, by łączyć testy rozgrywki z inspekcją skupionych i zaznaczonych stanów UI: przejścia stanów mogą działać poprawnie, podczas gdy kontrolki, które je ujawniają, nadal wymagają pracy.

Co faktycznie wykonały testy natywne

Końcowy miniprzebieg rozgrywki używał zwykłych akcji Godot Input i natywnych sygnałów Control; jedna kontrola mapowania wysłała InputEventKey. Kurier poruszał się dzięki fizyce silnika. Harness sprawdzał kolizję ze ścianą, blokowanie zamkniętej bramy, otwieranie i zamykanie przekaźników, wymóg wyjścia po zebraniu wszystkich ogniw, trzy wygrane pokoju, przegraną przez zagrożenie, restart, pauzę, ustawienia oraz wyzwalacze tworzenia i odtwarzania dźwięku. Nie teleportował gracza, nie przyznawał ogniw bezpośrednio ani nie ustawiał stanu wygranej.

Poniższe liczby to asercje wewnątrz tych przepływów, w tym waypointy i zrzuty, a nie niezależne zadania benchmarkowe. Wszystkie trzy końcowe przebiegi natywne zakończyły się pomyślnie z pustym stderr. Rozgrywka ze źródeł jest najszerszym testem; przebieg PCK potwierdza ładowanie pakietu i kontynuację zapisanego stanu, a nie drugą pełną kampanię w spakowanej grze.

Ponowne otwarcie sprawdziło trwałość i kompaktowy układ

Nowy proces natywny załadował unlocked=3, completed=true, trzy dodatnie najlepsze czasy, volume=0.35 i reduced_motion=true. Continue przeszedł do sektora trzeciego. Oddziela to trwałość od wartości, która po prostu pozostaje w pamięci podczas działania gry. Gra zapisuje postęp po ukończeniu pokoju, więc zamierzonym punktem wznowienia jest pokój, a nie ostatnia pozycja kuriera.

Przebieg kompaktowy dostarczył także drugiej kontroli układu: pokój, HUD, zegar i kontrolki pozostały w pełni ujęte w 720 x 540. Zrzuty desktopowe mają 1280 x 960. W końcowych przebiegach źródłowym i pakietowym dwanaście natywnych zrzutów przeszło próbkowanie niepustych pikseli, a inspekcja wizualna sprawdziła kadrowanie i czytelność. To autentyczne zrzuty natywnego viewportu; mniejszy obraz pokazuje kompaktowe okno desktopowe.

Czas i konfiguracja: jak czytać rejestr przebiegu

Żądany start nastąpił 5 września 2026 o 05:35:51 UTC; ukończenie zarejestrowano o 06:00:11.007 UTC. To 1,460.007 sekund, czyli około 24 minut 20 sekund upływającego czasu rzeczywistego. Obejmuje implementację, wykonanie narzędzi, testy, poprawki, zrzuty i pakowanie przy dostępnym silniku. Nie jest to opóźnienie odpowiedzi modelu ani prognoza czasu tworzenia innej gry. Jeden początkowy brief doprowadził do wielu iteracji implementacji i pracy narzędzi.

To przebieg Codex skonfigurowany z Astrą: koordynator zarejestrował spawn_agent.model=gpt-6-astra z reasoning_effort=xhigh. Potwierdza to wyłącznie żądaną konfigurację. Tożsamość modelu odpowiedzi API, użycie tokenów, koszt i liczba wywołań modelu/API nie były ujawnione i pozostają null w run-summary.json; nie zaobserwowano bezpośredniego żądania APIsRouter ani rozliczenia. Publiczne sprawdzenie katalogu 5 września również nie znalazło Astry w APIsRouter. Oficjalna dokumentacja modelu i ta lokalna konfiguracja nie potwierdzają dostępu przez gateway.

Pobierz i uruchom Circuit Shift w Godot

Pobierz ZIP kodu źródłowego, aby sprawdzić implementację, pełny brief, sterowanie, harness testowy i zachowane dowody. Wypakuj go, zaimportuj game/project.godot w Godot 4.5.1 i uruchom projekt. Poruszaj się klawiszami WASD lub strzałkami, aktywuj pobliski przekaźnik klawiszem E lub Space, restartuj przez R i wstrzymuj przez Escape. Zbierz wszystkie ogniwa, aby aktywować wyjście; kontakt ze strażnikiem kończy próbę.

Wersję spakowaną pobierz jako circuit-shift.pck i uruchom za pomocą zgodnego runtime Godot z użyciem poniższego polecenia. PCK wymaga Godot i nie jest samodzielnym plikiem wykonywalnym. Zweryfikowano integralność ZIP, równość krytycznych plików w archiwum, równość źródeł względem końcowego przebiegu natywnego oraz równość SHA-256 skopiowanych zasobów. PCK uruchomiono z tymczasowego katalogu poza projektem źródłowym. Linki do obu artefaktów, run-summary.json i manifest SHA-256 są wymienione poniżej.

godot --main-pack circuit-shift.pck

Do czego ten prototyp jest gotowy w następnym kroku

Następnym użytecznym krokiem jest ludzki test pętli trzech pokoi: czy nowy gracz rozumie numerację przekaźników, zauważa, dlaczego wyjście jest zamknięte, i potrafi wrócić po przegranej? W tym przypadku nie zebrano ludzkiego playtestu, testu odsłuchowego ani danych użycia prawdziwych użytkowników. Zautomatyzowane ukończenie i wygenerowane bufory audio potwierdzają ścieżki funkcjonalne, ale nie dowodzą przyjemności, balansu trudności, jakości dźwięku, retencji ani szerokiej użyteczności.

Windows, przeglądarka, Steam, dotyk i gamepad pozostają nieprzetestowane; szablony eksportu przeglądarkowego były lokalnie niedostępne. Przyspieszone przebiegi bez interfejsu nadal emitowały diagnostykę certyfikatów macOS i ostrzeżenia zamykania zasobów audio, choć końcowe logi natywne miały puste stderr. Przed wyborem celu wydania rozwiąż odpowiednie problemy wykonawcze i uruchom własne kontrole wejścia, zapisu, pakowania i wydajności dla tego celu. Praktycznym wynikiem jest inspekcjonowalny natywny prototyp i powtarzalny proces weryfikacji, który może pokierować następną rundą developmentu.

Częste pytania