After an arduous journey I have finally set up my project using the newest LibGDX version. One significant difference that complicated the normally rather simple LibGDX setup was their change from Maven to Gradle at some point since I last used it. Gradle is essentially Maven’s shiny new child that seems to be all the rage these days. It is something I’ve been wanting to learn for a while and this was the perfect opportunity. I was forced to really dig down into the details of Gradle due to one rather bizarre choice made by the LibGDX authors. They have decided to use a non-default directory structure. This was confusing to me as it didn’t really leave a good place to put unit tests. Switching to the default directory structure was no small matter, as I quickly learned; there were many moving parts to adjust.
My bare bones project was finally building and I quickly set to work. My first order of business this time around was to implement game states, or some way to go from a main menu to the game to an in-game/pause menu. I was pretty confused about how to implement game state in an ECS when I previously worked on this project so the game was just something you ran and were put immediately in the action. Additionally, if you wanted to connect to a server other than localhost you would have to do so from the command line when launching the game. This time I wanted to have a main menu with some option to connect to a server from within the game. Something else I desired out of this game state system was a layered pause menu. That is, when you open the pause menu, I want the player to be able to see what was happening in the background. To that end, my solution ended up being pretty simple but I’ve yet to see how well it works in practice. Basically, each state will have a set of entity systems that it allows to run. For instance, to pause the game, I can simply enable a UI rendering system and disable the entity movement system, effectively pausing the movement in the game and rendering the pause menu UI on top of it.
I’ve ended up salvaging a little bit from the first iteration of this project. So far, just a position component and the texture rendering system. These things worked well enough and weren’t fiercely entangled in the old netcode. I expect I will pull as much as I can from the old project as long as it is straight forward and is or can be decoupled from the old netcode.
My immediate goals now are to get a working main menu with the ability to transition to the main game state. After that, simple ship movement so that I can test how well this layered game state works with a pause menu. The pause menu of course only makes sense in a non-multiplayer game so going forward I’m going to be working under the assumption that I will have an offline mode available.