I think I've done something smelly, but not sure. I want to access some of my main class, Game, fields (SpriteBatch, change current state, etc.). The solution I was using prior libGDX is to make all fields and methods of Game static (smellrometer overflowing!). But libGDX uses an instance to start the game loop, so I had to change the way I do things.

Now I have a Overlord static class which stores all the important instances (right now is only Game) and provides public static methods for accessing its fields.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

publicclassOverlord{privatestaticGamegame;

publicstaticGamegetGame() {returngame; }

publicstaticvoidsetGame(Gamegame) {Overlord.game = game; }}

I have global access to the SpriteBatch (the canvas where I draw) via Overlord.getGame().getSpriteBatch().

In a scale from "good idea" to "worse than unjustified GOTO", what do you think about it?

@Regenuluz: Thanks! I used to keep a private reference to Game in all the classes that made use of it. But there are two problems:

1) it escalates really bad (just imagine you have to access to other two classes, more getters/setters, more fields...)

2) it breaks certain symmetry that my OCD didn't allow to happen. Imagine you use game states. Menu is a child of GameStates which in turn is parent to all kind of menus (pause, game over, main menu, etc.). Probably some menus will make use of Game while others don't. Then what? Include special Game fields in the ones that use it (apart from special constructor and/or getters and setters) which makes every Menu child different, or include a Game field in Menu, which is under-efficient.

So I ended up using a static Overlord XD

@Riven, @princec, @Damocles: Thanks for the advice! I knew about kevglass uber-rules that rule (I still have to improve GettingStarted.part 5...) and it certainly is a relief to know that important gamedevs like yourself think it is not too bad not to use it :_)

Having a global Game is perfectly fine. But you should be aware of where you use it. Consider passing data in as parameters to methods or to the constructor instead of getting the data threw the global Game object. It will reduce coupling. So it would be ok to use it in the Menu screen but maybe avoid it in the Font class.

Also, some personal preferences:

Avoid using setter and getters. Just make the fields public if it is a data heavy class, like tuples. If the data is read only then pass it into the constructor and make the field final.

Avoid using inheritance. Especially if you use it as a way to reuse code.

GameWindowGame (has Bitmapfont, main loop and SpriteBatch)|_____> all states (Game as constructor ref) |_____> entities (Game as constructor ref too, so each entity can grab delta time, keyinput, SpriteBatch which is public)

[...] Consider passing data in as parameters to methods or to the constructor instead of getting the data threw the global Game object. It will reduce coupling. So it would be ok to use it in the Menu screen but maybe avoid it in the Font class.

I don't understand that, especially: "Consider passing data in as parameters to methods or to the constructor instead of getting the data threw the global Game object". Do you mean something like this example?

Avoid using setter and getters. Just make the fields public if it is a data heavy class, like tuples. If the data is read only then pass it into the constructor and make the field final.

I agree. By default I always use getters/setters and never public fields (Effective C++ can be really convincing), but for some read-only fields I think the final field + value passed as constructor parameter could be 1) logically better, 2) prettier :-)

Avoid using inheritance. Especially if you use it as a way to reuse code.

I mainly use it because of polymorphism (I have a GameState field, but store a Menu, a Level, or Cinematic, which are children of GameState).

But also for code reuse. Menu has the methods to check whether the user has touched a menu entry and to call the appropriate Command to execute. So MainMenu, PauseMenu, GameOverMenu, and so do not have to repeat that piece of code.

GameWindowGame (has Bitmapfont, main loop and SpriteBatch)|_____> all states (Game as constructor ref) |_____> entities (Game as constructor ref too, so each entity can grab delta time, keyinput, SpriteBatch which is public)

What do you accomplish by using a local reference to Game instead of having it accessed globally? For an entity-heavy game you could end up with 100+ local references to Game. Isn't it better to use only one reference that is globally accessible?

Thanks for your comments, I'm enjoying very much knowing how other people have dealt with these problems :-)

I use a fairly reasonable amount of inheritance - usually no more than 3 or 4 levels deep - because composition in Java is ugly boilerplate and basically slower to code and a bitch to maintain vs. inheritance.

What do you accomplish by using a local reference to Game instead of having it accessed globally? For an entity-heavy game you could end up with 100+ local references to Game. Isn't it better to use only one reference that is globally accessible?

