Portals & Bridges
The portals were designed to be small holes in space that the player would squeeze through and come out of it's corresponding portal exit entity. Keeping this in mind, the portal was sketched to look like a spatial rift, or crack in the background - this was to push the idea that you as the player would essentially temporarily break the flow of the game by essentially zapping from one point of the map to another within an instant.
This was further supported by the animation of the portal, wherein the entity appears to float up and down at a regular pace. This was an aspect of intentional design, as to further signal that this rift in space was the opposite of what the player is expecting to see from the map. It was hoped that the player would see this portal, think to themselves that this looks like them (based on original character design) and therefore must be a good thing to interact with.
Finally, floating strings of binary code were implemented to randomly sort and change themselves as the portal floats. This again further cements the ideal that this portal is a method of zapping into the system at one point, and zapping out of the system at the exit portal.
As of now, portals are represented as doors in the game. The use of portals has yet to be definitively decided by the studio feature teams. As mentioned previously, portals were originally designed to map to other portals to allow the player to move throughout the level with more ease. However, there was perceived overlap between the function of portals and doors, and thus the possibility of using portals in lieu of doors was discussed.
The portal and bridge entities are all mapped to a specific button entity which, when pressed, either enables or disables collisions with the relevant obstacle. Portals begin the level closed, or shut, thus not allowing the player to move through them until their mapped button has been pressed. Bridges begin the level open, or un-extended, thus not allowing the player to move over them until their mapped button has been pressed.
This functionality is handled in the onCollisionStart function in the PlayerMovementComponent class. All portals and bridges are created with a SubInteractableComponent which is a dummy component that acts as an indicator to the mapInteractables function in the LevelGameArea class and the onCollisonStart function that the entity is a sub-interactable entity. A sub-interactable entity is one that starts in an initial state and whose state is changed after the player collides with its mapped interactable entity (i.e. button).
Bridge entities will be created as a sensor such that the player will fall through them until they have pressed the bridge's relevant button. Portal entities will be created with a regular collider component (not a sensor) such that the player will not be able to move past them until they have pressed the portal's relevant button. When an entity is a sensor, it does not collide with other entities.
if (interactableComponent != null) {
// Colliding with button
// Get the list of mapped sub-interactables
ArrayList<ObstacleEntity> mappedSubInts = interactableComponent.getMapped();
System.out.println(target.toString() + " mapped to " + mappedSubInts.toString());
for (int i = 0; i < mappedSubInts.size(); i++) {
ObstacleEntity mapped = mappedSubInts.get(i); // Get current mapped interactable
if (mapped != null) {
ColliderComponent colliderComponent = mapped.getComponent(ColliderComponent.class);
HitboxComponent mappedHitboxComponent = mapped.getComponent(HitboxComponent.class);
ObstacleDefinition mappedType = mapped.getDefinition();
if (mappedType == ObstacleDefinition.DOOR) {
// Desired affect on mapped door - disappears
mappedHitboxComponent.setSensor(true);
colliderComponent.setSensor(true);
} else if (mappedType == ObstacleDefinition.BRIDGE) {
// Desired affect on mapped bridge - appears
mappedHitboxComponent.setSensor(false);
colliderComponent.setSensor(false);
}
}
}
}