Hi guys just finished this lecture and thought to my self, “What if I need to move to a portal that hasn’t got the same destination as the one I’m at?”. Would it not make sense to have 2 variables? A myDestinationIdentifier and a destinationDestinationIdentifier.
Yes, that would work for that situation.
Yeah, I did it this way as well. I got very confused as to how each portal know its own identifer vs where it was going to ‘send’ the player.
what would the code for this look like. I tried to implement something similar but adding a source enum didnt seem to affect where the portals sent each other
[SerializeField] DestinationIdentifier source;
private Portal GetOtherPortal()
{
foreach (Portal portal in FindObjectsOfType<Portal>())
{
if (portal == this) continue;
if (portal.source != destination) continue;
return portal;
}
return null;
}
1 Like
Hi Brian,
this is what I have already. I meant how would using two identifiers eg myDestinationIdentifier and a destinationDestinationIdentifier look/work different to what we have now.
Cheers
Perhaps I should have been clearer… this was assuming leaving the destination identifier in place:
[SerializeField] DestinationIdentifier destination;
[SerializeField] DestinationIdentifier source;
private Portal GetOtherPortal()
{
foreach (Portal portal in FindObjectsOfType<Portal>())
{
if (portal == this) continue;
if (portal.source != destination) continue;
return portal;
}
return null;
}
We’re comparing the source of each portal we find in `FindObjectsOfType() to the current portal’s destination.
2 Likes
Sorry for necromancing, but indeed I’ve used 2 variables too one for the name and another for the destination.
private Portal GetOtherPortal()
{
foreach (Portal portal in FindObjectsOfType<Portal>())
{
if (portal == this) continue;
if (portal.portalName != portalDestination) continue;
return portal;
}
return null;
}
Also instead of A B C D… I’ve used military alphabet code 
enum PortalIdentifier
{ Alpha, Bravo, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, India, Juliet, Kilo, Lima, Mike, November, Oscar, Papa, Quebec, Romeo, Sierra, Tango, Uniform, Victor, Whiskey, XRay, Yankee, Zulu }
Which is fun… I guess 
I am also using 2 variables.
[SerializeField] private int portalIndex = 0;
[SerializeField] private int spawnPortalIndex = -1;
I chose to use int instead of an enum. I wanted the ability to have an unlimited number of portals, i.e A cave, one for each house in a town, etc. I did not want to have to edit the enum latter if my scene ended up with more portals then what the enum contained.
private Portal GetOtherPortal()
{
if (spawnPortalIndex == -1)
{
Debug.LogWarning("No Portal set.");
return null;
}
foreach (Portal portal in FindObjectsOfType<Portal>())
{
if (portal == this) continue;
if (portal.portalIndex != spawnPortalIndex) continue;
return portal;
}
Debug.LogWarning($"Could not find a Portal with an index of {spawnPortalIndex} in scene {SceneManager.GetActiveScene().name}");
return null;
}
1 Like
One advantage of an enum is you can easily select which value to use in the inspector, and you can give each item in the list a speaking name.
For example you could call the portals by wind direction and setup the scenes so you had one portal per direction, so you have an “east” and a “west” entrance perhaps. Add to this the optional notion (which has been discussed in other threads already) of having both, a “source” and a “destination” identifier, and you can connect one scene’s “west” exit with the neighbouring scene’s “east” entrance (and vice versa).
With a little extra work one could also keep track on which portal one left the previous scene so one might have exits leaving to the other scene in “east” and “southeast” but the other scene may only have one “west” exit. That one could always go to the “east” portal, or your player has memorized he came from “southeast” and might return to it.
Or if you want to complicate a simple working solution even further, make the identifiers strings. “But why?” I hear you ask. Because then you can have a portal the players can place wherever they want, and name it themselves. Add a second one to link to it (with the same ‘name’) and you have a ‘player created’ portal system like the ones in Valheim
That would probably be a derived PlaceablePortal script that would have some visuals and can be given an in-game tag (which has nothing to do with Unity’s engine tags).
You might want to have some sort of variable portable at some point anyway or some other way for a checkpoint system that might work across different scenes…
From the technical point inside the code I would say these dynamical portals should still be using the fixed portal’s enum for marking and perhaps there could be an extra entry in the list just for those, depending on how many you might want to allow inside a single scene.
Sounds like fun stuff, but also like too much scope creep for the project shown in the course…
Yes, there’s a lot more to player-placeable portals than just giving it a string destination. In Valheim it’s easy because all of Valheim happens in a single scene, but the RPG course uses multiple scenes and you’d have to have some way of ‘finding’ portals in other scenes, etc.
With a Diablo-style “teleport back to town” system it would be manageable in that all you needed for the dungeon->town transistion would be keeping track of which entrance into the dungeon (initial portal to the first level, or any of the shortcuts that become available later on) was used to enter the dungeon and use that as a reference to the correct spawn point into town.
For the transition back into the dungeon you would either have kept the generated dungeon level in memory and have that one portal which should be easy enough to locate. Or likewise you would just have the level depth and simply generate a new level on the fly.
If all you have is ephemeral generated dungeon levels, you don’t really have to manage any specific player spawn points which would make it much easier to do (apart from the “dynamically generating a dungeon level” bit which is all but).