XHXIAIEIN's Forum Posts

  • I'd keep polishing it for a bit, but put the time into game feel rather than more features. Pong is a good project for that, since the game is so small that every bit of feedback you add shows right away.

    These are the classic talks on it:

    Juice it or lose it - Martin Jonasson & Petri Purho

    youtube.com/watch

    The art of screenshake - Jan Willem Nijman (Vlambeer)

    youtube.com/watch

    Can We Make This Button Fun To Press? - Jonas Tyroller

    youtube.com/watch

    There's a lot more on YouTube if you search "game feel" or "juice".

    In Construct, two habits get you most of the way:

    1. Animate with the Tween behavior instead of just setting a value.

    2. Look at the triggers you already have (On collision, On tween finished, On timer...) and ask what the player should see or hear at that moment.

    For example:

    1.

    Squash and stretch - set the size on a hit, then tween it back with Out Back so it overshoots a little.

    2.

    Screen shake - Camera is an invisible sprite in the middle of the layout with the Scroll To behavior. Your layout is the same size as the window, so turn on Unbounded scrolling in the layout properties, or there's no room for the view to move.

    3.

    Hit freeze - stop the game for a moment on a paddle hit. Untick "use time scale" on the Wait, or it waits forever.

    4.Sparks - a Particles object with Type set to One-shot, created at the ball. It sprays once and destroys itself.

    5. Sounds - one for the paddles, a softer one for the walls. This made the biggest difference for me. bfxr.net is good for quick retro sounds.

    After a point - a sound, a bigger shake, and the ball fades in before the serve. That's also the pause before the serve you asked about, and R0J0's choose() can pick the side.

    Last, once it feels good, try dressing it up. Swap the art for a table tennis table with two players, a tennis or badminton court, two goalkeepers on a football pitch, or anything else you like.

    Keep the collisions and the art apart: leave the plain Ball and paddle sprites doing the bouncing, make them invisible, and add a separate sprite for each one that only shows the picture. Attach the picture to its sprite with a hierarchy (Add child in the Layout View, or the "Add child" action), so it follows along. Then you can swap images, add animations or make the art any size you want without touching how the ball bounces, and the squash and stretch can go on the picture instead of the real ball.

    It's surprising how much a theme changes how the same game feels.

  • Timelines can’t keyframe 3D rotation directly at the moment, but they can keyframe instance variables.

    Add three number instance variables (e.g. rx, ry, rz) to the 3D shape, animate those in the timeline, then add an event: 

    Every tick → 3DShape: Set Euler rotation (Self.rx, Self.ry, Self.rz)

    0s → Value: 0
