first person movement controller

scripted event camera tool

top-down action role playing game

alien stole my sh%!

side-scrolling action platformer

additional game projects

Proof that I make friends quickly,
even the four legged kind

Striking my best pose at the Eiffel Tower

contact

• [email protected]

+46 760 26 09 98

• LinkedIn
• CV

Hello!

My name is Philip, and I am a game programmer currently studying at The Game Assembly in Malmö. Video games have always been a part of my life. Studying at The Game Assembly has allowed me to be part of what I love.I enjoy games where movement is the core feature. I was intrigued by how smooth and accessible the traversal was in Dying Light, and how impressive the momentum carries itself in Counter-Strike's various game modes.My main areas of interest in programming are 3C (Camera, Control, Character) and all kinds of gameplay programming.
The love for these grew during our third game project, Unbound, where I had the opportunity to create my first player movement. I'm also familiar with other areas of programming, such as tools, AI, and engine.My favourite part of game development has to be the social side of it. To work with multiple disciplines, communicating and bringing the games to life. This was a skill I cherished in my previous job in logistics, so it's very welcome to see that game development holds the same or even higher standard in communication.During my free time, I like playing video games (surprise!), but I also enjoy nature, working out, singing and playing my guitar. During my workouts, I usually love running the most, especially outside in nature and exploring new areas of town.

Purpose

The scripted event camera tool was developed by my co-worker Denis Codreanu and me, with the inspiration to ease out the scripted events process within our game projects with handmade camera sequences.This tool features a simple interface that took heavy inspiration from Maya's keybind and the visuals from Unreal's Sequencer. The goal was that our animators or level designers should have an easy time creating something memorable within our game projects by using camera sequences.

Denis and I shared an interest in making a sequencer. I was more interested in the camera work, and he was more interested in the interface and UI design. So we decided to work together to create something stronger during TGA's course in Tools Programming. We spent 3 weeks working half-time to finish this tool.

A hero introduction for a 3D character, made by my colleague Anders

ImGuizmo preview

Visual Editor with ImGui

One of the most important things Denis and I talked about was having a very clear and easy-to-use UI. We used ImGui to create a simple yet effective UI with their custom draw commands. With these commands, we could create a simple visual editor and a space for editing variables.

An important feature we added for this project was a visual indicator of where the camera was and what it was moving. We quickly decided to use ImGuizmo due to its compatibility with ImGui and the simple implementation. With this tool, the user could easily create and manipulate the camera to the desired direction, rotation, or even size, creating seamless motion with minimal effort.

Custom binary file format

To optimize our integration and stability of transferring data between projects, we decided to create our own binary file format where we would serialize all relevant information. Such as keyframes, frame amount, and transformations.We also made our tool component not rely on any code in this project, making it easy to move it into our game project at a later stage without requiring any extra work.

With the file format done, we wanted to have a safe way of saving, opening files, and restarting from scratch. Which is why we created a way to do just that during run-time, shown in the video to the right.

Saving and opening a custom file format

Undo in action!

Undo-Redo

With a tool created for animating cameras, the user will likely make some kind of mistake at some point. Regardless if the mistake is big or small, an undo/redo function is essential.This proved to be more difficult than we both thought, as there are so many edge-cases that you have to keep track of. Our method for keeping track of the user's action was using a vector, and whenever an action was done, we saved the original information, then we pushed it into our vector. If the user wanted to redo, all we had to do was pop it, and the action was reversed.

UI implementation & UI animations

I worked full time on this project to create animations for the UI, specifically the map, which had a unique visual for every level and a unique animation displaying it for the player. I also made idle animations for the main menu UI to make it look floaty

UI optimization & UI creation

Due to a lot of absense during the project, a lot of the graphical artists were in need of help. I helped them out by creating simple but easy UI in unity that was later shipped with the game. As this was a mobile game, I had to be very careful to not overdo it, as the performance was crucial.

UI implementation

