How to properly create Game Objects

Question

I am making sims like game and right now I am trying to figure out how I will structure my objects.

Right now I am thinking to create a class called GameObject, the psuedo is below

public class GameObject {
       name:String
       width:int
       height:int
}

This way I could create objects like bushes, trees, and buildings. But then I began to think. what if I wanted to create multiple buildings and trees of the same type ?? I would have to keep making instances of GameObject and giving it a new name and height and width. The properties would have to be the same values in order for me to duplicate one object. That seems a little tedious. Then I figure , maybe that isnt the right way to go. So I was thinking, I would have to extend GameObject like below

public class Tree extends GameObject{
       birdHouse:Boolean
}

public class Building extends GameObject{
       packingGarage:Boolean
       stories:Number
}

public class House extends GameObject{
      garage:Boolean
      stories:Number
}

Now this way, I can just create multiple instances of house, or tree, without creating properties that specify that it is indeed a house or tree. This seems more logical, but at the same time it seems it allocates more memory because I am creating more classes.

I just need to know what the best practices for dealing with objects like this. If anyone can help me out with this. also if you know any resources for best practices of reducing loading on games or any application at that. I also want to use Interfaces. the second concept seems more reasonable and I was thinking about having the parent implement a interface like below

public class GameObject implement IGameObject {
           name:String
           width:int
           height:int
    }

Now this way I can create a class that has a method that loosely accept accepts any type that inherits GameObject.

Selector.loadObject(gObject:IGameObject); 

Depending on what type it is (i.e tree, building, house) I can use a case statement to figure out which type it is and evaluate it accordingly.

I also created a Tile Class that will pass through the loadObject method. It also will be a child of the GameOject class. if the case statement finds that it is type Tile, it will highlight whatever Tile depending on what tile my mouse is over.

My second question is if a class inherits a class that implements a interface, is that class child class considered to be a IGameObject as well. or does it have to implement that interface directly.

does all this sound like I am going in the right directions lol, as far as organization is concerned.

Thanks for all of your help, thanks guys!

Answer 1

You should look into the Flyweight pattern

From wikipedia:

Flyweight is a software design pattern. A flyweight is an object that minimizes memory use by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory.

As for your second question, the answer is yes. All Subclasses of a Class can be said to implement all interfaces that the parent class implements.

Answer 2

One thing you could think about is using Composition of objects over inheritance. This sort of goes along with the Flyweight answer. Rather than having all your GameObjects inherit properties from GameObject; instead, have each game object just have a reference or pointer to an object or interface that has the properties it needs. For example, all your game objects probably have some sort of "size" property - rather than inheriting this from a base class, just have each game object reference or point to a "Size" class, so that the size object can potentially be shared among similar objects.

Answer 3

This seems more logical, but at the same time it seems it allocates more memory because I am creating more classes.

Creating new classes doesn't use a significant amount of memory. It's creating instances that uses memory - but again, the amount will be negligible compared to the memory used by loading in your graphics etc. Don't worry about memory. Your only concern at this stage should be good code organisation.

You should have separate classes when they have different behaviour. If they have the same behaviour but different properties, then you use the same class and set the properties accordingly.

In this case, you don't appear to have significantly different behaviour, but if separating it into Tree, Building, and House makes life easier for you when managing which items can be included in others etc, do it.