Analysis & Improvement for Dungeon Automation

Hey everyone,

Continuing my work on a dungeon automation bot, I spent some time analyzing why portal detection methods often fail or don't work universally. I wanted to share my findings in case it helps other developers.

The Old, Problematic Approach

Many scripts, including my initial ones, used a fallback method to find portals, something like this:


// Old code snippet
private void FindPortalFallback()
{
// ...
// Searches ALL scene objects for a specific name
foreach (GameObject gameObject in UnityEngine.Object.FindObjectsOfType<GameObject>() )
{
if (gameObject.name.Contains("Portal"))
{
// Found it!
}
}
// ...
}

I identified two major problems with this:

Poor Performance: The FindObjectsOfType<GameObject>() function is extremely heavy. It causes FPS drops and inconsistencies, especially on less powerful PCs or in more detailed dungeons.

Unreliability: Searching by name (.name.Contains(...)) is brittle. It fails as soon as developers use a name different from what's expected or in future updates.

A More Robust Solution

The more correct and universal approach is to focus on the components the game itself uses to manage transitions, like CTADungeonLoad. To ensure the portal is actually ready for use (and not just visible), the key improvement is to also check if its Collider is enabled.

Example of the New Logic:


// Focus on finding the game's specific component
CTADungeonLoad portalComponent = FindObjectOfType<CTADungeonLoad>();

// ... (logic to select the correct portal) ...

// Verify the portal is actually "open" before using it
Collider portalCollider = portalComponent.GetComponent<Collider>();
if (portalCollider != null && portalCollider.enabled)
{
// Now the bot can safely teleport.
}

This approach has proven to be much more stable and reliable in my tests. Instead of guessing by name, we use the game's own structure to our advantage.

Hope this analysis helps anyone working on something similar.

Cheers.