Day 3: Major Flaw in the Logic

I hit a lot more roadblocks than anticipated today, which led me to consider refactoring a lot of the existing game logic. A lot of this day was spent debugging issues and optimising existing processes, as well as preparing for level design and puzzles.

One of the main issues was how the development layout was organised. The GameObject hierarchy and how the portal and pedestal prefabs were assembled were admittedly messy. I was too concerned about scalability that I neglected the immediate concern: having it actually work. This caused issues in implementation and slowed down development (I didn’t realise it then).

At this point, I started developing the Switch puzzle mechanic. Switches can be activated to switch the isRed state of pedestals. Using tags, the levers identify which pedestals are toggleable and which ones are static. It then swaps the colours of the dynamic portals to the opposite (from red to blue).

Here was my mistake: The levers only affected those without the static tag. Currently, there are 2 types of pedestal prefabs—static pedestals that ignore the lever, and dynamic portals (the one named pedestal_neutral) that are affected by the lever.

However, the levers changed the colours of all pedestals with the same tags, including dynamic ones. As the portals themselves are parented to the pedestals, this meant mismatched colour puzzles were impossible to test at the moment.

(Notice the difference in the appearance of the static pedestals below and the dynamic pedestals above.)

The teleportation logic worked fine, but only because I explicitly linked each portal's entry and exit references — they did not do so automatically. I was essentially making 2 pairs of portals that were always activated when their parent pedestals were in a certain state, The goal was to make it so that portals only appear when linked pedestals are of the same colour.

Another issue. I had intended that the lever was only interactable when the player was nearby (limited sprite variation = no player viewing direction). I forgot that, and now the player can swap portals from anywhere with the press of a hotkey.

Now there were 2 issues:  

1. Fix the range of the lever.  

2. Add a way for pedestals to dynamically detect paired pedestals, creating portals if linked.  

A lever fix would be simple, and the ranged trigger is pretty useful when testing. So I decided to focus on fixing the portals as they were the main mechanic behind the puzzles.

Let's see how pedestals are set up.  Each parent pedestal prefab had 2 pedestal children marked as blue or red. Each pedestal GameObject had an identifier: The isRed boolean (to determine whether they are either red or blue). The child prefab pedestal_red or pedestal_blue, normally deactivated as child components,  is activated depending on its isRed bool state. Each of these pedestals also had an aptly named portal prefab, which contains the logic for teleportation (The same logic used for portals with no pedestals, i.e. disappearing big portals). I'll explain more about how the portal logic differs between small and big variants later in the log.

On start, the pedestals are assigned blue by default because a lever has no neutral state, and is a bool of either Red or Blue. Depending on the lever state, child elements of pedestalStandard are activated based on their corresponding tags.

Each colored pedestal, tagged pedestalBlue (or red), houses another child portal element, such as portalSmall_blue. Small portals are my way of identifying temp or static portals. In this case, small portals don’t disappear on use, unlike the big portals. They are tagged separately for identification required in the matching portal script.

The current issue is with how tags work. What if I had multiple pedestalBlues with multiple smallBlue portals? How are they linked? To understand this, we need to study how the portal logic is configured.

When a player triggers a portal collider, they are teleported to a targetOut position (including the movement pointer to avoid bugs). The portal is then disabled to prevent portal looping since the targetOut is also technically a targetIn (the script only detects the portal collider).

The problem is that each targetOut is manually assigned for every portal. There was no automatic linking of portals based on matching colours. The only "paired" objects are pedestals, but only because they share an identical tag, differentiating them between static and dynamic pedestals. At its current state, there was no way to differentiate dynamic pedestals from one another.

This was a crucial flaw that I had neglected since the beginning. I assumed that same colored portals/pedestals would be connected through tags, that I forgot a mismatch of pedestals and portals should be possible for puzzles to work the way I intended them to. So I had to restructure the relationship of portals and pedestals.

To start, pedestals must be linked by an ID. The ID determines if specific pedestals (and targets) are paired. If similar colored pedestals are the same colour but not paired via ID, they won’t generate a portal. Pedestals with the same ID should also have the same colour to create a portal.

Since IDs are unique, they cannot be universal tags. I would need to make a simple Class for pedestals—it only needs to store an ID (to match paired pedestals) and the isRed bool to check its current colour. Only if both parameters match can a portal be created and activated.

Both lever and portal logic have to be refactored to accommodate this additional ID requirement. The lever cannot change pedestal IDs, but the new script will be responsible for matching them. GameObject hierarchy also has to be revised for more dynamic portal activation.

A major setback from what I had planned for the day, but luckily, I caught it while I still had time. Once the logic is revised, level design should be modular and fast, as it is only placing prefabs in a creative puzzle layout. More work for Day 4.