Daniel Daniel Daniel Daniel
Game Project 2 At FutureGames
Introdution
Play on itch: https://futuregames.itch.io/daniel-daniel-daniel-daniel
Daniel Daniel Daniel Daniel is a first-person shooter roguelike set in a cyber-dystopian world affected by AI corruption. The game features procedurally generated rooms and escalating difficulty as the player progresses. As a Gameplay Programmer, I was responsible for implementing several core gameplay and UI systems, focusing on scalability, reusability, and clear player feedback.
Upgrades "Mod" Selection
Being set within a computer, the upgrades were referred to as "Mods/RAM" and the space for the upgrades was referred to as "memory usage".
I made a script that controls the UI for managing Mods/RAM in the game. It lets players equip or unequip RAM mods, check memory usage, and get visual feedback when they overload their memory. It updates buttons, shows tooltips, and adjusts the UI dynamically based on how much RAM is being used.
This script controls the UI for managing Mods/RAM in the game. It lets players equip or unequip RAM mods, check memory usage, and get visual feedback when they overload their memory. It updates buttons, shows tooltips, and adjusts the UI dynamically based on how much RAM is being used.
At first, the script had a lot of issues. The UI wasn’t updating properly, RAM slots weren’t being managed efficiently, and buttons kept getting recreated instead of reused, which made
everything feel clunky. The biggest fix was introducing a dictionary to track existing buttons, so instead of constantly creating and destroying them, they were simply moved between the “equipped” and “backpack” sections. This made the system much more responsive and
optimized.
Weapon Selection
I implemented the weapon selection system used at the start of the game, allowing the player to choose their initial weapon before entering gameplay. The system is part of the starting room prefab and is designed to be clear, controlled, and resistant to unintended state changes.
The system ensures that only one weapon is active at a time, immediately equipping the selected weapon while disabling the others. This keeps the game flow smooth and prevents
unnecessary UI clutter. The script also checks when the player enters or leaves the selection area, ensuring they can only interact when inside.
This approach keeps the weapon selection process simple, allowing players to make a clear choice before moving into the game. It also ensures a clean transition between selecting a weapon and starting gameplay without unnecessary delays or confusion.
Audio Manager
I built a centralized audio management system using a singleton AudioManager and serializable sound data. This allowed designers to easily configure and reuse audio assets directly from the Unity Inspector.
To create the audio system, I developed two key components: the Sound and AudioManager class along with an Audio Manager object in the root scene with the AudioManager script on it. The Sound class serves as a data structure for storing audio properties such as volume, pitch, looping behavior, and AudioMixerGroup assignment.
By making it [System.Serializable], designers can adjust sound properties and add new sound clips into a list directly in the Unity Inspector without modifying the code. This dynamic approach ensures that each sound is easily configurable and reusable throughout the game.
Health & Damage System
For this I implemented a reusable, interface-based health system using an IDamageable interface. This allowed players, enemies, and destructible objects to share damage logic while remaining flexible. The system is event-driven and integrated with the HUD for real-time feedback.
Rösvik
Game Project 3 At FutureGames
Introduction
Play on itch: https://futuregames.itch.io/rosvik
Rösvik is a first-person survival horror game set in an abandoned northern Norwegian village. Players take on the role of a surveyor investigating the mysterious site, uncovering pagan myths and gathering resources to survive. The gameplay combines exploration, stealth, and mystical elements, with a focus on managing a backpack-based inventory and avoiding supernatural threats.
Inventory System
The inventory system I created was built to be reusable, scalable, and tightly integrated with both the player character and UI. Its main purpose was to allow players to collect and use items found throughout the game world, with minimal friction and maximum clarity. I designed the system to support multiple item types (e.g., consumables, keys, crafting resources, quest items), and it was developed with future expansion in mind.
AI Enemy Behavior
The Watcher is a patrolling enemy designed to support Rösvik’s stealth and horror gameplay. I developed its behavior entirely using Blueprints and Behavior Trees, focusing on modularity so that multiple Watchers could function independently within the same level.
Tutorial System
To help onboard players and guide them through Rösvik’s core mechanics, I implemented a flexible tutorial system using Blueprints. The system was designed to be lightweight, flexible, and easy for designers to expand or adjust without rewriting logic.
Cosmosis
Game Project 4 At FutureGames
Introduction
Play on itch: https://futuregames.itch.io/cosmosis
This game is a dark fantasy, top-down co-op fighting game inspired by Lovecraftian horror. Designed with two players in mind, players take the roles of two spellcasters battling through eerie environments filled with cultists, eldritch creatures, and ancient horrors. The game combines tactical combat with an atmosphere of mystery and dread, encouraging teamwork and coordination between players.
Save & Checkpoint System
I implemented a save and checkpoint system designed to work in both single-player and multiplayer. The system automatically saves progress when players reach checkpoint triggers, storing and restoring the state of relevant UActors and player positions.
The system is built around a custom checkpoint subsystem, with actors defining their save behavior through an interface to keep the logic flexible. To prevent multiplayer desynchronization, all save operations are handled server-side, with a save lock in place to avoid conflicts during load operations. This ensured stable, authoritative saves in a networked environment.
Interaction System
I developed a modular interaction system that allows players to interact with world objects such as doors, pickups, and levers in a consistent and multiplayer-safe way.
Interaction is handled through a player-side component that detects nearby interactable actors and highlights the closest valid target for clear visual feedback. All interactions are executed on the server using Unreal Engine’s replication system, ensuring that interactions are synchronized correctly for all players. Key settings were exposed to Blueprint to allow designers to easily adjust behavior without modifying code.