(*I originally posted this in System Engineering, before I found this board - original thread can be found here: Original Thread*) I have a design problem: I want an object to carry out an attack. Once it attacks, a new object should be instantiated, a missile. Let us for easiness sake call the attacking object a tank, and the missile a shell. My problem is, that I don't like my tank to have so much knowledge of the shell, since it will be independent of the tank, once it leaves it. Since the shell - once fired - does no longer belong to the tank, someone else has to catch and manage it (the game). But in that case, couldn't the game just instantiate it in the first place? How did you solve this problem? Did you let the tank instantiate the shell and pass it to the game, or did you just put some flag on the tank, that it was attacking with a shell, and then let the game do the work? Or did you come up with something absolutely ingenious? Is there a norm on how to design this? Thanx in advance :) ---------------------------------------- ApochPiQ answered: Why is it a problem for the tank to understand what sorts of shells it fires? This is a situation where (IMHO, at least) tight coupling between two objects makes perfect sense. It is common to split this into a three-layer system, though: a Unit (tank), a Weapon, and the Projectile (shell). In this case, the Unit object holds a reference to the Weapon that it fires. When the Unit wants to fire, it asks the Weapon object to do this. The Weapon then takes care of instantiating the Projectile and passing it on to the appropriate lower-level game logic. This is advantageous for a few reasons. It allows you to split the weapons and firing logic into an encapsulated area, so that all of your game logic can use the notion of "firing a weapon." This makes it trivial to give a unit more than one weapon, allow weapon swapping, and even add emplaced weapons like stationary turrets. In addition to reuse, it allows a highly data-driven model to be put into place. The Weapon class might simply do a lookup in a data table to see what sort of projectile to fire (this is common in many games, especially mod-friendly games). This decoupling enforces a separation between projectiles and units, but it is important to note that there still has to be a tight coupling between units and weapons, and weapons and projectiles. The extra layer of abstraction between a Unit and its weaponry also lets you do sneaky stuff like add powerups and bonuses to individual units if you like. In general you get a much higher degree of flexibility than a direct hard-code link where your Tank class code creates a Projectile manually. Hope that gives you some ideas to work with. ---------------------------------------- I answered: Hi Apoc, and thanx for the reply. In one way I like that the tank instantiates, since this is analogous with r/l. How do you do it on a more concrete level? I have a list of units (tanks and otherwise) in a storage structure (array, linked list or whatever), that I call a method on (UpdateAttack() maybe?). When calling such a method, would you then make a return value with the new objects (shells) it instantiated? Like: vector<Missile*>* Tank::UpdateAttack() And when that one returns, the game puts the list of shells into its own storage and management system? ------------------ EDIT: Or maybe I could give the Tank (or weapon) access to the object storage and management system (which could be a singleton?), and let it itself instantiate and properly place the object into the system?

This won't really help your problem, but becuase guns/tanks shoot so quickly, some games just draw a ray out in the direction of the bullet and see where it intersects. At the first intersection place it creates an explosion and damages the enemy there(or whatever the bullet does).

Quote:

Original post by Mercenarey (*I originally posted this in System Engineering, before I found this board - original thread can be found here: Original Thread*)

The game design that this forum is about is more gameplay/less programming. 'Game Programming' would probably be the best place for this.

hehe, ya I noticed. I took the discussion in "Software Engineering" instead. It is my first time on this board, so didn't realize what the focus was.