C++, 2018 - 2020

Anno 1800

Anno 1800 is the seventh part of Ubisoft Blue Byte's strategy/simulation series "Anno".
As an intern, junior and working student, I took part in it, working mostly on
unit movement, military and feedback units.



Welcome to the dawn of the industrial age.
The path you choose will define your world.
Are you renovator or exploiter? Suppressor or liberator?
It's up to you how the world will remember your name.

In Anno 1800, players will take charge of their own fortune as they navigate the rapidly evolving technological and malicious political landscape of the 19th century in their quest to build an empire that will stand the test of time.

Combining beloved features with innovative gameplay in a memorable new setting, Anno 1800 marks the beginning of a new era for the Anno franchise.


My Roles

  • 03/18 - 08/18 | Gameplay Programmer Intern
  • 09/18 - 03/19 | Junior Gameplay Programmer
  • 04/19 - now | Working Student: Gameplay Programmer

Features I worked on

Due to NDA, I can not go into more detail, but those are the features I worked on:

  • Unit Movement
  • Unit Collision Avoidance
  • Unit AI / Military Movement
  • Feedback Unit Behaviour
  • Unit Multiplayer Synchronization
Windows Nintendo Switch
C#, LUA, MySQL, 2019 - 2020


A fast-paced, atmospheric 2D plattforming game set in a mysterious jungle.
Destroy the disease that infected it by making your way to the heart of the forest.



An ape-like creature goes on a journey to destroy the core of a horrible disease which infected his girlfriend who joins him in the form of a ghost.
Plokoth is an atmospheric 2D platforming game for Windows and Nintendo Switch and plays in a mysterious jungle.



As the teams only programmer, I was responsible for everything code-wise.

Game Designer

Also, I was the only game designer in the team, so I took care of everything from game design to level design to user testing.

Project Manager

Additionally, I managed a team of four using JIRA and Confluence.

Programming Contributions


Plokoth is built in an iterated version of Mission:EOS's custom engine-in-engine solution.
I decided to got with this solution for the following reasons:

Many features of Unity are great for prototyping, for instance the scene graph and its easy rendering capabilities.
On the flip side, some of its systems are not suited for situations where you want to be able to control every single bit of information like in a movement system.
A Unity-physics based approach would yield too unpredictable results here.
As well as that, there are a lot of performance issues with Unity Callbacks such as those that MonoBehaviours react to.
My approach here is to use only few of those and instead create a manager structure that ticks all objects it needs to tick, and can decide on its own when which objects need to be updated.
Not only brings this performance benefits, it also offers more control over timing between different systems and makes managers a true source of truth.
This manager structure also allows to easily implement binary serialization, as every manager gets a serialize call and can propagate it to all its members.

Asset Management
For asset management, I went with a custom solution where every game feature has a scriptable object in which it can define all data that it needs.
Via the asset manager, it is easy to load and unload asset bundles including these scriptable objects and to access the data for a certain feature.
See the graphic for a small overview of how the camera manager retrieves the data for the camera feature to move the camera correctly.
The big benefit of a system like this is that it is easily extendable, has all important data in one place and allows every system to access all data for every feature. As well as that, it is also easy to only load the features and levels that are currently needed, allowing the game to run smoothly even on the Nintendo Switch.

Debug Drawing
The engine in engine approach also supports a custom debug drawing system that allows for one-line-fire-and-forget calls like DebugDrawingInterface.DrawArrow(origin, direction, colour, numberOfFrames). This is especially useful for debugging systems that work a lot with vectors and radians-angles that are not easily imaginable when only logged.

Another engine feature is scripting support for LUA. I can tag any static function with an [ExposeToLUA] attribute and access that function via runtime LUA-code, allowing me to use it for cheats, alternative configurations and faster debugging times. In theory, it would even be suited to programme some logic, for instance, the movement logic, inside it, during runtime, without having to restart.

Movement System

The core principle of Plokoth was to be a fast and fluid game with a low iteration time.
This of course also affected pretty much all systems, including the movement system.

As movement is the core mechanic of the game, Plokoth features a variety of options for the player.
The system I created features ...

  • Movement on slopes
  • Jumping in different heights (via longer or shorter button presses)
  • Wall-Jumping
  • 8-Directional dashing
  • Wave Dashing
  • A lot of ways to reset your dash cooldown
  • Some smaller mechanics aimed at speedrunning

