+ My primary interests are game programming and player interaction.
+ I like learning about algorithms and design patterns.
+ As well as about how to get players invested and excited.
+ In my free time I like making games from scratch, or in custom engines.
+ When it comes to third party engines I'm most experienced with the Unreal and
+ Godot game engines. For personal projects I mainly work with SDL2, though sometimes I use SFML as well.
+
+
+
+
+
+
Experience
+
+
+
Galaxy Grove
+
C++ Intern
+
January 2023 - July 2023
+
+
+
Grafisch Lyceum Utrecht
+
Game Programming Student
+
September 2021 - Now
+
+
+
Appalot
+
Junior API and automation developer
+
September 2021 - Now
+
+
+
Appalot(internship)
+
API and automation intern
+
June 2021 - August 2021
+
+
+
Hobby Programmer
+
Chief Experimentor
+
2016 - forever
+
+
+
+
Natural Languages
+
+
+
Dutch
+
Native Speaker
+
+
+
English
+
Fluent
+
+
+
+
Formal Languages
+
+
+
C++ | Advanced
+
+ Frameworks:
+ std/stl, sfml, Unreal Engine
+
+
+
+
C | Advanced
+
+ Frameworks:
+ SDL2
+
+
+
+
C# | Advanced
+
+ Frameworks:
+ .NET, Google Cloud Functions, Unity
+
+ My second implementation of a boids simulation. This time written in C using a combination of SDL2 for rendering and a self-made ecs library for object management.
+ The program includes a ui window which allows users to modify the settings of the boids at runtime.
+
+
Project Overview
+
+ This was made as a stress test of a pure C entity-component-system library I was building for myself.
+ During the development of the boid simulation i managed to improve the ECS it was build around by multithreading it. As well as improving lookup times through binary search.
+ Both of which are rather rudimentary improvements i wanted to make, but the stress test not only made it more obvious they were needed, but also made it much more measurable when they worked.
+
+
+
Modules
+
+
+ The program is split into a set of distinct submodules. The ecs, adb, ui, engine and sim modules.
+ Of these modules the adb and ecs modules are entirely standalone, the ui module depends only on SDL2, the engine is dependent on all others except sim, and sim is dependent on engine.
+
+
+
+
Code
+
+ NOTE: Most of these modules were developed separately and as standalone libraries. As such, they have vastly differing naming conventions.
+ Still, each module is internally consistent about its own naming scheme. I just tend to switch style every project.
+ For clarity, the ecs and ui modules use camelCase while the adb, engine and sim modules all use snake_case.
+
+
+
Engine
+
+ The engine module provides the program's entry point and update/render/event loops. It communicates with the sim by declaring three functions as extern without defining them. The sim then defines them allowing the engine to call functions from the sim.
+ The functions in question are:
+
+
sim_config, which allows the sim to configure important parts of the engine by adjusting a settings struct.
+
sim_init this is called after all other modules are initialized and allows the sim to initialize its components, systems and entities, as well as load assets.
+
sim_quit which gives the simulation the chance to clean up any allocated resources after the main loop ends but before the other modules are terminated.
+
+
+
+
+
+
+
Sim
+
+ The sim module is the only module that actually interacts with anything boid-specific. Whereas the other modules are more so supporting of the simulation.
+ The sim can be divided further into the part that interacts with the engine module, and the part that actually models and simulates the boids.
+ The part that interacts with the engine is responsible for registering components and systems with the ecs, loading assets, and spawning the boids.
+
+
+
+
+
+ The second part of the sim module are the functions that make the boids behave the way they do. The ones that run as systems from the ecs all follow the signature of an ecs system function. They take in a list of entities, a list of the corresponding component masks, the number of items in both lists, and the delta time of the current frame. They then loop over the entities and perform specific actions for each one. In order to avoid looping over every boid in the simulation every frame, for every boid. The boids cache boids that are within the range of the behaviour with the furthest range.
+
+
+
+
+
+ When the boids that are close enough to interact have all been cached, the actually modifying systems start running. As a demonstration is the separation system, which keeps the boids apart from eachother to avoid all of them forming a singularity. For each boid, the system loops through all nearby boids, keeping a running average of the positions of each boid nearby enough to be within range. After all nearby boids have been accounted for, the boid's velocity is adjusted to move away from the calculated average.
+
+
+
+
+
+ Cohesion and alignment are similar enough that i wont place them here. Cohesion is the opposite of separation, and alignment is practically the same but with velocity instead of position.
+ The mouse does the same as cohesion but with the mouse, and thus without the need for an average. The wall behaviour pushes the boids back onto the screen when they exit it.
+
+
+
ECS
+
+ The entity-component-system (ecs) module manages the runtime object model where Entities are numbers, Components are blocks of memory attached to an entity and Systems are function pointers with a component requirement. This is the library that the boids where made to test.
+ The below code consists of snippets showing initialization and uses of components systems and entities.
+
+
+
+
+
+
Asset database
+
+ The asset database (adb) module is the module responsible for managing asset data. So it has functions for loading data from files, getting loaded file data, and releasing data after it is no longer needed. To keep this module generic, it has runtime defined rules for managing files through file handler functions.
+
+
+
+
+
UI
+
+ The ui module is based on the immediate mode graphical user interface (imgui) paradigm. This is a paradigm where there is no intermediate storage between the gui and the data. The gui directly modifies the data and vice versa.
+ In my implementation this is done by sending the gui functions pointers to the data they represent as parameters.
+
+
+
+
+
+
+
Boids (steering behaviours)
+
+
+
Info
+
+
Project type: C++ Simulation
+
Timeframe: 2022
+
+
+
Video
+
+
+
Product Overview
+
+ My first version of a boids simulation. Written in C++ with sfml.
+
+
+
Project Overview
+
+ I worked on this for about week inspired by the lessons on steering behaviours at school.
+
+
+
Code
+
+
+
Boid
+
+
+ The boids themselves are primarily a position, a velocity, a mass, and a collection of behaviour function pointers. These boids are then stored in a vector and each of the behaviours is run for each of the boids, resulting in the demonstrated movements.
+
+
+
+
+
+
+
Behaviours
+
+
+ As previously mentioned, the boids all store a collection of behaviours, represented by function pointers. These function pointers take as input a context object representing the program state at the start of the frame, and output a desired change in velocity. The original boids paper describes cohesion, separation, and alignment, so these are the main behaviours implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/sara.objectionable.solutions/projects/gml-tile-movement.html b/sara.objectionable.solutions/projects/gml-tile-movement.html
new file mode 100644
index 0000000..e3d2fed
--- /dev/null
+++ b/sara.objectionable.solutions/projects/gml-tile-movement.html
@@ -0,0 +1,67 @@
+
+
+
+ GML Tile Movement - Sara Gerretsen
+
+
+
+
+
+
+
+
+
+
+
+
Tile Movement
+
+
+
Info
+
+
Project Type: Gamemaker 2 Game
+
Timeframe: 2019
+
+
+
Video
+
+
+
Product Overview
+
+ One of my older projects. This is a prototype of a tile based movement system focused on getting smooth responsive movement with directional input.
+ Move around, defeat the enemies and move on to the next room. Made around 2019 or so.
+
+
+
Project Overview
+
+ Made on my own over a few days, main focus was on getting a smooth feeling tile based movement system in gamemaker, which was my engine of choice at the time.
+ After the movement was implemented I made some sprites, levels and a simple 'pathfinding' system that picks the unoccupied tile that is closest to the target.
+
+
+
Code
+
+
Try Move
+
+
+ The main challenge was allowing characters to move around without phasing into walls or eachother. The try-move
+ function is a generic solution to this problem.
+ It tests if the proposed movement would overlap with a non-walkable tile on the floor map. As well as testing if
+ any other character is trying to move to that position.
+
+
+
+
+
+
AI Movement
+
+ The AI in the game is a simple example of how the try move function could be used in context.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/sara.objectionable.solutions/projects/hlo-projectvtd.html b/sara.objectionable.solutions/projects/hlo-projectvtd.html
new file mode 100644
index 0000000..f008636
--- /dev/null
+++ b/sara.objectionable.solutions/projects/hlo-projectvtd.html
@@ -0,0 +1,82 @@
+
+
+
+
+ Project VTD - Sara Gerretsen
+
+
+
+
+
+
+
+
+
+
Tower VR
+
+
+
Info
+
+
Project Type: Unreal Engine VR Game
+
Project Timeframe: 2022
+
+
+
Video
+
+
+
+
Product Overview
+
+ A VR tower defence game where the player can fight enemies with their sword, or build towers by drawing patterns on a magic circle.
+
+
Project Overview
+
+ The game was made at a 'Hybride Leeromgeving' (Eng: Hybrid Learning Environment) or HLO. Which gives students the opportunity to work in an environment closer to that of a professional game company. The game was made with a team of five programmers and one artist.
+
+
Code
+
+
Tower Selection
+
+
+ One of the mechanics I was responsible for was the tower selection circles. The code calls them spell circles as they were initially supposed to cast spells.
+ Spell circles spawn a pattern of orbs with colliders, these orbs have their own logic to send a message to a 'spell map' contained within the spell circle.
+
+ spell circle - interface declaration
+
+
+
+ spell circle - implementation
+
+
+
+
+ These 'orbs' all know their own index within the spell circle's list of orbs. When an orb is hit, it sends its own index to the spell map component of the spell circle. This number is then converted to a string and appended to the spell map's pattern string. Because of the way the system works, only 1 digit indexes are used, though the code does not enforce this.
+ Whenever a new character is added, the spell map compares the formed string to a list of 'correct' patterns.
+ If the string produced after the last addition does not match a substring of the same length in a 'correct' pattern, the pattern is considered failed and the corresponding event is triggered.
+ When the string produced is equal to a 'correct' pattern, the event signalling a correct pattern is triggered.
+ Because a large part of the team prefered working with blueprints, a lot of the C++ architecture was designed with an eye on its blueprint interface. This lead to some odd decisions regarding the "success" event, as blueprints were unable to interact with the map of delegates to patterns that was used in the initial version of the spell map (hence the name).
+
+ spell map - interface declaration
+
+
+
+ spell circle - implementation
+
+
+
+ spell orb - interface declaration
+
+
+
+ spell orb - implementation
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/sara.objectionable.solutions/projects/ruins-of-edis.html b/sara.objectionable.solutions/projects/ruins-of-edis.html
new file mode 100644
index 0000000..cff5ca9
--- /dev/null
+++ b/sara.objectionable.solutions/projects/ruins-of-edis.html
@@ -0,0 +1,67 @@
+
+
+
+ Ruins of Edis - Sara Gerretsen
+
+
+
+
+
+
+
+
+
+
+
Ruins of Edis
+
+
+
Info
+
+
Project type: Unity Game
+
Timeframe: 2022
+
+
+
Video
+
+
+
Product Overview
+
+ A relaxing desert driving game about following a blue light around the ruins of a long lost civilization. Stay within the light or be lost to the desert.
+
+
+
Project Overview
+
+ For this project, I was a responsible for the car's controls and physics. I also helped with programming the terrain generation script.
+
+
+
Code
+
+
+
Controls
+
+
+ The drifting system uses a "force angle" which describes the angle relative to the forward direction in which the car should apply force.
+ This allows the direction while drifting to be changed to be somewhere to the side of the car for it to slide properly.
+
+
+
+
+
+
+
Terrain Generator
+
+
+ To make the terrain generation extensively configurable, we used a whole collection of stacked animation curves and multipliers.
+ These were then applied to the result of a perlin noise function to create a heightmap, which can then be applied to one or more terrain objects.
+
+
+
+
+
+
+
+
+
diff --git a/sara.objectionable.solutions/projects/spirit-of-science.html b/sara.objectionable.solutions/projects/spirit-of-science.html
new file mode 100644
index 0000000..22c1ecd
--- /dev/null
+++ b/sara.objectionable.solutions/projects/spirit-of-science.html
@@ -0,0 +1,73 @@
+
+
+
+ Spirit of Science - Sara Gerretsen
+
+
+
+
+
+
+
+
+
+
+
Spirit of Science
+
+
Info
+
+
Project Type: Unity Game for IEGJ
+
Timeframe: 2022
+
+
+
Video
+
+
+
+
Product Overview
+
+ A top down exploration game setting you to exploring an abandoned factory looking for tools and key-cards while avoiding the unexplained dangers around the place
+
+
+
Project Overview
+
+ This was made for the International Educational Game Jam with a team of three artists and two programmers. My role was mainly that of gameplay programmer. I wrote the interaction and movement systems, as well as a few interactions using those systems.
+
+
+
Code
+
+
Interaction
+
+
+ When the player clicks, clickable objects near the cursor should be notified that they've been activated. For this, I created an Interactible interface. This interface can then be inherited to clearly mark a component as clickable.
+
+
+
+
+
+
+
Clicking
+
+
+ The player interaction script triggers any IInteractible components within a radius around wherever the player has clicked.
+ It only does this after ensuring that the clicked object can be reached.
+
+ A fun, relaxing but still challenging, resource management puzzle game by Galaxy Grove. That I had the chance to work on for an internship of six months.
+ Being my first "job" working on a real production game, I learned a lot about developing a polished, final, product.
+ My main contributions were to the dynamic growth of the in-game cities in response to the player's success. I also wrote some internal tooling for generating ambient occlusion maps in bulk using Blender and python.
+ As well as the decorative birds' behaviour.
+
+
Steam
+
+
+
Announcement Trailer
+
+
+
+
\ No newline at end of file
diff --git a/sara.objectionable.solutions/projects/stig-kart.html b/sara.objectionable.solutions/projects/stig-kart.html
new file mode 100644
index 0000000..cbd851d
--- /dev/null
+++ b/sara.objectionable.solutions/projects/stig-kart.html
@@ -0,0 +1,88 @@
+
+
+
+ Stig Kart 64 - Sara Gerretsen
+
+
+
+
+
+
+
+
+
+
+
Stig Kart 64
+
+
+
Info
+
+
Project type: Unity Game
+
Timeframe: 2022
+
+
+
Video
+
+
+
+
Product Overview
+
+ A fast paced kart racer about timing your drifts and boosts just right. Play against your friends in splitscreen or the AI in singleplayer and try to get the quickest time.
+
+
+
Project Overview
+
+ The game was made by a team of six people over two weeks. I spent most of that working on the input and kart physics. After the time trial mode was done, I also worked on the AI.
+
+
+
Code
+
+
+
Steering
+
+
+ For steering we had some very specific requirements. While drifting, the player needed to be able to control their direction, without being able to flip the direction of the drift or 'drift' straight forward.
+ When drifting, the UpdateSteering function will transform the current steering input so that, if the drift was started while steering left, the possible range of steering values is within the range of -1 to -min, where min is a positive number lower than one which signifies the minimum amount of steering. When the drift is started while steering right, the range would be opposite, ranging from min to one.
+
+
+
+
+
+
+
Basic AI
+
+
+ After we had completed the basic time trial mode, we still had about a week to add more features. So while another programmer went ahead to implement splitscreen, I wanted to try and get AI working. The player input component was already separate from the kart physics part. So the basic steering AI works by steering until it is aiming at the next invisible checkpoint on the course.
+
+
+
+
+
+
+
Expanded AI
+
+
+ Allowing the AI to drift required it turning into the next turn rather than just aiming at the next checkpoint.
+ To do this, i first get the next three checkpoints to calculate the total angle of the next turn. This angle is then used to decide whether to drift or not.
+ After figuring out whether to drift or not, the AI will modify its physics in the same way as when the players presses the drift button.
+ With the drift started, the AI needs to aim at the checkpoint after the next to drift.
+
+
+