*Game details will be put on a website: this README.md is detailing the code structure.
All assets belong in the android/assets directory. This is because of some weirdness in Android. Art and music both go there. Currently, assets doesn't have a strong structure, but this will probably be changed soon. Just use your intuition for where to place assets within android/assets for right now.
All dependencies are managed in the top-most build.gradle of the repository. As such, project management is done using Gradle. Gradle is used because it was the LibGDX default. LibGDX is a game development Java library that handles just about everything: game lifecycle, graphics, audio, etc. However, while LibGDX is in Java, the game is actually coded in Kotlin because it is a much nicer language to use and has full interoperability with Java.
While there are separate folders for every platform (desktop, android, ios), everything in those folders (the build.gradle and the Java files) are boilerplate files generated by LibGDX. All of the real game code is in the core folder. The core folder contains all of the files with main game logic and graphics and such. Platform-specific folders only control small things such as window or phone settings.
Within the core folder, all of the game logic is separated further into 3 main packages: graphics, logic, and networking. Outside of those folders currently exist 3 files: Main, Constants, and Options. Constants contains all of the game literals such as default port, default drone/base names, default colors, etc. Options contains all of the user preferences (eg. music and sfx volumes). Main can be considered the entry point of the application (the entry points are actually platform specific: Main doesn't have a public static void main(String[] args), but all the real entry points use Main) and is a class that represents the application. Main handles the general start and exit procedure for the game.
The majority of the game's UI is handled in graphics. The classes in graphics handle how each screen looks/behaves and also the general flow of what the user can do on each screen and what screens they can go to from there. All screens in graphics must inherit from GalacticRushScreen, because GalacticRushScreen contains a few niceties that is relied upon. Graphics also contains custom implementations of commonly used UI components like Panels or ModalWindows. The majority of the general clientside application code is in graphics as graphics hooks into classes from other packages in order to display them/send user input to them.
All of the game rules are kept in logic. All classes for objects in the game are kept in logic and all game rules and game mechanics are programmed in the logic folder.
Because the game is 2-player only (so far), there is much networking involved. The networking package contains all the code for this. Networking not only handles sending and receiving game states and changes, but it also controls the general flow of the program. To see where all of the logic code is actually run, check GalacticRushServer. GalacticRushServer manipulates and times the logic so that everything happens in order and so that the game is playable. Inputs to affect logic from clientside, however, are sent from graphics. You may notice that there are player classes within the networking package. Player classes are only for the methods of signifying how each player sends and receives game states. For example, if a player was on the machine with the server, how the server would receive their changes would be different than how it would receive changes from a player whose machine wasn't also running the server and was instead on the network. Networking classes are initialized in graphics when the user decides whether they will be a game host or game client.