Dynamic Scene Management

To allow the player to perform continuous gameplay without loading screens
Plokoth features a dynamic loading system that loads new levels asynchronously.

Parallax System

For nicer visuals, Plokoth features a parallax system.
The system features a freely configurable, artist-friendly way to add a variable amount of parallax sprites.
For each sprite, the artist can define how much world space it should use up, compared to either the camera size or the area size.
All sprites automatically are scaled to fit the defined space in y-Direction and tile in x-Direction.
Technically, I automatically calculate bounding boxes for each level in the game.
Then, for each area, I can calculate another bounding box which then gets mapped to a progress value ranging from 0 to 1.
Using that value, the system can decide how scrolled each parallax layer should be.

Camera System

I also needed to create a camera system that could handle fast player movement, vertical & horizontal movement, zooming and camera anchor zones where the camera needs to show a special part of the screen as long as the player does not leave them.

I accomplished those design goals by a multitude of things, through many iterations.

The final result works a bit like this:

There is a rectangle in the middle of the screen.

The camera will always move to fit the focus point (black box at the left of the player) to be inside the rectangle. The only restriction here are colliders inside the ground of a level, that ensure that the camera does not show too much from under the level.

The focus point moves with the player but predicts player movement based on previous player movement. This allows the player to see more in the direction that they are actively moving in.

Project Specs

Genre: 2D Hardcore Plattformer
Playtime: 45 Minutes
Engine: Unity/Own Engine Mixture
Produced: Q4 2019 - Q1 2020, 3 months

C#, 2019

Mission: EOS

Mission: EOS is a strategy programming game.
To colonize mars, you must assemble and program your own mars rovers
to prepare human arrival.



In this game, you are challenged to build the foundation for the first human colony on Mars.
To achieve this, you have to assemble rovers out of a pool of different modules and program them to gather resources, build new infrastructure and more.

“ The time has come to make our stand on mars and guide humanity to a new age.
A first rover workshop has been established and you are the one in control.
Expand your network and tackle complex job chains with your customized rover squad. ”

- Tobi Stork (Head of Stork Enterprises)



My Roles

  • Lead Developer of a team of 3 programmers
  • Project Manager of a team of 5
  • Additional Game Designer



Mission: EOS is built upon a custom game engine that is mostly separated from Unity.
Due to the games focus around data, I created a system that is able to

  • Tick objects in the right order
  • Serialize everything
  • Build custom, procedural UIs
  • Be balanced at runtime with the help of a all-in-one-place asset management system
  • Render custom minimaps
  • Render custom debug drawings
More information on this custom Engine-In-Engine solution can be found at page of Plokoth, where I used an iteration of this approach.

Procedural Rover Assembly

All mars rovers that can be built in Mission: EOS can be built up from procedural parts.
The player can choose from different rover-cores, wheels/legs/thrusters/etc, and a variety of different modules.

Inside the rover workshop

Procedural Rover Programming

Once assembled, the player has to program their newly created rover.
To accomplish this, they has to line up commands the rover will execute.
These commands are tied to the modules used during assembly, which creates a back-and-forth gameplay
where the player tries to create the most optimal mars rover for the current needed task, for instance exploring for new resource fields on a rough surface.

Procedural UI

For both the rover assembly as well as the rover programming, a fully procedural UI had to be made.
Together with our UI Designer/Programmer, I planned the system and created the data-oriented part of it
as well as an interface for the UI Designer to fill my technical UI system with data.

Minimap System

The game features a custom made minimap that needed...

  • ... to be clickable
  • ... to be displayed at various positions and scales
  • ... to display many custom dynamic objects, including icons and lines
  • ... zoom and pan-able
To achieve all of those, I created a minimap system that works with many space-conversions to allow to convert positions from
World-Space to Minimap-Space to UI-Space to Screen Space and vice versa.

Project Specs

Genre: Programming Strategy Game
Playtime: 90 Minutes
Engine: Unity/Own Engine Mixture
Produced: Q2 2019 - Q3 2019, 3 months

Windows macOS
C#, 2017

Under The Light

