Deleting sprites (How would You do it #5?)
page 2

This method presumes enemies are objects on the display list. If you’re blitting instead, which you likely should be if you care about performance, then sadly you have to go through the Event system or inform the soldiers of the existence of the battlefield in some way. The second option is inelegant and breaks encapsulation.

Aside from how irrelevant what you said is, my method does not break encapsulation. If I said “Parent.List.Remove(this)”, it would break encapsulation. I am not calling the list and telling it to remove the item. I am calling a function from the parent class and having that function handle cleanup. Think MVC. The view and controller need some way to access the model. That is through functions. There is no such thing as a view or controller with absolutely zero access to the model.

The Class a given Class inherits from is called its superclass in AS3. ‘parent’ refers to the instance having ‘this’ instance as a child. Only DisplayObjects (well, instances of subclasses of DisplayObject) can be children, therefore only they can have a parent.

Once again, irrelevant. If you read my post you would see I know exactly what the definition of a parent is, otherwise I would not have made a specific note of how I used it.

Soldiers of the same type would be allowed to store a reference to the same “AI” instance, if appropriate.

Your example has the AI code spread around, some being in the unit classes and other bits being shared in different ways breaking the rule of high cohesion. Having all the different unit types keep references also means that changes in the AI interface demands for changing the code in all the units, breaking the rule of low coupling.

Do not get me wrong, I’m not using your example to call you a bad programmer, it’s a well known and well studied problem caused by the model centric view, which has stalled many products, created bugs and prevented the re-use of code between projects. I’m not saying you should change your practice, I’m just pointing out that there’s sanity behind Ace’s words, his method is derived from the research done to prevent the problems caused by the model centric view and now taught at universities.

Anyway, you shouldn’t spread the AI to the individual units, you might want them to work together in the future which is easier to handle from one place, it’s also easier to optimize the code (no need for all units to do the same calculation, it saves one so much more than shifting ints instead of multiplying).

Wow guys. Nice discussion. I’ve read it twice and I feel like I’ve learned something. The OOP is giving me a bit of headaches sometimes (most of the programing I do is for microcontrollers in C or assembler).

And by the way, I do it this way:
battlefield calls soldier functions like “hitByBullet” “walkedOnSpikes”, but the soldier determines if he’s dead all by himself;
soldier sets a flag “gone” when he needs to be removed, battleField checks these flags and removes soldier from all the lists he needs to be removed.

remember; each object should be worrying about things about itself; whether it has touched another object is not one if those things.

That is debatable. Assuming you aren’t making next gen games there is no loss or overhead for making each unit check its own state. If anything there is more overhead for not having the class check its own collision (in smaller games) since you can do other stuff within the same loop.

remember; each object should be worrying about things about itself; whether it has touched another object is not one if those things.

That is debatable. Assuming you aren’t making next gen games there is no loss or overhead for making each unit check its own state. If anything there is more overhead for not having the class check its own collision (in smaller games) since you can do other stuff within the same loop.

I never said anything about overhead… What are you going on about? lol

I never said anything about overhead… What are you going on about? lol

Overhead is something I wanted to point out. It really has nothing to do with what you said, but I am a stickler for optimization even though I am still learning about it. It is just a thought process that I arrived at. If it is incorrect, please let me know.

I never said anything about overhead… What are you going on about? lol

Overhead is something I wanted to point out. It really has nothing to do with what you said, but I am a stickler for optimization even though I am still learning about it. It is just a thought process that I arrived at. If it is incorrect, please let me know.

Yeah, you are right; there is not enough overhead to make the removing part worth optimizing. A quick profiling with monocle will show that the time spent executing the entire game logic will probably less than 1 ms over even 30 frames. The part we need to optimize the most is rendering.

Watch out when using event listeners in Flash, they are not performance friendly. Look into the monitor pattern instead.

EDIT: And try to only have one Frame-listener, which loops through an array with all the units and calls a function called ‘action’ or something on them.

I’m sorry, I couldn’t find any good resources on “Monitor Pattern”, could you or someone else provide one?
On another note, searching for it led me to several books on as3 design patterns I think I’ll buy in the next couple weeks.
“Design Patterns: Elements of Reusable Object-Oriented Software” is being called a bible on the subject, any truth to that?

Watch out when using event listeners in Flash, they are not performance friendly. Look into the monitor pattern instead.

EDIT: And try to only have one Frame-listener, which loops through an array with all the units and calls a function called ‘action’ or something on them.

I’m sorry, I couldn’t find any good resources on “Monitor Pattern”, could you or someone else provide one?
On another note, searching for it led me to several books on as3 design patterns I think I’ll buy in the next couple weeks.
“Design Patterns: Elements of Reusable Object-Oriented Software” is being called a bible on the subject, any truth to that?

I’m the one who should be sorry for using the wrong name, it’s called the “Observer” and not “Monitor” pattern. :)

Never read that book, but I know one should be weary about books on the topic. Design patterns are simple, there aren’t many and they are easy to understand, the real problem is when and how to apply the patterns without getting tangled up in UML planning.
What I’m trying to say is that you should look for a book which bases its teaching on a project which it gradually evolves by applying the different patterns.

Hey, do you like games? So do we — that’s what makes Kongregate the best source of free games online. We have thousands upon thousands of free online games, from both one-man indies and large studios, rated and filtered so you can play the best of the best. Read more »