Technically, development is not over yet... As Mario of badlogicgames said, we can post bugfix updates without any content change. So we decided to do that and update the DevLog accordingly. This will be a bit more technical one.
The code was a mess with a lot of c/p code and unnecessary loading done in the background. We had several places to do some cleanup and optimization.
Our sound was always created on the spot using the Gdx.audio.newSound. This is not that bad, it does what it has to. But, we do not know if the newSound method checks if sound was already loaded, also Sound objects should be disposed when they are not used and that is a tricky thing to know. Our guess was that if not leaking, such on the fly sound loading is at the least slowing the game down. So we created a SoundManager that preloads sounds (optionally) and newSound is only called once per sound file. Since we do not have a lot of sounds it should not be a big memory issue. In the previous version one could notice a small lag before a sound was played for the first time, now that lag is gone. The manager itself is quite simple, one enum for all sounds with path/volume/pitch info and a map of loaded sounds.
Another thing was that our MainStage and GameMultiplayerStage were unconnected classes with a lot of underlying code just c/p from one another (downside of working fast with new technology) and we decided to clean it up. One GameStage later and no more copy paste code! It was a good OOP practice for Marija.
We had this pattern scattered through our game object classes (Ship, Asteroid, etc.)
private static TextureAtlas classAtlas = null;
private TextureRegion getSomeRegion( String regionName ){
if( classAtlas == null ){
classAtlas = new TextureAtlas( atlasPath );
}
return classAtlas.findRegion( regionName );
}It was a simple and useful pattern that prevented a bunch of atlases being created and was simple enough to c/p (again). But it was unsustainable. Instead, now we have AtlasUtils (an atlas cache) that does the same job, only it uses a static map of atlases and can be filled with any atlas. The downside is the overhead of digging through the map, but that should not be such a big deal. Again, the project is small, the added memory footprint of always having the atlases at hand is negligible considering the gain. A more advanced game should have some sort of cleanup mechanism for the atlas and sound caches.
Another thing we noticed was unnecessarily spawned were the animations. Flower blooming animation was created every time with every flower. Basically, all flowers have the same frame animation so we just made it static it in the Flower class and instantiated once. A similar thing was done on couple of other places.
And there you go, a bit smoother experience :) We have no idea how other people work with libGDX and Java, and to fix that I will check out other people's repos this week. If you are interested in our code, here is our repo. Check it out, tell us what you think!