A puzzle adventure game in which you have to escape a cavern using lightbridges and reversing gravity.
The project was created in 3 months as a second semesters project by a team of 8 lead by me.
My focus was the games programming with its unique mechanics involving a lot of vector, matrix & quaternion maths.



My Roles

  • Team and Project Leader of a team of 8
  • Programmer
  • Co-Game and Level-Design together with Leon Arndt
  • Visual Effects

Noteworthy Mechanics

The Lightbridge

The Lightbridge being built between 2 mirrors

The Lightbridge is the games main mechanic used to solve puzzles.
It can be created by marking (next to) any two points in a room.

Technically, it had to meet several requirements, making it quite a challenge:

  • Varying amount of segments due to reflective surfaces
  • Hexagonal profile
  • No intersection with level geometry
  • Cant be too steep
  • Needs correct UVs
To accomplish the final result, I had to learn a lot about procedural geometry.

The Gravity Boots

The gravity switch

The Gravity Boots are the secondary game mechanic used to solve puzzles.
Using the boots, the player gains the ability to walk on some ceilings.
Boots and Lightbridge may be combined for puzzle solving.

The implementation required a custom anti-gravity walking algorithm with reversed collision detection as well as
both a first and third-person camera to fade between during the backflip/gravity reverse animation.

Shaders and Lighting

Some of my animated shaders in the game

The Shaders and VFX I did for this project include:

  • Lightbridge wind-up and animation
  • Different types of crystals that react to player proximity
  • "Barrier" around death crystals
  • Spawn animation for green crystals

Cinematic Camera

From an level design perspective, some levels needed a hint on where to go, so we implemented a cinematic camera system capable of
interpolating the current view quaternion to a custom camera setup, allowing for a "black-bar cinematic camera" during cut scenes and upon entering some levels.

Lorman AI and Game Design

The project features a NPC AI for the sidekick Lorman which is able to follow the player, waypoints and can speak using a custom dialogue system that handles timing, sound and subtitles.

Another part of my work on this project is the game and level design for some levels.

Project Specs

Genre: First-Person Puzzle Adventure
Playtime: 30 Minutes
Engine: Unity
Produced: Q2 2017 - Q3 2017, 3 months

Windows macOS
C#, 2017-2018

A Watch Into The Past

A narrative first person adventure game set in the early 20th century in rural england.
Your goal is to solve a crime using a occult watch able to bend time!
My main focus point in this project was understanding the realtime graphics pipeline!



A Watch Into The Past is a story-driven game with an emphasis on an immersive setting around a rural village in England.
The game was created by a team of 4 as a student project over a time span of approximately 3 months, from October 2017 to February 2018.



My Roles

  • Team and Project Leader
  • Programmer
  • Story & Gamedesign
  • VFX / Shader / Image Effects

Noteworthy Mechanics

The Time Shift

The Time Shift is the games main mechanic used to solve puzzles.
It allows the player to visit a location in several times in the past to find out more about what once happened.

The technical difficulty implementing such a mechanic existed of mainly 2 parts. At first, I had to create a deterministic state system for all objects that are able to to be changed or appear in multiple timelines that also takes care of showing each object always in its current state tied to the current time.
So make sure, everything could be recreated by e.g. a save/load system, all inputs to such a interaction/state system had to com from a generic interaction system that had to cover all types of interactions such as clicking on objects, moving into trigger zones, time travelling at certain points in the world, picking up objects, using objects, moving objects or even playing animations, sound effects, particle effects, setting other object states.

Secondly, I was also responsible for the visual appearance of the time shift as well as the past memories the player can live through.
Starting with the time transition, I created an image effect that is able to blend between two different versions of the scenery using a custom grey-scale blend mask while also providing some radial blur and flowing distortion.
For the visions of characters, I went with rendering them onto a different render target and then applying screen space wobbly distortion while also using a custom ghost shader to make sure it looks like the visions are not "stable" and that the player is just "bending" the time and not really living in it.

The Dialogues

As the semester's theme was story-driven gameplay, our team decided to go the full story route.
Even though it is not the type of game I generally play, it was a great experience creating a somewhat believable story that can take about 30 minutes to an hour to completely live through with interesting characters and an immersive setting.

Of course, such a game tends to introduce a lot of dialogue. To make sure everybody in the team could contribute to creating & implementing dialogue I wrote a Dialogue System making it easy for my teammates, to time, subtitle and balance new dialogues in the game as well as adding them via a simple "Add Interaction -> Play Dialogue ->" button to intractable objects.

