ECS
Gameplay, Physics, Collision
Profiling

ECS space shooter

Solo project - SDL / C++

Memory shooter

Small space shooter made with SDL,

exploring data-oriented concepts.

Windows

SDL

C++

4 weeks

solo

Platform

Engine

Language

Dev time

Team size

project contents

ECS
Gameplay, Physics, Collision
Profiling

intro

The goal of this project was to make a small game with data oriented concepts and performance in mind. Throughout the process I learned a lot, fetching from a broad variety of resources. It was a really interesting challenge to work with a data-oriented mindset while not relying on a preexisting engine like Unity or Unreal.

ECS

To better understand the potential benefits of working with data-oriented design I tried to create an implementation of an ECS for the project. Starting and not really understanding the problem at hand led to a overly complicated first implementation and hard to use system so after understanding the basics of ECS better I reworked the system from scratch using resources found online. Sources are listed in the github repository.

With the core of the ECS in place I tried to maintain a structure throughout the project with components being pure data and having the corresponding system only working with the data it needs. In the project

I have systems and components handling core functionality like collisions, rendering, physics aswell as gameplay related systems handling for example damage and enemies.

collision

In the first version of the collision system each entity in the game checked collisions with each other entity. As this leads to linearly increased complexity and I wanted to work with performance in mind I tried to create a system that scaled well enough to suit the game's needs.

The result became a system divided into two steps. The first sorting entities based on positions, the second the one to one AABB-collision checks. The two steps, together with excluding unwanted collisions with collision layers from the calculations, led to a dramatic increase of performance.

Collision system showing possible collisions in yellow.

Damaging and removing entities on AABB collision.

Through out the process of making the system perform better I got hands on experience with profiling my code and to be able to increment the amount of entities while testing and keep an ok framerate made the process of optimizing the code a really fun experience.

takeaways

This project was one of my favorite solo projects I’ve worked on thus far. I gave myself time to research and understand the problem at hand before I went into code and also relied more on theoretical resources rather than referencing other people's code.

I feel I have a better understanding of optimization and how the CPU and memory works. Researching data-oriented design and the process of implementing the ECS also made me rethink how I approach problems. In previous projects I feel I’ve tried to rush to solutions and taking a slower approach, starting simple and only fleshing out when needed, is something I’ll carry with me going forward.

Engine programming
Graphics pipeline
Shaders
Procedural animation

procedural walking

Solo project - OpenGL/ C++

procedural walking

IK Solver and a small engine made with OpenGL.

Windows

Open GL

C++

7 weeks, non continuous

solo

Platform

Engine

Language

Dev time

Team size

project contents

Engine programming
Graphics pipeline
Shaders
Procedural animation
IK

intro

The goal of this project was to get a better understanding of the concepts and requirements of game engines. I also explored procedural animations and got to go down a math-heavy rabbithole and learn more about the technical sides of animation and tools I've used daily.

engine

Having previously only worked with existing engines it was really exciting to read up on and try to create the basis of my own. Starting the project not knowing what requirements I'd need got me occasionally lost and frustrated with myself but with the project behind me I'm really happy I pulled through. The engine handles inputs, cameras and textured rendering. I kept the engine 2D due to the timeframe but learned alot about 3D researching the project.

In hindsight I would have benefitted from a more precise goal other than purely learning. As an example I built a structure that feels clunky to use when trying to create game logic while just having fun with shaders, not the primary intent, went with ease.

Working with the project I learnt a lot about Shaders and the Graphics pipeline. I've gotten a deeper understanding for engines and it feels exciting to be able to better analyze the tech behind alot of my commonly used tools.

Shader from the project, eyes calculated and distorted inside the shader following mouse input

ik solver and walking

Having done a fair share of rigging and being interested in a lot of previous work like the animation system in Spore and the current project on procedural animation at Embark I wanted to try to implement my own basic IK and se if I could make a character walk.

The resources i referenced was very math heavy and I tried to make sure that I understood each step, starting simpler with calculating angles and Forward Kinematics before I continued to Inverse Kinematics and finally reaching the result below. The character is driven by input but the walkcycle is procedurally generated and solved with IK.

My process was first understanding my goal, then researching the math and later to try to work iteratevly with my implementations one problem at a time. As an example the first version of my step was one leg only and the feet sliding on the ground. Below is a gif from the process of figuring out the IK and a simple visualisation of how taking a step is decided.

Calculating angles and solving two form IK.

Explanation of step calculation

takeaways

To not shy away from information that at first glance feels over my head is one big takeaway from this project. I'm very happy I trusted the process and continuosly looked for new information on what I didn't understand.

