Ilya Firsov – Sobaka Studio Kiborg Game Designer Portfolio
About
A small personal Unreal Engine 5 project I worked on for several months to improve my technical skills and Blueprint knowledge. I prototyped:
- Inventory system
- Several enemies
- Day and night cycle
- Locked and barricaded doors
- User Interface
- Dialogue system
- Several world states stored in sub-levels
- Ranged weapons
Inventory System
[0:00 - 0:36] Demonstration of pickups, inventory, and interactable actors.
[0:36 - 1:07] The PlayerCharacter uses an interaction trace to check what the player is looking at. If the hit actor has the BPI_Interaction interface, I save it as the current interactable and call the interaction from an input action.
[1:08 - 1:27] The InteractWith function from BPI_Interaction is used to call the pickup logic in BP_Pickup.
[1:27 - 1:41] The progress bar logic runs on Event Tick only when it is actually needed, while the player is holding the interaction button.
[1:41 - 1:54] If the progress bar is filled, or if the item does not require holding, the item is added to the inventory system.
[1:54 - 2:18] The inventory system is a component on the PlayerCharacter. It stores items in a map variable and manages them with three main functions.
[2:18 - 2:35] All item-related settings are stored in Data Assets.
[2:35 - 2:47] Interactable objects only keep the logic that is specific to them. The shared interaction logic is handled in the BP_Interactable parent.
[2:47 - 3:11] BP_Interactable checks if the actor needs a specific item to be activated. If it does, it checks the inventory, removes the item, and then handles activation or deactivation.
[0:36 - 1:07] The PlayerCharacter uses an interaction trace to check what the player is looking at. If the hit actor has the BPI_Interaction interface, I save it as the current interactable and call the interaction from an input action.
[1:08 - 1:27] The InteractWith function from BPI_Interaction is used to call the pickup logic in BP_Pickup.
[1:27 - 1:41] The progress bar logic runs on Event Tick only when it is actually needed, while the player is holding the interaction button.
[1:41 - 1:54] If the progress bar is filled, or if the item does not require holding, the item is added to the inventory system.
[1:54 - 2:18] The inventory system is a component on the PlayerCharacter. It stores items in a map variable and manages them with three main functions.
[2:18 - 2:35] All item-related settings are stored in Data Assets.
[2:35 - 2:47] Interactable objects only keep the logic that is specific to them. The shared interaction logic is handled in the BP_Interactable parent.
[2:47 - 3:11] BP_Interactable checks if the actor needs a specific item to be activated. If it does, it checks the inventory, removes the item, and then handles activation or deactivation.
Dialogue System
[0:00 - 0:25] Demonstration of the dialogue system.
[0:27 - 0:52] The PlayerCharacter uses an interaction trace to check what the player is looking at. If the hit actor has the BPI_Dialogue interface, I save it as the current dialogue actor, and the dialogue can be started with an input action.
[0:52 - 1:10] When the dialogue starts, the system switches the input mapping context so the player uses dialogue controls instead of the default gameplay controls.
[1:10 - 1:22] After that, it calls the first dialogue point and starts writing its text.
[1:22 - 1:24] This part writes the text letter by letter to create a typewriter effect.
[1:24 - 1:55] When the player continues, the system checks if the current dialogue point still has lines left. If it does, it moves to the next line. If not, it moves to the next dialogue point.
[1:55 - 2:05] When the dialogue is finished, the system switches back to the default input mapping context.
[0:27 - 0:52] The PlayerCharacter uses an interaction trace to check what the player is looking at. If the hit actor has the BPI_Dialogue interface, I save it as the current dialogue actor, and the dialogue can be started with an input action.
[0:52 - 1:10] When the dialogue starts, the system switches the input mapping context so the player uses dialogue controls instead of the default gameplay controls.
[1:10 - 1:22] After that, it calls the first dialogue point and starts writing its text.
[1:22 - 1:24] This part writes the text letter by letter to create a typewriter effect.
[1:24 - 1:55] When the player continues, the system checks if the current dialogue point still has lines left. If it does, it moves to the next line. If not, it moves to the next dialogue point.
[1:55 - 2:05] When the dialogue is finished, the system switches back to the default input mapping context.
Enemies
Zombie
[0:00 - 0:52] Demonstration of a simple zombie AI.
[0:52 - 1:20] Giant zombies can also appear in some world states.
[1:20 - 1:30] Zombie detection logic is handled in the PlayerCharacter. It is easier to avoid zombies while crouching, but at night their detection range increases significantly.
[1:30 - 2:00] Here is the trigger and untrigger logic. In hindsight, I should have used the built-in perception system instead of reinventing the wheel. I wanted a more optimized solution for zombie hordes, but this version ended up having a lot of limitations.
[2:00 - 2:30] Zombies use a blackboard and a simple behavior tree. If they have a PlayerTarget, they move toward the player. If not, they just wander randomly.
[0:52 - 1:20] Giant zombies can also appear in some world states.
[1:20 - 1:30] Zombie detection logic is handled in the PlayerCharacter. It is easier to avoid zombies while crouching, but at night their detection range increases significantly.
[1:30 - 2:00] Here is the trigger and untrigger logic. In hindsight, I should have used the built-in perception system instead of reinventing the wheel. I wanted a more optimized solution for zombie hordes, but this version ended up having a lot of limitations.
[2:00 - 2:30] Zombies use a blackboard and a simple behavior tree. If they have a PlayerTarget, they move toward the player. If not, they just wander randomly.
Eye
[0:00 - 1:00] Demonstration of a non-AI eye enemy that tracks the player’s movement.
[1:00 - 1:05] The eye logic is split between the parent BP and the eye BP, because another enemy also uses some of this logic.
[1:05 - 1:13] Triggering and untriggering work with a simple overlap.
[1:13 - 1:37] The eye rotates and uses a trace to check if it can see the player directly. If it can, it enters the active state and deals damage.
[1:44 - 2:16] The player can destroy the eye with the flashlight. As before, the general destroy logic is in the parent, and the eye-specific logic is in the eye BP.
[1:00 - 1:05] The eye logic is split between the parent BP and the eye BP, because another enemy also uses some of this logic.
[1:05 - 1:13] Triggering and untriggering work with a simple overlap.
[1:13 - 1:37] The eye rotates and uses a trace to check if it can see the player directly. If it can, it enters the active state and deals damage.
[1:44 - 2:16] The player can destroy the eye with the flashlight. As before, the general destroy logic is in the parent, and the eye-specific logic is in the eye BP.