The Players Notebook

In the game, the player holds a fully animated notebook with which he can interact via clicking.
As the rig for the book was created for only two double pages that can be flipped from and two but the game needed at least 4 double pages I created a system to swap out the pages in realtime while flipping them. The System uses a second canvas outside of the player's screen where the currently active notebook double page is being rendered into a texture by a custom camera, which then is used as a texture for the notebook.
Every time a page is flipped the canvas changes its content to the next double page and the last open page will be copied into a back buffer to make for smooth page flipping.

Next thing to solve was that the player still had to be able to click the canvas elements such as buttons or even input fields to write into the notebook.
I accomplished this by casting rays onto the notebook and tracking at which UV coordinate they hit. Then I transformed the hit UV coordinate onto the off-screen canvas and simulated the mouse clicking at this exact position.

All in all, having a real 3D-notebook in the game took more development time than it should have, but still brought a good learning effect with it.

Animation Splines

Building on the Spline tool from previous projects such as Fish Firework, I added the ability to give my spline points a world rotation.
This, in combination with the Time Line Editor I wrote, allowed my splines to be used with timed keyframes to move objects such as a carriage or even cameras in tracking shots along the spline in a nice and smooth way, making it the tool to fulfil a lot of animation jobs even unity's timeline tool could not have done for our game keeping in mind that we had a lot of special needs as we were rendering with about 2 to 4 cameras at the same time (present/past/past objects/notebook UI).

Project Specs

Genre: Narrative First Person Puzzle Adventure
Playtime: 30 Minutes
Engine: Unity
Produced: Q4 2017 - Q1 2018, 3 months

C++/OpenGL/GLSL, 2017-2018

Project "Ranogue"

OpenGL based 3D game engine



A 3D game inspired by The Binding Of Isaac made to accompany a custom written game engine.
This project was used to learn more about real time lighting and shadowmapping as well as the
A broader description of the project can be found here.

C#, 2017

Fish Firework

A networked two person bullet hell game in which you shoot the crap out of enemy fish.
It was created as a homework on the topic of networking over the span of 4 weeks.
My main focus points were networked object pooling, bezier curves as waypoints and a multiplicative power up system.


Noteworthy Features

The Networking

Fish Firework is a real-time networked game featuring an internet-ready multiplayer.

As the game is a bullet-hell game, it naturally generates a lot of bullets on the screen.
To improve performance and allow for more expensive power ups, the game uses networked object pooling.

Use of Bezier Curves

Bezier curves in editor view

To make camera pans more smooth, fish firework uses a custom written bezier curve system.

Bezier curves generate a lot smoother camera motions than linear or sine interpolations I used in earlier projects.
After a some research, Fish Firework features a system to create and modify bezier curves in Unity Editor View which then can be used by cameras, waypoint systems and more.

Multiplicative Power Ups

Shooting after some power ups!

Fish Firework features a multiplicative power up system.
Picking up a three-shot and for-shot power up results in 12-shot in total.

Even when it may sounds simple, creating a multiplicative power up system (eg. Binding Of Isaac) is not as straight forward as it seems.
Some thoughtful class construction and the right delegates need to be optimized for all categories of power ups.

General Information

The game was created in a timespan of 4 weeks mostly by myself.
It was a student project for second semester game development class with the main focus on networking.

C#, 2016

Years Of The Settlers

A simulation game inspired by old anno / settlers games.
Created in 4 days during university freestyle "week".
Features perlin-noise random world generation & fog of war.


About The Game

Goal of the game is to set up a stable population by unlocking multiple buildings such as mines, farms and houses in which people can work for money and produce food and resources.
The first try on creating an old idea inside Unity (see Let's Build 5)

Noteworthy Mechanics

Random World Generation

Years of the Settlers features a randomly generated world

The project uses Perlin Noise to create a variety of maps to play on to make sure there is always a new challenge for the player.

Minimap & Fog of War

A clickable minimap covered by fog until the player builds a building with a "view" component.

Using a bitmap that is influenced by view components of buildings, the game features a simple fog of war system.
Underneath the fog lies a miniature map to help navigate that is made up of the average color of each field.