Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement support for Conditional Biomes #3

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

Qwertygiy
Copy link

This PR introduces the ability for biomes to implement arbitrary conditions that must be met for them to be selected by the world generator for a specific generating region.

These conditions are primarily intended to be world facets such as humidity, temperature, and surface elevation.

With this addition, a generator may receive a list of valid biomes to choose from for a certain area, rather than hardcoding specific conditions. This allows for modules to more easily add its own new biomes to existing world generators.

@Cervator
Copy link
Member

Pinging @Adrijaned, @vedant-shroff, and @ktksan for possible review (really should sort through our GitHub teams to make people more assignable for reviews and such)

Copy link
Contributor

@skaldarnar skaldarnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this, a few questions come to my mind:

  • Is a binary check enough? That obviously helps to in some cases to rule out some biomes, but falls short in other cases. For instance, as the biome info is done "per block" it could happen that multiple biomes are valid at that point - so how do I decide on which biome to use now? One often finds fitness functions that determine a non-binary value for each biome (which could be sorted by).

  • Should conditions be encoded in biomes or the biome registry? This approach introdcues a new ConditionalBiome subtype. If we've got non-conditional biomes, there is no way to add restrictions to them 😕 However, if the BiomeRegistry would hold the information for each biome, we could enrich all kinds of biomes with conditions...


/**
* Returns all biomes that do not forbid themselves from the given location.
* @param region The world region
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @param region The world region
* @param region The world region to generate, holding the facet data

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I created the implementation inside the biome instead of inside the registry is that it is a much simpler matter to add abstract conditional logic as an overridden method of the biome than it is to insert such logic directly into a map.

Honestly, it leaves me wondering if biomes should not be changed to a form of asset that can be handled by the entity system, like prefabs... but I believe that doing so would likely require an overhaul of the game loading system so that the entity system is initialized before facets are created.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the facet providers already use components to hold their configuration (not that this is working for actual world gen, though). Turning biomes into assets sounds like a good idea, overall...

import java.util.Map;
import java.util.Set;

public abstract class BaseConditionalBiome implements ConditionalBiome {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please provide Javadoc what this base class offers.

*/
Set<Class<? extends FieldFacet2D>> getLimitedFacets();

void setLowerLimit(Class<? extends FieldFacet2D> facetClass, Float minimum);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing Javadoc on the semantics of minimum. In the BaseConditionalBiome I can see that both values or inclusive - that should be noted here.

Likewise, for setUpperLimit.

@Override
public void setLowerLimit(Class<? extends FieldFacet2D> facetClass, Float minimum) {
limitedFacets.compute(facetClass, (k, v) -> {
if (v == null) v = new Vector2f(minimum, Float.MAX_VALUE);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use braces even for these simple one-line if-statements.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I'd do

if (v == null) v = new Vector2f(Float.MIN_VALUE, Float.MAX_VALUE);

for the initialization in both cases, and only set the minimum or maximum once afterwards.

import java.util.Set;

public abstract class BaseConditionalBiome implements ConditionalBiome {
protected Map<Class<? extends FieldFacet2D>, Vector2f> limitedFacets = new HashMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of using Vector2f to store the range, maybe consider using the Range class from Guava?. Handily, it would come with range.contains(value) for even simpler checks 😉

Copy link
Member

@Adrijaned Adrijaned left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code seems to promote the use of per-column biomes where it should work well, and probably couldn't be used in worlds making use of per-block biomes.

@@ -0,0 +1,56 @@
/*
* Copyright 2019 MovingBlocks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...

@@ -0,0 +1,74 @@
/*
* Copyright 2019 MovingBlocks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants