Lots of big frameworks (Spring, Akka, Grails, etc.) have so-called reference implementations that showcase the proper use of the framework and that demonstrate best practices and how to properly implement the various features of the framework, etc.
I’m wondering if anything similar exists for jME3. Reading the docs & tutorials is amazing and wonderful (and I do appreciate jME3’s wonderful documentation). But actually seeing the API/code in use (and being used correctly) is a whole other thing.
Even if there aren’t any official reference games for jME3, is anyone aware of any open source jME3 games (that I might find on GitHub, BitBucket, etc.) that serve as good examples for structuring a game properly? Obviously all games are wildly different from one another, but surely there are “right” and “wrong” ways of using the API, structuring the game, etc.
JME is generally built and it’s difficult to tell if a game is “properly” structured or not. However,if you understand the [Application States] (https://jmonkeyengine.github.io/wiki/jme3/advanced/application_states.html#toolbar) you should be able to make a good hierarchy for your project. You can look for code examples in the page i linked and if you’re looking for a template,check those threads:
You can also look into the Tests (the SDK generates a project or you look through each subfolder of the repository) which demonstrate specific capabilities one per test.
Apart from that you have @pspeed and his repos (simsillica lcc on github).
Pauls Code is always relying deeply on app states etc, however for small games they might even be oversophisticated (at least that is my opinion, but you can learn good structure from that)
Since they were mentioned, some links to thinks that use JME-preferred architectural approaches:
There are lots of good reasons to start this way. It may seem overly complicated, I guess… but the alternative is to plan for a rewrite as soon as your giant main class collapses under its own weight.
It uses an entity system, though, which may cloud things a bit. Though that’s also a highly recommended approach… it has its own somewhat steep unlearning curve. (“unlearning” because 70% of an ES is learning to forget a lot of OOP habits.)
Appstates for me give a portability and maintainability. I am in support of them as long as the user understands what they are. They are not singletons yet raw code in examples suggests otherwise (getState(classname.class).doSomething() for example) and confuses newcomers. This is where and why documentation is important i guess. But i took an appstate out of my code just today in under 20 minutes including uploading to github. That shows how they can and should work. The documentation should encourage that behavior too. Shame you cant have dependencies for appstates… bleh. I digress…