Tworzenie gier z AI

Zacznij od kompletnej, małej pętli gry

Dobrym pierwszym celem jest pojedyncza aktywność z obserwowalnym początkiem i końcem: rozpocznij rundę, poruszaj się lub dokonaj wyboru, napotkaj wyzwanie, osiągnij wygraną albo przegraną i uruchom ponownie. Zanim poprosisz agenta o zapisanie plików, określ, co gracz widzi przy każdej zmianie. Dopracowany ekran tytułowy nie dowodzi, że pętla działa.

Wybierz jedną platformę docelową i niewielki zestaw urządzeń wejściowych. Dodatkowe poziomy, sieć i treści proceduralne potraktuj jako późniejszy zakres. Dzięki temu nieudany prototyp można zdiagnozować: odróżnisz zepsutą regułę kolizji od niedokończonej funkcji, zamiast stale rozszerzać prompt.

Najpierw wybierz proces, potem silnik

W przypadku małego, oryginalnego projektu 2D zacznij od oceny udokumentowanej CLI Godot w cyklu inspekcja–edycja–uruchomienie. Unity jest dobrym punktem wyjścia, gdy istniejący projekt lub zespół już zależy od jego pracy w edytorze. Możliwość utrzymania wyniku powinna wpływać na wybór równie mocno jak pierwszy prototyp.

Porównaj pracę potrzebną do odtworzenia awarii na własnym komputerze. Najlepszy punkt startowy to ten, którego strukturę projektu, wymagania budowania i błędy potrafisz wyjaśnić. Agent nie usuwa odpowiedzialności za aktualizacje silnika ani pakiety firm trzecich.

Oddziel dostęp do modelu od narzędzi silnika

Agent ma dwa różne połączenia: usługę modelu, która tworzy rozumowanie i edycje, oraz lokalne narzędzia do inspekcji i obsługi projektu. Godot MCP i Unity MCP należą do strony narzędzi. Instalacja któregoś z nich nie wybiera dostawcy modelu ani nie dowodzi integracji z gatewayem.

Wybierz połączenie modelu w kliencie agenta, a połączenie silnika w ustawieniach narzędzi. Zweryfikuj każde niezależnie małą operacją. Gdy lokalna ścieżka projektu jest błędna, popraw tę ścieżkę; zmiana endpointu modelu nie sprawi, że pojawi się właściwa scena.

Spraw, by pierwszy brief można było przetestować

Wymień wymagane sceny, działania gracza, przejścia stanów i zachowanie trwałości. Poproś o najmniejszą implementację spełniającą te wymagania oraz wyraźną listę nierozstrzygniętych decyzji. Użyj poniższego przykładowego briefu jako punktu wyjścia i zastąp jego zakres grą, którą naprawdę chcesz stworzyć.

Zapisz pierwszy brief bez zmian. Nowe wymaganie oznacz jako zmianę zakresu. Wyjaśnienie awarii lub samodzielną edycję pliku oznacz jako interwencję. Zachowuje to różnicę między jednym promptem początkowym a wieloma późniejszymi iteracjami modelu i narzędzi.

Deliver one original 2D room with start, play, win/loss, and restart states.
Use project-owned placeholder art. Preserve the chosen engine version.
Record each edit, tool result, failed check, and human intervention.
Stop before downloads, purchases, uploads, or publishing.
Report unfinished requirements with their reproduction steps.

Pracuj w zmianach łatwych do przeglądu

Po początkowym szkielecie proś o jedno zachowanie naraz: ruch, następnie kolizję, a potem przejście końca rundy. Po każdej zmianie przejrzyj zmodyfikowane pliki i uruchom tę samą ścieżkę akceptacji. Zachowaj znany działający stan projektu przed dodaniem zewnętrznych pakietów lub modyfikacją ustawień importu.

Agent powinien otrzymać właściwy błąd, kontekst sceny i zaobserwowane zachowanie, a nie tylko prośbę o większy wysiłek. Gdy ten sam objaw przetrwa kolejne edycje, zatrzymaj się i odizoluj granicę. Brakujący zaimportowany zasób i błędna referencja węzła wymagają innych poprawek, nawet jeśli oba tworzą pustą scenę.

Traktuj zasoby i lokalizację jako dane produkcyjne

