Wielu osób nadal pisze gms2, mając na myśli dzisiejszy GameMaker. Załóżmy, że postać chodzi tam i z powrotem, a kamera drży, ponieważ pozycja przechowuje wartości ułamkowe. Otwierasz folder projektu, opisujesz objaw w jednym zdaniu i pozwalasz PixelTread znaleźć kod. Agent mapuje folder za pomocą list_dir i glob, odczytuje skrypty ruchu i kamery za pomocą read_file, a następnie proponuje drobną zmianę jako diff. Nic się nie zmienia, dopóki nie podejmiesz decyzji, więc pierwsza sesja to też bezpieczny sposób na naukę, co robi każde narzędzie. Ten sam cykl działa przy większości drobnych błędów: opisz, przeczytaj, przejrzyj, przetestuj. Każda iteracja kończy się w edytorze, gdzie wciskasz play i sam widzisz wynik. Jeśli pierwsza naprawa nie wystarczy, opisz, co się zmieniło, a kolejna karta opiera się na poprzedniej. Trzymaj projekt otwarty w edytorze podczas pracy.
Wybierz folder projektu GameMaker jako folder roboczy czatu, aby narzędzia do plików mogły widzieć Twoje skrypty i pliki tekstowe projektu. Rozpocznij nowy czat dla każdego błędu, co utrzymuje każdą rozmowę w kontekście jednego problemu i jednego diffa. Folder roboczy to granica dla narzędzi do plików, więc wskaż go na projekt i nic więcej. Wszystko spoza tego folderu nie jest objęte narzędziami do plików.
Napisz, co widzisz i gdzie, na przykład że kamera drży, gdy postać się obraca, i wspomnij o skrypcie, jeśli go znasz. Konkretne objawy dają agentowi coś, czego może szukać za pomocą grep. Dodaj, co już próbowałeś, ponieważ to powstrzyma agenta przed powtarzaniem tego. Krótkie zdania działają najlepiej.
Przeczytaj każdą kartę, otwórz diff i zaakceptuj tylko te linie, które rozumiesz. Odrzuć resztę i powiedz dlaczego, a agent spróbuje ponownie. Tryb Ask first pauzuje przed każdą akcją, która zmienia plik, więc nic nie jest zapisywane bez Twojej wiedzy. Otwórz rozwiniętą kartę, aby zobaczyć pełny diff, a nie tylko linię podsumowania.
Uruchom kompilację w edytorze GameMaker, odtwórz pokój i wróć z raportem o tym, co widziałeś, aby następny krok zaczynał się od faktów. Jeśli kompilacja się nie powiedzie, wklej dziennik do pliku w folderze i pozwól agentowi go przeczytać. Następnie zapisz wynik w czacie, aby następne żądanie miało jasny punkt startowy. Uruchom ten sam test po każdej zaakceptowanej zmianie, w tym samym pokoju.
scr_move.gmlreaddraw_sprite3 dopasowaniascr_move.gml+2 liniebuildexit 0// Move an object with the arrow keys
function scr_move(_speed) {
var _r = keyboard_check(vk_right);
var _l = keyboard_check(vk_left);
var _d = keyboard_check(vk_down);
var _u = keyboard_check(vk_up);
x += (_r - _l) * _speed;
y += (_d - _u) * _speed;
// keep the position on whole pixels
x = round(x);
y = round(y);
}Funkcja odczytuje klawisze strzałek za pomocą keyboard_check, przesuwa x i y o wartość prędkości i zaokrągla obie, aby sprite był rysowany na całych pikselach. Zaokrąglenie to naprawa opisanego powyżej drgania. Skrypt taki jak ten to dokładnie to, co agent może otworzyć, zmienić i pokazać jako diff, a Ty możesz go przetestować w pokoju w ciągu minuty. Najpierw zapisz go jako zasób skryptu i zmieniaj po jednej linii na raz. Poproś agenta o dodanie komentarza nad każdą zmianą, abyś mógł ją później znaleźć. Nazwy zastępcze takie jak _speed są łatwe do zmiany.
Często słyszy się pytanie, jak naprawdę nauczyć się kodowania w GameMaker, a dobrą odpowiedzią jest zmiana prawdziwych skryptów i obserwacja tego, co się dzieje. Otwórz mały projekt i poproś agenta o wyjaśnienie jednego skryptu linia po linii. Odczytuje plik za pomocą read_file i cytuje nazwy funkcji z oficjalnej dokumentacji za pomocą web_search. Następnie poproś o jedną drobną zmianę, na przykład szybszą prędkość chodzenia. Przeczytaj diff w trybie Ask first, zaakceptuj go, zbuduj i zagraj. Powtarzaj z nową zmianą każdego dnia i pozwól agentowi napisać plik notatek za pomocą write_file, abyś mógł wrócić i zobaczyć, czego nauczyła Cię każda edycja. Wolny postęp to nadal postęp.
Możesz chcieć, aby tylko część sprite'a była przezroczysta, na przykład dolna połowa postaci stojącej w wodzie. Agent odczytuje Twój skrypt rysowania za pomocą read_file, szuka bieżącego wywołania rysowania za pomocą grep i proponuje zmiany edit_file, które rysują sprite w dwóch kawałkach za pomocą draw_sprite_part_ext, z czego jeden ma niższą wartość alfa. Tryb Plan only może najpierw pokazać Ci te 2 kawałki. Krótkie i testowalne. Zaakceptuj diff, uruchom pokój i sprawdź szew między obiema częściami na poziomie pikseli, ponieważ luka o jeden piksel jest łatwa do zauważenia w ruchu. Jeśli poziom wody się porusza, poproś agenta o powiązanie podziału ze zmienną.
Aby zatrzymać ruch przed zderzeniem się z obiektem, skrypt powinien sprawdzić następną pozycję i dopiero wtedy się poruszyć. Poproś agenta, aby przeczytał Twój skrypt ruchu i aby opakował każdy krok w sprawdzenie place_meeting dla docelowej pozycji. Karta edit_file pokazuje nowe linie, a Shell raportuje kod wyjścia Twojej komendy kompilacji. Wejdź w ścianę w pokoju. Najpierw przejrzyj diff, a następnie przetestuj przy wolnej i szybkiej prędkości, ponieważ szybki obiekt może nadal przeskoczyć cienką ścianę, i poproś o mniejszy krok, jeśli tak się stanie. Utrzymaj mały pokój testowy, z jedną ścianą i jednym graczem.
Długi dziennik kompilacji ukrywa ważną linię. Zapisz dziennik jako plik tekstowy w folderze projektu, a następnie poproś agenta, aby go otworzył za pomocą read_file i wyszukał w nim za pomocą grep słowo error. Raportuje pierwszy błąd wraz z nazwą skryptu i numerem linii, a może przeczytać ten skrypt, aby zaproponować naprawę za pomocą edit_file. Naprawienie pierwszego błędu często usuwa te poniżej. Zaakceptuj diff w trybie Ask first, zbuduj ponownie i porównaj nowy dziennik ze starym, aby zobaczyć, czy liczba błędów spadła. Powtarzaj, aż dziennik będzie czysty.
