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

1560 regular spawn #2397

Merged
merged 46 commits into from
Aug 13, 2021

Conversation

Maxonovien
Copy link
Contributor

@Maxonovien Maxonovien commented Jul 10, 2021

Brief Description of What This PR Does

This PR takes on #2138 (algorithms only) to rework the spawn system. It tries to stick to the old implementation.

It brings two major changes:

  1. Spawners are now drawn from a ShuffleBag. This enumerable structure allows to draw items from a list, each item being only drawn once. When empty, the bag refills the list and uniformely shuffles it. This means that over a patch (with no spawner change), each spawner get as many opportunities to start spawning things (with varying success) as the others. This favors spawn diversity (spawners may still fail to spawn).
  2. To avoid 'belt-spawning' (see image) when the player is not moving, this PR introduces a cap of 15 entities spawning around an immobile player, 'immobile being defined here as not leaving a small specific zone. Also, when immobile, spawning is no longer bias in favor of the player's orientation, but uniformely distributed around).

image

Note: further issues are related but could be dealt with another PR:

  1. Per-species cap (issues 1261 and 1551, not tagged as not solving)
  2. Contextual encounters (issue 2055)
  3. Keeps attempts based system, which uses caps breaking linearity of success with density (related to issue 2055).

Related Issues

Fixes #1550 . Closes #1739
Also resolves #1541 and resolves #1626 and resolves #1777 . Partly overlaps with and closes #2389.

closes #2138 (previous PR)

Progress Checklist

Note: before starting this checklist the issue should be marked as non-draft.

  • PR author has checked that this PR works as intended and doesn't
    break existing features:
    https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
    (this is important as to not waste the time of Thrive team
    members reviewing this PR)
  • Initial code review passed
  • Functionality is confirmed working by another person (see above checklist link)
  • Final code review is passed and code conforms to the
    styleguide.

Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author.

@Maxonovien Maxonovien marked this pull request as ready for review July 11, 2021 13:59
@Maxonovien Maxonovien requested a review from FuJa0815 August 4, 2021 10:00
FillAndShuffle();
}

return currentContent[currentContent.Count - 1];
Copy link
Member

Choose a reason for hiding this comment

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

why are you picking the last element? Picking the first one saves one calculation and count-call. This is even more important if you use a LinkedList.

Copy link
Member

Choose a reason for hiding this comment

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

I would guess that it's because the list is popped from the back (as popping from the front is very bad for performance).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this was precisely done to pop from the back indeed. Worth mentionning in a comment though.

private List<T> initialContent;
private List<T> currentContent;

public ShuffleBag(Random random)
Copy link
Member

Choose a reason for hiding this comment

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

I think more reusability is always good here. An optional boolean that defines if the bag should be refilled automatically would be great. When set to false this class would behave like a randomized Stack or Queue, which could have it's future usages.

Suggested change
public ShuffleBag(Random random)
public ShuffleBag(Random random, bool refillWhenEmpty = true)

