20 replies to this topic

[gregwarner]

If you are building a Class Object which can only be one of a specific set of types, perhaps you want to declare an Enum type in your class, which specifies the range of possibilities of that type. This ensures that only valid types are stored in your Object. If all you use is an int to encode the type, then you must do error checking to make sure the value isn't set to some unmapped number.

public class GameObject {

    public static enum Type {
        SPACE, WALL
    }

    private Type type;

    public GameObject(Type type) {
        this.type = type;
    }

    public Type getType() {
        return this.type;
    }
}

You can create and test your object types like so:

GameObject wallObj = new GameObject(GameObject.Type.WALL);
GameObject spaceObj = new GameObject(GameObject.Type.SPACE);
...
if (wallObj.getType() == GameObject.Type.WALL) {
    // This conditional evaluates to TRUE.
}

if (spaceObj.getType() == GameObject.Type.WALL) {
    // This conditional evaluates to FALSE.
}

If you need more types than this, just add them to the enum list. You can also perform switches on enum types, which can be handy.

[kalimann]

If you store a value in an array, it will never go away, unless the array changes. You can trust that it will always be the same. You should make an array, and then set the type of them. Don't use color, as you could add color depending on the type of it. Get what I am saying?

Yes, I get what you are saying. (:

If you are building a Class Object which can only be one of a specific set of types, perhaps you want to declare an Enum type in your class, which specifies the range of possibilities of that type. This ensures that only valid types are stored in your Object. If all you use is an int to encode the type, then you must do error checking to make sure the value isn't set to some unmapped number.

public class GameObject {

public static enum Type {
SPACE, WALL
}

private Type type;

public GameObject(Type type) {
this.type = type;
}

public Type getType() {
return this.type;
}
}

You can create and test your object types like so:

GameObject wallObj = new GameObject(GameObject.Type.WALL);
GameObject spaceObj = new GameObject(GameObject.Type.SPACE);
...
if (wallObj.getType() == GameObject.Type.WALL) {
// This conditional evaluates to TRUE.
}

if (spaceObj.getType() == GameObject.Type.WALL) {
// This conditional evaluates to FALSE.
}

If you need more types than this, just add them to the enum list. You can also perform switches on enum types, which can be handy.

I almost get you, but can you just exemplify what this is useful for? It's for preventing bugs or how?

[gregwarner]

If, let's say, you mapped 'space' to be int value 0, and 'wall' to be int value 1. In the code:

obj.setType(1);

it isn't immediately obvious what you're doing in this statement, unless you know what the mapping is. You should strive to make your code self-documenting. You could declare some static int's to use as constants, like so:

public static int SPACE = 0;
public static int WALL = 1;

and then you could do this:

obj.setType(WALL);

However, it still doesn't prevent you from doing something like this:

obj.setType(2);

because in your mapping, there's no such thing as 2. This would still be accepted by the compiler, if setType() was declared to take an argument of type int, however, you could have unforseen runtime errors unless you do some extra error checking to make sure that the int value is in the accepted range.

By instead using an enum type as I described above, the compiler checks to make sure you're passing in an accepted value, because it won't accept any value other than what's written in the enum definition. Enum can be thought of as creating a new data type in the Java language, recognizable by the compiler. (In actuality, the entries are mapped to int's.)

With an enum, you can also do switch statements like this: (using the same enum example from my previous post)

switch (obj.getType()) {
    case SPACE:
        // draw a space on the screen.
        break;
    case WALL:
        // draw a wall on the screen.
        break;
}

You can also create EnumMaps, which are Hash Maps which use an Enum type as its key, which could be used, for example, for storing the image for a particular type:

EnumMap<GameObject.Type, Image> map = new EnumMap<GameObject.Type, Image>();

You may never need that, but you should be knowledgeable on what you are able to do with Enums.

[Chall]

Using an enum type allows for a set range. For example, if I had a set of enums:

public enum Type{
WALL, HOLLOW;
public int getType(){
	 switch(this){
		 case WALL:
			 return 0;
		 case HOLLOW:
			 return 1;
		 }
	 }
}

By declaring each of the "GameObjects" as a certain enum for a type, they are limited to a specific type. Since you are limited, you do not have to worry about whether or not the assigned type even exists, because it has too. You made it, of course

