Overview
Through many Unreal engine based projects, I’ve created custom Kismet sequences to control advanced level behavior, and in some cases, to create entirely new methods for game play. Below are examples from three different levels that highlight my scripting skills.
Bedlam Kismet
The simplified level design of Bedlam supports a modular design theory. In the map below, the five subsections of the levels as well as the starting and finishing points of the level are visible.
|
S, F: |
Start, Finish |
|
|
Numbered Pairs: |
Entrance / Exit for each subsection |
Example level connection order
Each subsection uses entrance and egress points to connect to the remaining portions of the level. Each connection point includes access to a freight elevator and an elevator button to trigger the scripting. To connect these rooms in a random order, several steps occurs. First, each elevator’s teleportation target is assigned to an easy to identify variable name. The below kismet assigns these.
Next, the starting elevator receives it’s teleportation target, and that target immediately back targets the elevator – providing the necessary bi-directional mapping for game play. The targeted room’s boolean variable is marked as true, and a remote event calls the next stage in the level mapping.
In the next stage, the room mapping checks the room count to decide if to map to the exit, or to another room. Moving on to the next room, a switch randomly targets the pool of subsections, and loops back if the room is already used, until it finds an unused connection. Then, the current room’s exit target maps to the next room, and back targets the next room to the current room’s exit. The script marks the next room as used, and follows a similar script for the next stage. This process repeats until the room count meets the predefined number, and then maps the final room’s exit to the last subsection of the level.
Once all the mappings are complete, the script controlling the movement from room to room has valid targets for the teleport destinations and bi-directional mapping is complete.
Checkpointing occurs as players enter a new subsection for the first time, using a trigger volume to capture the event. Compartmentalizing the checkpoint system works very well in Bedlam.
Derelict Kismet
The scripting solution for Derelict features standard Kismet nodes, but arranged in a unique manner. Based upon the number of interior spaces each room shell type offers, the script assigns an integer seed for each shell. This seed controls the initial map layout, and subsequent map refreshes. This system arose to prevent map refreshing from loading in a different room interior during a play-through.
Each objective uses a discrete Boolean variable, stored in the persistent level. On subsequent map-refreshes, during checkpointing, or loading of a checkpoint, the value of these Booleans determine which map-wide events occur. Also, a mission type integer variable prevents these objectives from firing out-of-order, or cross-triggering a different objective list.
Derelict uses many prefabs to not only add to immersion, but to strengthen the level building process. Each airlock door prefab uses 22 sub-objects plus scripting to control behavior. This door prefab allows Star Trek style operation – where it opens for encroachers, and closes only after the immediate doorway vicinity is clear. By using a trigger volume and object list, the script counts the actors near the door and updates the list as they die, or leave. Additionally, the door prefab supports locking and unlocking. Locking the door toggles a new material, with a red glow instead of blue, and renders the trigger volume inoperable. Unlocking the door not only changes the material back to blue and enables the trigger volume, it also quickly toggles the collision on the trigger volume. This way, if an encroacher is at the door when it unlocks, the door detects the presences of the actor and opens naturally.
The lighting overhead uses multiple materials and light colors within a prefab to provide portable, repeatable lights with controllable behavior. By selecting the options on the scripting, the designer controls whether the light turns on, or is broken, or randomly working or broken.
The scripter controls the color of the light to match the ship, or use a random color, and finally a trigger to turn the light on. This prefab allows flexibility and utility in level design, and lets the designer focus on building the level, rather than each light instance.
The above and below shots show the same view from the bridge into a manifold space. The upper shot uses only emergency lighting. The lower shot displays the ship with power restored. Note that the emergency flood light above the opposite door has shut off.
Within the engine room, a pipe prefab creates another random event for players to encounter and enjoy. A number of pipes within the engine room need interaction before the reactor can start. With the scripting in the prefab, each pipe starts either ready or requiring player interaction, and a switch counter tallies the pipe interactions. Attached to the pipe interaction, a random Wretch spawn adds to the immersion, as the noise of opening the valve draws attention to the player in the engine room. With the scripting set up this way, players need to interact with as few as zero up to the total number of pipe prefabs to enable the reactor control panel. By creating the prefab in this manner, each play through of an engine room remains a different experience.
DM-17 Kismet
DM-17 required scripting for the sniper platform. Acquiring the sniper rifle broadcasts a warning to the entire arena, and reports the name of the player on the platform. This is controlled through the Kismet below.
When the UDamage is collected, the large trapdoor opens, dumping players into the lava below. Prior to the door opening, a vortex captures and suspends players above the door, preventing their escape. This is controlled through a trigger volume, object list, and some set physics nodes. This Kismet is called with the trapdoor sequence.
Wet Work Kismet
The random cover system works in Kismet at the start of the Wet Work. The available cover objects are InterpActors initially flagged as hidden. When the level loads, the cover nodes surrounding the InterpActor are disabled, and the InterpActor’s collision is set to none.
With all random cover systems invisible and non-colliding, a delayed script triggers randomly turns each one back on, or leaves them off. This re-enables the cover nodes surrounding the InterpActor, and re-enables the collision. In the above picture, only the far cover node is selected and displays the cover options from behind the crates.
