More Mumbling On LibGdx

My journey into libgdx continues. I am writing a 2D puzzle game at the moment so as you read this you should bear that in mind.

So far I am finding it a positive experience. It is taking a bit of an adjustment to using Vector2 that are mutable so things like add() change the original vector rather than creating a new one. I used to code like this but have recently taken a more immutable approach to things. It is not a big deal and just a little bit or rewiring my brain sorts it out.

Yes, I can see why you would want to do it their way for performance reasons and more intensive games certainly benefit from it. With a simple puzzle game that I am creating it just adds a little bit to my cognitive load.

Otherwise I am quite happy. The code I am working on is gradually moving towards game play and UI design rather than displaying stuff so I am writing less code that directly calls libgdx.

The concept of Screens is about what you would expect for a top level game state holder although I would like there there to be some built in transitions between screens. You can do it fairly easily, see this blog post,  but I would have thought most people would like to transition between screen and hence have it build in.

The things mentioned here are quite picky as you can see, they are not really a bit deal in the grand scheme of things. That should tell you that libgdx is pretty good at doing what it does. It is not super high level and has made design trade offs that give performance a priority rather than ease of use. Overall so far the trade offs are acceptable and something I will be grateful for should I try to do anything more complicated than a simple puzzle game.

Most importantly libgdx lets you easily target both Desktop and Android with ease and without the hassle of creating you own wrapper library. The progress on the HTML5 target is the icing although I have yet to try it.