One of the best features of GDX is stability and by that I mean API stability – despite undergoing a fair number of changes throughout its development, the number of project breaking changes have been kept to a minimum. Given that its a high level graphics library that can also be used at a low level, this is no mean feat. The result of this is that its often my go to library when I want to try out some idea or experiment.
I find these experiments much easier if I have a functional starting point, which is probably something that will make life easier for others too, so for what its worth I’ll describe some of my boilerplate codes features and make it available here.
There are four classes, MainDesktop can be ignored, its just the platform specific stub, which you’d replace to make for example an Android version
We’ll look at the Entity classes later, which leaves the BoilerPlate class as a good place to start…
The life cycle of a typical GDX application begins with the create method, while this is great place for assets that don’t require loaded resources, anything that needs loading (and parsing) should be handled with the asset manager (Its easy to create your own custom loader if needed) this allows for a nice loading progress screen… (you’ll find mine particularly awesome!)
While the model creation part is specific to the example (and not really boilerplate…) but its worth mentioning the material use with the model instances.
boxModel = modelBuilder.createBox(1f, 1f, 1f, new Material("Colour", ColorAttribute.createDiffuse(Color.RED)), Usage.Position | Usage.Normal ); instances = new ModelInstance(boxModel); instances = new ModelInstance(boxModel); instances = new ModelInstance(boxModel); instances.getMaterial("Colour").set( ColorAttribute.createDiffuse(Color.GREEN)); instances.getMaterial("Colour").set( ColorAttribute.createDiffuse(Color.BLUE));
the first thing to note is that I’ve made sure to give the material an id ( “colour” ) this mean when we have a model instance we can very easily retrieve the material later to give potentially each instance its own colour… (or any other property for that matter)
There’s little more that 100 lines ignoring the example code, so its all fairly straight forward one thing that makes this possible is the use of an entity class.
The Entity class is abstract with just a little code to allow for a collection of all the entities (the entities are added to the list by the constructor) two methods allow rendering them all and also updating, the updateIndividual method is abstract and is where you implement the behaviour for a particular entity type, for example if you were to implement a simple state machine for an “alien” entity you’re a long way down the road towards faking some kind of “intelligence” for your entities.
By looking through the code and reading the GDX API you should be able to get a handle on anything you’re not terribly familiar with.
You can get the full source here