A selection of gameplay systems and mechanics engineered across shipped and in-development games.
Dynamic wetness system
Build a systemic wetness simulation where items and the player react dynamically to rain, water, mud, wind, temperature, and clothing layers. The system tracks individual item wetness, supports layered clothing protection/leakage, and aggregates body wetness for gameplay, UI, and visual feedback.
Tool Interaction System
I co-wrote and helped refactor a flexible tool interaction system where each equipped item can define its own behavior. The player input is handled centrally. Depending on whether the player uses left click or right click, the system triggers either a normal Interact action or a Special Interact action. These actions are called through an interface on the item instance currently equipped from the inventory. The system is mostly data-driven. Sounds, animations, interaction settings, and tool-specific data are configured through Data Assets, which keeps the logic clean and avoids hardcoding every item behavior manually. Each item is responsible for its own rules. This makes it easy to create different tools with different behaviors, such as unique animations, sounds, cooldowns, interaction types, or special actions. Each item can also define its own Input Mapping Context when needed. This allows specific tools to override or extend the default input actions. For example, items like binoculars, radios, or other special tools can add their own controls without affecting the rest of the inventory system. The system also works properly with gamepad controls, so both standard interactions and item-specific actions are handled cleanly across keyboard, mouse, and controller. I refactored the system several times to make it cleaner, more modular, easier to maintain, and easier to extend with new tools.
Boarding System Implementation
I implemented the boarding system as a special two-step building flow for placing wooden planks on windows and frames. Instead of placing the plank immediately, the system first lets the player pin one end of the board to the target surface. This pinned point becomes the pivot anchor. From there, the free end of the board rotates around that pivot based on the player's camera direction. Technically, the rotation is mostly driven using dot product calculations between the camera/look direction and the placement plane. This allows the system to determine the intended rotation angle in a stable and intuitive way, without requiring complex manual controls from the player. The result is a natural interaction where the player feels like they are "nailing one side, then swinging the board into place." The implementation is split between the Building Manager and the Buildable Component: the Building Manager handles the active build item, placement mode, inventory source, and target detection, while the Buildable Component controls the preview behavior, pivot placement, rotation logic, validation, and final spawn/confirmation. For boarding specifically, the component stores the initial pivot point, calculates the board orientation relative to the player camera, and updates the preview transform every frame until the player confirms the placement. I also implemented an auto-placement helper system to make boarding easier for players. This uses four line traces to check whether the board is aligned with valid placement helper boxes placed on windows or frames. When the traces detect these helper volumes, the system can assist the player by snapping or validating the board placement more cleanly, making it easier to cover windows with planks without requiring pixel-perfect manual alignment. Finally, all possible material sources are merged into a single usable pool, including player inventory, hotbar items, carried under-arm items, and nearby dropped boards. This allows the player to smoothly cycle and place available boarding materials without opening extra menus.
Multiplayer gameplay ability integration
Integrated gameplay abilities in a multiplayer context, connecting player input, ability activation, targeting, and execution. The system ensures abilities can be triggered correctly, apply their effects, and remain compatible with the project's multiplayer gameplay structure.
Monster integration
Implemented and integrated monsters into the gameplay loop, including their abilities, behaviors, and interaction with the player. This involved connecting AI logic, ability usage, and combat behavior so monsters could function as active gameplay entities rather than static enemies.
Placement collision handling
Worked on placement collision logic for park structures and rides, ensuring objects could only be placed in valid locations. The system checks spatial constraints, collision overlap, and placement rules before confirming the final position, preventing invalid or broken object placement.
Visitor needs systems
Contributed to visitor needs systems that drive simulation behavior inside the park. Visitors react based on internal needs and park conditions, allowing the game to simulate player-facing management consequences such as satisfaction, demand, and attraction usage.
Many 2D zombie logic without lags
Implemented optimized 2D zombie gameplay logic designed to handle many active enemies without noticeable performance drops. The focus was on simple but efficient behavior, reducing unnecessary updates, and keeping enemy movement and decision-making lightweight.
Tree-to-tree traversal system
Designed a traversal system allowing movement from one tree to another through defined gameplay rules. The system handles valid traversal targets, movement transitions, and player flow, creating a structured way to navigate between connected points in the environment.
Checkpoint system
Implemented a checkpoint system to save the player's progression through a level. When the player reaches a checkpoint, the system records the respawn location and restores the player there after failure, making level progression smoother and more forgiving.
Trap systems
Built trap gameplay systems used to challenge the player during platforming sequences. These traps can detect the player, trigger damage or failure states, and integrate with the checkpoint system to create a complete loop of challenge, failure, and retry.
Data-driven scalable level loading with level select
Created a scalable, data-driven level loading flow connected to level selection. Instead of hardcoding each map, the system uses structured data to define available levels, load the correct map, and keep the selection logic easy to extend as new levels are added.
Shipped on Steam