Anno 1800 is the seventh installment of Ubisoft Blue Byte's strategy/simulation series "Anno".
From starting as an intern, now as an intermediate, I am taking part in it, working mostly on
unit movement, military and crowd simulation.
Anno 1800 is a city builder/economy simulation game set in the victorian era.
Island by island, players can build up settlements, economic chains and form an economic empire.
This gameplay is accompanied by opposing parties, bringing trade, diplomacy and military action into the mix.
03/18 - 08/18 | Gameplay Programmer Intern
09/18 - 03/19 | Junior Gameplay Programmer
04/19 - 09/20 | Working Student: Gameplay Programmer
01/21 - 09/21 | Junior Gameplay Programmer
since 10/21 | Intermediate Gameplay Programmer
Features I worked on
Unit Movement + Collision Avoidance
Other noteworthy work
Onboarding new team members
C#, LUA, MySQL, 2019 - 2021
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.
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.
Additionally, I managed a team of four using JIRA and Confluence.
Plokoth is built in an iterated version of Mission:EOS's custom engine-in-engine solution.
The main idea behind it is that only few managers and the player are represented using Unity's monobehaviours.
These managers then tick their objects, which are mostly plain old data structs.
This approach allows the use of Unity as a fast prototyping tool with scene graph and rendering capabilities, while also retaining more control over tick order, decoupling ticks from frames and an easy binary serialization of all data.
For systems such as the movement system, any Unity powered solution provided too little control, which was an important requirement for a fast paced plattformer.
Every game feature defines a scriptable object containing all configuration needed for the feature.
Via an asset manager, it's possible to access the configuration for a given feature, as demonstrated in the graphic.
The main benefit over configuring inside Unity's monobehaviours is that all data is - separated by feature - in one place and every place in code can easily access it without the need of an instance.
This also allowed to only load the features and levels that are currently needed, making the game run smoothly even on the Nintendo Switch.
The engine in engine approach also supports a custom debug drawing system that allows for fire-and-forget calls like DebugInterface.DrawArrow(origin, direction, colour, numberOfFrames).
This is especially useful for debugging spatial code dealing with vectors and angles, which is where logging does not really help anymore.
Another engine feature is scripting support for LUA. I can tag any static function with a C# 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.
The core principle of Plokoth was to be a fast and fluid game with a low iteration time.
As movement is the absolute core of the game, we offer a variety of options...
Movement on slopes
Jumping in different heights (via longer or shorter button presses)
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.
The parallax 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.
Based on calculated bounding boxes for each little level in the game, it is possible to determine the bounds of the parallax planes.
Finally, based on the player position it is then possible to determine the scroll of each parallax layer.
Plokoth needed a camera system that could handle fast player movement, vertical & horizontal movement, zooming and camera anchor zones (= the camera needs to show a special part of the screen as long as the player does not leave the zone).
This is solved using 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.
Aurora is a visualisation system made for the looking glass.
It is able to render 4-dimensional signed distance fields using projection onto the autostereoscopic display.
While doing that, it incorporates lights, shadows and surface texture using a novell rendering algorithm.
For my bachelor's thesis, I investigated how shading and texturing of 4D structures could be implemented in a renderer.
The goal was to test the impact of these spatial vision cues on the understanding of the perceived 4D structures.
Rendering for an autostereoscopic 3D Display
The display I used was the Looking Glass.
To achieve a 3D image that can be seen from multiple angles, I needed to render the scene from multiple viewpoints, mimicking the spots the observers can stand in.
From that, I could create a big texture and pass it to the looking glass API, which makes a dithered result image from the big texture.
Depending on the view angle, differently ionised glass panes in the display will redirect your view so that you only see the right parts of the dithered texture to create a holographic effect.
Rendering a 4D structure
4D structures are represented with signed distance fields.
Existing approaches took just one slice of a 4D structure and rendered that in 3D.
As the idea was to determine the ability to perceive a 4D structure in total, I wanted to project the 4D sturcture onto the 3D display, with only one "compressed" dimension.
To achieve this, I still needed to create multiple 2D images from different view points from the 4D scene.
This is achieved by a modified version of raymarching, but instead of travelling along a ray, we travel along a plane (biray).
Each pixel from the resulting image sends one biray, so it covers two dimensions worth of data.
This approach was chosen over using two projection matrices as raymarching allows for the light and shadow calculation needed for the thesis.
Performance with CUDA
In the end, I needed to render a scene 45 times per frame, from 45 different angles, all while using the new and more expensive biraymarching algorithm.
To still achieve an interactive application, I used CUDA for the rendering algorithm.
This caused a speedup of ~500% over the previous software thread approach.
For interested readers
More detailed information can be found in my bachelor's thesis.
Feel free to contact me in case you want to read it :)
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, the company behind the mars settlement)
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
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.
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.
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.
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.
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
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
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.
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.
Team and Project Leader
Story & Gamedesign
VFX / Shader / Image Effects
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.
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 -> foo.bar" 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.
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).
Genre: Narrative First Person Puzzle Adventure Playtime: 30 Minutes Engine: Unity Produced: Q4 2017 - Q1 2018, 3 months
A 3D game inspired by The Binding Of Isaac made to accompany a custom written game engine.
Real Time Lights & Shadows
With this project, I went to learn how classic forward rendering shadowmapping works.
For this, I implemented cubemap based point-light shadow maps and object instancing to support ~16 active point lights without big performance drops.
Entity Component System
Another focus of this project was to implement my own entity component system once to learn about it.
The engine features its own smaller scale version of such an ecs.
A more in-depth description of the project can be found here.
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.
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.
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.
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)
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.