Many people still write gms2 when they mean today's GameMaker. Say your player is walking back and forth and the camera jitters, because the position holds fractional values. You open the project folder, describe the symptom in 1 sentence and let PixelTread find the code. The agent maps the folder with list_dir and glob, reads the movement and camera scripts with read_file, and proposes a small change as a diff. Nothing changes until you decide, so the first session is also a safe way to learn what each tool does. The same loop works for most small bugs: describe, read, review, test. Each pass ends in the editor, where you press play and see the result yourself. If the first fix is not enough, you describe what changed and the next card builds on the last one. Keep the project open in the editor while you work.
Choose your GameMaker project folder as the chat's working folder, so the file tools can see your scripts and the project's text files. Start a fresh chat for each bug, which keeps every conversation about one problem and one diff. The working folder is the boundary for the file tools, so point it at the project and nothing else. Anything outside that folder is not covered by the file tools.
Write what you see and where, for example that the camera shakes while the player turns, and mention the script if you know it. A concrete symptom gives the agent something it can search for with grep. Add what you already tried, because that keeps the agent from repeating it. Short sentences work well.
Read each card, open the diff and accept only the lines you understand. Reject the rest and say why, and the agent tries again. Ask first mode pauses before every action that changes a file, so nothing is saved behind your back. Open the expanded card to see the full diff, not only the summary line.
Run your build in the GameMaker editor, play the room, and report back what you saw so the next step starts from facts. If the build fails, paste the log into a file in the folder and let the agent read it. Then write down the result in the chat, so the next request has a clear starting point. Run the same test after every accepted change, in the same room.
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);
}The function reads the arrow keys with keyboard_check, moves x and y by a speed value, and rounds both so the sprite is drawn on whole pixels. Rounding is the fix for the shaking described above. A script like this is exactly what the agent can open, change and show as a diff, and you can test it in a room within a minute. Save it as a script asset first, and change one line at a time. Ask the agent to add a comment above each change so you can find it later. Placeholder names such as _speed are easy to rename.
People often ask how to really learn GameMaker coding, and a good answer is to change real scripts and watch what happens. Open a small project and ask the agent to explain one script line by line. It reads the file with read_file and quotes the function names from the official manual using web_search. Then ask for one tiny change, such as a faster walk speed. Read the diff in Ask first mode, accept it, build and play. Repeat with a new change each day, and let the agent write a notes file with write_file, so you can look back at what each edit taught you. Slow progress is still progress.
You may want to make only part of a sprite transparent, for example the lower half of a character standing in water. The agent reads your draw script with read_file, searches for the current draw call with grep and proposes edit_file changes that draw the sprite in two pieces with draw_sprite_part_ext, one of them with a lower alpha value. Plan only can show you the 2 pieces first. Short and testable. Accept the diff, run the room, and check the seam between both parts at the pixel level, since a one pixel gap is easy to see in motion. If the water level moves, ask the agent to tie the split to a variable.
To stop moving before colliding with an object, a script should test the next position and only then move. Ask the agent to read your movement script and to wrap each step in a place_meeting check on the target position. The edit_file card shows the new lines and Shell reports the exit code of your build command. Walk into a wall in the room. Review the diff first, then test at slow and at fast speed, because a fast object can still skip a thin wall, and ask for a smaller step if it does. Keep the test room small, with one wall and one player.
A long build log hides the line that matters. Save the log as a text file in the project folder, then ask the agent to open it with read_file and search it with grep for the word error. It reports the first error together with the script name and line, and it can read that script to propose a fix with edit_file. Fixing the first error often clears the ones below it. Accept the diff in Ask first, build again and compare the new log with the old one to see whether the count of errors dropped. Repeat until the log is clean.
