What would be the best way to create a trigger area?
To detect when you enter, stay and leaves the area.
I think you haven’t many options… You could use a Sprite (any custom collision mask, even pixel-perfect in native but poor performance), or any other object with modifiable size to get a rectangular collision mask (Tiled Sprite, maybe Text, etc.), and the performance hit won’t be noticeable in the final game unless you have hundred of trigger areas to check, if so (you have hundred of trigger areas) you’ll have to check the performances by yourself hehehe 
Initially, I thought to use a sprite as trigger area, but you can not use empty sprite in collision mask(Uses detection by pixel)
After, ask the question if there was any possibility of using the physics engine.
I have not found any possibility of using the physics engine, not having to use mask collision with detection pixel.
Finally I used an algorithm to detect if two rectangles overlap. I use a empty sprite as trigger area.
Download link: http://www.speedyshare.com/3xYgz/TriggerArea.zip
Using the physics engine for a trigger area collision detection isn’t the best option, you should set the physics object as not collidable (to walk through), and then the collision detection from the physics engine wouldn’t work at all I think…
I would use a sprite object, with an simple image as texture, for example a semi-transparent green (or multy-colours to represent different event types, visually) with a small size since the image has only a constant colour (32x32).
Then, at the beginning of the scene, just hide every trigger area object (at the beginning of the development process you can leave the areas visible for debugging).
Then you can use the mask collision detection, the fastest choice. But if you found that the performance is going bad, you could try with a tiled sprite, this object has a rectangular collision mask but, unlike sprites, this one doesn’t need to check for timers and animation switches (sprites has to do it even if they are hiden I think).
Finally, in the previous reply I was about to discuss structure variables, but then I came that you should check collisions through hand written rectangle-rectangle collision detection algorithms, but since you are doing it already …
The ultimate choice for super-performance and a super-UNfriendly system is to use structure variables, with the form:
TA:
Rain00:
left 150
top 870
right 200
bottom 970
Rain01:
...
Enemy00
Enemy01
Cinematic00
Boss00
...
Then you can check every TA (trigger ara) with the character position-size through your algorithm to trigger the event or not.
There are two problems: This system is very ugly, and not easy for debugging, update, etc… The second problem is that you take the character collision mask as the entire image size (Player.X(), Player.Y(), Player.Width(), Player.Height()), this way if the image is a lot bigger than the real character, you’ll have a lot of inaccuracy errors.
To solve the second problem, and make this system even more ugly and harder (almost impossible) to maintain, add two points to your sprite frames, the top-left and the bottom-right, and check the trigger area vs the rectangle made from these points.
To give an idea of the syntax:
Do = Variable(TA.Rain01.Left) to variable TA_Left
Do = Variable(TA.Rain01.Top) to variable TA_Top
Do = Variable(TA.Rain01.Right) to variable TA_Right
Do = Variable(TA.Rain01.Bottom) to variable TA_Bottom
Do = Player.PointX(TopLeft) to variable Left
Do = Player.PointY(TopLeft) to variable Top
Do = Player.PointX(BottomRight) to variable Right
Do = Player.PointY(BottomRight) to variable Bottom
If (Right > TA_Left) AND (Left < TA_Right) AND (Bottom > TA_Top) AND (Top < TA_Bottom) ===> Collision
Note that the last line is the only one checking for the collision, the others are just storing the values in variables with a shorter name for a better reading 
So… try sprites with little images 
I would use an image, in the case of irregularly shaped areas.
But it is normal to have a rectangular or circular shape.
If the area is circular, it would still be simpler algorithm collision, we would have to calculate the distance. But we could not see the area from the editor, because there is no object with circular shape in GDevelop.
If we use structures, I think we would lose the GDevelop approach.
I continue to use an empty sprite where we can move and size the trigger area visually from the scene editor, without having to hide anything.
About the circle collision, you’re right, it’s easy and fast just checking the distance vs the sum of the radii, but you need to take both the trigger area and the character as circles.
To represent it visually, you could use again a sprite with a little circle as texture, and radius = sprite.Width()/2.
Why do you use an empty sprite instead sprites with a simple texture? The event to hide them all would be:
At the beginning of the scene: Hide object TriggerAreaBut you need it only during the development process. Before exporting it to release, you can simply delete this event that hides the objects, and delete the animations/frames from the trigger area objects, I can’t find a reason to use empty sprites 
Because, for me, it is enough to select the trigger area to see the mask.
But yes, that would also be a good choice to circular and irregular area.