Hello everyone, this is producer Morino again! I hope you are enjoying the change in seasons now.
With the end of our summer, we’ve been able to release version 1.1.0, which had the first big change to the Visual Script UI and updated the engine to Godot 4.4.1.
In this Producer Letter, I’d like to look back at what we’ve accomplished and share our upcoming development plans.
Looking Back on Version 1.1.0
Visual Script UI Renewal
Due to all the feedback from the community, we were finally able to implement the ability to freely create links in any direction, just as done in Pixel Game Maker MV, instead of being restricted to left-to-right scripting flow.
Advanced users will notice that some features, such as holding the SHIFT key to force straighten lines, are not yet implemented, and we still think there are many areas (such as the Inspector interface) that can be improved. We will continue refining these systems in future updates.
Upgrade to Godot 4.4.1
This engine update brings many enhancements, but perhaps the most significant is the addition of UID support, which now makes it possible to track scenes used in Visual Script. This should also make it easier to organize a project.
We had hoped to also track things like variables and database values, but UID support did not resolve this issue. UIDs are only generated for externally output files, and cannot be applied to internal values such as variables or database data.
We do want to support this in the future, but it will require large-scale changes and thus more time. So it must wait for a future update.
Additionally, Godot 4.5 stable launched just before this update released. We plan to upgrade to 4.5 as well, but that will come later – after the development plans outlined below.
Development Plans
As of this release, 2 of the 5 development goals we announced back in Letter #12 have been completed, and 3 remain:
Release of the Linux editor / support for Linux export
Implementation of executable actions/conditions in GDScript
Creation of a lightweight object dedicated to bullets
Based on our progress so far, we’ve decided to revise and expand the near term roadmap. Our updated plans are as follows:
Overhaul of the collision detection system
Creation of lightweight objects that can be used for any purpose (not just bullets)
Implementation of executable actions/conditions in GDScript
Release of the Linux editor / support for Linux export
Let me provide some additional information about these changes and additions below.
Overhaul of the Collision Detection System
As reported in Producer Letter #14, we’ve decided to overhaul the detection system to resolve some root issues.
Background
In ACTION GAME MAKER, a rectangular detection area is automatically generated based on the size of the wall collision box. Rays (normals) are cast from this area to check for contact. While this is a common design, several issues have with our implementation have arisen:
False triggers when “clipping” into geometry Due to Godot’s physics, moving characters sometimes momentarily clip slightly into walls or the ground. Since each tile in a tilemap has its own collision, rays fired from certain angles may touch a neighboring tile, triggering a false contact. This causes problems such as contact suddenly activating when walking, or landing on a wall when jumping toward it.
Slopes and Tile Gaps
Because detection is rectangular, on slopes the character may only touch tiles at a corner. Furthermore, Godot tiles have invisible gaps between them, through which rays can pass. Combined, this leads to situations where the character visually appears to be on a slope but the program is not registering any collision.
We tried adjusting ray origins, timing, and size to address this, but it ultimately proved unworkable.
Collision sizes vary greatly by game—from tiny 1x1px to extreme 1000x2px—plus resizing, rotation, or even complex shapes (like banana-shaped hitboxes). To handle this diversity, we concluded that a full redesign is necessary.
Redesign Approach
We will move away from simple auto-generation. Instead, we’ll allow more parameters to be configured:
Number of rays
Their spawn positions
Whether detection requires all rays to hit or just one
This will give you the ability to tune detection for your specific game and fundamentally resolve the current problems.
Multi-Purpose Lightweight Objects
We’ll introduce a new game object based on Godot’s Area2D.
Originally planned just for use in creating large numbers of bullets, we now intend to provide it as a general-purpose object for cases where physical collision is unnecessary.
Object Details:
They will not support physics-driven behaviors, such as running along tiles or sliding down slopes.
Action Game Maker pre-defined actions that rely on physics, like Bound (MovementTemplates), will not function with this object type.
However, all other Visual Script behaviors should function as expected.
We cannot stress this enough: since it cannot physically collide, it’s not suited for player characters.
It is intended for and should be useful for bullets, items, destructible objects, and other similar doodads and elements.
While it won’t collide physically, it can still detect contact and overlap with tiles or other objects. So, for example, stopping movement on contact is possible.
Closing Words
We know some areas are still not fixed to the level that some people would like to see, and we sincerely apologize for the inconvenience for this.
But I hope we have earned your trust that we are working to not just resolve known issues but also to add in features that users want to see! We are still hard at work, and hope you will continue to be with us as we work to bring you an even better tool.
That’s all for today’s Producer Letter.
See you in a month!