I've been making little games in mmf2 for a while now, I did this by messing around in the program and
finding ways to make stuff move and interact. This I feel is the most fun of scripting. Making something work
by trial and error.
The down side is, that I don't really know if what I'm doing is the most optimal for computer performance. And I don't know what the standard way of working really is. So I'd like to make a little list of things that I'm not really sure about in the coding or in the way the mmf2 works. Maybe you can help me out with some of these things and give me tips and tricks on how you would code something like that. If you can anwser only one that would already be very helpful!
Camera and backstory
First a little backstory on the game. It's a flying platformer, my program window is 800×600 and in my frames I just throw the entire level on the screen, so the frame might be 6700×2000. I make the camera move by centering it on a camera object that follows the player around. I use 4 lines around the character and check if they're hitting the background by the use of fastloops. The rest of the game is constructed around "ifs".
Activating Enemies
For some enemies I have an invisible active, that if the player overlaps, the active is destroyed and attacking enemies are created nearby.
In other instances, the enemy is already placed in the level and the problem here is; how do I activate him? I've tried that the enemy activates if he is in "in play area" but that never seems to work. so at the start of the frame, I've "spread a value" over the enemies in an alterable value (named ID). Then I've created an invisible active overlapping the enemy. If the player overlaps the active, and the enemy is overlapping that active a flag is turned on, activating the enemy. It also checks if the ID corresponds to the enemy ID so it doesn't activate all enemies. The downside is that the code for activating the enemy needs to be copied and pasted as many times as there are enemies in the level. Or else the code doesn't work. I hope this makes sense, haha.
This also brings me to the point of deactivating the enemy, How would I go about doing this? if the player just runs around the enemy for instance. I don't want to make another set of invisible actives that see if the player is not in reach of an enemy.
Groups
I'm not using groups for everything in my coding. if I have alot of "ifs" in the coding, does that mean that the computer is checking them all every 50th of a second? Does that make the game run slower? And does activating and deactivating groups for enemies make it easier on the computer?
That's all for now, I might add some questions later. This might also help people who are starting out with mmf2.
Some general optimising tips would be helpful aswell.
Thank you for looking at my post and I hope you can help!
The 4 lines around the character are usually called "detectors". Personally, I always use "embedded detectors" instead (see the article by Dalal), which are a very simple and efficient alternative, but it's a matter of taste.
If you're using fastloops to position detectors, you should switch to using the ForEach extension instead - it's more efficient.
A lot of people use spread values, fastloops, etc to match objects by brute force - but it's so much simpler to just use MMF2's automatic matching system (see my articles on "Handling Duplicates").
For "activating" enemies, I would forget using invisible detectors, and just use maths to calculate the distance between the objects and the player. Set an alterable value to the distance, and check if that is below a minimum range - if so, turn on a flag to mark the unit as "active" (and then obviously add a condition to your other events to check the flag is on). There are tons of articles and examples of this if you search.
By "Ifs", I presume you mean conditions, rather than the "Immediate If" extension?
Yes, MMF2 does check every condition 50 times per section (you can actually change the framerate in the properties panel), but that's not a problem.
Fastloops on the other hand, can be a problem. If you "always" run a fastloop 100 times, that means MMF2 now needs to check 5000 conditions per second. Even worse, if you use fastloops and spread values to match objects, the number of calculations MMF2 needs to run increases exponentially with the number of objects - which is why you should use the ForEach extension instead.
Apart from fastloops, the common bottlenecks are displaying graphics (unless you're using HWA) and fine-collision detection, which is very slow on large objects.
For the most part, groups are just a convenient way to organize your code. However, if you're running a fastloop, it improves efficiency if you disable groups contaning unrelated "on loop" events (see the article by Pixelthief).
So yeah, as far as optimizing goes, you just need to be careful how you use fastloops. With anything else, it's more important to keep your code clean and easily readable - even if it's not the absolute most inefficient.
Hey thanks for the quick reply!
This all looks very interesting, I'll try experimenting with and using the options you described. I've already looked at your article and tried activating the enemies in that way and it works just fine! So thanks for that already. I already have a question about that though.
If the player is within 400 pixels of the enemy it activates flag 0 of the enemy.
Is it a problem that flag 0 keeps getting activated? I've tried restricting the code so it won't loop. but if there are multiple enemies in sight only one enemy will work.
This segways nicely into my next question.
When I want an enemy to have a certain patern in his movements and actions, I add 1 to an alterable value when a flag is active. When the alterable value is a certain number (100 for instance). The enemy shoots, goes to action B or whatever. Is this a normal way of doing it? or is there a better way.
Now I've got the code to say :
if the player is within 400 pixels,
Add 1 to alt. Value A
Thanks again and sorry for these questions. Sometimes I have to look up on the internet how to do something really simple, since I figured most stuff out myself I tend to over complicate things.
Oh, I didn't know you could spread values! for instance, haha.
That looks like a pretty standard way of doing things - it's what I'd do anyway.
There's no problem with repeatedly turning a flag on. If you don't need to deactivate an object when it goes out of range, then it would be a little more efficient to stop recalculating distance after it first comes within range (calculating a distance is slower than just checking the state of a flag).
Alternatively to calculating distance you can use "Enemy is getting closer than -x pixels from the window's edge" and negate it, where x is how far away you want it to become active from the window. This does object selection etc just fine and avoids calculating actual distance, but then again if your slowdown is ever from math calculations for distance I'd be amazed.
On the downside, this is also rectangular testing for distance which can be useful sometimes and others... Not so much.
Honestly, your biggest concern for speed in MMF2 is always going to be number of objects (especially ones with logic / collisions), big objects scaling / rotating (especially with fine collision), too many layers and fast loops (as Sketchy mentioned).
Your game sounds like it avoids pretty much all of these so, you're on the right track.
In other instances, the enemy is already placed in the level and the problem here is; how do I activate him?
What I do is I have an invisble circluar object always follow the player around, and if that circle overlaps an enemy, that enemy's attack code is then active / triggered. The circle is roughly 3-4x the size of the player, with the player dead center. I find this method works pretty well.
--
"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!
Ahh yeah, that could work aswell. Once again thanks everyone. The demo is almost done so look out for that! I'll probably have some more questions on the way, it's good to know there's a whole database of information here and forum people that are willing to help!
Advertisement
Post Reply
.
