Construct 3 in the AI agent era — what actually makes sense?

AI tools are advancing quickly, and many engines have started integrating them into development workflows. Regardless of how effective current implementations are, AI-assisted tooling is clearly becoming part of normal software development. So the question isn’t really whether Construct should have AI — but what kind of interaction would actually work for it.

Most AI discussions around game engines focus on generating full projects. For Construct, that direction feels awkward. Generated projects may look impressive, but they’re difficult to iterate on and rarely survive real production. A more interesting possibility might be different: not AI generating Construct projects, but AI understanding Construct projects.

Why this matters for Construct

Construct projects follow a strict internal structure. The editor already knows exactly what a valid event looks like, how actions connect to conditions, and what data can be pasted back into the project.

AI, however, doesn’t know those rules. Because of that, current assistance relies on approximation. Even when providing an existing JSON snippet and asking it to modify it, the model may still hallucinate — introducing unsupported fields or invalid data types that the editor cannot accept.

The output often looks correct, but fails when actually used inside C3.

If the structure were defined

If the project format were formally documented, developers wouldn’t need to build their own datasets and repeatedly feed projects to AI just to approximate how Construct behaves. Instead of spending tokens on trial-and-error learning, tools could work against a known structure and interact with existing projects more predictably.

What could that look like in practice?

• checking why a condition never triggers even though it looks correct
• pointing out picking or event order issues that change behavior
• adjusting an existing mechanic (for example adding coyote time or input buffering) without rewriting it
• modifying a snippet while preserving instance variables and object references
• given a layout clipboard fragment, reorganizing object positions automatically (for example aligning or sorting placed instances)

The shift wouldn’t really be about automation, but about reliability — moving from approximate suggestions to tools that can reason about the project.

What might make that possible

Instead of building AI features directly into the editor, another approach could be making Construct easier for external tools to understand. A clear reference of what is valid would allow experimentation to happen outside the engine, rather than requiring constant iteration inside it.

I have three ideas that might help with this.

The first is providing a complete JSON schema for the project format. That would give external tools something stable to target instead of approximating behavior through examples. I’ve already opened a request here:

https://github.com/Scirra/Construct-feature-requests/issues/709

The second is publishing the documentation in a GitHub repository and providing a Markdown version. This would make version changes transparent (so developers can see what actually changed between releases), and it also allows tools to reliably reference up-to-date documentation.

At the moment the manual is written in BBCode, which is difficult to consume programmatically. I experimented with converting it using an AI-assisted pipeline (bbcode → html → markdown) and published the result here:

https://github.com/XHXIAIEIN/Construct3-Manual

If useful, the repository and scripts can be freely reused — no credit needed.

The third is continuously updated example projects. Real projects show patterns that documentation alone cannot describe, and they act as reference behavior for tooling instead of guesswork. I also suggested this here:

https://github.com/Scirra/Construct-feature-requests/issues/708

Together these aren’t really “AI features”, but they make it much easier for tools and community projects to understand Construct without relying on guesswork.

AshleyTomDiegoM Interested to know your perspective on where AI could fit into Construct.

Nobody is saying AI should make entire games for you. Other engines are integrating AI because it can genuinely help with game development - assist with complex code, automate repetitive tasks, answer engine-specific questions.

This is especially important for new users. In GDevelop, I can tell their AI what kind of game I want to make, and it will pre-build a project, explain the next steps, and answer my silly questions.

If I'm a C3 newbie, my options are to Google everything myself or post on the forum and wait 2 days for someone to reply.

Oh yeah? If I search for "array" in the examples, I get 65 matches — and none of them immediately answer a basic question like "how do I find a specific number in an array?"

And many beginners don’t even know the examples exist.

I'm old-school - if I have a question, I check the documentation and Google. Five years ago beginners learned from YouTube tutorials. These days, people use AI - half the forum posts now start with "I asked ChatGPT first but…"

That's the new reality. Like it or not.

If you are so eager to use ai in your game development - use it, no one is stopping you. You can ask ai for the code, ask it to generate an image for you. What else do you need? Those actions are on you and the amount of disrespect you have for your audience.

There is zero point in shoving it directly into engine. Construct is good as it is, they are already adding features that are actually needed. Ai? It's not needed.