2s → Value: 180
4s → Value: 360

  • 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.

  • 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.

  • One family is enough.

    For each turret, pick the nearest hull of the other team and pass it to "Acquire target":

    "Add object to target" works on the whole family, so the team filter goes in these conditions.

    Full:

  • 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.

  • Thanks for the so much info, I'm gonna try this.

    The model itself also matters a lot.

    So far, I’ve only tested this workflow seriously with Claude Code using Fable 5.1 and Opus 5.

    A strong model can often infer your intent from limited context and fill in the missing pieces on its own. In many cases, even if your prompt is not very detailed, it can still reason from the surrounding project structure and documentation and produce the right result.

    With weaker or free models, the same workflow can be much less reliable. Even when you explicitly tell the model what to do, it may still make incorrect edits, sometimes to the point where the Construct project becomes corrupted and can no longer be opened.

    I tested the same workflow with V4.1 Flash DeepSeek Harness. After it broke the project, I gave it the error logs and spent around ten rounds going back and forth trying to fix everything. Eventually, the project opened again, but by that point the result was still completely off from what I wanted. I ended up having to start over from scratch anyway. That was probably the most frustrating part: after all that debugging, I had burned a lot of time, effort, and money, and still ended up back at square one.

    If your budget allows, I’d strongly recommend trying Claude Code with the $20 plan.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I still have question like you said you manually create AGENTS.md and CLAUDE.md in the project root. do you use pre-made AGENTS.md and CLAUDE.md and just place them in project's root folder or always create them with custom instructions?

    Yes. For a new project, I usually start with a pre-written AGENTS.md template.

    The main purpose of this template is simply to remind the agent to read Construct’s interface/type documentation and related references before making changes, instead of relying on its memory and guessing how Construct works.

    As development continues, I let the agent gradually improve AGENTS.md itself.

    For example, it can record mistakes it has made, my personal preferences, coding conventions, project-specific rules, or anything else that should be remembered for future tasks.

    If the agent does something incorrectly even though I already explained it before, I usually ask it to add that lesson to AGENTS.md so it won’t repeat the same mistake next time.

    Over time, AGENTS.md usually evolves into a kind of project-specific "working memory" and development guide for the agent.

    If it grows beyond around 200 lines, I usually ask the agent to review the official AI/agent best-practice documentation, such as Claude Code’s best practices:

    code.claude.com/docs/en/best-practices

    Then I let the agent reorganize and optimize the instructions itself. Typically, it will keep the important and always-relevant rules in AGENTS.md, while moving more specialized rules into separate files under a rules folder inside .claude/ or (.codex/).

    Those rules can then be loaded or read only when they are relevant to the current task, following a progressive disclosure approach.

  • How did you manage to make Claude listen to what you actually wanted? I tried too, but it was driving me crazy and kept producing weird results.

    Thanks BTW.

    I built a RAG project that instructs the AI to consult Construct's interface type documentation, the Construct Manual, and similar patterns from example projects before writing event sheets.

    You can start by cloning these repositories:

    github.com/XHXIAIEIN/Construct3-RAG

    github.com/XHXIAIEIN/Construct3-Manual

    github.com/Scirra/Construct-Example-Projects

    -----------

    My workflow is roughly like this:

    I create a new project in Construct and save it as a folder project, then open that project folder in VS Code.

    The first thing I do is initialize a Git repository. Very important.

    Then I manually create AGENTS.md and CLAUDE.md in the project root. These files contain instructions that guide the agent to follow the workflow and proactively consult the reference material. I also use symbolic links to point the project to the local copies of those repositories.

    You can see my example here: AGENTS.md

    After that, you can start Claude Code or Codex with the session opened inside the project folder.

    The agent modifies the Event Sheet JSON directly in the project's source files, without going through the Construct editor. Once the changes are complete, just reopen or reload the project in Construct and test it normally.

    -----------

    Based on my experience so far, using this RAG setup to guide the agent has been extremely reliable.

    I don't use any elaborate prompts. I usually just describe what I want to build. Even with that, the generated event sheets have been close to 100% correct in my tests.

    Claude can now generate complete Construct event sheets while making proper use of Construct's native features, including hierarchies, families, containers, arrays, dictionaries, JSON, custom actions, and functions.

    It also handles more subtle patterns correctly. For example, it knows when to add For Each inside On Timer events, and it can correctly use AJAX to load files data.

    -----------

    One interesting thing I noticed is that a big reason for the high reliability is that the agent created its own build-project.py tool.

    Instead of directly improvising Construct JSON every time, it generates the project through Python and converts that structure into Construct event sheets and project data, including sprites, animations, and other resources.

    That seems to make the whole process much more deterministic.

    -----------

    One small tip when working with coding agents:

    Whenever you finish a specific task, have the agent commit the changes to Git. Then start a fresh session for the next task. Try not to mix several unrelated tasks into one long session.

    In my experience, keeping each session focused on a single task helps reduce hallucinations and makes the output much more consistent.

  • I made a make a prototype with Claude Code:

    https://github.com/XHXIAIEIN/WaterSortPuzzle

  • There is not enough data for training, and there are very few freely available examples online, this is not enough for training.

    To pull this off, every Construct3 developer would need to have a spy in their engine that would peek at their code and collect it in big data, and then learn somewhere on the servers.

    Who would agree to give AI access to their projects?

    In fact, this is another area where Scirra has a real advantage over many other engines: a rich collection of high-quality example projects.

    https://editor.construct.net/#open-example-browser

    github.com/Scirra/Construct-Example-Projects

  • dop2000 reply pretty much captures what I was trying to say

    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.

    It also highlights why making Construct more readable for AI, through proper documentation and structure, would matter in practice.

    Many beginners now instinctively turn to GPT first when trying to solve a problem, but they often receive answers that look correct on the surface yet don’t fully match how Construct actually works.

  • What I want to clarify is that I’m not calling for Scirra to integrate AI features directly into the engine. That really isn’t necessary. Competing in that space would require the kind of large-scale technical resources that companies like Google or OpenAI have — teams of thousands of engineers constantly iterating on model capabilities.

    In fact, I would rather Scirra not attempt to implement in-engine AI features right now. It may be wiser to wait until the technology matures further. Given how fast model capabilities and compute are evolving, today’s integrations can quickly become obsolete.

    At the moment, simply saving projects as folder projects already allows developers to use external tools like VS Code or Cursor for AI-assisted workflows.

    The main idea of this post is different.

    Rather than adding AI features, I’m suggesting that Scirra provide the necessary foundation for AI to grow around Construct. In other words, a clear reference that allows AI to read and understand Construct properly. The cost of doing that would likely be much lower, and it wouldn’t require maintaining AI features directly.

    The goal is not automation for its own sake, but enabling AI to understand Construct’s internal data structures well enough to produce accurate and stable results.

  • 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.

  • The hide timer is 0.5 seconds for an inactive bar (if focused it will stay visible). If it takes longer than 0.5 seconds for an inactive bar to hide, that might be a bug. Do you have steps to reproduce a longer hide time?

    This issue is easy to reproduce.

    1. The Properties bar is docked and pinned on the left.

    2. The Layer bar is docked and unpinned on the left.

    3. When the mouse hovers over it, the Layer bar expands. Now, it overlaps with the Properties bar.

    4. Then, I click from Layout 1 to Event sheet 1 in the top main-tabs. Its hide-timer will reset whenever I switch tags.

    5. The Layer bar will then remain visible for 2-5 seconds before hiding.