Working alone while getting lost in information can be frustrating so even though the character walks a bit stiff I'm really happy I managed to reach my goal. Starting with learning how to create a window and draw sprites, to working with shaders and generate the animations.

In the future I will hopefully make an overhaul of the engine code to make it easier to use and I also aim to make a more complex IK system and continue to explore animation driven by code.

Procedural animation
Rigging
Animation pipeline
IK

Body Adjustments, Quadrupeds

Solo project - Unreal/ C++

Body adjustments for quadrupeds

IK and procedural animations using Unreal.

Windows

Unreal

C++

solo

Platform

Engine

Language

Dev time

Team size

[ WIP ]

project contents

Procedural animation
Rigging
Animation pipeline
IK

intro

The goal of this project was to explore technical animation workflows working with Unreal and C++. I wanted to learn more about the animation related tools in the engine, with a focus on logic driven solutions and good practices for performance.

modular behaviour

In the project I wanted to create a modular workflow, creating building blocks with reusable functionality. One example of this in practice is the rig and logic handling the character’s Look-At behavior. The rig driving the behavior can be used by multiple different skeletons and, as shown in the gif to the right, swapping out what skeleton we affect can be a simple process.

Look At-behaviour made to be reused between multiple characters

[ WIP ]

ik and footlocking

temptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttemptexttempt

performance awareness

Understanding decisions made in Lyra

Thread safe functions for collecting data

State functions running on nodes

Maintainable structure

[ WIP ]

takeaways

Gameplay,
Animation, Rigging
Scrum Master, general support for the team

Monkey Business

Group project - Unreal engine / C++

No more MONKEY BUSINESS

No More Monkey Business is a juicy top-down brawler where you progress the levels by wreaking havoc at your prior work place and destroy everything that comes in your way...

Windows

Unreal

C++

6 weeks

13 ( 5 programmers, 3 artists, 5 designers )

Platform

Engine

Language

Dev time

Team size

Responsibilities

Gameplay, Character, Player Attacks, Player Interactions
Animation, Rigging and implementation in engine
Scrum Master and general support for the team

Intro

In this project I got the opportunity to work with a set of people all valuing clear communication and, due to it lacking in previous projects, an emphasis on team building. Continuous work in this field led to a really healthy work environment and an overall fun experience. I led daily and weekly meetings and tried to encourage and maintain cross discipline communication. I touched a little bit of everything in engine and code with a main focus on player abilities, player interactions and animation. It being my first project with Unreal each day presented new problems to solve, resulting in a period of constant learning.

Player abilities And interactions

Feedback from within the team

Designer/PO - "It was a really nice experience to work with you. You always kept a positive mindset, handled conflicts maturely and did more work than asked for even when it was outside your discipline’s responsibilities.

To my understanding, both the industry jury and the team felt good about how the project’s been led and a big part of that was you.

I hope to get to work with more people like you in the future!"

Artist - "Would like to take the opportunity to thank you and tell you that it’s been a pleasure to be in Team 05 with you, Martin! You’re one of the nicest people I’ve ever worked on a project with. And so talented and knowledgeable within many different areas. It’s truly been a pleasure!"

Programmer - "Martin is an excellent colleague and team member, he always helps out when it's needed and is a delight to work with!"

In the beginning of the project we divided the work based on interest, later shifting in to an "all do all"-workflow based on priority.

Writing code not just for me meant that structure and readability was important and we wanted everyone in the team to be able to easily expand on each system if needed. As I had other responsibilities in the project as Scrum Master I was intended to do code on halftime, in reality this turned in to a 75-25% split with the majority of my time in engine and code. Below is some examples of my contributions to the gameplay side of the project.

Finding interactable objects within range, calculating best candidate with dot product.

AOE-attack hitting enemies and world objects.

difficulties

Due to this project being our first in Unreal, to create a solid structure and find a good balance between logic in C++ and implementation in Blueprints was somewhat of a challenge. On some occasions this led to a need for restructuring and re-writing of code. Some problems became unnecessarily hard to debug when stepping within just C++, or just Blueprints felt like a non issue, but stepping between felt messy in comparison.

How we dealt damage is one example of where we didn't really plan ahead. Damaging objects and enemies were handled in two different ways leading to us needing to spend time reworking the system quite late into the project even though it was created pretty early on.

We solved these issues by taking a step back together in the programming team, giving ourselves time to discuss what changes we needed to make and made sure to stay organized as we implemented the changes.

In hindsight we could have benefitted from more thorough planning within the group as a whole. The intent was to maintain a modular workflow but, with us not really reviewing each other's code, combining our systems took some extra time.

code takeaways

