Actually, I had something a little more like this in mind. I'm just inlining functions for clarity.



I'm not sure exactly what PlayerShip::CallMovement is supposed to do; I think you should change the name, probably to something boring like update(). It seems, though that it is just supposed to move the ship based on key-downs and make sure that the gun is always in the same position relative to it. If that's the case, here's about how I would do it.



GUN_OFFSET_X and GUN_OFFSET_Y are just constants that tell how far the position of the gun is from the position of the ship, since their positions are generally their top-left corners, and just assigning their positions to be equal would look funny.

Don't copy my code, because I'm in a hurry and it's almost gauranteed not to compile, but you probably get the idea.

Quote:Original post by blewisjr
There alone is the first flaw. Your design is slightly off. The classes for the ship and the gun can be separated but why. The gun is part of the ship.

Composition. Create a generic gun class and you can give your ship one or more guns fairly easy. You can reuse the gun code for your enemies as well. Just because something is part of something else doesn't mean you shouldn't create separate classes for them.

Quote:If you insist on keeping them separate then you should put in a property structure into each class. Use getters and setters.

Create a decent interface instead. For example, Move() is better than a SetX() and SetY() pair, as it is more geared towards the actual use of the object.

Quote:However, in all honesty since the gun is part of the players ship I would just keep the 2 together in the same class and share the position values where the origin of the gun projectile is the position of the ship and after the projectile leaves the ship it should have its own variable that tracks its travel. Making the ship and the gun move as one unit.

Here you're saying something interesting. Make them move as one. Personally, I would make the gun position relative to the player. This means you only need to update the player location. Whenever you fire a bullet, you add the player and gun positions together to get the initial bullet position.


A few more notes: in C++, structs are almost the same as classes, although they're often used to indicate that something is merely a collection of data. I would say that a Gun is more than just data - it also has specific behaviour (hey, it fires stuff, right?), so the current approach here is somewhat off. You're storing gun data in a Gun struct but the gun functionality resides elsewhere. Why this separation?

@theOcelot: why create the Gun on the heap? In this case, the manual memory management is more trouble than it's worth. After all, a Gun isn't a heavy object anyway.

Quote:Original post by Captain P
@theOcelot: why create the Gun on the heap? In this case, the manual memory management is more trouble than it's worth. After all, a Gun isn't a heavy object anyway.

Oh, no good reason. It's just what comes naturally. I actually like pointers. Allocating in the constructor and deleting in the destructor doesn't strike me as horrendously difficult. I suppose though that having it by value would be easier, esp. for a beginner or someone brushing up, and it seems OP is one of the two.