The title is fairly self-explanatory, but just to clarify, by “Trigger Mask”, I’m referring about detection areas similar to what fighting games and other similar genres call “Hit-Boxes” and “Hurt-Boxes”. The primary reason is that the game engine is not very friendly for these types of games that rely on this core feature to work properly. And the only way you can “kinda” get it to work, is by creating some separate invisible sprites that use the collision boxes. However, this method quickly becomes far too inefficient once you start getting into complex animations sequences and needing a constantly changing Hit/Hurt box that is common for most games of this genre. TBH, I’m surprised this feature wasn’t in the engine already since this should be a fairly standard feature for a flexible 2D game engine like GDevelop.
I already know how to make collision boxes, the issue is the fact that you can ONLY make collision boxes which sometimes isn’t desirable. I’m talking about simple NON-COLLIDEABLE detection boxes. And the reason for this is because having collisions for your hitboxes lead to your sprites clipping through walls when doing certain actions, and having to create a separate sprite for EVERY hitbox will just lead it to it being a time consuming/organizational nightmare, as well as blowing the size of the game file to unreasonable levels.
The way I do it is the same way (logically connecting indicators rather than drawing something manually) they show to do it in Defold and Unity tutorials I’ve found from a quick google.
Create extra custom points on your object named things like “hand” and “head”. Move the points on each unique animation to their respective place.
Create a generic object (sprite or whatever you prefer) and shrink or stretch it to the size you want. Name that single object type to “hitbox”
Give each one a variable that says what name point it should attach to. This should be the same name as the custom point
Use a for each “hitbox” event, and in the actions just use the “center position” action, with the target being the Object.PointX(hitbox.VariableString(yourvar)) or PointY expressions.
This will keep those hitbox objects pinned to the respective points on the original object, and can be targeted via whatever events you want going forward
This mostly matches how 2D fighting games were done even going back as far as street fighter 2, although they manually had to write the coordinates and size of every hit box for every frame, and in GDevelop you will be able to just adjust place the objects and use scale/size events if you need to.
Fighting games and similar other games use multiple square/rectangle hitbboxes and not “match the exact shape of this character”, so you won’t need to super customize the players collision mask or that of these hitboxes.
If you can find examples of other 2D engines that do something different, definitely post those examples, but I can’t find any currently.
I’m also aware of this method, and although it solves the character sprite from clipping through walls, it doesn’t solve the issue of the “Hitbox Sprite” triggering events behind walls because of how the engine handles collision boxes overlapping each other. And there’s also still the issue of having a MASSIVE number of different Hitbox sprites I would have to manage, which again would balloon the game file size. All I’m asking for is to be able to toggle the collision behavior of the collision masks off so I can better control the behavior of my animations. Plus, this small feature would render the need for “Hitbox Sprites” obsolete anyways. As for an example of this, there’s an old engine called “Fighter Maker 2002”, and how it handles hitboxes is that you can draw the box to the shape you need, and there’s a tick-box called “Striking” (not a great name TBH) that allows the box to become collide-able with other hitboxes marked the same way.
No, you have a single hitbox sprite. You create multiple instances of the same object (not unique objects) into the scene and give them each an instance variable, and that variable is what dictates which hitbox they actually are. That’s why you use a “For Each” as mentioned above. For other events you would also use that same variable in conditions to only select the hitbox sprite you want for the event itself.
You’d have to give more context here.
Speaking only as a community member, the devs of GDevelop have mostly indicated they are focusing on making an equivalent to Defold, Unity, Godot, Construct, etc.
Fighter Maker was a special use engine like RPG Maker (by the same company) and really isn’t a example for a general use engine. Similarly, for RPGs there will always be special task things that RPG Maker is going to be better at, and generally the devs would not spend time on something that isn’t utilizable as a more general purpose thing.
To be clear, this isn’t a “No they won’t do this”, its a “it may not make sense to the Devs or contributors from a level of effort vs the amount of interest/value created by adding this”. It’s been asked in the past but only a handful of people showed interest. Multiple mask that can be used individually
My character does a “Pull Lever” animation, and it some how affects a lever object behind a wall when it’s not suppose to. Or it does a punching animation too close to a wall and it somehow completely teleports through to the other side of the wall.
Ok, better example, Unity literally has “Trigger Boxes” that don’t have a physical mech to collide with, but still can trigger events.
That definitely sounds odd, it shouldn’t be possible to touch the other lever unless something’s going real weird with the collision masks. It might be a good use case for custom points on the lever and using “Point is inside object” conditions instead of just checking for normal collision for that.
This somewhat matches to the link I have above. Again, personally I have no qualms with the idea, I just haven’t seen enough interest from the community to get it on the main devs radar, or a contributor (non-GDevelop company dev) that has shown interest in taking a crack at it.
So you’re telling me there might be a bug with collisions?
Thats a shame, because that would make life easier for quite a few people who aren’t just creating little platformer games. And as I’ve stated in a previous post, all they would have to do is add a little tick-box next to the collision masks that allows you to turn off collision behaviors and have it be purely a trigger box.
I’m telling you that what you’re describing shouldn’t be possible with the information you’ve provided. If your collision masks are huge and go through the wall to touch two switches, totally possible and not a bug. But if the mask never goes past the wall, it won’t activate both of them unless your events are set up in a way that would activate both of them.
Easiest way to tell would be to activate the visual debugger (search for the action that says “show visual debugger” in the action list, it’ll draw all hitboxes during a preview).
Alright, I guess Gdevelop isn’t the engine for my project then, which is a real bummer because I actually like the layout. Hopefully i’ll find something that works how I need it to work, or something gets added to Gdevelop that makes it easier on me to make my project. But considering my budget and coding skills are about as non-existent as an ice cube’s chances in the middle of the Sahara, I’m going to have a hard time with that lol.
I would recommend to not give up, and to try the method I mentioned above. If you decide not to, I sincerely wish you the best of luck with your next endeavor, and hope you eventually make the game of your dreams.
Don’t worry you will make the game of your dreams, no matter what engine you choose to get there. You must become the Rocky Balboa of game devs.
Ok, I’m a complete idiot. Apparently, my problem came from the fact that my object has the “Platformer Character” behavior. And as for the multiple hitbox sprite issue, instead of having a separate invisible sprite for my hitbox, I invert that idea by having my platformer object be invisible while I have the character sprite overlayed over the invisible sprite and have the character sprite be the hitbox. That way, I can have bug-free platforming while keeping the precise hitboxes for the fighting aspect of the game. I’m changing the title of this conversation to reflect this discovery.