Honestly, not much. I use the global method. Not only is it used by just about every class in the system, it's also effectively a singleton; it simply doesn't make a lot of sense to pass it around everywhere unless you're of a mind to do unit testing. If you're doing unit testing for your game you've already wasted half your time making the game.

I don't understand that, especially: "Consider passing data in as parameters to methods or to the constructor instead of getting the data threw the global Game object". Do you mean something like this example?

I agree. By default I always use getters/setters and never public fields (Effective C++ can be really convincing), but for some read-only fields I think the final field + value passed as constructor parameter could be 1) logically better, 2) prettier :-)

I meant the opposite. I consider getters/setters as a bad smell and can often be symptomatic of bad design.

There is always a conflict between the right way and the easy way. Atleast its impotant to know the downsides if you go the easy way. e.g. maintaining a large Application without units test or reading Code with deep inheritance hierachy is a pain. For me the only way to go fast is go well.

That's good in this case, because all the draw methods are called from Game.draw() and I can pass the SpriteBatch parameter on them. But when things go the other way around (imagine Entity.update() needs information of SomeOtherEntity.getPosition()) then I don't see how to make it. It's just the way I know how to make things work :-(

I meant the opposite. I consider getters/setters as a bad smell and can often be symptomatic of bad design.

That's weird, I consider accessing the field directly to be a bad habit. You are breaking encapsulation for good. I understand that sometimes, when modifying great amounts of data, passing a heavy input parameter to a setter could be less efficient. But accessing the field directly by norm...

Composition. Google around and you'll find that most people favor composition over inheritance.

Hmm, I thought composition was preferred to inheritance when there is no clear is-a relationship, but in my case, MainMenu is-a Menu and Menu is-a GameState. It really don't go further than two/three levels. Also, composition has the great disadvantage of delegating all methods to the implementation (is it more tedious to maintain though might be less coupled to the superclass).

Thanks! I keep it in mind and have to read about composition with interfaces, which the author claims is the real replacement to inheritance.

Honestly I agree with him. Look how easy problem can be solved by interface, and I use interface a lot. Basically it tells you to avoid inheritance and code separately then use interface when you need polymorph.

That's weird, I consider accessing the field directly to be a bad habit. You are breaking encapsulation for good. I understand that sometimes, when modifying great amounts of data, passing a heavy input parameter to a setter could be less efficient. But accessing the field directly by norm...

If you have code like this:

1 2 3 4 5 6 7

publicvoidsetBounds(Rectanglebounds) {this.bounds = bounds;}

publicRectanglegetBounds() {returnbounds;}

Then all you've done is add boilerplate code that does nothing.

If you've got code like this:

1 2 3 4 5 6 7

publicvoidsetBounds(Rectanglebounds) {this.bounds.set(bounds);}

publicRectanglegetBounds() {returnnewRectangle(bounds);}

Then fair enough, you've protected your internal state. You should always try to do this.

However you've exposed to the outside that the object has a bounds. The object oriented way would be to have methods on the object that uses the bounds instead of exposing it. So instead of:

@tom, @sproingie, @ReBirth: I read Item 16 of Effective Java. This item example is clear on when composition is better than inheritance. It took me long but now I'm convinced that composition is a real alternative, thanks! :-)

That makes sense, but I'm not sure I know how to implement it in the design I have so far :_(

Ok, the thing I get from this discussion is I have to keep reading/learning to improve my code AND kevglass/Riven advice 1) make a game, 2) make it efficient enough so it is fast, and 3) make it pretty. I'll try to advance in both paths in parallel!

In general I find that exposing the fields of objects makes my toes curl and hang my head in shame, and I've always tried to design systems such that no such access is required for classes of any reasonable abstraction beyond what amounts to a struct (eg. tuples and such).

But the longer I code games and need to get shit out of the door the more I find myself bodging them in to get something to work quickly. Game ships, money is made, the Perfect Code Angel quietly weeps and the Great Pile Of Money Daemon cackles.

But the longer I code games and need to get shit out of the door the more I find myself bodging them in to get something to work quickly. Game ships, money is made, the Perfect Code Angel quietly weeps and the Great Pile Of Money Daemon cackles.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org