Who should manage projectiles?

Question

I was following a tutorial that was recommended to me to learn the basics of game design through XNA. And I got to this tutorial: http://www.xnadevelopment.com/tutorials/thewizardshooting/thewizardshooting.shtml

This is the tutorial that shows management of dynamic object generation and handling.

In the tutorial, he links the "Fireball" class to the "Wizard" class. The wizard class maintains a List<Fireball> and they're updated, drawn, loaded, etc. within the Wizard class itself.

My question is this: Is this good design? Should the Producer of the Objects be the one to manage them, or would it be better to implement, say, a ProjectileHandler class, that could manage the fireballs shot both by the Wizard and the Evil Dragon?

Answer 1

Treat projectiles as particles and use a kind of particle system to manage them. In essence you know you want to control where the projectiles spawn, and how long/where they are deleted, but moving the projectiles should be automated.

Instead of the Fireball class extending the Sprite class (which to me already sounds like a bad design), have the ProjectileHandler class with a list of Fireball objects, each including a Sprite. Fireball objects define a direction, which the ProjectileHandler uses to update the position. This way you can spawn a new Fireball with any sprite you want like: ProjectileHandler.AddProjectile (new Fireball(sprite, position, direction)); and the FireballManager adds it to the list.

You may notice that the Sprite could be just about anything here, so Fireball can be just as well be given a more generic name to suit all kinds of projectiles. The ProjectileHandler is unaware of what texture each projectile uses for the sprite. The dragon may use different, bigger fireball sprites, or you may want the wizard to upgrade his attacks and have the new fireballs look the part.

Byte56 did mention that texture switching should be kept to a minimum, so this implementation has that drawback of not doing so automatically as different sprites can be added in any order. I suppose a sorted List of KeyValuePair<Sprite, Fireball> would solve this, but don't try to optimize yet unless it becomes real necessary.

The reason I said it's bad to have Fireball to extend from Sprite is that Fireball is treated as a projectile, not a Sprite. It should instead contain a Sprite object to represent that Fireball visually.

Answer 2

For me, projectiles are just another kind of object in the game. They don't need a separate manager, and just get updated along with every other updateable object such as characters. It is sometimes useful for them to keep a reference to their creator however (eg. for deciding who was responsible for inflicting damage).

Answer 3

If the current scenario works, you don't need to change it.

However, I can see some benefits of having a projectile handler. You would need to make a change to the Fireball class to include a reference to the owner though. One nice thing about the Wizard class managing all his projectiles is you know which ones are his, and can easily emulate that with a reference to the owner in the Fireball.

Keeping all the projectiles in a single class can mean a few things. For one, you have far more control over the order these things get drawn instead of having each "producer" manage their own projectiles. Given that, there are some rendering improvements you can make based on knowing when these objects will be drawn. You can load the fireball texture once, then draw all the fireballs in the scene, for example. That cuts down on texture switching. Having all the projectiles in one place makes it easier to implement things like projectile-projectile collision.

Answer 4

A good reason for having the fireballs in a list of projectiles rather than owned by the wizard is what happens when the wizard dies? Do you want his fireballs in flight to suddenly vanish?