Geometry Dash's triggers are some amazing tools, allowing creators to build some amazing works of art in the editor. But anyone who's tried to become more advanced in their trigger use knows that you can get lost in a sea of triggers when creating some of the more exceptional effects. I'm going to break down some ways GD's triggers can be improved so that creators can more efficiently design what they want without the headache of tedious trigger logic.
One thing all triggers need is a delay parameter. That is, a number which delays the execution of a trigger for a specified amount of time. Now, this was kind of already the purpose of the spawn trigger. The spawn trigger is great if you want to delay a group or triggers, but if you're only delaying one trigger, using a whole spawn trigger seems like a waste. It makes editing faster if you don't have to go into a separate trigger to change a single delay time variable.
Speaking of the spawn trigger, that needs an upgrade as well. While spawns, on the surface, are just a delay trigger, stringing a sequence of spawn triggers together can allow you to create loops. These loops are crucial for levels with non-GD gameplay, such as Serponge's Altergames and other minigames. The thing with spawn loops is that you need as many spawn triggers as groups you're looping through. If you're looping through 10 groups, you need at least 10 spawn triggers. This is because the spawn trigger can only call one group.
The obvious fix for this would be to have the spawn trigger call multiple groups. If the trigger could call multiple groups and set the delays for each one, it'd essentially function as multiple spawn triggers. Add a simple loop button and your loop is ready! For bonus points, RobTop could add a value for how many times you want to loop so you don't have to introduce all the pickup and count triggers, and the item ID system.
This upgraded spawn trigger takes what could be a theoretically infinite number of triggers down to only one! Below is one idea of how the spawn trigger interface might look.
Geometry Dash's pulse trigger could use some work too. The pulse trigger should have a slider to set the opacity with. You can affect opacity with the color and alpha triggers, but seeing as the pulse trigger is the most used out of the three, it really needs this option. Plus, to recreate an opacity pulse with either the color or alpha triggers, you need to use two of them. One to set the opacity, and then another to fade it back.
Doing this is pretty cumbersome and is part of the reason why the pulse trigger was even created in the first place; to avoid using two color triggers to flash colors. Flashing an opacity isn't too common, but I believe part of the reason is because it's more hassle than it's worth to implement. If the pulse trigger could affect opacity, we'd be seeing loads more effects using this feature.
We also need HSV sliders in the color trigger. Like the last one, this feature is already present in another trigger, the pulse trigger. But, obviously, for permanent color changes, you'd want to use a color trigger. Perhaps all the HSV options the pulse trigger has could make the color trigger too cluttered, so RobTop could create a dedicated HSV trigger for a robust HSV changing system.
An HSV trigger could be particularly useful to work on an object's HSV parameters rather than a color channel. You know, those HSV sliders that are available through the "Edit Object" button?
The pulse trigger doesn't override those, and in fact, once you set them in the editor, they cannot be changed during runtime. So the HSV trigger would save you trying to work around that hard limitation with a million triggers.
Last for today will be the move trigger. There is just so much potential for it, but I'll cover just one improvement. If you've ever tried to use move triggers with rotate triggers, you know it can be a nightmare. Just look at Jezor's Most Tedious Effects In GD video to see the hundreds of triggers used for an effect using the two types of triggers.
The reason move and rotate triggers don't work well together is because all their movements stack on top of one another. This stacking is actually incredibly useful for the most part, but this is one time where it's a hindrance. To paint a clearer picture, if you have an object rotating around a target and you use the "use target" option in the move trigger to move the object towards the target, the object will miss the target. While the object moves, the rotate is still in effect and effectively offsets the object to where it's no longer heading in the right direction.
Now, RobTop doesn't have to implement a whole parent-child system to have the object move relative to its parent. A simpler option would be to have the move trigger recalculate the move direction. That way, the object is updated to always move towards the target, even while it is rotating. And boom, a whole field of effects combining the move and rotate triggers is unleashed to creators!
More trigger improvement suggestions are discussed in this video.
RobTop usually adds new triggers to suit his own creative needs while working on new updates, so he's clearly not creating all these effects or I'm sure he'd have implemented these features already. RobTop said he'd be taking more community requests post 2.2, so we have a chance for these ideas to be heard. Fingers crossed!