My game loop is structured like this:

update

draw

checkforcollision

sleep

I want to draw the death animation in my draw method but the problem is

by the time I check for collision, the draw method already been executed which

means it won't execute this draw code in my Ghost class.

// if ghost is in a dead state
if(getDeadState())
{
 
 
g.drawImage(ghostMovementAnimation.get(3), (int)position.getX(), (int)position.getY(), null);
}

The code posted below is in my Laser class.

Quick explanation of my collision code:

if collision is valid, remove the laser

set monster dead state to be true

remove the monster

 
/* check the intersection of the laser's rectangle and all the monster's
*  rectangle. If both rectangles intersects, it is a collision
*/
 
if(rectangle.intersects(((Collidable) component).getRectangle()))
{
 
 
// remove laser upon monster contact
Game.getInstance().remove(this);
 
// set monster to be dead
monsterIsDead = true; 
 
// set monster to be dead
((Monster) component).setDeadState(monsterIsDead);
 
 
// remove the monster upon contact of the laser
Game.getInstance().remove(component);
 

Have you considered setting it to a dead state but not removing it? Then after a few frames or a few seconds, you can remove it.

Since I am not removing it upon collision, it would draw the dead animation of the monster. It is in the game looking dead.

I am using milliseconds for frames. But I am having trouble figuring out how to make it a few seconds pass as a condition to trigger the removal of the monster.

Is it not preferred to draw an image every frame?

You could place a particle at the enemy location that runs the death animation and then deactivates and signals for cleanup. That would be a hack, though. What's going on with your entity that makes it so strongly coupled to collision testing?

Actually, I don't really understand the question, I guess. How are you executing other animations?

The game is a 2D game in Java. The monster is stored in a list. Game goes through this list that has object that needs to be updated or drawn(like the monster). Laser checks through the list looking for objects of a Monster Type. If laser has found objects of a Monster Type. Create rectangle object around the monster. Test intersection of its rectangle with the laser rectangle. If valid, perform the removal of the monster.

I can perform the removal of the monster. I just cannot figure out how to make the dead animation appear because the monster is already removed.

If I do not remove the monster, the dead animation is shown but the monster does not get removed.

The monster animation is done by picking out a specific image to be drawn from the list (where these animations files are stored).

What do you mean by a hack?

Two things.

One I'm not really sure why you're drawing before updating.. is there some good reason for that?

Two I don't really see why your collision is so coupled to removing your entities. If anything when an enemy gets hit it should go into a sort of "dead mode" where it plays its animation but is still a live entity in the entity list, getting updated and drawn. Once it's animation is complete then you would decide what to do with it, maybe set some flag on it to "disposed" and have your update loop remove disposed entities when it spins around again.

There's not really a rush to remove entities.

oops...

I actually update first then draw. I flipped it around...

I will think about #2. I am still learning game programming so it is nice to see that is how I should be doing it based on #2.

oops...

I actually update first then draw. I flipped it around...

I will think about #2. I am still learning game programming so it is nice to see that is how I should be doing it based on #2.

Given game programming, there is no silver bullet or one fits all methodology of course, but.

Usual generic way to handle collision in a game with a bunch of like "entities" is to have some higher up object like the gamestate or.. whatever do the actual collision checks between entities, perhaps with the use of a helper class that provides the methods.

However the entities themselves should probably respond to the collisions, if two entities collide you could call something like HandleCollision(Entity&) on them, to let them "decide" how to react to what they collided with. This lets both objects know they collided and gives you room for expansion. Maybe you collided with a powerup, the player could set the buff the powerup gives on itself, the powerup could deal with destroying itself and maybe spawning particle effects or something.

It's more natural to let the objects control their reactions to the environment than to let another object do it unless the object is some kind of.. controller, and the entities themselves are just dumb data.