Project Info - Sector Control

Sector Control is a puzzle game about flying through an abandoned spacecraft and avoiding its still active security. Players clear obstacles by using "Security Switch Buttons" to change the color of obstacles and traps that are active. The level is designed to slowly teach the player the game's mechanics without requiring much of a tutorial. The level design and scripting are all done by me. The art is starter assets.

Scripting

In making the Sector Control prototype, I considered that I might want to return to this game to make more of it. To this end, the game systems are made so that they can easily be expanded upon or altered.

Main Takeaways

• Enumerated values are useful in many cases and make the state of your code more readable to humans.
• Game Manager actors and their ability to be instanced across different levels are helpful where level blueprints might prove inefficient to code.
• A readonly Map can be used to link enums to other values.

Color Switching

The core of the game's "Color Switching" mechanic is a Game Manager actor meant to be placed in each level. Within the code, the colors are known as "Security Layers". The Game Manager's purpose is to signal other actors whenever a Security Layer has changed, though it also acts as a way for a level designer to define the rules for each level on the front end. The Security Layers are stored as an enumeration. The Security Layer is linked to its color and any other relevant information using a readonly Dictionary stored in the Game Manager.

Whenever the Security Layer is swapped, the On Security Switch event is called, signaling all actors subscribed to this event to update their state. Notice how the different Security Layers are stored in sets; This was done to add the potential for more than one color of object to be active at once. You may also notice that the Game Manager has the option to cycle to a third set of Security Layers.

All actors that react to the Security Layer being switched are parents of the BP_SecurityObject class. In game these Actors are laser barriers, mines, and turrets. This class holds whether or not the security object is active in the form of an enumeration (Object Mode), what Security Layer the object is active on (Security Layer), and caches the color the object should glow while active (Object Color). Object Mode stores three values: Active, for when the actor's Security Layer is swapped to, Inactive, for when the actor's Security Layer is swapped out of, and Disabled, for when the actor should be inactive irregardless of the current layers active.

In the actor's construction script, the Game Manager is cached and then used to access the Security Layer Map, allowing the actor to figure out its color based on the Security Layer assigned to it. Because all of this is done in the constructor, a level designer can use the color of the actor to see what Security Layer it is assigned to without selecting it or entering play mode.

Important to note at this point is a special Security Layer known as permanent. "Permanent" is a red Security Layer that is always active, no matter what the active layers are set to. This is used for the hallway mines and the red laser barriers. If an actor's Security Layer is not set to Permanent when the Begin Play event occurs, it binds an "Update Active State" event to the Game Manager. The Update Active State event is then called for the first time in case the actor's Security Layer does not start active. Whenever Update Active State is called, the actor checks if its Security Layer is in the Game Manager's set of Active Layers and adjusts the Object Mode accordingly. The Object Mode is not altered if the actor is set to Disabled.

Turrets

All turret variations are children of the BP_TurretBase class. Turrets search for players within their cone of vision, detecting them using an invisible cone mesh set to OverlapAll. When the player overlaps with the actor, their pawn is saved to a Marked Actor variable. When the overlap ends, the Marked Actor variable is cleared.

As long as the turret is neither inactive nor disabled and has a Marked Actor, it will perform a line of sight check for the Marked Actor each tick. The line of sight check is done through a raycast from the turret to the player. Should the ray reach the player without being intercepted by an obstacle, the Turret will destroy the player. The turret requiring the player to be marked means that the line of sight check is only performed if the player is within its cone of vision. Turrets can mark players even while they are inactive or disabled, allowing them to perform the line of sight check and potentially kill the player the moment they are active again.

The turret's movement is handled by a Move function. The function does not have any code in the turret's base class and is meant to be overridden by child classes. Unique to turrets is the ability to remain active on more than one Security Layer through an alternate movement pattern. If the turret is set to have alternate movement, it can have a secondary movement pattern on a separate Security Layer while changing color to match that layer. An example of this in game is the turret in the Remote Security Switch room, which begins rotating the opposite direction instead of becoming inactive when the layer is swapped to purple.

The glowing "eye" of the turret, as well as the glowing parts of other Security Objects, are implemented using Dynamic Material Instances. The Material itself is a simple emissive material with its color set as a parameter. When the material is used as a Dynamic Material Instance, the parameters such as the color can be changed during gameplay. Using this method, only one material asset needs to be created and the game does not have to load a new material whenever its color is changed.