One big takeaway from the project is the importance of good communication with everyone in the team, also outside my own field. The team as a whole struggled a bit with this in the beginning of the project but with time, and after discussing it during our weekly retrospectives, we started to break down that divide. As we tried to shift more into feature teams working closer together, we had less misunderstandings and, having more details from the designers and being able to ask questions when needed, made it easier for me to work.

I feel really fortunate to have gotten to work with the other programmers in the team and learned a lot throughout the project about developing gameplay, team workflow and structure. I also got more experience of debugging my own and others work.

animation

To offload the art team I helped with setting up an animation workflow to support both custom and downloaded animations. For the final product we ended up using only custom animations I made and even though animating was not my main priority it was a really fun experience going through the process from rigging to implementation in the engine.

Jump Attack Montage utilizing 'Animation Notifies’ and ‘Notify States’ giving designers more control of look and feel.

Three Punch Combo, ended up not being used in game.

Punch in game, splitting upper and lower body movement with Montage Slots.

Directional Hit Stun, blending to Ragdoll on the upper half of the character on hit.

animation takeaways

With the look and feel of the animations having such a big impact on the gameplay we should have implemented and tested some of it earlier. Finding a good balance between anticipation and responsiveness was a longer process than I planned, leading to some animations not feeling as tight in game as I wished. Though the game could probably have benefitted from a more exaggerated, cartoony style, I’m happy with the results overall. Due to other priorities I had to get the work done fast and really learned a lot from the process.

Gameplay
Camera
Audio

GOTY nominee, 2022

Movr

Group project - Unity / C#

Movr

MOVR is a fast and frenetic driving game about trying to satisfy customers requests without crashing your car in the process.

Windows

Unity

4 weeks

13 ( 4 programmers, 4 designers, 2 artist, 1 PM, 2 QA )

Platform

Engine

Language

Dev time

Team size

Responsibilities

Gameplay, player and physics- interactions, in game tasks
Camera
Audio

Feedback from within the team

Project Manager - "Martin is positive, takes responsibility and is good with communication. He contributes with pushing projects forward and helps creating a healthy work enviroment for the team. En klippa!"

Designer - "Martin is not only an excellent, pro-active and enthusiastic programmer, he's a warm affable addition to any team that will help create and maintain a positive work environment."

Programmer - "Martin was a joy to work with during GP2. Attentive for the team, great with what he was doing, helpful and cooperative. He took a big part of the workload while still helping others, including me, and still delivered his work on time. Definitively someone I’d like to work with again!"

Artist - "Martin is among the few people who was dependable and approachable during the project. I had a very positive experience working with him. A very collaborative person, having a fair share of artistic expression and skill, was not just crucial for the team, but also indispensable for an artist like myself during the whole project."

Car and object interactions

While driving the player gets prompted to complete tasks. The car is equipped with cabinets, levers, buttons and objects used to meet the customers different needs. Working on these interactions was my main focus during the beginning of the project.

Physics simulation and object interactions inside the car while it's moving.

Dashboard with interactable buttons and levers used for solving in game tasks

difficulties

The physics simulations while driving led to a variety of issues. Unwanted movement of objects due to the movement of the car, objects jittering etc. During the process of solving these issues we had to make sure we tested mechanics in the intended in-game setting, ex test picking up objects while the car is driving and not just standing still. Having multiple systems to piece together required we’d keep our work structured and kept the communication up.

Tackling the problems with the interaction systems led to me reading up more on physics inside of games and I learned to be mindful of execution order and the importance of testing.

As we had good communication within the programming team I had the opportunity to talk through most of my issues and findings making many of the tasks at hand a fun process of learning.

Simplification of our solution for issues with physics objects inside the car while it was moving.

camera and audio

During development the game had support for camera switching used for specific views like looking back or raising the camera up while grabbing the steering wheel. This functionality was left unused in the final build in benefit for a simpler, one camera setup as asked for by the designers.

I created a basic Audio-manager with references found online giving the designers and easy time to add and replace audio where needed and also helped the designers with sound design and in engine implementation.

takeaways

To not shy away from asking for help and be honest with what work you think you'll be able to do is some of the takeaways I took with me from this project. The project was overscoped for the resources we had wich led to some frustration and misscommunication within the team as a whole. The fact that I maintained good communication with the team and tried to have fun with the ones I worked closest with made it easier to deal with stress and enabled me to ask for help even in tense periods of the project.

Codewise i learned more about interactions and physics in games and importantly, to try to not overthink and over engineer my solutions. That i spent alot of time creating functionality that we ended up not using in the final game, as with the camera system, also feels like a valuable experience in regards of not getting to attached to the work done as the process of making games tend to lead to alot of pivots and changes of direction.

Top