As I wanted to try out almost everything in this project to get a feel for what I enjoy. One thing that really stuck was UI, so naturally I started to work more on the UI and implementing a majority of the buttons and UI in the game.

Collectibles visual feedback & Movement

The first thing I worked on this project was the first iteration of the movement. We also wanted to make it clear that you picked up the power-ups, so I transported it above the player and made it sink into them!

Animation pipeline and timings

I built the animation component completly from scratch. This was the first project using 3D, so I had to learn how to handle 3D models, textures and how to get everything properly. We used a state machine architechture for this.

Various animations playing all over the place

Shadows and lighting

This was my first time experimenting with shadows and lighting. We got a tutorial project from our educators. I used this project to reverse-engineer the lighting and shadow shader to implement in our game.

Lighting and shadows existing even though it was cut

Full player movement

As our game was very movement heavy, I wanted to have permanent iteration on our player movement, as it is the main feature of the game. I wanted to handle the player movement over the course of the entire project.

A display using a lot of the movement features

Springs

Springs were a movement mechanic which would bounce you in the direction that the spring was facing. Fun and difficult to implement due to a lot of collision problems and getting stuck in walls.

It's a bounce house of springs!

State handling for the player

The system we used was a state machine based on enums, which means we had to keep track of the state during every stage of the code. This was made so it seamlessly transitioned to the correct locomotion state.

States swapping and stamina shortage

Quality of life

There were a lot of quality of life added to the player, such as the following: Auto-mantling, ledge nuding, coyote time, jump buffers and a whole stamina system which makes your character blink red when it's low.

Ledge nudge in action so you don't bonk your head

Crewmates

Crewmates kind of act like a collectible, as they need to be rescued by the player and then used to win the game. As soon as there was a collision, a sequence started, and I had to swap out a mesh to visually represent the bubble popping.

Crewmate saved & custom dialogues on every crewmate

Collectibles

I created the system that kept track of all the collectibles and their movement. As well as some quality of life effects, such as auto-pickup and visual feedback.

Collectibles spin and pickup

Player Jump

One thing I really wanted to work on was the player jump. I believe a satisfying jump will change the experience of the game. This jump was done by adding minimal jump, a variable jump, and a max height jump, which the player can control.

Variable jump height with a maximum and minimal jump

Deathzones, level transition and checkpoints

Deathzones and checkpoints work hand in hand. If the player falls off the map, takes damage, and then checks the nearest checkpoint, teleport them there. We do this by taking the transform of the checkpoint and then moving the player there with the correct rotation and position.

Deathzones and checkpoint system with the portal for level transition

Production time:

• 14 weeks half time

Reference game:

• Diablo 3

Engine:

• Unreal Engine (editor)

• RNG (Custom built engine)

Team:

• 2 Animators

• 4 Graphical Artists

• 4 Level Designers

• 7 Programmers

• 4 Technical Artists

Made at The Game Assembly by:

Camera shake

I implemented a camera shake to enhance the feel of the bigger attacks. This was done by sampling Perlin noise and applying it to the camera.

Player Abilities

I worked on all of the player abilities during the course of the project, but created the Buff and Heavy slam ability from scratch

Knockback system

As there were powerful abilities, we needed a system to portay the power, and we did this with knockbacks. This was done by applying a velocity to a vector away from the collision area.

Biggest enemy applying knockback on player

Stat system / Buff system

Every character needed stats which included: Speed, health and damage. These metrics were applied using JSONs and a modular system that allows player and enemies to receive buffs during run-time

Using a Buff Clock Actor that randomly applies enchanced player stats

Ability unlock

The abilities got unlocked by punching a big bell, which in turn would unlock an ability depending on which level you were at.

Unlocking the first ability by punching the bell

Quality of life

To create a good feel for the player, enabling them to punch in the air whenever they wanted, as well as being able to hit every bell and pot that they could ever want to destroy.

Punching all the ceramics you could ever want to destroy!