Cursor for making games

Cursor is a coding assistant in an editor. It is not a game engine, and it is not a designer. Used on purpose, it speeds up the text around a game. Used as a wish machine, it invents systems you did not play.

What it is for

Use it on scripts, config, notes, and the boring glue. A movement script, a cooldown, a data table, a checklist for a playtest. You can read a diff of those. You can refuse the parts that are wrong.

It is also useful for explaining a file you forgot. Ask what a function does, then check the answer against the function. The check is the point.

What it is not for

It should not be the one who decides the game is fun. It has not played your build. If you ask for “a better combat system,” you will get a pile of plausible code and no feel. Describe the change you already felt was missing. “The dodge starts too late” is a task. “Make combat better” is a mood.

Do not hand it the whole project and ask for a new game. You will not be able to review the result, which means you cannot ship it honestly.

Keep the engine in the loop

After a script change, run the game. The error that matters is the one in play mode, not the one in the chat. If the assistant cannot see the screen, you are the person who can. Write down what happened and only then ask for another edit.

On a project like Tingbase, that loop is the work. One ability exchange, a change, a play. Cursor can type the change. It cannot feel the exchange.

Leave a trail

Commit when a change plays. A chat is not a history. The repository is. If a suggestion was wrong, revert the file instead of arguing the chat into a larger mess.

Common questions

Can Cursor replace Unity or Godot?

No. Cursor edits the project. The engine is still what runs, renders, and builds the game.

Should I let it rewrite a whole scene?

No. Ask it to change a script or a note you can read. Scene and prefab files are easy to break and hard to review.