Bubbles moving bottom-to-top
Paxton
Member Posts: 89
I am looking to have actors come into the scene from the bottom side, one after another, moving upwards (something like Tap the White Tiles). As time progresses, they should move faster and faster. The trick is to make the vertical space between actors constant, even as their upwards speed increases with time.
I tried 2 ways, both failed:
The bubble actor has a Move behaviour to move up, with a speed that is linked to an attribute that is constantly increased. Every 2 seconds, a bubble is spawned from the bottom. Why it doesn't work: as the speed increases, the bubbles will eventually be further and further apart.
First bubble moves up, and when it reaches Y200, it triggers the spawning of another bubble at Y-70. Why it doesn't work: it appears to work at first, but after a few seconds when the bubble speed increases, all of a sudden bubbles are not being spawned any more. The speed at which the algorythm stops working is random. It seems like this logic is too much for GameSalad to handle.
Any thoughts will be greatly appreciated. I'm stuck 
Comments
This does work (from your description), you've probably just implemented it incorrectly.
Demo file attached, see if this works for you (it works as expected for me).
"First bubble moves up, and when it reaches Y200"
The bubble probably never reaches Y =200.
If GameSalad runs at 60fps and the actor is moving at a speed of 340pps, it will travel 5.6666667 pixels per frame.
On frame 35 the bubble will be at y198.33333333333345
At frame 36 the bubble will be at y204.00000000000012
So if would have never 'touched' Y=200, so if you have a condition looking for Y=200, it will never be triggered (no bubbles get spawned).
Change this to when self Y => (equal or greater than) 200.
Also tried this, it didn't work. Might be related to the fact that when a new bubble is spawned, it appears at Y-70 and invalidates the "if Y >= 200". Things could be happening too fast to be processed properly, and sooner or later the rules will stop working.
Also tried with new bubbles to be spawned 0.2s after Y is 200, but it didn't change the problem.
Regarding your file - I will look at that the minute I get home! Thank you for taking the time!
How does the bubble's starting position 'invalidate' the "if Y >= 200" rule ? And what does 'invalidate' mean in this context ?
Guessing stuff isn't going to get you anywhere
Not guessing, but that's what is happening - using that logic, it should work (theoretically) - and it does, but only for a while. Sometimes after 5s, sometimes after 20s, sometimes after 60s the bubbles will stop spawning.
If the rule was broken, it would either work or not - or if it works partially, it should be consistent as to when it stops working. Right?
@Socks regarding the 'invalidation' bit - I didn't word it properly. If Y > 200, it changes a boolean to TRUE, and this triggers the spawning of a bubble at y-70.
Each bubble has a rule in it saying that if Y>200, have this boolean set to TRUE - otherwise, set it to FALSE.
I think that this boolean changes from true to false and the other way around way too quickly. Think about it: if Y>200, it spawns a bubble at Y-70 - there are no bubbles lower than y200 only during the time it takes for an actor to be spawned.
Yes, that is what is happening, but it doesn't then logically follow that therefore - things are happening too fast to be processed properly, that's just a guess.
We might not recognise 'consistent' in all circumstances, what appears to be random might have a perfectly consistent underpinning.
Why pass the information to an attribute, and then check that attribute (to see whether it is true or not) before spawning ? Maybe it's the way your game is set up and you need it to work this way, personally I try and keep things simple, an attribute is already being checked (if attribute Y >200), it seems odd that if this condition is met, then another attribute is changed, and then that attribute is checked before triggering the rule . . . . but the condition for spawning has already been checked for (and met) no need to move it somewhere else and then check again as you already know the answer !
At the moment you have:
If X is true, then make Y true, if Y is true then do action.
Whereas you could simplify it to:
If X is true do action.
I'd dump all the attributes and rules/conditions and keep it simple, I'd do it like this:
When self Y => 200
--Spawn bubble at Y-70
I'm going to guess this is a local (self) attribute ?
I'm not sure I understand how all this works to be honest, is this boolean a game level boolean, and are you relying on the actor being spawned at -70 to reset it to false ?
//
@Socks
The bubble has a rule in it: if self.positionY>200, change game.boolean to TRUE. If self.positionY<200, change game.boolean to FALSE.
TRUE means that a new bubble is spawned.
There is a spawner actor off-screen, which picks up the game.boolean. If this is TRUE, it spawns a new bubble at Y-70. Remember that the bubble has the rule described above in it. So if a bubble is spawned at y-70 the condition that "If self.positionY<200, change game.boolean to FALSE" is met. So the attribute becomes FALSE. The bubble moves up, and when it goes above Y200 the game.boolean is set to TRUE - a new bubble is now spawned at Y-70, and when this new bubble appears, the condition that "If self.positionY<200, change game.boolean to FALSE" is met again.
What I tried to say is that the game.boolean is true ONLY in the time it takes for a new bubble to be spawned, because once it is spawned, it will be at Y<200 and the game.boolean will become false.
I understand that I could bypass the game.boolean attribute by having the new bubble spawn behaviour inside the bubble actor, but it should still work even like I did, right?
It doesn't sound like an ideal way of working, as a rule is made true, the action of making it true makes it false (through the spawning of an actor that makes it false).
Race conditions incoming !
https://en.wikipedia.org/wiki/Race_condition
Both actors are triggering the same attribute (an attribute I am now guessing is a game level attribute) at the same time with differing values, when you are relying on tiny fractions of a second time differences (so you can use the same attribute to do two jobs) you only need introduce a small element like a change in rule order or layer order or the fact that you have Facebook or Photoshop open in the background and therefore using CPU (or whatever) and all sorts of strange things might occur.
Anyhow, I hope you sort it out, this really isn't a case of GameSalad not being able to handle two rules, this kind of thing is trivial and done all the time, I'm sure you can sort it out with a few small adjustments.