This is a general request for multi-dimensional and continuous attachment constraints with specific API requests. These features all work together in tandem to create a comprehensive attachment constraint API with a consistent theme, so I bundled them together here.
There is a single API currently that I consider a good example of a multidimensional, continuous Attachment constraint. The PlaneConstraint is extremely useful and provides value constantly in my projects. Most of these APIs build off of that design.
I’ll give an example with each component of this request.
Spline Constraint
Spline Constraints would constrain two attachments such that A1 is constrained to an arbitrary spline shape centered on A0. This spline could be edited in studio with minimal changes to existing tools.
Right now, trains and minecarts are very difficult to make. You can’t rigidly connect the cab to the track because there are no continuous, deformable constraints. With a Spline Constraint a developer could easily lock a train onto a track.
This should have an option for automatically closing the loop, to allow train and minecart tracks to easily loop back onto themselves.
This should have options for continuing indefinitely past the start and end. A train that players can drive forward indefinitely to encounter procedurally generated game content comes to mind.
This should have an option for widening the spline, at particular points into a flat ribbon. Consider a game where players can drive a car down the road but shouldn’t be able to drive into the market stalls. A ribbon spline constraint would allow the developer to continuously constrain the car to the road, allowing a degree of freedom for steering.
In addition to the ribbon width option, the spline should be able to switch between a ribbon mode and a tube mode. The tube mode would allow the spline the envelop space around it. Consider a pachinko machine with balls flying through a tube. The balls should be able to bounce around freely within the tube, but they should be constrained within it. A tube spline constraint can accomplish this.
Hull Constraint
Hull Constraints would constrain two attachments such that A1 is constrained to an arbitrary 3D hull centered on A0. The hull could be built in studio just by positioning a number of child vertex instances.
Right now, it’s very hard to constrain players to a playable area. Invisible walls have historically been used for this, but they’re also a famously bad solution. They complicate the building process by introducing a new class of primitives to your game, and players can simply clip through them under in less-than-rare circumstances. With a hull constraint, a developer could easily constrain players and game entities to the playable area.
This should have an option for binding a vertex to an Attachment. Playable areas can change during gameplay, and connecting physical objects improves the flow for map creation.
Prism Constraint and Spheroid Constraint
These should be considered as additional features to supplement the Hull Constraint. They can provide very similar features, but as simpler constraints they can be edited and manipulated by developers more easily.
Constellation Constraint
Constellation Constraints would only constrain one attachment, and they would reference other continuous or multidimensional constraints to create a complex 3D space where an attachment can move freely.
The above examples are simple and easy to grasp, but they fall short when you try to actually make a game with just those pieces. The Constellation Constraint combines their individual, primitive features into a complex system that’s suitable for practical use.
Consider the train example from the Spline Constraint. What happens when the track splits? Without a constellation constraint, you need to make multiple splines and then manage attachment references from luau. When luau mistimes this, you end up with a discontinuity in your simulation as it snaps to the correct spline. If you use a Constellation Constraint you can refer to both splines and then the train will be able to path down either one, continuously and without script intervention.
Consider the car example from the Spline Constraint’s ribbon section. What happens when the car encounters an intersection? Without a Constellation Constraint, you need to switch which spline is constraining the car based on some best guess heuristic. When you get this wrong, the car is unable to move along the road until your code figures it out. With a Constellation Constraint, you can simply create a ribbon spline for each road and add them all to a Constellation, then constrain the car to the Constellation. Now your car can drive along any associated road spline.
Consider the playable area example from the Hull Constraint. This works great with a hull-shaped area, like a basketball court or a lobby, but what about a more complicated or open-world layout? By design, the hull can’t represent twists and turns in the playable area. You’d have to use luau to best guess which surface your players and game entities should be constrained to, and you’d have to do this constantly for everything in the game. With a Constellation Constraint, you can just add all your playable area volumes - Hulls, Splines, etc - to a single constellation and just bind your characters and game entities to that constellation. A single step, right at the beginning of the game, constrains them for the rest of the server’s lifetime.
Conclusion
Complex constraint systems are difficult - and sometimes impossible - to achieve without a comprehensive API for constraining an attachment’s available positions. This API set provides layers of complexity that allow inexperienced developers to engage with the fundamental features while still providing experienced developers with the tools they need.
Hopefully this makes sense. I tried to keep this focused on real-world use cases that I constantly run up against. Let me know if anyone has any questions. 