Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

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?

share|improve this question
up vote 2 down vote accepted

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.

share|improve this answer
So you're saying Particle inherits Sprite, and Projectile inherits Particle. From there, passing in a Sprite object so that I can use the particle's base Draw, Update, and LoadContent methods that <i>it</i> inherited from Sprite. That makes much more sense as a solution, thanks! – Caerulius Feb 1 '13 at 23:31

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

share|improve this answer
+1 for simplicity. – jmegaffin Feb 2 '13 at 15:50

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.

share|improve this answer
Hmm. Okay yeah, I honestly think I'm going to run into problems with this unless I change it around a bit. I think I'll let each actor manage a list of List<Projectile> but have a producer sort of "inflate" that projectile into whatever is appropriate for the need. Hopefully that should give me the functionality I like from each approach. – Caerulius Feb 1 '13 at 21:04
@Caerulius Don't accept too quickly. Give it some time, you might get some better answers than what I can give. People are less likely to provide answers if there's an accepted answer already. – Byte56 Feb 1 '13 at 21:05

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?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.