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?
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.
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.
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.
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.
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
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.
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.
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!
"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.
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?
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.
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.
Advertisement
Post Reply
Edited by nim
