0
\$\begingroup\$

Basically imagine a game where the Player has a Weapon which has a BulletType/type of Bullet.

Now Player, Weapon and Bullet are Models having properties and they would represent Instances in the game.

I want to Instantiate a Bullet when the Player fires and I have to check what BulletType the Weapon currently has, but I don't understand what kind of Property Weapon should have to represent the current type of Bullet.

Should in the Weapon class the BulletType be an Instance of Bullet or should I use some kind of Constant as BulletType that would map to the Bullet Model?

class Weapon{
    IBullet currentBulletType //<-- a Bullet Model with Position and everything
}

or

class Weapon{
    BulletTypeConstant currentBulletType // a Constant that is mapped to a specific Model
}

The first approach is using a whole Model to represent the BulletType currently equipped. The Second uses some kind of Constant that must then be mapped to a specific Model of Bullet on firing.

I always find myself troubled as to which approach would be better. Or perhaps you have an even better Idea. Thanks

\$\endgroup\$
  • \$\begingroup\$ I solved this issue by simply creating class Bullet and create static Bullet for each type. And then call Bullet.FromType(type, pos) that would create deep copy of my static bullet at defined position. \$\endgroup\$ – wondra Jul 30 '14 at 21:33
  • \$\begingroup\$ Are you using C#? You might want to add that as a tag. \$\endgroup\$ – RandyGaul Jul 30 '14 at 22:09
  • \$\begingroup\$ You should have a WeaponType similar to your BulletType, which holds the right BulletType, as I imagine you would have multiple weapons that fire the same bullets, but each would have its own state such as firing timers, number of bullets left in the clip and so on. \$\endgroup\$ – congusbongus Jul 31 '14 at 6:03
0
\$\begingroup\$

I think that any good OOP source you check will advise you to program against interfaces, which is one of the pillars of OOP, so your first option would be better.

However the problem here is conceptual. If you think about it, your weapons doesn't have a bullet, as your model suggest, but it produces bullets. In that sense, what your really need is to use a creational design pattern.

For my game, I use the Prototype pattern, which would make the code look similar to your first option (include an Interface variable, and make clones of it). However, depending on your needs, I think Factory Method can work as well.

\$\endgroup\$
  • \$\begingroup\$ The link to the Design Patterns is really Helpful thank you. I think some kind of factory referenced in the Weapon will be the best solution for me \$\endgroup\$ – user1090755 Aug 6 '14 at 6:14
0
\$\begingroup\$

Whether or not a "Weapon", a "Character", or the "World" (or some other more global concept) should contain a collection of bullets fired depends largely on how you want the bullets (or, generally, any object/concept) to be considered in your game.

Questions to ask:

  • Weapon: Does the bullet exist as tied directly to the weapon? If the weapon changes or switches in some way during the bullets lifetime, will the bullet need to change as well? If so, a Weapon containing a list of bullets fired would make sense to ease the process of a Weapon change affecting its "children"

  • Character: Does the bullet exist independent of the weapon, but heavily dependent on the Character/Agent firing it? If the Firing Character gets a "powerup" or moves or in some way changes, will those changes flow down to the bullets as well? Is there a maximum number of bullets a single character is allowed to fire or some other character-specific consideration for all bullets produced from the character?

  • World/Global Container: Does the bullet exist independently from everything in the world? After firing, does it simply travel until it collides or dissipates? Is it more akin to a particle effect occuring in the world than an object with some dependence on another object?

To be clear, answering "yes" to any of these questions doesn't necessitate choosing that option. However, a set of bullets heavily dependent on per-frame changes to the weapon or character would be simpler as a collection held by that object.

To be general to the architectural problem at hand, this is true for any similar problem of "Should it be contained in a related object or simply lightly referenced?" The question of architectural dependency can be answered by looking at the desired functional dependency. In general, if an object is heavily dependent on some "parent" object, it might be wise for that "parent" to be a container. If an object is simply "produced" or lightly linked to some other object, it makes less sense for that object to need to be the container.

\$\endgroup\$
  • \$\begingroup\$ The question really helped me determine where i should manage the bullets. For the Weapon I will probably use some factory. Thank you. I would vote your answer up but I apparently can't. \$\endgroup\$ – user1090755 Aug 6 '14 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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