The Daily Click ::. Forums ::. Klik Coding Help ::. Does the order of conditions matter?
 

Post Reply  Post Oekaki 
 

Posted By Message

nim



Registered
  17/05/2002
Points
  7233
29th August, 2009 at 11:43:36 -

Something I've been wondering since having a bit of trouble with a project. I know the order of actions matters, but what about conditions? I'm talking about when you're trying to select a few instances from multiple instances of an object. For example,

Pick object "Active" at random
"Active" collides with backdrop
Internal Flag 0 is on

I haven't messed around with it much so I really don't know. Anyone have a quick answer?

 
//

aphant



Registered
  18/05/2008
Points
  1242
29th August, 2009 at 12:13:39 -

Order of conditions do matter. In your example, that will pick an object at random, then test if it collided with the backdrop. If it did, check if flag.0 is on, do stuff. If it didn't, then move on to the next event.

If you reordered it like so:
"Active" collides
Pick random
Flag on?

You would end up testing objects that collided with a backdrop first, then pick one at random and see if it's flag is on.

Also, having the collision test first is an 'immediate event' (it's red!), meaning that event isn't tested until an active collides. Picking at random means that the event is tested every cycle.

 

nim



Registered
  17/05/2002
Points
  7233
29th August, 2009 at 12:22:08 -

Thanks very much

 
//

[DELETED]

Likes to put dots on paper

Registered
  08/12/2008
Points
  118

MushroomVIP MemberARGH Sign
29th August, 2009 at 13:08:10 -

I never really saw that it did but as of lately I have started to understand that everything must be in order, really. All the events, conditions and actions.

 
n/a

Silveraura

God's God

Registered
  08/08/2002
Points
  6747

Game of the Week WinnerKlikCast StarAlien In Training!VIP Member360 OwnerWii OwnerSonic SpeedThe Cake is a LieComputerChristmas Tree!
I am an April Fool
29th August, 2009 at 16:08:52 -

A lot of things work out of order, which I think is what leads a lot of people to believe that the glitches are in MMF itself, whenever they put the conditions or actions they want in, and something goes wrong. Once you start playing things out in your head and you make sure all the conditions and actions are in the appropriate order, you'll suddenly find yourself doing a lot more programing, a lot less debugging, and suddenly the whole process becomes a little more fun than frustrating because things just work.

 
http://www.facebook.com/truediamondgame

[DELETED]

Likes to put dots on paper

Registered
  08/12/2008
Points
  118

MushroomVIP MemberARGH Sign
29th August, 2009 at 17:23:34 -

I must say I do enjoy the debugging process when you *can* find bugs. It's a good feeling to run your program, it screws up, you go "Hmm!?" and then return to MMF, find what caused it and rectify the order or events. Or perhaps a condition that wasn't quite right.

 
n/a

UrbanMonk

BRING BACK MITCH

Registered
  07/07/2008
Points
  49566

Has Donated, Thank You!Little Pirate!ARGH SignKliktober Special Award TagPicture Me This Round 33 Winner!The Outlaw!VIP MemberHasslevania 2!I am an April FoolKitty
Picture Me This Round 32 Winner!Picture Me This Round 42 Winner!Picture Me This Round 44 Winner!Picture Me This Round 53 Winner!
29th August, 2009 at 18:04:45 -

I moved to gf from dark basic so I just assumed everything is checked/executed in order.

 
n/a

AndyUK

Mascot Maniac

Registered
  01/08/2002
Points
  14586

Game of the Week WinnerSecond GOTW AwardHas Donated, Thank You!VIP Member
29th August, 2009 at 18:18:02 -

One problem with The games factory is that although the action order matters just as it does in MMF1.5 or MMF2 you can't actually change the order without deleting them and remaking the actions in the right order.

But yeah, you can get completely different things happen depending on what order you have your actions.

A really simple example for instance.

Create object at 0,0
move object to 32,32
destroy object


move object to 32,32
destroy object
create object at 0,0

 
.

nim



Registered
  17/05/2002
Points
  7233
29th August, 2009 at 18:22:51 -

Just to clarify, my original post was about event conditions, not actions.

Edited by nim

 
//

AndyUK

Mascot Maniac

Registered
  01/08/2002
Points
  14586

Game of the Week WinnerSecond GOTW AwardHas Donated, Thank You!VIP Member
29th August, 2009 at 18:28:16 -

I get a bit confused between the different terms.

 
.

nim



Registered
  17/05/2002
Points
  7233
29th August, 2009 at 18:36:47 -

No problem, that's useful to know too, as is the event order itself.

I have trouble determining when MMF's internal "action loop" will perform the action on each object. I have trouble sometimes knowing when to use a fastloop and when MMF will do it automagically. Since I learned fastloops, I think I overuse them to loop through each instance of an object since that's how most real languages would work.

For example:

User presses [Space] : Destroy "Active"
..will obviously destroy all instances of "Active"

User presses [Space]
+ "Active" Flag 0 = ON : Destroy "Active"

..will destroy only those instances of "Active" with flag 0 on

but something like
"Active" is overlapping "Active"
+ Y("Active") > Y("Active") : Destroy "Active"

..doesn't work at all. (I want to destroy the lower instance)

So in situations like that, I usually fart around with fastloops and "Pick one at random" until it works, but I've never actually got to the bottom of how MMF selects instances.

Edited by nim

 
//

Muz



Registered
  14/02/2002
Points
  6499

VIP MemberI'm on a BoatI am an April FoolHonored Admin Alumnus
30th August, 2009 at 16:10:03 -

Yup, condition order is perhaps one of the most important things, memory wise. Normally you want all 3 conditions, so you won't notice it, but it goes from top to bottom. So, it's good to get the least likely condition at the top, to get MMF to scan through less objects. Say, if you have "A overlaps B" and "Flag 0 is on", it's best to have the "flag 0 is on" first, because it's much less memory intensive than the overlap check. If the overlap is first, it only checks the flags for all the objects that overlap. If the Flag check is first, then it calculates overlapping for each and every object that has Flag 0 on.

"Pick at random" is the most interesting one with object ordering. If you put it first, it will check the conditions for some random object, which is useful in some situations. If it's lower, then it actually picks out random objects. So if you're trying to pick random objects that meet a certain condition, it should be last. Putting it first means that you're picking them in random order.

If you don't have "pick at random" in the first line, MMF will check conditions from the first object created.

 
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.

Image

Del Duio

Born in a Bowling Alley

Registered
  29/07/2005
Points
  1078

GOTW WINNER CUP 1!GOTW WINNER CUP 2!GOTW WINNER CUP 3!GOTW WINNER CUP 4!Evil klikerHasslevania 2!The OutlawSanta Boot
1st September, 2009 at 17:19:15 -

Just to add for the hell of it, I've noticed that you need to have keypress checks first in the event order for them to work. Unless you don't have to and my coding is crap, which could very well be.

 
--

"Del Duio has received 0 trophies. Click here to see them all."

"To be a true ninja you must first pick the most stealthy of our assorted combat suits. Might I suggest the bright neon orange?"

DXF Games, coming next: Hasslevania 2- This Space for Rent!

Silveraura

God's God

Registered
  08/08/2002
Points
  6747

Game of the Week WinnerKlikCast StarAlien In Training!VIP Member360 OwnerWii OwnerSonic SpeedThe Cake is a LieComputerChristmas Tree!
I am an April Fool
1st September, 2009 at 20:47:19 -

"While key is pressed" will work as a second line, but you need to have events like When Key is Pressed as the start event because it's an immediate fire event, not looping. That's why it turns red when it's the first line.

 
http://www.facebook.com/truediamondgame

nim



Registered
  17/05/2002
Points
  7233
2nd September, 2009 at 01:05:01 -


Originally Posted by Muz
If the overlap is first, it only checks the flags for all the objects that overlap. If the Flag check is first, then it calculates overlapping for each and every object that has Flag 0 on.



So if Overlap is first, MMF checks every combination of objects to see if they're overlapping? That's very interesting, thanks. How did you discover that?

 
//

Silveraura

God's God

Registered
  08/08/2002
Points
  6747

Game of the Week WinnerKlikCast StarAlien In Training!VIP Member360 OwnerWii OwnerSonic SpeedThe Cake is a LieComputerChristmas Tree!
I am an April Fool
2nd September, 2009 at 01:45:24 -

It sounds like it has to do with MMF2's object selection system. It allows MMF2 to narrow down what object the actions will have an effect on, which makes it a lot easier and predictable to make games. Without it, it would be surprisingly difficult to make a game with multiple copies of an object.

 
http://www.facebook.com/truediamondgame

Levirules



Registered
  27/09/2008
Points
  37
2nd September, 2009 at 03:35:04 -

Indeed. It's one of the things that makes MMF easier, although I find myself creating more complex code to replace what MMF tries to hide from us.

In a normal programming language, you would have to do a "For every [object]" loop, perform a check, and execute code, all just to find something out about one object. So, in MMF, you have something like this:

If bullet is overlapping enemy: destroy enemy

If you have 4 enemies on the screen, and the bullet is overlapping one enemy, what MMF will do is create a list of all active objects, including the bullet and all 4 platforms. It will determine which enemy the bullet is overlapping, and take all of the enemies NOT overlapping the bullet off of the list. Therefore, it will only destroy the one enemy left on the list.

In real programming, every instance of an object has an index value. To accomplish this, you would have to write something like the following to pick which enemies have a bullet overlapping them:

For each bulet:
For each enemy:
If bullet is overlapping enemy: destroy enemy
End for
End for

You would have to write code that cycles through each bullet and each enemy (and you would have to write code to see the overlap too, unless the API includes an overlap function) in order to specify which is overlapping which.

As a side note, MMF doesn't destroy active objects until after all of the events have been checked and run. The advantage of a normal programming language here is that it would destroy them immediately.

 
n/a
   

Post Reply



 



Advertisement

Worth A Click