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 have an enemy which shoots 3 different kind of bullets. They are of different sizes, speed, and representation (rectangle, oval, and a more classic bullet).

Should they be 3 separate classes or just 1?

If a single class, how would I implement it?

share|improve this question

closed as primarily opinion-based by Byte56 Feb 15 '14 at 15:16

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This is a really hard question to answer properly, because it really depends on the actual use case, your implementation, etc.

The more similar the behavior is, the more likely you could handle them all with one class, but due to this not necessarily being the case, other options might be more interesting.

E.g. if the only difference is their speed or appearance on screen, simply using some member variable might be enough for Differentiation (although being not 100% perfect). If you've got different behavior as well (e.g. pathing, passing through things, etc.), using separate classes might be the best way to go.

On the other hand, if you're using some kind of component/system based approach to entities, just changing affected components might be the best Thing to do.

In short: The bigger/more complex the differences, the more likely it's useful to split the logic into its own class/entity type.

share|improve this answer
i was trying to do this: – goat Apr 22 '13 at 19:20

It can be 1, it can be 3, it could even be more. This is a design decision that you need to make, based on a number of factors. Some of them are soft decisions based on your circumstances and preferences:

  • How much functionality (data and behaviour) is shared between the different types of bullets?
  • How large and complex is the project going to be in the end?
  • Where do your architectural tastes lie: do you flinch at the thought of having multiple small classes which only differ a little bit?

To answer the first point, it seems to me like a fair bit of functionality is going to be shared among the 3 types of bullets, unless my assumptions are wrong. It's a good bet that they will have a position vector, a velocity vector, a size property, some way of drawing themselves on the screen, and some way of detecting collisions.

This is a pretty good indication that you should start by having a "Bullet" class, which implements many of these things. One option available after this would be to inherit from Bullet, so e.g. OvalBullet could inherit from Bullet and implement its own Draw() method. In turn, you may already have a class in your project which is even more simple than "Bullet", e.g. an "Entity" class. Bullet could in turn inherit from there.

One important area where your bullets may differ is in collision detection. You could of course implement the exact collision detection code in OvalBullet, RectangleBullet, etc, but after a while you'll notice that you are duplicating code. Many different things will want to use either a box or a circle for collision detection. You might want to refactor the collision logic into several classes like RectangleCollisionDetector, CircleCollisionDetector, etc.

At this point, the job of a class like OvalBullet would be something like: correctly configure the relevant collision detector upon construction, pass the relevant parameters to the base (Bullet) constructor, and implement any truly unique behaviour (e.g. custom drawing). This way you can reduce duplication in your code, and make a trade-off between having shorter classes, but more of them interacting to achieve the outcome (hence my comment about your own preferences). The most basic, monolithic implementation might be 1 class. On the other end of the spectrum, this might be split into 2 base classes, a couple of interfaces, 2 or 3 collision detection classes, and 3 bullet classes.

share|improve this answer

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