profile_space.png
“Hi, my name is Stefan and I’m a senior game programmer based in Stockholm, Sweden, focusing mostly on gameplay, tools and shaders.

You can find all of my work samples here, there’s a CV page for all that serious stuff and an About page if you want to know more about me.

Welcome!”
— Stefan Andersson

Releases

 

GORN 2

GORN 2 is an extremely violent (and funny) gladiator game in VR, and the sequel to one of the best-selling VR games of all time. This was an absolute dream project to work on and I learned so, so much about reactive programming, dependency injection, physics and more! It also has mod support!

Unique Kills Crowdpleaser

Ranged Weapons

One of my biggest responsibilities during the project was ranged weapons; essentially, write a re-usable and easily moddable ProjectileLauncher script, implement a Bow and Arrows and teach our Rokibes to use them. Later on, I was also tasked with implementing a Nailgun and a Bazooka using the same system.
Work Samples: GORN 2, Ranged Weapons
Bow and Arrows
Bow and Arrows

To stay true to the original GORN, I played around with its Bow a lot before-hand and tried to copy it in most ways and you can see me exploring the functionalities in the .gif:

- The bow uses the Z-axis rotation of one hand, and the direction to the other hand for the X- and Y-axes for its own rotation

- The bow spawns with arrows attached to the frame

- The player can remove and replace the attached arrows

- Pulling the string changes the strength of the shot

- Not pulling the string far enough cancels the shot

- Arrows can be retrieved from the environment

- Arrows can also be used as stabbing weapons

- Arrows can even be used as throwing weapons!

- The bow can also function as a bludgeoning weapon, if you’re out-of-ammo

Rokibes
Rokibes

Getting physically-based NPCs to hit the player with a physically-based ranged weapon may have been one of the greatest challenges of my career! Thankfully, this being a comedic game, it didn’t matter if they did it well or with any grace. My goal was simply to get the accuracy above 50% - which would likely be too deadly for the player - and scale it down from there.

I combined several techniques to achieve this:

- I manipulate the angle at which the Rokibe will face his target to adjust his foot placement

- I added an IK target that allows me to control the rotation of the torso, for smaller adjustments

- I added a second IK target that pulls the left hand towards a line drawn from the right hand to the target

- I added delays to the AI behavior to give the Rokibe time for any wobbling to settle down a bit

- Finally, I added an auto-aim system that takes the actual firing vector, checks if it’s pointed in the general direction of the target, and if so, moves the vector even closer.

And, it worked, for stationary targets at least! During gameplay, the Archers can be extremely deadly and so encourage the player to keep moving and often hit their buddies by accident, which causes them to fight amongst themselves. They’re great!

In the .gif you can see part of the aiming process. The yellow line is the direction to the player, the blue line is the non-adjusted forward vector of the arrow and the green line is the final auto-aimed vector; the direction the arrow will actually travel in.

In Gorn 2, we occasionally have optional challenges - called Crowdpleasers - that the player can complete to earn a reward, and during one of the last fights of the game, it was decided that the Crowdpleaser would require the player to kill 15 enemies with 15 different weapons; a sort of walk down memory lane, if you will. This posed an interesting challenge, because as I quickly found out, this is a lot harder than it sounds in a physics-based environment.

We had a system in place that I had developed earlier called DamageContext, which would allow us to glean information about a damage event:
  • A weapon has an attached DamageContext component and things the DamageContext needs to be aware of:
    • Colliders (even a regular collider, like the handle, can cause impact damage)
    • Damage-causing components (like Piercing, used for arrowheads)
  • When a body part impacts a collider, we check if the collider is associated with a DamageContext
  • The body part may also receive damage events from components like Piercing, and these carry a refernce to the DamageContext
  • The body part can then retrieve information from DamageContext like, “is the weapon this is attached to held by anyone, or was it recently held by anyone?”
  • The weapon itself can also listen to its DamageContext to receive information about the damage events it was involved in, like “did I manage to kill anyone?”
My starting point was here then, creating a script that could listen to OnKill events and use DamageContext to figure out if the player was holding the weapon. Except, when I tested it the accuracy was terrible - unusable, even! It turned out that when the player strikes an enemy, it’s often just as likely that what actually kills them is the enemy hitting their head against the wall, poking themselves with their own sword, falling off a platform or suffering any of a myriad of other horrible fates. The solution then, is not to try to figure out if the player is technically responsible, but whether or not they're liable to *think* they're techincally responsible!

I created a system called DeathBlameHandler that kept a history of recent damage events; instead of directly telling DamageContext it scored a kill, when an enemy dies, the system goes through the history to check if any of the recent events were associated with the player, and if so, uses that as the death-causing event and reports it to that events associated DamageContext!

This worked great, as you can see in the video! When I kill someone using a new weapon, a new box is ticked on the wall, but when I re-use a weapon, it does not. There are times when it feels a bit too generous, but I would rather the player feel they were treated unfairly in the positive sense than the negative.

UNREAL

As part of an online course in Unreal Engine 5 (C++), we made this third-person shooter game. The assets and the scene itself was made by someone at Epic, but as part of the course I set up the animations, created a basic combat system, win/lose state, AI and more. After completing the course, I added some additional features to the project, which you can see below.

Patrol System

The first thing I wanted to add was a patrol system for NPCs to use when not going after the player. Of course, in this video the AI has been modified to ignore the player.

