In this lecture we used an enum to cross reference scenes. What else could we have used?
We could have used a navmesh offmesh link between the scenes
Does that work between scenes? I thought it was for between two parts of a NavMesh?
Well apparently it can, https://docs.unity3d.com/Manual/nav-AdditiveLoading.html however, how effectivre it would be in loading additive, making the leap, removing the other… is another story, but I kinda like the idea. (I do confess I havent tried it, but this seems such a simple answer)
Definitely worth some further investigation. Does seem to require additive loading however.
If I understand this lecture correctly, we’re using the destination enum as a source ID as well - i.e. if the destination of a Portal in scene 1 is set to “B” then we’re also considering this to be the “B” destination from a Portal in scene 2. I.e. B links in both direction to B, C links in both directions to C, etc. If this is the case, maybe the field should not be named “destination” but “identifier” or “id” or “link” instead?
I can foresee this causing problems when more scenes are added that already use the identifiers we want to use. For example we might have two sets of scenes, one set only has the E identifier available, and the other set only has the A identifier. In this case we’d have to go through an entire set and “refactor” the linkages so that the same enum is available, or just create a new enum value I suppose.
Would a more flexible approach be to have both an identifier and a destination enum per portal, so that any portal in any scene can be connected to any other portal in any other scene without clashing?
Alternatively, allow arbitrary integer IDs (rather than enums) to create the links. I found this to work nicely, and it’s simpler than using two IDs per portal. Essentially the tuple (destSceneIndex, linkID) represents a unique portal-to-portal connection in one direction, and the opposite connection can be found with (originalSceneIndex, linkID).
What many students have done is to add two enums… a Destination and a Source…
So Scene 1 could have a Portal with Source A and Destination B, and would link to the portal Source B in Scene 2, which may link back to another Portal in Scene 1 Source C, etc.
That would work. I didn’t envisage needing this asymmetry in our game. I do agree that the naming is a little confusing. But I’m never going to be able to find the perfect names.