If the main class is named as "Game" with the "Game" template than the class has cyclic dependency.

[SonicGDX]

If the main class is named as "Game" with the "Game" template than the class has cyclic dependency.

[tommyettinger]

It's a fair point... I'm not sure how it could be solved in Liftoff code itself, since the template that's selected would affect what main class names are allowed. I think using the name of any core libGDX class for the main class name is a bad idea, though. Just like I wouldn't name a class in my code after something that exists in the core JDK library, like Array, I mean, Queue, I mean, Vector, I mean... uh...

[tommyettinger]

I have an easy monstrosity of a fix in the latest commit. I took the listing of every type in the libGDX core from a file generated in its docs, type-search-index.js, did some minor preprocessing with find+replace, and got a massive HashSet out of it. This is checked in the validation step for the main class field, and it also does a similar check to the one used for validating packages. Now, names such as Game, Stage, Map, Path, Cell, and so on are all noted as duplicates and forbidden from being the main class name. Platform-specific names aren't really a concern here yet, because so few classes might collide in a launcher file.

Thanks for your work, @cartesian-plane ! I do think the code that's in the latest commit is more robust, even if the way I wrote it is a little crazy. However, if you and @SonicGDX hadn't brought my attention to this issue, it would probably still be sitting here, collecting dust.

I think this is resolved, though I'm not totally sure. Please comment here or reopen after the next release (1.12.1.8) if this isn't solved then!

[cartesian-plane]

It's a fair point... I'm not sure how it could be solved in Liftoff code itself, since the template that's selected would affect what main class names are allowed. I think using the name of any core libGDX class for the main class name is a bad idea, though. Just like I wouldn't name a class in my code after something that exists in the core JDK library, like Array, I mean, Queue, I mean, Vector, I mean... uh...

I would like to make a more general fix for this, but I'm not sure if there is any way to read what Template is selected.
Is that not possible, or am I missing something?