How about the world holding a list of movers that it calls when it updates?

That's fine, but doesn't deal with collision. Something has to mediate movement with collision.

Objects that want to move would add themselves to this list, that sort of thing?
[/quote]

No. Something that knows about the list and the object can work between them.


And let's be clear here. I'm just offering advice. In the end, no software is perfect. In the end, if it runs correctly then the code is good enough. And all the forum chat in the world isn't going to make you a good program designer. Only practice will.

If you think something is a good idea, go try it out. If it causes you trouble, think of why and use that when you make the next game.

If the variable are consantly changing then don't use getters and setters. In fact, the editor I am making uses less getters and setters that previous draft versions. But what is a setter and a getter - ask yourself? A setter is just a function that sets a variable. So, if you think of a player's position and some way you want to retrieve the player's position then you can have a set up like this:


float3 PlayerPosition = x,y,z;

float3 getPlayerPosition() {
return PlayerPosition;

}


This is the approach I use but may vary with other users. So, for example say I set the player X: 5 units, Y: 0 units and Z: -15 unites as a starting point. If I want to run a conditional IF statement to see if the player has reached 0 units in the Z direction then making the code above works well. How?


float PlayerZ = XMGetVectorZ(GetPlayerPosition);
if(PlayerZ > 0) {
... Do whatever
}



So; you can see clearly that the Getter Function works well in this instance. The XMGetVectorZ extracts the Z position allowing the IF Condition Statement to see if the player is more than 0 on the Z Axis.

You can do the same as with a boolean or a integar.


int score = 500;
int getScore() {
return score;
}

if(getScore() > 1000) {
.. Do Level Up or whatever.
}



Hope this helps at least.

Can I hijack this thread a little?

Now, in uni we're being taught OOP, using Java. One thing that I didn't quite understand (and if I did, then I disagree) is making (protected) setters of the (private) attributes of a class for using them in the constructor of the same class.

What's going on there? Encapsulating the class from itself?

IMO looks useless and inefficient. The first thing that comes to mind when I think "What could have free access to this class's properties?" is the constructor. Why should need to use methods to access the class's attributes its trying to construct? It's one of those "It's in the paradigm!" things? Moreover, the classes that inherit from such class will also carry the "burden" of accessing itself through methods instead of simple direct attribute access.

I'd just use the getters and setters if I need to access the class's attributes from outside the class. It doesn't makes any sense to me to encapsulate the class from itself on constructors nor methods (except some "high risk" public method that could screw up the object that is, but probably that one should be implemented as a separate class anyway).

Well, perhaps there is a particular variable that needs to be set in a very controlled manner, with a lot of side code to execute at each change, so they just take advantage of the getter/setter syntax to put all the code there instead of in a separate method. This is only useful if there *is* a getter/setter syntax (as in implicit call through assignment) which is not the case in Java, afaik - you only get the ugly getX(), getY(), etc...

It certainly depends on the context. Can you give an example of such a class?

Anyway, in general, the less methods your class has, the better it'll fare. I just hate seeing classes with fifty repetitive one-line getters and setters, it's so useless and redundant.

It certainly depends on the context. Can you give an example of such a class?

Well, its exactly what you described. A bunch of one-line getters and setters for simple assignments dealing with ints, strings, and objects. Its getter/setter for everything.

Say:
public class blah {
private int, x, y;
private Object obj;

public blah (int tmpX, int tmpY, Object tmpObj){
this.setX(tmpX);
this.setY(tmpY);
this.setObj(tmpObj);}

protected setX (int tmpX){
this.x = tmpX}
protected setY (int tmpY){
this.y = tmpY}
protected setObj (Object tmpObj){
this.obj = tmpObj}
}

EDIT: Oops, double post.

Getters and Setters aren't inherently wrong, but they're usually a code-smell (meaning: something smells fishy, there's probably an opportunity to improve this).

The idea of a class in OOP is that it encapsulates data together with methods that modify that data in ways which respect the internal rules of said class (for example, a ball class probably shouldn't have a negative radius). Getters themselves don't really violate this as long as they return by value or const reference, but they imply that other code might not be adhering to OO principles. Setters (especially simple one's that don't validate input or prevent an unexpected state from being reached) directly violate the class's ability to maintain its internal rules (e.g. a poorly-written SetRadius() function might allow a negative radius to be set, even if the constructor didn't).

In the case of the power-up example someone cited, rather than having the affected properties of the ball be directly modifiable by an outside entity, you might instead have a method on the Ball class which consumes a PowerUp instance and modifies its own state, or you might have a method on the PowerUp class that consumes a Ball instance, and returns a new Ball instance that represents the affect of the PowerUp on the old Ball instance.

Another point to be made is that when someone says "a ball knows how to draw itself" or somesuch, they don't typically mean that the ball class is making Direct3D or OpenGL calls itself, they usually mean something closer to "a ball provides an interface that can be used to draw it with minimal sharing of information."