Also, in each of the container objects, you should declare the x and y value, and the type. Then, an easy way of drawing them would be to create a sort of handler, with a 1 dimensional array of the objects you will be using, and in each object, the x,y where you want it to be shown. You could then draw the shapes accordingly, based on the type. For example:

public GameObject[] objects = new GameObject[10];
// Set the values of each object using some method
@Override public void paint(Graphics g){
	 for(GameObject o : objects){
			 g.setColor(getColorForType(o));
			 g.fillRect(o.x, o.y, width, height); // You could have height be preset, or use one defined in GameObject.
	 }
}

public Color getColorForType(GameObject o){
	 if(o.Type.getType()==1){
		 // return color;
	 }else if(o.Type.getType()==0){
		 // return color;
	 } // You could set this up as a switch statement.
}

Assuming you are using a JFrame, you could just create a loop, and have it call repaint each time it loops around.

I do not recommend using a 2 dimensional array to store the GameObjects, as it will create a lot of unnecessary memory waste, assuming you don't want each part of the map to be filled.

To further decrease lag from painting, you might want to cull what it prints. For example, only print the object if the x and y , or the x+ width and the y+height are on the screen (use the dimensions of your JFrame to find out where to cull it). This will remove any unnecessary paint calls.

[gregwarner]

public enum Type{
WALL, HOLLOW;
public int getType(){
     switch(this){
         case WALL:
             return 0;
         case HOLLOW:
             return 1;
         }
     }
}

The getType() method here is somewhat superfluous, as WALL and HOLLOW are already internally mapped to 0 and 1, respectively.

public Color getColorForType(GameObject o){
      if(o.Type.getType()==1){
            // return color;
      }else if(o.Type.getType()==0){
            // return color;
      } // You could set this up as a switch statement.
}

This method of testing enum equivalence is somewhat couter-productive from my earlier stated remark about code being self-documenting. It isn't immediately obvious to the reader which of the above conditions (1 or 0) is for the WALL or the HOLLOW type. A more straightforward approach yields more readable code:

GameObject obj = .... // assume a valid GameObject type.
if (obj.getType() == Type.WALL) {
    // return color for wall
} else if (obj.getType() == Type.HOLLOW) {
    // return color for hollow
}

And like you said, that would probably be more effectively implemented with a switch statement.

[Chall]

public enum Type{
WALL, HOLLOW;
public int getType(){
switch(this){
case WALL:
return 0;
case HOLLOW:
return 1;
}
}
}

The getType() method here is somewhat superfluous, as WALL and HOLLOW are already internally mapped to 0 and 1, respectively.

public Color getColorForType(GameObject o){
if(o.Type.getType()==1){
// return color;
}else if(o.Type.getType()==0){
// return color;
} // You could set this up as a switch statement.
}

This method of testing enum equivalence is somewhat couter-productive from my earlier stated remark about code being self-documenting. It isn't immediately obvious to the reader which of the above conditions (1 or 0) is for the WALL or the HOLLOW type. A more straightforward approach yields more readable code:

GameObject obj = .... // assume a valid GameObject type.
if (obj.getType() == Type.WALL) {
// return color for wall
} else if (obj.getType() == Type.HOLLOW) {
// return color for hollow
}

And like you said, that would probably be more effectively implemented with a switch statement.

Yes quite. But, enums are quite confusing at first, so I tried to simplify it a bit, in the case he didn't know about enums beforehand. Also, I don't use enums much, so I didn't know about them being auto assigned to an integer value, but it does make sense. Thanks for that piece of info

[gregwarner]

For your reference:

enum FooType {
    FOO, BAR, FOOBAR
}
...
System.out.println(FooType.FOO.ordinal()); // Outputs 0
System.out.println(FooType.BAR.ordinal()); // Outputs 1
System.out.println(FooType.FOOBAR.ordinal()); // Outputs 2

[kalimann]

Many thanks to both of you, this sure gave me a lot to work with. And a couple of solutions for my problem.

[Chall]

Many thanks to both of you, this sure gave me a lot to work with. And a couple of solutions for my problem.

Glad to hear we were of help! Good luck with your game!