I Have developed various game mechanics and tools in Unity over the years, including inventory systems, health systems, AI behaviors, procedural generation, and more. This collection showcases some of these smaller projects and prototypes that demonstrate my versatility and problem-solving skills in game development.
Similar look, inspired by RE2.
PSX-style inventory system.
Inventory is accessible only via keyboard.
Player can equip items.
Player can inspect items.
Player is able to drop items.
If a dropped item overlaps another item, a drop-item sensor detects nearby items and places the item within a safe distance.
Player wallet system.
Player health condition/status.
Each item has its own info panel.
Each object is stored using Scriptable Objects.
Main tool: Animation Rigging Package.
To initiate the door knob opening animation, an IK (Inverse Kinematics) target is placed at the door knob position.
This IK target smoothly lerps toward the player’s hand as the player approaches the knob, triggering the animation.
Once the knob receives the interaction notification, it rotates itself.
Since the IK rotation already follows the knob position, the player’s hand naturally follows the knob’s movement.
As a result, the final output appears as a procedurally generated door knob opening animation.
To detect whether an enemy is affected by torchlight, a raycast combined with dot product calculations is used.
Once an enemy is detected, it implements the ILightAffectable interface, marking the object as light-affected and allowing the enemy to trigger the Run method.
To find a hiding spot, the process is relatively simple.
A position near a collider is located, its height is evaluated along the Y-axis, and its size is verified to ensure it is a valid hiding spot using dot product calculations and raycasts.
The hiding place is then selected on the NavMesh using a simple NavMesh Sample Position.
This position is chosen at the edge of the collider, but on the opposite side.
The above inventory system has been merged with this sample project.
The camera dynamically changes after obtaining the torch.
There are three types of doors available:
Trap Door.
Key Door.
Non-Key Door.
Picking up and positioning objects uses DOTween for smooth movement.
The object smoothly moves toward the camera with a specified offset, creating a polished pick-up effect.
Callback options allow the player to pick or leave the object.
When picked, the object is added to the inventory, indicating a seamless inventory interaction flow.
Object rotation is handled using Unity’s IPointer interfaces for mouse input.
This provides a clean and standardized approach, ensuring responsive rotation tied directly to user input.
LocalEulerAngles are used to control rotation, allowing precise local orientation without unintended global rotation issues.
Object zoom is implemented using mouse scroll delta.
The object’s Z position is dynamically adjusted based on scroll input, with a configurable speed value for fine-tuning responsiveness.
The system is implemented using Unity’s New Input System.
This ensures modern input handling with improved control, flexibility, and scalability.
This system implements a rotating radar mechanism used to detect nearby entities within a defined radius.
The radar continuously rotates both in world space and UI space to simulate an analog scanning effect.
Entity detection is handled using Physics.OverlapSphereNonAlloc for performance-friendly scanning within a configurable detection radius.
Each detected object is evaluated using dot product calculations to ensure it lies within the radar’s forward scan angle.
Once an entity passes the angle threshold, it is checked for the BaseEntity component.
Detected entities are stored in a list to prevent duplicate UI icons from being created.
For each valid entity, a ping icon is instantiated on the radar UI.
The icon position is calculated by converting the world-space distance to radar-space coordinates and scaling it relative to the radar UI size.
The icon position is rotated to match the player’s forward direction, ensuring accurate orientation on the radar display.
Icons are clamped within the radar radius to prevent them from appearing outside the UI bounds.
When an entity is destroyed, its corresponding radar icon is automatically removed via an event callback.
This ensures the radar UI always reflects the current state of the environment.
This system implements an SCP-173 inspired enemy AI using a simple state-based behavior system.
The enemy operates with three states: Idle, Chase, and Attack.
The Chase behavior is driven by Unity’s NavMeshAgent, allowing the enemy to navigate toward the player using NavMesh pathfinding.
The enemy continuously checks whether it is visible to the player using camera frustum testing.
If the enemy is within the player’s line of sight, it immediately stops moving and its animation is paused, simulating SCP-173’s “do not move while observed” behavior.
A raycast is used to determine whether the enemy is behind walls or other obstacles.
If the player is not directly visible due to obstructions, the enemy is allowed to move toward the player.
When the enemy has a clear line of sight and is being observed by the player, its NavMesh destination is set to its current position, freezing movement.
When the enemy is not being observed or is hidden behind walls, it resumes chasing the player.
This combination of camera frustum checks and raycast-based visibility creates a horror-accurate SCP-173 movement behavior.
Customer Behaviour
- Waiting For Their Foods
- Player Will Cook For Them
- Each Customer Can Have Different Behaviors
Just In Prototype Phase
Technical Implementation:
Utilizing a queue, an abstract class, and ScriptableObject.
Available as an open-source project on GitHub for developers and Unity enthusiasts.