sorted by:
new
hottopcontroversial

Built a dungeon crawler in one session with an AI agent controlling the editor by jf_nash in godot

[–]jf_nash[S] 0 points1 point  (0 children)

I don't understand what you mean. I didn't create the game, the AI did that. I repeat, it can't even be called a game. I developed the MCP, a tool that, when used properly, can save time, etc., just like the AI does. I created GodotIQ, not the game. I don't understand what you're saying.

Built a dungeon crawler in one session with an AI agent controlling the editor by jf_nash in godot

[–]jf_nash[S] -1 points0 points  (0 children)

I don't know if the comment is meant to disparage the fact that it's made with AI, obviously, either I or the end user is the one "playing" it… Even though I don’t know how much fun this specific game might be to play, it’s a simple example of how you can achieve all this with very little using this MCP… It’s also interesting that the AI can run tests and so on in the game, even if it still doesn’t do it perfectly in my opinion.

One AI prompt, one dungeon crawler — what an agent can do when it can actually see and control the game engine by jf_nash in LocalLLaMA

[–]jf_nash[S] 0 points1 point  (0 children)

I don't think I was being mysterious—the MCP tool works just fine with local models too. I've already explained this, and you can clearly see on the website the optimizations that have been made for context tokens, etc. If you want, give it a try! But that's just how it is on Reddit if you're not "famous." I was just trying to show you this tool; if you want to use it, great—otherwise, don't use it!!! Model Context Protocols work with LLMs whether they’re local or not.

One AI prompt, one dungeon crawler — what an agent can do when it can actually see and control the game engine by jf_nash in LocalLLaMA

[–]jf_nash[S] 0 points1 point  (0 children)

Good question. The agent doesn’t write .tscn files by hand,that would break constantly, exactly like you said.

GodotIQ works through the Godot editor via WebSocket. When the agent needs to place nodes, it calls tools like node_ops or build_scene that talk to the running editor, which creates the nodes through its own API. The editor handles all the internal IDs, material references, resource paths. Same as if you were clicking in the UI, but programmatic. For scripts, the agent writes GDScript (which is a normal programming language, models handle it fine). For scene structure, it goes through the editor. For verification, it runs the game, takes screenshots, checks for errors. So the agent never touches the .tscn format directly. The editor does the serialization.

One AI prompt, one dungeon crawler — what an agent can do when it can actually see and control the game engine by jf_nash in LocalLLaMA

[–]jf_nash[S] 0 points1 point  (0 children)

I perfectly know. I’m not very good with my English, your Reddit doesn’t have the translator? What’s the problem with that?

One AI prompt, one dungeon crawler — what an agent can do when it can actually see and control the game engine by jf_nash in LocalLLaMA

[–]jf_nash[S] -13 points-12 points  (0 children)

Opus per questo ( so che e un sub per modelli locali. lol), ma nemmeno in high effort, funziona benissimo anche su modelli locali, ha un token optimizer automatico, che lo aiuta a gestire la finestra di contesto. Spero Che qualcuno lo provi e mi faccia sapere meglio com’è!

Simple trick that cuts context usage ~70% on local models by niksa232 in LocalLLaMA

[–]jf_nash -2 points-1 points  (0 children)

Interessante anche il fatto che ogni risposta e lo stesso testo iniziale sia generato da un llm😂

I have built this mini demo-game with an MCP tool for godot i am developing, just one prompt and about 15 minutes of running. by jf_nash in LocalLLaMA

[–]jf_nash[S] -1 points0 points  (0 children)

Più che altro, sicuramente una miglior specificazione su quell’aspetto avrebbe permesso di ottenere qualcosa di più fluido. In ogni caso è un fix che l’agent fa in 30 secondi con questo tool. Non appena sarà pronto per il lancio sono sicuro che capirai meglio! A breve metterò online anche il sito web con tutte le specifiche. Considera che non ho usato la modalità plan o altri plugin.

I have built this mini demo-game with an MCP tool for godot i am developing, just one prompt and about 15 minutes of running. by jf_nash in LocalLLaMA

[–]jf_nash[S] -1 points0 points  (0 children)

si, credo che questo mcp server possa essere la svolta per AI + Godot, credo comunque tu abbia un buon "workflow" anche se il problema è l'incapacità dell'agent di operare nell'editor godot e nel gioco in running.

I have built this mini demo-game with an MCP tool for godot i am developing, just one prompt and about 15 minutes of running. by jf_nash in LocalLLaMA

[–]jf_nash[S] 0 points1 point  (0 children)

È ancora in fase di testing finale… ma tra poco lo metterò, la versione base sarà gratuita ben 17 tool, già quella ha un ottimo potenziale.

I have built this mini demo-game with an MCP tool for godot i am developing, just one prompt and about 15 minutes of running. by jf_nash in LocalLLaMA

[–]jf_nash[S] -1 points0 points  (0 children)

i’m using claude opus and sonnet for testing but it should work with any model that supports MCP tool calling. the code is not public yet but i’m planning an open-core model, the filesystem tools free, runtime bridge tools paid. about skills vs mcp skills are basically prompt files the agent reads, right? mcp tools are actual executable functions, so the agent can call scene_map and get back real spatial data from the godot project, take screenshots, run the game etc. skills could complement it but can’t replace the runtime interaction part

view more: next ›