It seems like you are enjoying your first major plateau experience. Plateauing happens to every programmer, but can be more intense and longer in duration especially if you are working alone / self taught. There are articles out there about plateauing and I’m sure you can find more in a search, but here is one. A cycle forms in this process where when you make the jump to that next plateau the first half of the experience is often refactoring your existing code then potentially problems once again pop up and the search for the next cliff to scale starts once again.
From a game dev perspective going down the traditional OOP route leads to not the best modular code / entity system. The anti-pattern that develops is the “god / blob” object; IE your base game object that everything extends from… As more and more systems are developed the tendency is to push the majority of them up to the god object. What you have built so far is not complex enough for this to have reared its ugly head; note OOP dependency injection should be avoided as it’s not a good solution; just a band-aid. This is the main impetus to move to an entity / component system.
Some good book resources (I’ve not read the first two):
Game Programming Patterns (free web version!)
Game Engine Architecture
OpenGL Superbible
On entity systems / components:
Data Oriented Design
Adam Martin’s ES series
I’d start with Game Programming Patterns since it’s free; jump right to ECS discussion as it gives a good overview on the why. The others will be much more dense in content and take a lot of time to absorb. Adam Martin has quite a few ES / Java articles though don’t take the design advice 100% as the way to do things; it’s just one way.
Since you are still getting a grasp on OOP two oldie, but goodies for that is Head First Java and Head First Design Patterns which will provide reasonable coverage of “traditional OOP”. This will probably help provide the vantage point to embark further down the data oriented design / entity / component system direction.
About data oriented design… At a glimpse this is the discipline in game dev (or any performance oriented programming area) of understanding how the underlying hardware works best to efficiently process data. Your GPU processes data in parallel; you can also process data on the CPU in parallel. Entity / component systems are the high level realization of DOD that organizes ones code / data for better processing. A central premise is that a good data component collects all the data that is associated with a given domain (physics, etc.) such that one can do the processing necessary without retrieving or collating multiple areas of code to get all of the data necessary to perform the processing. There may also be cases where a data component for all entities is pre-processed creating one giant block of data that needs processing in bulk.
Hand in hand IMHO at least with DOD / ECS also comes event driven programming. This is how components communicate with each other and the rest of the system aiding modularity and control flow. You will be familiar with the listener pattern from the various Java SDK implementations for say input, etc. It’s 2017 now and the 90’s can keep the listener pattern. You’ll want to look up “Java eventbus”. You may find a bunch of links about Google’s Guava; stay away from Guava or at least that is my opinion.
To make the jump to fully understanding how ECS work in Java one needs to thoroughly understand generics and in particular generic methods. As things go this is a rather advanced subject and can be a bit mind bending. The best reference is this resource. It took me 5 years ('05-'10) to fully appreciate Java generics and realize the applications beyond just the syntactic sugar applications (where 95%+ of folks stop).
Eventually you’ll need to master concurrency, but this is an advanced topic; a good starter book though. For now just keep all your code single threaded on the CPU.
Though you’ll want to learn how GPUs work (older article, but good start). Go directly to shaders and don’t bother to implement in your code the much older fixed pipeline approach except at least read about it for educational purposes. What shader programs do is define an algorithm for vertex & fragment (the final pixel rendered) processing that is applied across multiple data at the same time. The OpenGL Superbible is your first stop for this direction.
Since you have a go getter attitude and are using libgdx. Certainly put something together as a demo then examine the libgdx code for how and why it works especially sprite batching (advanced topic). You can also check out the available Java entity / component systems; I’d suggest Junkdog’s Artemis ODB as the best candidate. On the latter there though none of the public ones are what I consider to encompass the complete picture of what is possible.
As far as some of the previous discussion. When I mentioned find a team to participate with that is more about the temporary hackathon experience versus finding a distributed ongoing team.
Another example are bits, I don’t seem to understand how to use bits.
Bit masking can be useful as the first implementation of state tracking, but it is fragile. The fragility comes as more and more states are added and that this type of approach is not suited for modularization where one combines state across multiple domains. The better approach is using Enums and EnumSet, however even that is not complete as you can not mix two different types of enums together. You can though create extensible enums and use a HashSet at first. Sadly there is no publicly available ExtensibleEnumSet implementation that I’m aware of out there which is the next step in efficiency allowing EnumSet performance across multiple extensible enums. Some starter references; the grand master is from Effective Java (a good book itself); here are some notes. It should be noted though that Joshua Bloch in his exposition on extensible enums stops just short of some of the really powerful applications.
It should be noted that the info above is coming from my perspective. You’ll find a fair amount of folks on JGO that are more pragmatic or eschew some or all that I’ve mentioned above, so you may come across varying attitudes.
And just be ready to spend years getting a hold of most of the above. Be ready to spend several months to really grasp some of these topics as they can be deep and are complicated. Learning OpenGL / shader programming will be one of those areas that simply put just takes time even if you are already an accomplished programmer. I wouldn’t recommend for instance even looking at Vulkan until you have a thorough understanding of OpenGL.
