Verik-

Yes conceptually it makes sense... something like this in my level class?
(it contains all the data for player, background, enemies, bullets, etc.)


class Level{
Player player;
GameInput input;

update{

if( input.getInput() = foo){
player.doBar();
}
}


Am I thinking about it the right way? It seems like it could get complicated if I have multiple buttons pressed....

be-the-ero.net -

Yes from your example I totally see the benefit of interfaces. A question though... I have render/ update methods in my baseObject that everything else is derived from. Is it better to put that into an interface or should I just keep it as it is? I am guessing if I dont need to override the functionality just keep it in the base class but if I want each object to hande the function differently make an interface? It is definitely a learn as you go process.

Also, yeah I am slowly trying to refactor my code as I learn more about this stuff, it can get frustrating at times because I end up breaking my game every time i end up coding and end up recoding stuff but I am enjoying it and learning alot about it.

Thanks Again!

Yes, exactly!

Now I have a little old school OO advice to add to the wise words of be-the-hero. And that is that one of the best way to make classes and decide what to put in which classes is to think about the responsibility of those classes. Responsibility formal CS lingo for that a class should mind its own business. But what business is that? Actually it is that business that is implied by its name.

You have a class named "Player". The name implies that this class and this class alone represents the player as a whole (in the context of your game). And it should be this class that manages everything that happens inside the player. Having a player consist of a location and a weapon is great. The weapon knows how to fire bullets (create bullet objects) and the weapon can decide when it can fire again. So the weapon class also fits the 'mind your own business' rule. I envision that you will be having a Shield class in the player as well that keeps track of whether the shield is active, and how long the shield is active.

In this sense: a small optimization is that you could consider to rename Player to SpaceShip or PlayerShip or something similar. As it is not really 'the player' that is flying through your level, it is a spaceship. The player is someone who is playing the game, controlling the spaceship. It may seem nit-picky, but the better you get at finding the most accurate and concise words for your classes and methods, the better a programmer you will be. And how cool is it to have a line that says: spaceship.fire()?

Now I really like your interest in how to 'do it right'. But bear in mind that there are several different styles of how to do OO programming, and my advice is somewhat strict OO. I don't actually program this way at my work, it is not necessarily always the best way for all problems. However, I think think that it is an excellent way to learn the ropes and get a feel for the responsibilities of classes. Also your nice and compact game structure seems to lend itself very well for this. But don't think you are doing it wrong if you have a few lines that don't seem perfect. It is usually unavoidable. And at this stage it is probably better just to get a few running programs and experiment with using classes than to make the code of this one game perfect.

Wow, a lot longer post than I intended. I guess I really like conveying my ideas about how to do OO

Cheers!

Verik-

Yeah I totally get what you are saying, "Make it work right, then make it more efficient", I am actually going for a CIS degree at my college, I am almost done but I havn't done any C++ in awhile so I am rusty... but anywhoo, another question ( I am full of them lol). I have a getBounds() method that returns a rectange that is the size of the graphic of the object at the objects location. My shield is going to be a circle shape and I would like if I could return a circle instead of a square but I can't override the method like that. I would really like my shield to inherit from my baseObject class as it has alot of useful methods that I do not feel like rewritng is there any workaround?

Oh, and my playerobject is called playerShip or something like that I was just writing some quick pseudo-code. I haven't had much time to work on it, real life gets in the way but I'm sure I'll have some more questions as I progress.

Thanks,
Nick

Something like this ???


interface Shape {
boolean contains(Point p);
boolean coversTo(Shape s);
boolean overlapsWith(Shape s);
...
}

class Rectangle implements Shape {...}
class Circle implements Shape {...}

class BaseObject {
Shape getBounds() {
...
}
}


I was thinking along the same lines as ppgamedev. You are probably returning a Rectangle to do collision detection. If you define a class (Shape) that can detect collision of a point [x, y] with itself then you are free to implement whatever shape you want and have a custom collision detection for each shape. Now this gets complex fast if you want to detect collisions between to arbitrary shapes, but it might work for your setup.