Is this a bad design?

Hi,

Before my project gets any more complicated than it already is, I was hoping to get some advice on the way I’m currently handling my game objects, or rather, if the way I’m doing it is a bad design or not.

I’m not too sure which part I should start with, but I hope it makes some sense. :confused:
I’ll also try and minimize the code by explaining the best to my abilities.


I have an interface, called [icode]BaseObject[/icode].
It contains getters and setters that I think the most basic object would use, in my case, [icode]Matrix array, Model, Material, int numOf[/icode]
(int numOf is the amount of instances of this object)

I have several other interfaces that extend [icode]BaseObject[/icode], these are intended to be used to give extra information, things that would be specific to a spaceship, planet or even an asteroid.

I then have classes such as [icode]Planet[/icode] in which I implement [icode]PlanetObject[/icode]
(One of several classes that extend [icode]BaseObject[/icode].)

Now when launching the game, I create a new [icode]Planet[/icode] object, provide any information needed, and initiate it.
When it’s initiating, the model gets loaded from file and VBOs and VAOs are set up, the texture are loaded and set up also.

At the end, when everything is loaded, I put all the separate objects, put them into an array, say [icode]Planet[] planets[/icode].
Of which I pass to a setter, which sets an array [icode]BaseObject[] assets[/icode].
Like so:

BaseObject[] assets;

public loadAssets() {
   Planet p1 = new Planet(/* Some data */);
   // init
   Planet p2 = new Planet(/* Some data */);
   // init
   Planet p3 = new Planet(/* Some data */);
   // init

   Planet[] planets = {
      p1, p2, p3
   };

   setAssets(planets);
}

Then we get to the gameloop and things go as one might expect, I call an update method, which updates things like positions, rotations, checks the input, updates values and such.
I also have a method where set an array in my render class [icode]BaseObject[] toRender[/icode].

And if we don’t update, we render.
In the render class I would do the usual, but it would be like:

GL30.glBindVertexArray(getToRender()[i].getModel().getVao());
									
GL15.glBindBuffer(GL15.GL_ELEMENT_ARRAY_BUFFER, getToRender()[i].getModel().getVboI());

For example, where [icode]getToRender()[/icode] returns [icode]BaseObject[] toRender[/icode]. Keep in mind that [icode]BaseObject[/icode] is an interface.


So to refine the question, is it an ok design to use interfaces and such in that way?

And just to confirm, I should try and aim for readability and maintainability in my code?

Why use an interface? Why does it have getters and setters? This would require you to set those up everytime, to most likely get the same fields.

Why not just have a concrete class called GameObject, have it store fields that all objects will have. Maybe make it very generic so that more specific objects can extends and build from it.

If you need methods to be forcefully inherited by sub class, just make them abstract.

I do not see the need to use an interface here, unless I am missing something.

From what I have learned, you use interfaces to provide a public API and you should not heavily design with them. If it is only you that will use the code, then it is pointless. Exceptions are things such as callbacks or events, if you have a game that runs off events and all events need to use the same methods, then an interface can be very useful.

I… Uhm… didn’t think of that
facepalm

I don’t know, it was the first thing I came up with.

I guess, I don’t really know when to use an interface and abstract classes yet :confused:
And that I may have read somewhere that extending stuff was something that the developers regret implementing into Java, I can’t fully remember.
That may have influenced my thought process.

So thank you, I will redesign my game objects and hopefully end up with a better set up :smiley: