By default, a project is set up with "desktop" creating a new LwjglApplication from your main class in "core".

The main class in "Core" implements ApplicationListener and contains everything needed for the display, most importantly, "Render".

This is very awkward. I'm used to having things set up as follows:

Main
- Controller
- View
--> Input

Where Main creates an instance of Controller and View and I use interfaces to communicate between the two. I do not like my entry point being the "View" (which is what I will end up doing if I continue like Lwjgl has it set up).

I'm unsure how I can modify this setup to better suit my needs. I suppose I could modify the "desktop" program directly, use it as the "main" and have it create the controller and view. Is that the right way to go about doing this?

Thanks,
Chumble

This sounds like you are overly complicating things for yourself through the needless use of design patterns. I really don't know what to tell you other than accept the API as it is and layout your code logically and reasonably.

I dont even understand your problem. Could you show some code to demonstrate what you mean?

It's not a code problem, really. With the default setup (let's assume my project is called "Game"), the process is

1) "Game-Desktop" program with void main executes "new LwjglApplication(Game(),otherArgs)"
2) "Game-Core" "Game.java" program executes. This class implements "ApplicationListener" (and any attempt to remove this implementation messes up the args in LwjglApplication).

So, that means basically the first major part of the entire application to execute is the piece that renders the screen. This is totally backwards from what I'm used to. As posted above, I really enjoy the entry point to be a "main" class that executes the separate pieces of the application (Back end/calculations, Screen, Input).

What I ended up doing is modifying the "Game-Desktop" program to do just this. It may be completely against convention and I will need to duplicate these steps for any other platforms, but it allows me to set the game up as I like. I do not like the screen rendering program to be responsible for performing backend calculations.

I dont see how the Screen-Rendering part would be responsible for back-end calculations as you put it.

You only need to set up the display in the same thread where you poll the input and do all OpenGL-related stuff.

You can still do everything else in a separate thread. Game-logic, networking, music, whatever. Only OpenGL-related function calls need to be done by the same thread that created the Display.

Are you pointing out what the libgdx LwjglApplication is ? Here's my advice :
The model view controller MVC pattern is not the same as a client-server pattern (...), in which a Listener is likely to be the -server- or alike. LibGDX obviously runs like a client API, which can handle crossplatform coding.
Therefore I would consider modifying the client behaviour, so that it will handle things like physics algorithms and other similar stuff. The client-server pattern assumes that this would be the SERVER-side job, or yours indeed.
That's the clue...