Sooo... Since Clickteam doesn't even plan to fix this extremely 1996 feature in F2.5, did anyone find a painless workaround? Or at least something? Please don't tell me I have to code all the objects separately, or fix the same bug for each level, simple copying doesn't always do the trick
ping... anyone?
mmmm, an alternative to using qualifiers in global events... (*thinking*)
maybe
in global events picking all objects with flag (xxx)=on
and setting in each frame all qualified object's flag "xxx" on?
(or hardcoding all frame-qualified object's flag "xxx" in global events)
Not so painless indeed..
(and most importantly not as flexible as a qualifier would be)
that actually makes sense, and is better than anything i could think of. it just feels a bit too nasty for the performance, it would require many 'for each' loops and they would have to be triggered by 'always'. right?
i mean i would go with alterable strings, not flags, but still...
Depends on what you intend to do with qualified objects, I would guess.
Always-foreach could be avoided in general situations,
but should be needed on specific singular needs, I'd say.
For performances,
there is a widespread re-thinking on the nastynessgenerally associated to the always-foreach practice,
in many cases it works well without slowing down performances.
But this is to be tailored on your needs to be sure.
But the biggest drawback of this system would be for actions you would perform starting from the actives,
think of "collisions" or "which animation is playing?".... that would be pratically undoable.
You could only setup a very limited set of actions with this flagging system, I fear.
Another idea that just bumped in my mind:
(but would require a serious re-engineering of your game, I fear!)
not using qualifiers, but single active objects, for your "class" of objects,
and then playing with their animations, setting up a custom system.
Let's say you have group "good" (players).
You could set all "good" sprites (i.e. two different characters) in a single active, using custom animation slots,
then give an id, let's say "11" to first player
and "21" to second player, so on.
All animations will be calculated by id+(chosen animation)
and would have to be manually set,
but in this way you could nest different sprites inside the same object,
and then refer to a single object in global events..
schrodinger's method is used by War for Robovania, a game I've been working on, despite it actually not using Global Events, so I can confirm it works for some games at least. The game is a real-time strategy game that has multiple unit types, by the way, each of which behaving fairly differently, with one constantly dealing damage to the nearest enemy in a certain range (no projectiles), one firing explosive fireballs, one having a lot of extra hitpoints but being unable to attack, etc. And don't even get me started on the enemies and minibosses and bosses...
Wow, that looks cool hgf!
I'm curious about drawbacks of this method
(aside from that little to moderate
and most of all, on its -eventual- advantages!
I use qualifiers a lot in one project, and they suit very well,
but since my game is a one frame setup (no global events),
I really never hit any wall with them.
May I ask you, happygreenfrog,
if your choice was motivated by limitations/drawbacks in the use of qualifiers?
One I can already imagine, could be a partial additional handyness/"clean code",
having only one object instead of one qualifier + lots of objects (foldered)
Thanks
The choice was more that the engine I decided to base the game off of (I used the engine from Beetle Invasion) did it that way, and I saw no reason to not do it that way as well, since it works really well for what I want to do. For some units all I need to do is just make stats (such as speed, health, fire rate, range, etc.) for them and then make the graphics for them, and then that's it. For others, I need to add a few extra events for their extra traits, and their stats, but that's about all I have to add. It's a fairly easy process for the most part. The hard part is when the engine misbehaves with the stats I want to give a given unit, such as with the decoy (it was able to fire at point blank range at one point in time, which, due to a lack of attack delay, lagged the game like crazy (fortunately I found a solution to that and several other issues)).
However, that being said, it's a technique I wouldn't mind using again for other projects, with it working as well as it does. With the way it is set up in War for Robovania, it's not hard to get it working. For something like a platformer where the enemies and player characters and such need multiple animations, I could see it being a bit harder, though I can already see a potential solution to that...
Posting Permissions
Reply With Quote