Mulți dezvoltatori mai scriu încă „gms2” când se referă la GameMaker actual. Imaginează-ți că personajul se plimbă înainte și înapoi, iar camera tremură din cauza pozițiilor cu valori zecimale. Deschizi folderul proiectului, descrii problema într-o singură propoziție și lași PixelTread să găsească codul. Agentul scanează folderul cu list_dir și glob, citește scripturile de mișcare și cameră cu read_file și propune o modificare mică sub formă de diff. Nimic nu se schimbă până nu decizi, așa că prima sesiune este și un mod sigur de a învăța ce face fiecare unealtă. Același ciclu funcționează pentru majoritatea bug-urilor mici: descrie, citește, revizuiește, testează. Fiecare iterație se termină în editor, unde apeși play și vezi rezultatul singur. Dacă prima remediere nu este suficientă, descrii ce s-a schimbat și următoarea carte se bazează pe cea anterioară. Ține proiectul deschis în editor în timp ce lucrezi.
Alege folderul proiectului GameMaker ca folder de lucru al chat-ului, astfel încât uneltele de fișiere să poată vedea scripturile și fișierele text ale proiectului. Începe un chat nou pentru fiecare bug, ceea ce menține fiecare conversație concentrată pe o singură problemă și un singur diff. Folderul de lucru este limita pentru uneltele de fișiere, așa că indică-l către proiect și nimic altceva. Orice lucru în afara acelui folder nu este acoperit de uneltele de fișiere.
Scrie ce vezi și unde, de exemplu că camera tremură în timp ce personajul se întoarce, și menționează scriptul dacă îl știi. Un simptom concret îi oferă agentului ceva pentru care poate căuta cu grep. Adaugă ce ai încercat deja, pentru a evita ca agentul să repete pașii. Propozițiile scurte funcționează bine.
Citește fiecare carte, deschide diff-ul și acceptă doar liniile pe care le înțelegi. Respinge restul și spune de ce, iar agentul încearcă din nou. Modul Ask first se oprește înainte de fiecare acțiune care modifică un fișier, astfel încât nimic să nu fie salvat în spatele tău. Deschide cartea extinsă pentru a vedea diff-ul complet, nu doar linia de rezumat.
Rulează build-ul în editorul GameMaker, joacă camera și raportează ce ai observat, astfel încât următorul pas să pornească de la fapte. Dacă build-ul eșuează, lipește jurnalul într-un fișier din folder și lasă agentul să îl citească. Apoi scrie rezultatul în chat, astfel încât următoarea solicitare să aibă un punct de plecare clar. Rulează același test după fiecare modificare acceptată, în aceeași cameră.
scr_move.gmlreaddraw_sprite3 matchesscr_move.gml+2 linesbuildexit 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);
}Funcția citește tastele săgeților cu keyboard_check, mută x și y cu o valoare de viteză și rotunjește ambele astfel încât sprite-ul să fie desenat pe pixeli întregi. Rotunjirea este remedierea pentru tremurarea descrisă mai sus. Un script precum acesta este exact ceea ce agentul poate deschide, modifica și arăta ca un diff, iar tu îl poți testa într-o cameră în decurs de un minut. Salvează-l mai întâi ca un asset de tip script și modifică o singură linie pe rând. Roagă agentul să adauge un comentariu deasupra fiecărei modificări, astfel încât să îl poți găsi mai târziu. Numele placeholder precum _speed sunt ușor de redenumit.
Dezvoltatorii întreabă adesea cum să învețe cu adevărat programarea în GameMaker, iar un răspuns bun este să modifici scripturi reale și să vezi ce se întâmplă. Deschide un proiect mic și roagă agentul să explice un script linie cu linie. El citește fișierul cu read_file și citează numele funcțiilor din manualul oficial folosind web_search. Apoi roagă o modificare mică, cum ar fi o viteză de mers mai rapidă. Citește diff-ul în modul Ask first, acceptă-l, compilează și joacă. Repetă cu o nouă modificare în fiecare zi și lasă agentul să scrie un fișier de note cu write_file, astfel încât să poți reveni la ce a învățat fiecare editare. Progresul lent este totuși un progres.
Poți dori să faci doar o parte dintr-un sprite transparentă, de exemplu jumătatea de jos a unui personaj care stă în apă. Agentul citește scriptul tău de desenare cu read_file, caută apelul de desenare curent cu grep și propune modificări edit_file care desenează sprite-ul în două piese cu draw_sprite_part_ext, una dintre ele cu o valoare alfa mai mică. Plan only îți poate arăta mai întâi cele 2 piese. Scurt și testabil. Acceptă diff-ul, rulează camera și verifică îmbinarea dintre ambele părți la nivel de pixel, deoarece un gol de un pixel este ușor de văzut în mișcare. Dacă nivelul apei se mișcă, roagă agentul să lege divizarea de o variabilă.
Pentru a opri mișcarea înainte de a colisiona cu un obiect, un script ar trebui să verifice poziția următoare și apoi să se mute. Roagă agentul să citească scriptul tău de mișcare și să încadreze fiecare pas într-o verificare place_meeting pe poziția țintă. Cartea edit_file arată liniile noi, iar Shell raportează codul de ieșire al comenzii tale de build. Mergi într-un perete în cameră. Revizuiește mai întâi diff-ul, apoi testează la viteză lentă și la viteză rapidă, deoarece un obiect rapid poate totuși să sară peste un perete subțire și roagă un pas mai mic dacă se întâmplă. Ține camera de test mică, cu un perete și un personaj.
Un jurnal de build lung ascunde linia care contează. Salvează jurnalul ca un fișier text în folderul proiectului, apoi roagă agentul să îl deschidă cu read_file și să îl caute cu grep pentru cuvântul error. Raportează prima eroare împreună cu numele scriptului și linia, și poate citi acel script pentru a propune o remediere cu edit_file. Remedierea primei erori adesea elimină pe cele de mai jos. Acceptă diff-ul în Ask first, compilează din nou și compară noul jurnal cu cel vechi pentru a vedea dacă numărul de erori a scăzut. Repetă până când jurnalul este curat.
