Getting a rule to loop over and over until a condition is met.

markb

I was trying out a rule that moves an actor between different points on the screen (read in from a table) but it wasn't entirely behaving as expected and in addition it stopped after the first iteration. So if I want enemies in a game to keep patrolling an area in a certain pattern until the player comes close enough to attack, how would I do that?

gyroscope

@markb

Hi Mark, loops aren't catered for with a behaviour unfortunately; maybe one day..... so in the meantime, there are workarounds.

One way I'd do this is make a two new attributes, the first one a boolean to act as a toggle; and a second one an integer for the loop. Set this to the amount of times your actor goes back and forth

(I've made the Rules using straight attributes; you can substitute for your table entries, of course, if you wanted).

Rule: When RunThro > 0 and Toggle is true

-----this toggle value above is if you want to trigger it as new at some point, where you just need a Change Attribute Toggle set to true from false somewhere else. Otherwise, if you're wanting the loop to happen straight away, change the value of Toggle to false in the attributes list before runtime)

Change attribute Toggle to false
--- nested in the one above--- Rule: When YourActor.Position.X =30
Interpolate YourActor.Position.X to 390
Change Attribute RunThro to RunThro-1
Change attribute Toggle to true
otherwise
Change Attribute RunThro to RunThro-1
Interpolate YourActor.Position.X to 30

markb

Thanks. I can't believe there's no support for loops, it's such a basic programming staple. I'm wondering if your technique doesn't get messy when dealing with a lot of actors, though. The other problem I ran into was that I would put four "move" commands in my rule and only 3 of them would execute. So now I'm wondering if it wouldn't make sense to put each move into its own rule and make the rule check to see if the actor's X or Y coordinate is equal to the position set in the previous rule. It's not very elegant.

MotherHoose

if; elseIf; for; while; loop; etc. are languageTerms for conditional statements
that is: if the condition is true … do this action
think: when and what

Game Salad simplifies programming for us with our Rule and one term: When
most all conditional statements no matter what the term/functionality can be easily done in GS

Example:
gameAttributes: playerX; playerY
for conditions the enemy needs reference to trigger its behaviors

enemyActors also need to know what their state should be
… to determine when condition is valid … and values for their when conditions

enemyAttributes: range; rowCount (if using Tables)

Rule: when
Attribute: self.range ≤ magnitude( game.playerX - self.Position.X , game.playerY - self.Position.Y )
-do these behaviors
(for continuous triggering of these behaviors:)
-Timer: Every ??? seconds… for loop
   with tables:
       change rowCount to rowCount+1
       changeX/Y (whatever) to tableCellValues(table,self.rowCount,col)
       Rule: when
       Attribute: rowCount = tableRowCount(table)+1
       -changeAttribute: self.rowCount To: 0
(or for simple movement: change MLV X/Y to: -MLV X/Y)
Otherwise: do this: a movement to playerX/Y (attack)

MH

gyroscope

An excellent explanation & suggestion by MH there. :-)

@markb I've no idea what you mean about the Rules I suggested getting messy with more than one actor....

So for more than one, just put those straightforward Rules I suggested in a prototype in the Inspector, make more attributes: the Toggle attributes called Toggle1, Toggle2, etc; for instance; similar with RunThro (RunThro1, RunThro2, etc) - drag as many actors as you want onto the screen, then unlock to amend the left and right coordinates in each one's Rules, as well as changing theToggle and RunThro attributes each time, then you're done. Nothing messy about that...

As for moving the actors, it's probably best to use Interpolate rather than Move To in this instance.

Anyhow, if you still think this way messy, try your way, hope it works out.

markb

By messy I meant that you would need separate attributes for each actor. However, I thought you meant game attributes and forgot for a moment that Actors can have their own attributes, which makes it much easier to browse. Anyway, I just realized that it makes more sense to have the movement be in relation to the Actor rather than the Scene, in which case it automatically loops. A series of moves that end up at the origin point should do it.

gyroscope

If you need your actors to move backwards and forwards so many times but different amount of times for each, and for each to have their own start and end coordinates, and different moving times, then yes, of course they need their own attributes, self or otherwise.... don't know why you find that messy.... until GSC has a Telepathy Behaviour there's not much else to do... ;-)

Nor will making "the movement in relation to the Actor rather than the Scene" make it less "messy" either ...

"A series of moves that end up at the origin point should do it" Yes, of course it will, that is exactly what you asked for in your question. Just how you do it is still unclear.... it seems my solution is "messy" to you, so I guess you'll do it your unmessy way, whatever that is.

markb

Didn't have time to try your solution, but realized that I could just make a series of rules moving the actor to location 2 if it is at location 1, location 3 if it is at location 2 and then location 1 again if it is at location 3. Loops perfectly! Thanks for your time.

The_Gamesalad_Guru

That's what frame rates are that are monitored via the viewer this is how many times a second the code is scanned especially a loop. This is why people shoot for the best FPS as the faster the code is scanned the quicker the program notices a change in condition of an attribute and triggering of a rule. Especially when you make a rule based on a condition of anything as MotherHoose described, it is looped (scanned) at the frame rate of your game.