assets should be a separate project

[Ali-RS]

In the current build setup, assets are included inside /src/main/resources/ and are packed in the game jar. IMO it is better to make assets and code separated for real game projects.

Assets better to be a separate project in gradle with no code in it that the game project depends on and it should be packaged separately to assets.jar.

See this for an example
https://github.com/Simsilica/Examples/tree/master/sigem

[richardTingle]

I'm not sure I understand this one, isn't that the old, pre gradle way of doing things (but then modified to get gradle to behave)?

Why isn't this suitable for a real game project? (It's how all of mine are organised)

[Ali-RS]

That is how the previous gradle bootstrap generator (developed by Nehon) worked back then, also the SDK is packaging assets to a separate jar file iirc.

For example, BootMonkey or all of the Paul Speed examples (I have linked one above) follow the same approach

https://github.com/Nehon/bootmonkey

https://hub.jmonkeyengine.org/t/bootmonkey-bootstrap-your-jme-project/37141

Why isn't this suitable for a real game project?

assets better to be portable and separated from code (I guess it can even be used with ZipLoader for example), despite modularity it also improves build performance. See Electrostat-Lab/Cross-platform-template#10 (comment)

That is what I recall.

[richardTingle]

@Ali-RS A lot of JME templates tend to have that structure, but is that just a legacy of their ant origins?

With Gradle resources aren't processes unless they have changed (gradle takes a lot of care to avoid unnecessary work) so I'm not sure that build performance would be affected either way. This can be quite difficult to test because gradle is so good as noticing when you've messed with its build folders. I tested this by putting a HUGE file in my resources folder, then calling gradle run; first run took 1m 21s. Changed the java then ran it again and it took 8 seconds. So it isn't copying the files every time.

I'd suggest start a thread on the forum, if you can demonstrate broad agreement that a separate assets folder is better I won't stand in the way of a PR. But I will be arguing on that thread that keeping to a normal gradle structure ought to be the default as it means its easier to understand and plugins are less likely to get confused and need special configuration. That said, if I do lose the argument I will still be asking "why not a normal multimodule project, why a floating assets folder?"

[Ali-RS]

@Ali-RS A lot of JME templates tend to have that structure, but is that just a legacy of their ant origins?

Not sure, I think that is because those are mostly copied from @pspeed42 examples.

I'm not sure that build performance would be affected either way

Well, yeah, newer gradle can handle it pretty nicely these days, but a subproject is still nice because it gives you a separate assets.jar just like the SDK would produce.

I'd suggest start a thread on the forum,

Ok

I will still be asking "why not a normal multimodule project, why a floating assets folder?"

It is a gradle subproject but without a build file which I believe is nice for assets. See the original author's comment

https://hub.jmonkeyengine.org/t/projects-template-without-sdk/35200/96?u=ali_rs

here is how it is defined in build.gradle

https://github.com/Simsilica/Examples/blob/6ccd7a138fd948ac472793106780935b57e42657/sigem/build.gradle#L22-L34

included
https://github.com/Simsilica/Examples/blob/6ccd7a138fd948ac472793106780935b57e42657/sigem/settings.gradle#L1

and added as a dependency:

https://github.com/Simsilica/Examples/blob/6ccd7a138fd948ac472793106780935b57e42657/sigem/build.gradle#L57

Edit:
Forum topic:
https://hub.jmonkeyengine.org/t/initializer-gradle-game-template-assets-setup/46516

[richardTingle]

The forum discussion felt like it went down evenly both ways. Any objection to me closing this as "won't fix"?