public void Add(T element)
{
initialContent.Add(element);
currentContent.Add(element);
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't the new element be inserted at a random index? (.Insert(random.Next(...)))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm, that could be a way to go, but you can still shuffle the bag afterwards if you really need to. I see it as putting something in your irl bag: unless you shake it, that is the first thing you'll be able to pick afterwards.

I'm not sure which behavior is the best one. The current one only adds further possibilities, but perhaps we don't want them to be a thing.

If kept as such, I think I should specify this non-random behavior in a comment nonetheless.

Comment on lines 82 to 87
private int estimateEntityCountInSpawnRadius;

/// <summary>
/// Last recorded position of the player. Positions are recorded upon leaving the immobility zone.
/// </summary>
private Vector3 lastRecordedPlayerPosition;
Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer inline initialization here to match the rest of the class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with you but I have a faint memory of having a reason to avoid it. But this does not seem necessary from looking at the code, so maybe I'm mistaken. I'll take a look.

Copy link
Member

@hhyyrylainen hhyyrylainen left a comment

Choose a reason for hiding this comment

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

I'm happy with the changes that are here, but this does not actually solve #1560 so that remains an issue, and for the future there's a problem as each spawner is not fully tapped before potentially moving onto the next one.
I'm fine with merging this if you are fine with my changes.

@hhyyrylainen hhyyrylainen added this to the Release 0.5.5 milestone Aug 13, 2021
@hhyyrylainen hhyyrylainen dismissed FuJa0815’s stale review August 13, 2021 15:03

probably was addressed, dismissing to get this in for the next release

@hhyyrylainen hhyyrylainen merged commit 900bf60 into Revolutionary-Games:master Aug 13, 2021
@sirdanforth
Copy link

Here's a list I made to keep track of what to specifically test and what I found on each of them.

  1. Check to see if spawners still work correctly = The spawners still work as intended and spawn entities normally.

  2. Check to see if spawners spawn compounds and entities randomly but in diverse patterns = It seems a random but diverse pattern pretty much happens in the Hydrothermal Vent, Ocean Floor, Mid Ocean, Ocean Surface, and the Underwater Cave. However when I went to test the Polar Sea the compounds did not seem to spawn in diverse patterns. Only iron would spawn and very very rarely would I see any other compound. However, the Polar Sea is iron rich but I would still expect to see other compounds at least a bit more frequently.

  3. Make sure no belt spawning occurs = I'm not entirely sure if this is still a problem or not because I did find that compounds would still be in a row like this and sometimes even in a circle around the player. It wasn't quite as noticeable but I thought I would still include it just in case.
    2021-08-13_12 37 48 2839

  4. Make sure that there should be at max 15 entities spawned at once (especially when player is stationary) = I did not find any problems pertaining to this. I mark this as a pass.

  5. Check to see if spawner spawns entities uniformly around player when stationary = No problems found and works as stated.

  6. Check to see if PR Reduce compound spawns while the player is stationary #1550 has been fixed = Seems like this issue is fixed and is working correctly.

  7. Check to see if PR Investigate why there is no iron spawning in the cave #1541 has been fixed = Issue has been fixed, iron now spawns in caves.

  8. Check to see if PR Investigate why chunk spawn rate is way down #1626 has been fixed = Issue has been fixed, iron now spawn and more specifically in the Polar Sea. However, it could be that it spawns iron too frequently now.

  9. Check to see if PR Check if hydrogen sulfide spawns in the cave #1777 has been fixed = Issue has been fixed, hydrogen sulfide now spawns in caves.

  10. Saving and loading does not break PR branch and works as intended.

  11. Loading saves made in a previous version works correctly.

Let me know if I missed anything.

@hhyyrylainen
Copy link
Member

That's a very comprehensive list. Sorry I was in a hurry and merged this before you were done. I'll link that as a good example of very thorough testing on our wiki on the testing page. https://wiki.revolutionarygamesstudio.com/wiki/Testing
Btw, you can edit the wiki pages if you see something missing or a typo or something like that by logging in with a dev forum account.

@Maxonovien
Copy link
Contributor Author

That's a great testing review, thanks! If I get it well you raise caveats for 2. and 3.

For 3., you could indeed call it a "belt spawning" case, but you can't really avoid it because we make things spawn around the player (approximately on the border ), as we do not want things to close nor far away from the player. The precedent issue was that belt spawning would make contiguous spawning from an edge of the screen to the other, so my way to fix it was to just limit the amount of entity. Such patterns are thus fully part of the algorithm, which I don't think is much of an issue, or at least not one the PR intended to fix.

For 2., it is not a surprise that iron is over-represented. But are other compounds not spawned enough? In other words, do you encounter significantly less of them when compared to a patch with similar values for other compounds? Normally, the spawns should be independant for each compound over the long run (you may have some more local interactions, though).

@sirdanforth
Copy link

For 2., it is not a surprise that iron is over-represented. But are other compounds not spawned enough? In other words, do you encounter significantly less of them when compared to a patch with similar values for other compounds? Normally, the spawns should be independant for each compound over the long run (you may have some more local interactions, though).

So yeah the other compounds do spawn but very rarely it seems. It took me probably around 5 minutes before I finally found a patch of phosphate. All I was seeing for 5 minutes was only iron clouds, iron particles, and ice shards. Eventually, I did find more patches of compounds and it was a bit more frequent after I found the phosphate cloud but when I saved and loaded it back it was back to rarely finding any other compounds (but maybe this time it didn't take as long).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
5 participants