The future of Construct

Not favoritedFavorited Favorited 1 favourites
  • 9 posts
From the Asset Store
Casino? money? who knows? but the target is the same!
  • I think there needs to be another discussion about AI and where Construct is heading.

    If you've been following AI coding it's clearly reached a point where the idea of manually writing all the code yourself (including Construct events) is a thing of the past.

    So why is Construct ignoring AI and expecting people to write events manually one by one?

    I've used AI with Construct. It can write TypeScript of course but its the lack of tooling such as integration with the editor, AI API's, skills, plugins, AI docs that makes it a slow and error prone process.

    I ported my project to Unity and was able to make more progress on my project there than I have in years with Construct. AI writes my scripts and I can focus on game design in the editor tweaking values and setting up scenes etc.

    TBH I'd rather use Construct as Unity's so big and slow but making games with Unity is now so much more enjoyable as I can make real progress.

    This might be heresy but In my view the future of Construct is to ditch events altogether. Go all in on AI generated TypeScript code, hidden by default from the user, and focus the engine on game design.

    After all weren't events created as a way to obfuscate code? I feel AI code is the evolution of that idea.

  • I don't think the Construct team needs to do much here. AI is improving fast, and a capable model will find its own way. What matters is that they keep the manual well maintained and publish more example projects; that alone is enough for AI to master Construct.

    I've been working on getting AI to understand Construct 3, and made Construct3 Agents Skills, built mainly on those two.

    It installs into a Construct folder project as an agent skill. With it, agents write complete event sheets directly, using Construct's native features, and the result opens in the editor like any other project.

    If anything, I think event sheets are what make this work. They are a language both you and the agent can read: every condition and action comes from a fixed set the agent can look up exactly, so it has little room to make things up, and everything it writes stays readable to you, so you can follow each event, point the agent at the one that's wrong, or tweak values by hand in the editor.

    In my experience so far, working with AI through this skill has been very stable. Before writing, the agent reads the Construct manual, similar official example projects and, for addons, the Addon SDK, and looks up the exact condition or action and its parameters. For scripts, it reads Construct's TypeScript definitions the same way.

    The official examples help the most. There are nearly 500 of them in the editor's example browser, covering almost every feature. The agent finds the ones on the same topic or using the same addons, reads their event sheets, and follows how they solve the problem, down to how events are grouped, named and commented, so what it writes reads like the official examples themselves.

    Afterwards it checks the project against the rules the editor applies when opening it, and can then drive the real Construct editor in Chrome or Edge over the DevTools protocol: it opens the project, previews it, plays it with taps and key presses, and reads the game state and screenshots to see whether it works. Then you reopen the project in the editor and review the result yourself.

    If you want to try it, send the link to your agent (I'd recommend Claude) and it will set things up from the README.

    What mattered more than prompting:

    - Git from the first minute. Commit after each finished task and start a fresh session for the next one.

    - The model. Claude Code with a strong model has been reliable in my tests; weaker models broke projects badly enough that they wouldn't open.

  • Personally I prefer my game engines, IDE's etc... free of AI features. I do a lot of AI coding, I even have a university degree in AI, but I also like coding for fun. I think if they do it, it would be nice to have it as an optional feature. An official MCP would be nice.

  • Hey XHXIAIEIN those AI skills look pretty good and would go a long way to solving many of the issues I had when trying use AI with Construct. I'm going to take a look when I get chance.

    But even so my purpose with this post is to try and prompt Ashley to take another look at where the industry is heading and look at official support going beyond skills into tight editor integration and new ways of working.

    For example AI should allow me quickly iterate on a game design feature.

    • Code it
    • Set it up in the editor
    • Create placeholder art
    • Enter play mode
    • Allow me to to quick switch between 5 versions of the same feature

    Wiring this up 5 different ways in the editor is not really something you can replicate with code or events. The implementation is now so quick it fundamentally changes how games are made.

    There's a million examples. I get no everyone's is on board with AI (and it shouldn't replace manual code if people want it) but for the long term success of Construct I worry if Scirra spend the next 12 months on 3D then it might be too late.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Most of the loop you describe is already doable, so it might be closer than you think:

    Just save your project as a folder project, then right-click the Scripts folder and pick TypeScript > Set up TypeScript for external editor (steps in the manual). That generates types for your own objects, instance variables and layouts, so the AI can write TS in VS Code against your actual project.

    With my Agent Skills, the agent can already do the rest. It looks at the official TypeScript example projects and follows how they're written. It adds the layouts, objects and instances itself, then opens the project in the editor to make sure it loads. For art, it starts with placeholder shapes, and if you have an image tool, it generates the images and swaps them in.

    Since a folder project is all plain files, you can use git to manage versions, either with the git support built into VS Code or a tool like Sourcetree. Have the agent create a branch for each of your 5 versions and switch between them.

    For play mode, since Construct runs in the browser, the agent drives the editor over the Chrome DevTools Protocol: it previews the game, plays it with taps and key presses, and checks the game state and screenshots to see if the feature actually works.

    All of this runs from outside, with no built-in integration from the editor, but it already gets the job done.

  • Pls don't slopify Construct. AI already works with Construct if you really want and I don't want Ashleys thinly spread resources spread even more thin. And if we're speaking of "where the industry is headed" I'd really prefer to go in the exact opposite direction, considering that industry has been circling the drain pumping out some absolute slop for quite a while. And they did that even before AI was a thing, we need less slop, not more.

  • I get further programming games (without coding) with openai codex, but I still have a soft spot for construct. If they had an official MCP I would certainly look at it. Its hard to imagine a game engine that isn't interested in whats going on with AI.

    yours

    winkr7

  • Obviously we're aware of everything happening with AI, and it's something we've been thinking about. There are of course all sorts of existing ways AI can already be used with Construct as has been mentioned already - modifying project files directly, using automation tools like Playwright, or just driving the regular UI via AI, are all techniques that work or might be able to. I am interested in developing something with WebMCP when it becomes available in browsers. I think that hits the spot between integrating AI without affecting the user interface - the way we'd implement it would be that if you don't want to use it then it doesn't change anything about how you use Construct or how it looks. So in other words you can have a completely AI-free experience of Construct if you want. However WebMCP is still in development and not enabled by default in browsers right now, and I'd prefer to only start experimenting with it once it's easy for people to try out. I think this might start happening some time earlyish next year.

    While I can see the advantages of various AI enhancements, I still think it's important to preserve an AI-free experience in Construct. I've said before that Construct should primarily be about human expression, and I stand by that; even if AI takes over the world, I would still want Construct to be a nice tool for people who want to work the good old fashioned way and not try to push AI stuff at them all the time. I think there may still be a gap in the market long-term for this kind of thing, partly because lots of people remain hostile to AI and want to avoid it (I don't intend to get into a whole debate about that, it's just something I think is the case, especially looking at responses to AI discussions on our forums), but also because there is more to life than maximizing efficiency. I think an interesting analogy is that computers have been better at chess than humans for a long time now, and yet people still play chess. It can be an enjoyably hobby or pursuit for its own sake - and historically Construct has had a large hobbyist userbase. So even if most of the world is AI generating all their stuff, there could well be a market for people who just don't really care about that and still like to work on things themselves, and I'd be happy to continue to develop Construct for them.

    I could be wrong about this - I don't think anyone knows exactly how all the disruption from AI is going to play out. But so long as people want software like Construct, we'll be keeping it going!

  • Looking forward to WebMCP.

    In the meantime I posted a few feature requests for things I keep running into when editing projects outside the editor:

    1. Reload a folder project from disk without closing it

    2. Reload addons without restarting Construct

    3. Show which file and event caused a project load error

    For WebMCP, the tools I'd use most are opening a project, previewing a layout, sending input, and reading back runtime errors and game state. That's roughly what my agent does now over the DevTools protocol, so it can break when the editor UI changes.

Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)