I did this by creating a PatrolPath blueprint that uses a USplineComponent to define the path. I then created a Patrol node to use in the AI behavior tree, which is assigned a PatrolPath Actor; if the NPC is too far off the path, the AI will pathfind to the closest point on the Spline; if the NPC is on the path, the AI will pathfind to a point slightly further ahead on the Spline.

Investigation System

I also wanted to add an investigation system the NPCs can use after losing track of the player, before they return to their original patrol.

Having the NPCs pathfind randomly didn't look natural at all, so I created an Actor called InvestigationPoint that I could hand-place throughout the scene. Each InvestigationPoint can contain references to other InvestigationPoints, so when an NPC loses sight of the player for too long, it takes the last known player position, pathfinds and moves to the closest InvestigationPoint, waits, then proceeds to a random unvisited InvestigationPoint referenced by the last one. If no references exist, it picks the closest unvisited one. This worked a lot better!

UNTITLED PROJECT

This is my private project that I worked on in my spare-time for a few years. The original goal was to make a space-station simulation game, and I wanted the player to be able to create an indoor environment with as few restrictions as possible (while still keeping it as a normal, uniform grid for my own sanity’s sake).

In the end, I didn’t get to the other parts of the game and had to make a lot of compromises, but I think the result - while not completely finished - still turned out pretty nice. I’ve written some stuff about the more interesting features below.

Work Samples: Untitled Project (Gallery)
Building Tool
Building Tool

Internally, the grid is constructed using a simple one-dimensional array, with each element representing one corner of a grid tile.

Externally, a large mesh is generated and every tile on the grid is given five vertices; four corners and one center.

A spritesheet is used as the texture for the mesh and the UVs of each tile are changed in runtime The center UV is only used to help smooth out the lighting.

The build tool snaps to the internal grid - so, the corners of the rendered tiles - and changes the UVs of the mesh in the selected location, thus changing the part of the sprite sheet that is displayed to the user.

The build tool also supports adding doors and airlocks to existing walls, and these will also animate when a character wants to pass through.

Originally, there was support for diagonal walls as well, but as I learned the hard way, there’s a reason most grid-based games don’t attempt diagonal walls. Removing this feature greatly simplified the code base!

Coloring Tool
Coloring Tool

The painting tool allows the player to create a custom color scheme for tiles to use, then apply it to whatever tiles they choose.

A texture based on the main spritesheet is used to define the cardinal directions (and special components) of the displayed environment. The user can pick 1/128 colors per direction and special components and when paint is applied, the color indices are sent to the GPU via the tile UVs. The frag shader then checks the texture and applies the appropriate color for the appropriate part of the sprite.

Lighting Tool
Lighting Tool

The lighting system allows the player to place colored lights on the grid. 

Like the other tools, the lighting system simply deposits a color and brightness value onto the tiles of the grid mesh and the shader decodes the information to render it nicely. To get the light to move around corners nicely, I simply use A* pathfinding from the light source to every tile in its range and base the brightness value off the distance of the found path.

Fluid Simulation

What started out as part of another project later just ended up becoming a fun exercise in compute shaders and multi-threading! I found an old implementation of smooth-particle hydrodynamics in Java which I rewrote to C#, then converted to HLSL after learning how to use compute shaders.

Below you can see some of my progress; from a basic implementation with a pseudo-temperature system, to a much larger scale simulation, to a final version with support for solids.

Work Samples: Fluid Simulation (Gallery)
The Basics
The Basics

While I got some help with the basics, I had to create my own temperature system. Temperature here is simply a float value passed from particle to particle that affects their behavior, allowing them to emulate solids, liquids and gasses.

The biggest annoyance working with SPH is that particles often tend to collapse into each other when the pressure gets too high, which meant I had to spend a lot of time tweaking settings just to try to avoid it, but never being able to solve it completely.

Optimizations
Optimizations

After making some serious optimizations, I was able to have huge amounts of particles. In this gif, I’ve simulated 131.072 particles at around 100FPS; at most I managed to push it to 262.144 particles at 60 FPS, but unfortunately Unity appeared to freeze if I increased the size of the grid any further.

Note that these .GIFs have been sped up a fair bit; To get good precision and avoid total collapse, a particle can only move a small distance per frame, which slows down the whole simulation even with good FPS, and I didn’t manage to find a good solution to this problem.

Final Result
Final Result

This is the final result and where I decided to stop. On the left is a block of ice and on the right is lukewarm water.

For this final version, I decided to render the bins that particles are grouped into for optimization purposes and use the amount per bin as the alpha, rather than rendering the particles directly. This reduces the apparent amount of particles on-screen as one bin can contain up to 16 particles, but it greatly improves the visuals at a lower cost than something like metaballs.

Lootbox Worktest

This was for a worktest I did for a position as a Tech Artist. The assignment was to create a scene where a lootbox appears, the player opens it, is presented with the contents and then you can choose to reload the scene. Preferably with some unique setting, so, I chose space!

Work Samples: Lootbox Worktest (Gallery)
Sequence
Sequence

Here is the whole lootbox sequence from start to finish.


I wanted to focus on the animations, shaders and particles, so most of the assets are just random images found online that I’ve modified to fit the style better.
There are three tiers of gems with varying rarity (though only two are visible here) and this also affects the particles as they slam into the ground.

Transition Shader
Transition Shader

Here’s me triggering the reload transition a couple of times in a row.

When the sequence is reloaded, a grabpass is taken of the whole screen and everything in the scene is reset to its initial state. Using a meteor-texture with a baked-in gradient, I check whether each pixel on the screen should be inside or outside a falling meteor; if inside, the gradient and a random color is applied; if outside, the grabpass is applied.