Initial PlanetGenerator Setup #602

IsaiahBlanks · 2021-07-21T14:39:00Z

Description

This PR adds the default implementation of Planets to the new modular world-gen system. It also sets up the game so that SolarSystems and Planets generated by Generator classes show up in the game.

In this implementation, many options are available to the Planet via getting the config in your particular implementation, and then changing various values

Testing

Run the game, and you should see SolarSystems running with Planets in them, but no belts and no mazes. There are two types of SolarSystems that will generate, the default systems and large SolarSystems. Generate a world with a good amount of systems (at least 4) to make sure you see the different types.

Outstanding Work

Two features still need to be added for Planets. One is the ability to place custom objects/ modify terrain, which will involve modularizing the PlanetObjectsBuilder class to accept types of objects, instead of specific objects. The other is the ability to load custom PlanetConfig files. Additionally, tests need to be written still. There is an issue with testing PlanetGenerators as the require the PlanetConfigs class to be loaded, and this seems to be dependent on the class CollisionMeshLoader, which is throwing an error when running tests

Create default Planets, display SolarSystems and Planets in game

PlanetGenerators working and modifiable, PlanetGenerator tests

Cervator · 2021-07-27T19:25:37Z

Tests out!

Was able to run the game in my Android Studio setup, although I had to delete my local warp module (incompatible with the worldgen changes, although probably an easy fix). Did get some weird errors from trying gradlew clean buildDebug run but that might just be the workspace. gradlew jar run worked fine after I deleted warp

Can confirm the game runs as described, I started with a few more systems than usual and got a nice big game world, no belts or mazes - which is fine even for merging since there's a target topic branch. Was able to travel to the nearest planet and see it looking pretty normal. One oddity: on my way there I flew by a hostile space station - I think those are limited to the second solar system in the classic setup? With worldgen changing it makes sense some things like that will be thrown off, the starter system should probably be special and have fairly mundane spawning rules.

It might also help this PR with a quick description of a test that'd vary a planet or planet type, although that may well be more for a tutorial like Terasology's worldgen one :-)

I did eventually crash, after arriving at a different solar system and heading toward a planet there, with a java.lang.AssertionError: normalizing NaN angle - DS code tends to crash rather overly hard with these assertion errors over even tiny things. We probably have existing bugs floating around still that cause the issue, but maybe this is new since the stacktrace includes some planet gen. Full stacktrace:

com.badlogic.gdx.utils.GdxRuntimeException: java.lang.AssertionError: normalizing NaN angle
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:117)
	at org.destinationsol.desktop.SolDesktop.main(SolDesktop.java:149)
Caused by: java.lang.AssertionError: normalizing NaN angle
	at org.destinationsol.common.SolMath.norm(SolMath.java:107)
	at org.destinationsol.common.SolMath.angle(SolMath.java:354)
	at org.destinationsol.game.planet.PlanetObjectsBuilder.buildGroundShip(PlanetObjectsBuilder.java:336)
	at org.destinationsol.game.planet.PlanetObjectsBuilder.buildGroundEnemies(PlanetObjectsBuilder.java:107)
	at org.destinationsol.game.planet.PlanetObjectsBuilder.createShips(PlanetObjectsBuilder.java:88)
	at org.destinationsol.game.planet.PlanetObjectsBuilder.createPlanetObjs(PlanetObjectsBuilder.java:75)
	at org.destinationsol.game.planet.Planet.update(Planet.java:79)
	at org.destinationsol.game.planet.PlanetManager.update(PlanetManager.java:68)
	at org.destinationsol.game.SolGame.lambda$null$2(SolGame.java:385)
	at java.util.ArrayList.forEach(ArrayList.java:1249)
	at org.destinationsol.game.SolGame.lambda$update$3(SolGame.java:384)
	at java.lang.Iterable.forEach(Iterable.java:75)
	at org.destinationsol.game.SolGame.update(SolGame.java:383)
	at org.destinationsol.SolApplication.update(SolApplication.java:251)
	at org.destinationsol.SolApplication.safeUpdate(SolApplication.java:225)
	at org.destinationsol.SolApplication.render(SolApplication.java:189)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:392)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:137)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:111)
	... 1 more

If this isn't an obvious bug it may be a call to harden the code somewhere to catch this better and either log more informative details or even skip over something small if it is like a single turret that fails to place (still logging an error, of course

Other stuff:

