Getting all set up

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.

First post for a new beginning

Hi there,

My webpage has been empty for quite a long while and it’s time to change that. You see, last summer I began pursuing a B.S. in Computer Science at UNCA. This semester, I added on 1 credit hour for undergraduate research. My professor is rather hands off for this research project and overall it feels pretty free form. I figured I should probably have some kind of record of what I’ve been doing so this blog just seemed like the obvious place for that.

For a long while now I have been wanting to design a multiplayer game using an entity component system (ECS) and a client/server setup over UDP. Why UDP? Mostly because it is way harder to design for UDP than for TCP, but also because the game I want to create is an action oriented game. I thought that this concept would be great to explore for my undergrad research and an excellent way to really push my limits.

For some background, I had already started on this project a long while back. I began making the game in Java using the LibGDX game library. The game concept is a 2D, top-down space shooter/sim inspired by the likes of Escape Velocity. I got as far as having a single ship on a starry background and a very basic client/server setup allowing multiple players to connect to each other and see each other flying around – at least until you fly away from the starting point and are never able to find each other again due to there being no level boundary. I started looking at how to implement something like Source Multiplayer Networking and felt very overwhelmed by it all. Other projects came around and it wasn’t long before I moved on to other things.

So far my undergrad research this semester has consisted of studying these Gaffer on Games articles about multiplayer networking while looking over my old source code and hopelessly wondering how in the world to continue it. The old code, while it was a basic UDP client/server implementation, had the issue of not knowing how big the packets I was sending were and that bothers me a lot now. Additionally, I recall that the multiplayer was more or less working for at least 3 players but now it does not work very well at all. In my last test run, we got 2 players connected to the server and had their movement synced for all of about 1 second. I’ve come to the conclusion today that since I’m not very far along I might as well just remake it from scratch.

KryoNet will likely still work as my networking library but I will need to ensure that I am will be able to keep track of how much data I am sending/receiving with it. My choice of ECS will likely still be this reflection based ECS (RECS) that I have contributed to in the past though I plan to look into what new options are out there. The author of RECS has used a lot of very clever tricks in order to obtain a highly performant system; it will be interesting to see if other ECS libraries can compare.

I briefly considered using C++ for my rewrite but I have decided against it for the following reasons. I am not very familiar with C++. While many large game developers tend to use C++ there are a huge number of indie developers who don’t and are still able to produce excellent games. Getting better at game design, even if only in one language, will likely be better than using sub par techniques while stumbling through another language.

Here’s a link to the github repo for the project if you’d like to follow along.