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

43 posts

Flag Post

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.

 
Flag Post

am I the only one who doesn’t get why this is a problem? The method you use really depends on your paradigm and game strucuture.

 
Flag Post
Originally posted by qwerberism:

am I the only one who doesn’t get why this is a problem? The method you use really depends on your paradigm and game strucuture.

No, I’m with you on that. I’m all for people explaining how they do it but I don’t understand why there is a debate about it.

 
Flag Post
Originally posted by player_03:
Originally posted by OctaBech:

[…] you try to see it from every single unit as if they are independent thinking beings, but that either creates a lot of duplicated code or a whole lot of cross references […]

I’ve implemented it that way, and no, it doesn’t. Why would it?

It does and you gave a rather good example of that:

Originally posted by player_03:

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).

 
Flag Post
Originally posted by qwerberism:

am I the only one who doesn’t get why this is a problem? The method you use really depends on your paradigm and game strucuture.

Well the OP asked for the best way, so it’s only natural that some want to know why the other methods are better, which advantages they have.

The thread with its many different views also raises another interesting question, how weary should one be from participating in projects with more than one programmer? I’d say very.

 
Flag Post

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.

As I understand this is not the worst method to do it, is it?

 
Flag Post

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

pick up the removal right after or right before updating.

 
Flag Post
Originally posted by qwerberism:

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.

 
Flag Post
Originally posted by EndlessSporadic:
Originally posted by qwerberism:

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

 
Flag Post

I really like my method of deleting things from the main class via external classes.

First lets say we’ve got enemies, and some way to kill enemies. Lets say a bullet hits an enemy, and its health drops to zero or its an instant kill, whatever.

	//in enemy class, usually in a "die" function or similar.
	//remove all listeners first
removeEventListener(Event.ENTER_FRAME, loop);
	//then dispatchEvent
dispatchEvent(new Event("deadEnemy", true));

is pretty much how it goes. I usually have all my enemies extend a main enemy class so my main class only has to listen for this single dispatchedEvent as well, I find it much cleaner.

	//listener is in my init function
stage.addEventListener("deadEnemy", removeEnemy);

	//function is later in main class
private function removeEnemy(e:Event){
	var index:int = enemyArray.indexOf(e.target);
	stage.removeChild(enemyArray[index]);
	enemyArray.splice(index, 1);
}

Although I have not the faintest idea how efficient this is.

 
Flag Post

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.

 
Flag Post

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.

 
Flag Post
Originally posted by EndlessSporadic:

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.

 
Flag Post
Originally posted by OctaBech:

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?

 
Flag Post
Originally posted by alecz127:
Originally posted by OctaBech:

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.

 
Flag Post

Oh I am so glad, I thought I was failing to use google properly, medical patient monitors were coming up! That was weird.

huh, so basically I just use eventDispatchers instead of other listeners like enter_frame loops.
That makes a lot of sense actually.

 
Flag Post

Slightly related question:

Does having a movieclip stop() on a blank frame, when it has no references, result in its destruction? Because it seems to, but I’m not sure. Or does it just leave it there for the garbage collector?

 
Flag Post
Originally posted by feartehstickman:

Slightly related question:

Does having a movieclip stop() on a blank frame, when it has no references, result in its destruction? Because it seems to, but I’m not sure. Or does it just leave it there for the garbage collector?

Nope, it’s still on the stage, so it’s still a part of the display list.