Eventually make a compatibility PR for the warp module and any other modules the GSOC work may break - which I suspect is very few as code in modules so far is really rare
Probably just for making an issue to process later, but: are starlanes being placed excessively, to where you can get to many places from many places, rather than have to hop hop hop to get somewhere distant? I got into a way long one to get to an outer system (played with like 6-7 systems). Probably this needs to be balanced by either breaking the starlanes into shorter multi-hop trips or maybe vary the speed based on the length to reach a comparable short-ish duration on any sort of travel.

Cervator

Egads I have had time to do a semi-thorough review! Probably not really though, it is limited how much focus is available with a newborn half-sleeping behind you. Consider this some starting recommendations rather than necessarily an involved treatise on the architectural applicability of the PR overall - would probably be good with another set of eyes to consider that :-)

I think one thing I run into repeatedly is separating your new/moved code with legacy code. We could probably talk about refactoring naming and such all day long yet that's at least somewhat beyond the scope of your GSOC. So wherever I'm poking at a naming issue feel free to skip if it is preexisting or better yet add some todos or issues so somebody else can return and address it later at some point :-)

Cervator · 2021-07-27T19:29:22Z

engine/src/main/java/org/destinationsol/game/planet/CloudBuilder.java

@@ -0,0 +1,95 @@
+/*
+ * Copyright 2020 The Terasology Foundation


Happy New Year! Wait, it is almost August? 😁

Cervator · 2021-07-27T19:30:52Z

engine/src/main/java/org/destinationsol/game/planet/CloudBuilder.java

+ */
+public class CloudBuilder {
+    private final List<TextureAtlas.AtlasRegion> cloudTextures = new ArrayList<>();
+    //Frequency at which clouds will generate


I love seeing variables documented like this, although maybe that's just a weird personal thing. Although I'd use single line javadoc - even if the code is private it highlights nicely in an IDE and I figure it would actually show with javadoc preview even if javadoc generation doesn't exact it. So in other words:

/** Frequency at which clouds will generate */

I'd also leave a newline between each set of var + javadoc. Although again I dunno if this is just a rare personal preference or what not.

Cervator · 2021-07-27T19:32:44Z

engine/src/main/java/org/destinationsol/game/planet/OrbitEnemiesBuilder.java

+ * variables, such ship density (how many of the ships are places), are dependent on the specific ShipConfig,
+ * and so are held within the list of ShipConfigs.
+ */
+public class OrbitEnemiesBuilder {


OrbitalEnemiesBuilder maybe? Rather than "Orbit" alone

Elsewhere too like the nice javadoc has "Orbit Enemies" which reads funny, "orbital enemies" would be entirely natural :-)

Cervator · 2021-07-27T19:35:21Z

engine/src/main/java/org/destinationsol/game/planet/OrbitEnemiesBuilder.java

+public class OrbitEnemiesBuilder {
+    private ArrayList<ShipConfig> orbitEnemies = new ArrayList<>();
+    //Offset Percentage represents how far apart enemies should be made, in terms of circumference of the planet
+    float offsetPercentage;


Is package scope intentional here? Or meant to be public/private/protected?

Cervator · 2021-07-27T19:41:31Z

engine/src/main/java/org/destinationsol/world/WorldBuilder.java

-            calculateSolarSystemPosition(activeSolarSystemGenerators, generator, generator.getRadius());
+            try {
+                calculateSolarSystemPosition(activeSolarSystemGenerators, generator, generator.getRadius());
+            } catch (Exception e) {


Any way to narrow this catch a little? Going straight for Exception is a tad wide :-)

I realize this is probably still an improvement on prior state as-is!

Cervator · 2021-07-27T20:28:28Z

engine/src/main/java/org/destinationsol/world/generators/PlanetGenerator.java

+    }
+
+    /**
+     * This method modifies the percentage of the atmosphere at which low orbit ships start spawning.


The percentage of the atmosphere? Huh. As in, related to height/distance from the surface of a planet? I guess in theory you could think of an atmosphere as thinning out (thus lower percentage the higher you go), but I wonder if a simply height offset or something would be clearer (I could imagine exotic / magical atmospheres that could be equally thick from surface to top...) . As usual probably a separate refactor.

Cervator · 2021-07-27T20:30:27Z

engine/src/main/java/org/destinationsol/world/generators/SmallPlanetGenerator.java

+import org.slf4j.LoggerFactory;
+
+/**
+ * This class is a concrete implementation of a PlanetGenerator and handles its creation. This class creates planets


"its" creation being relevant to the planet generator or a planet itself? Nitpick :-)

Cervator · 2021-07-27T20:31:04Z

engine/src/main/java/org/destinationsol/world/generators/SolarSystemGenerator.java

                Orbital orbital = solarSystemOrbitals.get(orbitalPosition);
                orbital.setFeatureGenerator(generator);

+                generator.setAngleInSolarSystem(SolRandom.seededRandomFloat(180));


Magic number (descriptive constant for 180 probably would be good?)

Cervator · 2021-07-27T20:33:01Z

engine/src/main/java/org/destinationsol/world/generators/SolarSystemGenerator.java

+     * after the build method is called
+     * @return List of Planets
+     */
+    ArrayList<Planet> getBuiltPlanets() {


"Built" sounds funny to me here. "Generated" ? What exact state are the planets in before, after, and what happens next? Is surface feature placement and other stuff still to do? This is where again a diagram or two would be awesome to show the phases / state changes :-)

Cervator · 2021-07-27T20:35:33Z

engine/src/test/java/org/destinationsol/world/generators/SolarSystemGeneratorTest.java

    private void setupSolarSystemGenerator() {
        solarSystemGenerator.initializeRandomDefaultFeatureGenerators(1f);
-        solarSystemGenerator.buildFeatureGenerators();
+        //solarSystemGenerator.buildFeatureGenerators();


Might be good with a quick TODO to note why this is commented out

Cervator

Good changes! Was able to test a bit more without crashing (but not without dying! Woo)

Cervator · 2021-07-30T21:54:42Z

engine/src/main/java/org/destinationsol/game/planet/PlanetObjectsBuilder.java

+        logger.info("Planet: " + planet.getName() + ", Station Vector: " + distanceToPlanet.toString());
+        float angle = 0;
+        //TODO: Determine why distanceToPlanet is occasionally equal to {NaN, NaN}
+        if (!distanceToPlanet.equals(new Vector2(Float.NaN, Float.NaN))) {


Not really needed right this moment, but it may be worth simply declaring a constant Vector2 somewhere with the NaN values rather than create a new one every check?

Cervator · 2021-07-30T21:55:59Z

engine/src/main/java/org/destinationsol/world/WorldBuilder.java

+         * from the center of the world when placing a system. However, in order to ensure a place will be found, the
+         * number is multiplied by 100
+         */
+        maxWorldRadius = (12 * numberOfSystems * 100);


The comment definitely helps, these values are still magic numbers though :-) Also a low priority but likely replacement with constants would be nice. That would also limit the need for the comment being lengthy if the name of the constants make the code self-documenting (and extra details could go on javadoc on the constants)

Cervator · 2021-07-30T21:58:14Z

engine/src/main/java/org/destinationsol/world/WorldBuilder.java

            try {
                calculateSolarSystemPosition(activeSolarSystemGenerators, generator, generator.getRadius());
-            } catch (Exception e) {
+            } catch (RuntimeException e) {


Better 👍 There are still a lot of RuntimeExceptions that are possible. Not necessarily needed to go more narrow right now, but in addition to printing the stacktrace might it be worthwhile logging a more specific message to this place in the code and its expectations? IIRC there's also a logger method that ends up including the printed stacktrace anyway.

IsaiahBlanks added 4 commits July 20, 2021 22:02

1aeeb5a

Create default Planets, display SolarSystems and Planets in game

Create default Planets, display SolarSystems and Planets in game

7b0bc03

Merging branches

b70f8d9

cf78f99

PlanetGenerators working and modifiable, PlanetGenerator tests

Cervator requested changes Jul 27, 2021

View reviewed changes

Revised comments, naming of some methods, hardened turret bug

49d33fd

Cervator approved these changes Jul 30, 2021

View reviewed changes

Cervator merged commit 01498e3 into MovingBlocks:gsoc2021 Jul 30, 2021

		@@ -0,0 +1,95 @@
		/*
		* Copyright 2020 The Terasology Foundation

Initial PlanetGenerator Setup #602

Initial PlanetGenerator Setup #602

Uh oh!

Conversation

IsaiahBlanks commented Jul 21, 2021

Description

Testing

Outstanding Work

Uh oh!

Cervator commented Jul 27, 2021

Uh oh!

Cervator left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Cervator left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants