Tom the Dragon

• 15
• 4 Weeks
• Unity

This game is a fun and relaxing platformer designed for kids ages 7-11 was made during the FutureGame course Game Project 1. In this project I was in charge of making the user interface.

The GameTom the Dragon is a fun, relaxing 3D platformer designed for kids aged 7-11, where players take on the role of Tom, an adventurous little dragon on a mission to escape a slowly rising sea of lava! The goal is simple but exciting: climb higher and higher through vibrant, whimsical landscapes while avoiding obstacles and collecting helpful power-ups.As Tom soars up the towering cliffs, players can use special mushrooms to gain an extra boost of height, jump over obstacles, and avoid falling rocks thrown by mischievous mole miners. Along the way, they’ll collect blue flowers for a speed boost and yellow flowers for an extra high jump, all while racing against the lava's rising tide.With easy-to-learn controls, colorful environments, and playful challenges, Tom the Dragon is the perfect game to keep young players entertained while developing their timing, coordination, and problem-solving skills. Whether they’re dodging rocks, boosting through clouds, or climbing towards victory, every moment is packed with adventure!Will you help Tom escape the lava and reach the sky? The higher you go, the more exciting the journey becomes!-

Purpose

The purpose for this project was to simulate a game development work place. We collaborated across disciplines including game design, artists, animation & VFX, UX and other programmers. This was done to better understand each other's roles and improve our ability to work as a real development team

My Role

UI ProgrammerImplemented the logic and player interaction for the Main Menu and Pause Menu systems.Developed smooth and reliable scene transitions between gameplay and menus.Focused on responsive and intuitive user experience through UI programming.

Week 1

In the first few days our team focused on brainstorming the game concept and assigning roles. I took the role of UI programmer and began collaborating with the UX design team to outline the structure and behavior of the main menu and pause menu system.To work without interfering with the rest of the project during early development I created a dedicated scene for the Main Menu and Pause Menu systems. This allows me to iterate freely without conflicts with the rest of the project.

Week 3

This was the most technically challenging part of the project.
I began integrating the pause menu into the actual gameplay scene and hooking it into the GameManager and Player Controller systems. However I ran into a few issues doing so:

The Pause function in the GameManager wasn’t firing properly.
Even when triggered the pause menu UI would not respond to inputs
After significant work and debugging. I fixed the function not getting called in the GameManager, the root of the input problem. The GamePlay scene lacked an EventSystem which prevented UI elements from registering input events. Once I added that the pause menu started working as expected.I also had to adjust the UI system after the designers proposed a cinematic rotating camera for the main menu using Cinemachine. While I got the cinematic system working it was later scrapped due to time constraints.

Week 2

By the second week i had a completed the first version of the main menu, including:Next I developed the Loading Scene system that could be called anywhere in the game to handle smooth scene transition. The loader would store all currently built scenes in an enum and then use the loader and the enum to trigger the level to change reliably. This level could be loaded without the use of strings that are case sensitive and can easily be misspelt and index numbers that are easy to forget.

With that complete. I moved on to build the Pause Menu. Again using a separate scene called PauseMenu. This menu included:

Next I developed the Loading Scene system that could be called anywhere in the game to handle smooth scene transition. The loader would store all currently built scenes in an enum and then use the loader and the enum to trigger the level to change reliably. This level could be loaded without the use of strings that are case sensitive and can easily be misspelt and index numbers that are easy to forget.

Week 4

The last week of development was hectic. Some features like audio sliders could not be fully connected. While the audio was added in the end there was not enough time to hook it up into the UI.There were still minor bugs in the main menu system at submission, proud of the modular scene transition system and the overall UI logic. Despite setbacks I had delivered the core functionality and helped ensure the game could be navigated between scenes cleanly.

To take damage i created a simple TakeDamage() Function.I then created a simple Ore spawn that spawned the ores in a radius around the deposit.
Then when the Deposit took enough damage its model was replaced with a broken one created with Unreal Fracture mode. Then I blueprints I added another timer that after an amount of time the debris shrink and is destroyed.

Dark Descent

• 19
• 4 Weeks
• Unity

This game is a fast-pace roguelike action game set in Limbo the first layer of hell. This game was made during FutureGames Game Project 2. In this project I was responsible for for the programming the UI and Audio Systems, while also learning with FMOD

Purpose

The purpose of Game Project 2 was to create a playable game in Unity within 4 Weeks while collaborating with people from other disciplines. The goal was to apply the skills and experience gained form the previous Game Project 1 together with the skills acquired from the courses between. We were tasked with creating a game and narrative around the theme given in this case was “Daggerblade” We could do anything we wanted as long as the name or idea of “Daggerblade” was in some way part of the game.

My Role

UI and Audio ProgrammerDeveloped interactive UI systems, enabling seamless player input and feedback.Integrated FMOD into Unity for dynamic sound playback and control.Collaborated closely with sound designers to implement and test game audio.Assisted in prototyping and implementing the spell system for the alpha release.

UI

My main role was UI programmer. So i was in charge of programming the logic behind the Main menu, pause menu, Interface and Level transition. Picking up from Game Project 1 with the drive to improve my quality compared to last time. Thanks to having done this in the earlier Game Project this time it went way smoother.When making the UI i worked in my own scene and created both Menu and Pause Menu in that scene.

Audio and FMOD

My secondary roll was to program audio together with the tool FMOD. I hade before no experience or knowledge programming Audio or using it together with the FMOD tool. But with the help of the audio designer and sound producer the audio was added and worked together seamlessly with the game. I also worked with the UI Menus so that the audio could be managed and controlled with settings.I created an FMOD Events library responsible to call and play the sounds from the FMOD files.Then I made an Audio Manager that is responsible to call on the library events and then play them when called.

Astroids Explorer

• 17
• 7 Weeks
• Unreal

GP3

Purpose

The Purpose for this Game Project is similar to other game projects. simulate a game development work place. We collaborated across disciplines. Learn how to make games as a team. But this time it was made in Unreal togeather with C++. Witch i att the begining of this project only had 4 weeks of experienc with from a previous course.

My Role

My role for this project was Gameplay systems programmer. I was in charge of programming many of the core systems and features. I worked on the Blackhole, the Mining and ore system, the backpack system and the player health.

Blackhole System

My first task in this project was the games core blackhole system. This system handled the gradual growth of a blackhole. I did this buy having the blackholes scale, CurrentMaxScale gradualy update with either the time of the game or with the Ores mined. Then have current scale constantly increas over time but never higher than CurrentMaxScale.

Mining System

In the mining system my task was to code the logic for oredeposits. Objects that when hit with the pickaxe would:

To take damage i created a simple TakeDamage() Function.I then created a simple Ore spawn that spawned the ores in a radius around the deposit.
Then when the Deposit took enough damage its model was replaced with a broken one created with Unreal Fracture mode. Then I blueprints I added another timer that after an amount of time the debris shrink and is destroyed.

The ore spawning needed fixing after playtesting as its spawned inside walls, underground and inside invalid objects. To fix this I created a ore spawn sweep. This sent out test spots for the ore to spawn. if it was colliding with something then its location is invalid, do not spawn and do the check again. But if it did not collide with anything then the spawn is valid and spawn.

Health Component

This was by far the simplest task and only took me an afternoon. All I had to do was create a PlayerHealth component to the player. All it contains is player TakeDamage() function and a Health() Function