As requested by @richtea, I am starting this thread to collect opinions about the below issue on jme-initializer web app.
Should we put assets inside /src/main/resources/ which is then packed inside the game code or should we make assets a separate subproject that packages all assets into assets.jar when assembled? (like in simple-jme template)
Which one do you use in your project?
Afaik the SDK and BootMonkey (I think it was built on top of Paul Speed JME examples gradle template) use the second approach.
It’s the standard Gradle setup, that means it works out of the box without any gradle configuration, it also means that IDEs, Plugins etc are less likely to get confused and need special configuration. Also it’s where new developers who are familiar with Gradle will expect it to be, avoiding initial confusion; this also means when people want to do something unusual they are starting with a normal setup so whatever guide they are following is likely to cater for it (rather than developers having to figure out how to deal with a separate assets folder).
(admittedly the reverse is also true, as people who have used the ant JMonkeyEngine layout expect /assets/)
On performance, I tested running ./gradlew run with large resources and it doesn’t recopy over all the resources into the build folder every time, only when they change, so I don’t think /src/main/resources/ or /assets/ has much of an impact on build performance
I always put assets in “src/main/resources” and create a “fat” JAR combining classes and assets. I never build a separate JAR just for assets.
If a project utilizes procedurally generated assets, then the generators are usually a subproject. The generators write into the “src/main/resources” directory of the subproject that builds the library or app.
Personally, I use both in my real projects… but use src/main/resources in the simple ones or ones that I would prefer distribute together anyway.
But, for example, a real released game, it would suck to have to give everyone a new 200 meg jar just because I updated a class file… so the intent is to keep things separated. By the time that’s a problem for a user, hopefully they’ve figured out how to do it.
If you choose to keep the separate “assets” project then it might be good to make it optional… and also if possible name the assets subproject after the main project.
mygame/mygame-assets
…the only reason I suggest that is because personally it caused me lots of heartache that all of my apps were writing “assets.jar” into the same .m2 location whenever I did gradle install and I wish I’d had better naming discipline. (Gradle supports having an assets directory with a different subproject name but I don’t know how IDEs like that.)
I am with the idea that assets should be treated as a separate dependency and add it to the class-path while assembling the project, it would be helpful in new releases, just the same as using code modules on large projects or whatever …
Yeah, that is because the gradle building tool implements an incremental building API, it compares both last date of modifications, the original files and the output files.
By default, I would keep the standard gradle directory structure, i.e. src/main/resources.
IMHO it will cause far less trouble for simple and example projects.
If someone reaches the limits of this approach, he certainly has the experience to move it to a separate jar.