Prowadź manifest zasobów zawierający źródło, uprawnienia, tożsamość autora lub narzędzia, modyfikacje i przeznaczenie. Sprawdzaj sprite'y w skali gry, w tym przezroczystość, wyrównanie klatek, kontrast i dopasowanie kolizji. Prawdopodobny obraz nie jest automatycznie użytecznym arkuszem sprite'ów.

Udostępnij napisy graczowi przez stabilne identyfikatory. Dodaj kontekst tłumaczenia i chroń argumenty formatowania. Obrazy, dźwięk, fonty i przetłumaczony tekst wymagają przeglądu przed dystrybucją. Rejestruj wydatek na generowanie obrazów niezależnie od pracy kodowej modelu tekstowego; ani licencja zasobu, ani licencja silnika nie ustanawia praw do każdego pliku w projekcie.

Niezależnie potwierdzaj każdy stan dostarczenia

Grywalna wersja demo wymaga, by człowiek ukończył zamierzoną pętlę. Eksport wymaga wygenerowanego artefaktu. Przetestowany eksport wymaga dodatkowo uruchomienia artefaktu na platformie docelowej. Wysłanie do Steam i premiera to późniejsze stany platformy. Używaj tych określeń precyzyjnie, gdy dzielisz się postępem.

Zachowaj tożsamość kompilacji, dane wejściowe testów, zrzuty z prawdziwej rozgrywki i pozostałe awarie. Zrzut z przeglądarki powinien pokazywać zmieniającą się rozgrywkę po wejściu, a nie tylko ekran ładowania. Plik wykonywalny Windows wyeksportowany na innym systemie nadal wymaga weryfikacji w Windows. Wymagania dotyczące konta i harmonogramu znajdziesz w przewodniku Steam.

Co przykład Playco pokazuje o procesie

Historia klienta OpenAI z 3 września 2026 r. opisuje użycie Astry przez Playco w Playbot, IDE połączonym z silnikami gier. Zespół iterował na bazie grey-box, a następnie tworzył prototypy tematyczne. To opublikowana przez dostawcę historia klienta, a nie benchmark APIsRouter.

Praktyczny wniosek dotyczy kształtu procesu: ustal mechanikę gry, a potem zmieniaj prezentację, zachowując wspólną bazę. Oddziel preferencje kreatywne od poprawek błędów, aby było widać, co osiągnęła każda iteracja. Oryginalna historia opisuje zgłoszone wyniki, ale nie jest prognozą dla twojej gry.

Sprawdź lokalny prototyp Godot

Switchyard to mała, trzy-pokojowa łamigłówka obwodowa powstała w lokalnym przebiegu developmentu Codex. Projekt źródłowy zawiera ruch postaci, przełączniki, drzwi, zbierane ogniwa, ukończenie pokoju, przegraną i restart, ustawienia oraz utrwalony postęp. Zautomatyzowane kontrole silnika wykonały pętlę gry, a osobny proces ponownie otworzył zapis. Poniższy zrzut to rzeczywiste ujęcie viewportu Godot, a nie concept art.

Zarejestrowany przebieg używał Godot 4.5.1. Jego tożsamość modelu i rozliczenia API nie były obserwowalne, więc nie przedstawiamy go jako benchmarku wydajności ani kosztu Astra. Pobieralne źródło i PCK pokazują projekt lokalny; PCK wymaga Godot. Samodzielna kompilacja Windows, eksport przeglądarkowy, test człowieka i premiera Steam pozostają osobnymi pracami. Przykład pokazuje konkretne artefakty, których warto żądać od agenta przed deklaracją dostarczenia.

Wybierz następny przewodnik według wąskiego gardła

Zacznij od wyboru silnika, jeśli środowisko jest nieustalone, od stron konfiguracji MCP, jeśli nie działa wykrywanie narzędzi, albo od przewodnika debugowania, jeśli projekt się otwiera, lecz działa niepoprawnie. Użyj przewodnika kosztowego, gdy naprawy dominują wydatki; zmniejszenie zakresu może być ważniejsze niż zmiana modelu.

Te przewodniki dają poparte źródłami procesy i ilustracyjne przykłady, a nie zmierzony ranking silników. Powiązany eksperyment Astra wyjaśnia dowody potrzebne dla konkretnego przypadku. W swoim projekcie wybierz następny krok rozwiązujący konkretną blokadę i zachowaj wynik przed rozszerzeniem gry.

Częste pytania