We need to have the structures required to implement procedural patch maps. How do we store patch information? How do we implement them aswell.
Is the patch screen wrapped into the editor? Or is it its own game state . Im not sure
So the first idea i had was that we would have some kind of C++ patch class (This is likely nessessary regardless, as the patch would need to know what cells are in it etc., its name, etc later on) The patch object would hold a biome object (more flexible) or a string with the name of the biome type (Would be the easiest solution, but the least flexible solution), it would also hold an array of connected patch nodes (A pointer to the patch? Or a specific node class, which holds a patch and a pointer?) (or a single node, so we have a kind of linked list). Then when you click on the patch in the patch screen (that lets you move between patches) it would simply load up that biome, like it does when you die right now. In order to generate the patches we will likely need to either have our Javascript interpret a Array or a json object, or we generate the patch map directly in the javascript. And have buttons linked to each patch that only “unlock” when you are in an adjacent patch.
I havet thought about it too much, but this is my first instinct idea anyway.
I would like to include the patch map as a GUI part thing. But the current GUI situation makes that a bit complicated…
Other than that we should have some class like PatchManager that would include a list of Patch objects which each have a list of other patches they can be moved to from.
The most complex part is probably making the spawn system reset the spawners when the player changes patches. Also all other entities except the player and the sister cell needs to be deleted on changing patches.
Oh yeah I forgot about the patch manager, we would also need the patch manager for auto-evo later,
(Also you mean a list of patches they are connected to right?, its the same as “you can move to from” but it was worded kinda confusingly)
Yes. I’m thinking of them as an undirected graph. So it can be represented with nodes that contain the edges in terms of having for example a weak_ptr to the other patch.
The patch system should be pretty easy to adapt to patches, we just need to change the list of spawners we currently have for a map of lists of spawners, with a patchId (or name if we’re really sloppy) as the key.
The despawning could just be a function that literally despawns everything with a spawn component (maybe in a new system if we’re really worried about overdespawning), and since the player doesn’t have a spawned component they wouldnt get despawned. The sister cell would, but i think it should since that cell would stay in the old patch along the rest of the secies (at least that’s what i understood), but we could add a bool or another component to avoid it getting despawned if we really want to.
It had one in the old engine (it wa the reason why it despawned immediately), maybe it got removed when we switched? Adding it again should be relatively easy.
I assume you mean if all the patches run autoevo simultaneously? in that case yeah maybe doing that would be good, tho it wouldn’t be all that hard to do from the species system, just delete all the spawners of the old patch and load all the new spawners, which we already do when a species is created/extinguished anyway. We would need a somewhat quickish way to get the species of a patch or we would get a slow transition between patches after many species are created tho.
I agree with @hhyyrylainen i prefer clearing and recreating the spawners when you go to a new patch. Remember that clouds use spawners, and iron/floating toxins also use spawners, its not just cells. And if we clear and recreate them for each patch we go to we simply wouldnt have to change the spawn system as much. Also, whats the point of having so many unused spawners in memory at a time? It doesnt take too much time to create new spawners. I think clearing and recreating them each time is the best/simplest option. There could be a large amount of patches, thats alot of unused existing spawners at a time if we dont clear and recreate each time. Also initial game would take longer to start since it would , what , generate the spawners when you start? If not then you are creating spawners when you traverse patches anyway, whats the point of over complicating that by using a map. Just clear and create the spawn components each time.
So im starting on this and i would like to figure out exactly what each patch contains:
So far heres what i’m thinking:
1.A edit-able biome object
2.I still would like to take a linked list approach,
So pointer to attached patches (Maybe not the best idea)
Or an unordered map with some means of representing attached patches (A vector of patch ids?)
3.A name, and an ID
4.The name is proc genned.
EG so you get things like “The pangonian abyss” like in the concept art
5.A list of species (SO they can adapt) (This will necessitate moving species completely over to c++)
Which should be pretty easy now given theres not much left there aside from the random-evo code,
which is mostly basic string manipulation and random population editing
I suppose it’s as good as any start.
Though I would store them like this:
first a std::unordered_map<size_t, std::shared_ptr<Patch>> that holds all the patches. And then each patch would have a std::vector<std::weak_ptr<Patch>> for the patches it is connected to.
