All enemies are ONE big active object? Smart Plan?

Hi everyone

I want to know your opinions of which of the following game designs is better / easier on system resources (I want to use the IOS exporter) and more bug resistant. :-)

In a Space Shooter Game...
A) ...every enemy is an other Active Object. All collisions and all behaviors have to be coded for every Enemy separately...

B) ... every enemy is the same Active Object but every enemy is represented by another Animation Sequence. So the basic behavior is programmed only once and everything can be defined by values.

My Problem: I want to choose solution B) but this big enemy Object that represents 20 enemies will have 20 Animation Sequences with different sizes. Does MMF and especially the IOS exporter will have problems loading the whole Enemy Object every time an enemy appears even if it only uses one Animation Sequence? Will this be significant?

What are your thoughts on that?
Thanks and best regards

Can't you define the enemies using the groups? You can have multiple enemy sprites that use the same script using the group.enemy as an example instead of pointing the code at the actual enemy.

I actually recommend B. It's what I always do these days. Qualifiers can't be named, and neither can't their alterable values. Meta objects makes everything much easier if you know how to use them. I tend to run out of alterable values pretty quickly though. They don't eat more resources, an instance doesn't need to load the graphics separately. Those resources are shared.

I would actually recommend A. Maybe it's just my preference, but I would think that controlling an active object with all those animations could get really confusing. Also, as the person above me says: You could run out of alterable values. One object can have A-Z in values, and would give you that many different things to do with an object. Sharing the values A-Z between different enemies with different characteristics would not give you many options to play around with for each enemy. Depends on what you are making the enemies do, of course. In theory though, I would expect that one large active object would be less demanding of the computer resource-wise. An interesting thought!

I am going towards B at the moment in my project. I'm even doing it for bullets infact.
If you keep your coding well commented and organised it will make life very simple for you, rather than having to handle 20 separate objects.
This is especially true if the differences in behaviour between your 20 enemy types are limited.

Alternatively, you could go for option C, which is say, 4 objects, each with 5 animations or so ... ;
fighters, large attackers, capital ships and bosses.

Presumably the fighters would behave fairly similarly to eachother so you could code their attacks to be conditional on the animations without too much bother and kind of 'split the difference' between A and B.
See how it goes.

Very little-to-no performance implications I would think.

Nifflas took the words right out of my mouth. Qualifiers *should* be perfect for this, but unfortunately they have too many annoying limitations. Using just one object saves a lot of duplicate code, keeps your code readable (because you can refer to alterable values/strings by name) - but still makes it easy to keep some code specific to certain object types.

Quote:

---

One object can have A-Z in values, and would give you that many different things to do with an object.

---

The whole point of meta objects is that you configure a shared mechanic to work differently on different objects. You'll get away with using 20 events instead of 200 and still have exactly the same result. It saves time, it's cleaner, more elegant, and much more resource friendly. Obviously, if you need a different base mechanic, you'll set up a different meta object for that anyway.

Now, behaviours should be exactly for this, but again, they can't be named and nor can their values, so it's no option.

Quote:

---

Sharing the values A-Z between different enemies with different characteristics would not give you many options to play around with for each enemy.

---

No, almost every non-MMF2 game works like this. The same code is used to control a whole lot of different characters, so that the can be configured with a set of values rather than having to be programmed individually. MMF2's limited number of alterable values causes some problems, but even only using those, in NightSky instances of a single object is enough for every physical object in the entire game, and instances of a single object is all that's needed for all the background animation in my new Knytt game (looks like this and this).

Of course, setting it up takes some knowledge, and perhaps one shouldn't begin creating games like this. You can not discourage it on the basis of it being limited though, because making the same code handle as many different scenarios as possible is usually the best way to do things.

If flexibility is short due to lack of values, then the enemies' behaviour are clearly too different to lend themselves to being integrated into eachother.
In that case, they're better off as separate objects.
As long as there's sufficient commonality between the enemies, I think you'll get a very positive result because you get fewer objects along the top of the event editor, fewer objects updating globally (because that doesn't always work the way it should), fewer behaviours, animations etc. scattered around in individual objects.

And you get that all for the cost of an extra condition in your events to test what identifier value (or animation perhaps) is set on the enemy.
And you don't have to repeat a whole load of identical events for each object either.

Thanks for your input. A lot of good points. I think I will go with option B (or C from crash86).

1. Are you sure that the ios exporter can handle an enemy object with 20 or even 40 different sized animation Sequences? Does it load all the animation Sequences even if only one enemy apears or does it load only the Sequences that get executed? Would this even be relevant?
2. how can I make a condition that the level ends, when a certain enemy type is destroyed? eg: -there are no Enemies with the animation sequence "Eveleye" left --> end the level (be aware that there may be still enemies in the form of meteorides)

Thanks!

Number of "enemy" = 0
- Next Frame (frame object)

You can add the value/animation of your enemy as an extra condition in the above event to stipulate what type of enemy (within that object) you want to have destroyed before you change the level.

There ought to be no problem with iOS.
It only bothers with the frame that's running. It has them all in memory but only thinks about the current animation.

Thanks Crash, but it doesn't work.
I want to progress to the next frame if all "EvilEyes" are destroyed even if there are other Enemies" in the game.
I tried:

- Number of "enemy" = 0
- Animation "EvilEye" is playing
--> Next Frame

It should be:
- Number of emenies with the animation sequence "Eveleye" = 0
--> Next Frame

Ideas?

Try flipping the two conditions in your first solution.

Quote:

---

Originally Posted by Crash86

fewer objects updating globally (because that doesn't always work the way it should)

---

Can you expand on this? I was unaware of this.

Thanks,

Marv

Sometimes I often find that even though I have identical global objects in different frames, one will not update the others or it will update some but not others.
So, the fewer global objects you have, the less management overhead you have in checking that they are the same.

I think they mentioned that they were going to fix that with a dialog, warning you that MMF2 thought one global was no longer identical to its buddies and asking you whether you wanted your new changes to affect the others.
Haven't seen any evidence of that happening though.

Quote:

---

Originally Posted by Crash86

Try flipping the two conditions in your first solution.

---

I will try that later and if it works, you are the man! :-)