GAMEPLAY DEVELOPER

Looking for experience

I am Arne Olemans, I always dreamed of world domination, but my mother refused to fund those dreams. So I became a curious and driven individual with a lifelong passion for exploring technology and the world around me. From a young age, I've been fascinated by software and technology, starting with my early days of tinkering with Nintendo games and the family desktop PC. This curiosity has fueled my journey into understanding and creating within the software developent space with a special intrest in gameplay programming and game engine development!

Cinque Terre
Internship
Feb 2025 - June 2025
Czech/Prague
GoldKnights
Symbol
Used Skills
  • Unreal Engine 4/5
  • C++
  • Widgets/UI
  • Materials
  • Team work
  • On-site
  • Remote
  • TortoiseSVN
  • Rider
  • Visual Studio



Solo Project
Sep 2025 - Present
Multiplayer
Third-Person-Shooter
ThreeForSimple - self-taught learning project
Symbol
Learned Skills
  • Unreal-Engine 5.6
  • GAS
  • C++
  • Networking/Replication
  • Listen & Dedicated
    server support
  • Hash table
    Inventory System
  • AnimEvents
  • Interfaces
  • Components
  • Rider
Cinque Terre
Solo Project
Oct 2024 - Jan 2025
Custom game engine
ReVengine - 1993 Doom engine inspired
Symbol
Used Skills
  • C++
  • DirectX11
  • Component based
  • Multi SDL/SDL2
  • PhysX collision system
  • ImGui
  • SoLoud
  • Stb
  • Glm
  • Github
  • Visual Studio
Cinque Terre
Solo Project
Jan 2024 - June 2024
Custom game engine
KnipTang-Engine
Symbol
Used Skills
  • C++
  • SDL
  • Self-made AABB
    collision system
  • SteamWorks
  • GLM
  • XInput
  • SDL_Mixer
  • ImGui
  • Github
  • Visual Studio
Team Project
Jan 2024 - June 2024
Party Co-Op
form matcher
Form Frenzy - Programmer & Game Designer
Symbol
Used Skills
  • C#
  • Unity
  • Perforce
  • Visual Studio
Cinque Terre
Solo Project
Sep 2023 - Dec 2023
Genetic algorithm
with Neural Network
Perfectly plays Flappy Bird
Symbol
Used Skills
  • C#
  • Unity
  • Github
  • Visual Studio
Cinque Terre
Behaviour Tree - Developed C++ BT framework & AI car - Unreal Engine 5
Solo Project
Cinque Terre
2D Vulkan engine
Solo Project
Cinque Terre
Ride Of Giri - Unwrap group GameJam project - Unreal Engine 5
Team Project
Cinque Terre
Dooom - Remake of Doom 1993 made in self made Game engine(ReVengine)
Solo Project
Cinque Terre
Pengo SEGA 1982 - Remake of Pengo made in self made Game engine(KnipTang-Engine)
Solo Project
Cinque Terre
BlurMePls In-Real-Time webcam face detection blur - OpenCV
Solo Project

Contact Me!

arne.olemans@outlook.com

Symbol
GoldKnights
Internship
Czech/Prague
Feb 2025 - June 2025
Cinque Terre
Used Skills
  • Unreal Engine 4/5
  • C++
  • Widgets/UI
  • Materials
  • Team work
  • On-site
  • Remote
  • TortoiseSVN
  • Rider
  • Visual Studio
Introduction
I successfully completed a 4-months internship at the Czech double-A studio GoldKnights.

I had the privilege to complete my internship at there studio in Prague itself.

About the studio
Programming wise GoldKnights was at the moment of my internship fully focused on Unreal. The employee skill level went from current students to experienced developers with over 10 years in the game industry.

Before the start of my internship they released two titles and worked on various client projects. Their most notable release has been “The Last Oricru”. This is a double A, action RPG with still active players, even 2 and a half year after release.

Projects I worked on
During my internship I worked for the most part on Redneck Zombie Hunter. This was the main title of GoldKnights that they were currently developing during the majority of my internship. This project was a story based horror zombie survival game. The project got unfortunately canceled during my internship.

I was also allowed to work on two of GoldKnights clients projects, the Oddin CS project and the Oddin Dota2 project. Oddin CS is a first person competitive shooter based on the valve title, Counter strike global offensive. Oddin Dota2 is a competitive Multiplayer online battle area like game, based on Dota2.

What I learned?
During my internship at GoldKnights that lasted from Feb 2025 - June 2025, I had the opportunity to work with Unreal engine 4 and 5 for 8 hours a day on real ongoing game projects. These double-A projects from the studio itself and from clients of GoldKnights. All of these were in the Unreal-Engine and made me realize why there has been so much commotion surrounding this engine for the last couple of years.

Besides the obvious graphical capabilities and ease of the engine, I was mostly surprised by all the build in futures Unreal provides. For every problem or assignment I faced, the engine had a tool to resolve it. It made it possible to achieve previously daunting tasks like providing networking in your game feel more accessible than always without to many constrains. It may seem like a insignificant aspect to some, but I was really blown away by the engine when I was asked during my internship to add multiple language support in one of the ongoing projects. After a quick search I found out that the engine already had a system setup for this. I was able to bind all game text to this localization system to setup a translation for everything the studio pleased.

Working in a team
Because GoldKnights is a smaller indie studio I was in direct contact with Pavel Jiri the founder of the company to arrange my internship. During my internship I had less contact with Pavel besides a short daily standup meeting where everybody of the company went over what they had been working on in the last day.

I communicated on a daily bases mostly with Petr and Tomas.

Tomas was the artist I worked closest with. Throughout my internship we were in constant contact while implementing new features. He worked on the design and art while I did the implementation of the UI tasks. We gave each other constant feedback throughout the development process. This gave me the feeling that we were working towards an end result together, and it taught me how to work in a team dynamic.

Petr is one of the lead programmers of the company and he also became my supervisor during the internship. I worked mostly with him on the Oddin project. He taught me the best practices to keep in mind while working with Unreal. Petr was the first colleague I would contact if I had any question relation to the Unreal Engine. He really took his time explained to me all the good practices and provided me with incredible feedback. I’m really thankful to have been able to work with him.

Tools used
Our main communication between colleagues during our daily stand ups happened on Discord.

During my internship I received half of my tasks through discord and the other half through FreedCamp. FreedCamp, is a project management tool to easily display tasks in a team dynamic.

Additionally I had the chance to learn the source control TortoiseSVN on a daily bases.

Reference
Petr Bubik Symbol
GoldKnights - Unreal-Engine engineer - Internship supervisor
Symbol
ThreeForSimple
Solo Project
Sep 2025 - Present
Used Skills
  • Unreal-Engine 5.6
  • GAS
  • C++
  • Networking/Replication
  • Listen & Dedicated
    server support
  • Inventory System
  • AnimEvents
  • Interfaces
  • Components
  • Rider
Introduction
It was finally time to make my childhood version proud. I started the development of ThreeForSimple. A Unreal Engine 5.6 C++ multiplayer third person shooter with as minimum blueprint usage as possible to fully learn the GAS plugin and improve my Unreal-Engine reflection system understanding.

The main objective of this project was to have a shooter game with three attack/weapon types(Melee attack, projectile weapon, hitscan weapon), an inventory system and a lobby system.

What I learned?
I learned an immense amount during the development of this project. It took over my life and mind the same way programming did when I first started getting into it.

It gave me an excellent introduction to the GAS plugin and how networking concepts work in Unreal. How everything in the engine can communicate with each other and how everything is connected over the network. I finally learned about the inner workings of the replication system of Unreal and how I can use hash tables to communicate changes in the inventory system over the network without having to pass entire objects.

I could keep going on about everything this project provided me so far. It offered me so many insights in how the Engine itself works and whats possible with it. For exactly this reason I will continue working on a daily bases on this project. It has been incredible motivating to work on this project because it provides me with so much new knowledge on a daily bases.

GAS
The GAS plugin made my learning journey much smoother and rewarding. It covered various overhead for me. THis way I could fully focus on the bigger concepts.

Ability System Component
Is the brain of the operation. I linked this to every character in this project. I used it to save various gameplay effects and gameplay abilities. The system also allowed me to bind custom input ID's directly to specific gameplay abilities
UPROPERTY(EditDefaultsOnly, Category = "Gameplay Effects")
    TSubclassOf<UGameplayEffect> FullStatEffect;
UPROPERTY(EditDefaultsOnly, Category = "Gameplay Effects")
    TSubclassOf<UGameplayEffect> DeathEffect;

UPROPERTY(EditDefaultsOnly, Category = "Gameplay Effects")
    TArray<TSubclassOf<UGameplayEffect>> InitialEffects;

//Abilities that you already have from the beginning of the game
UPROPERTY(EditDefaultsOnly, Category = "Gameplay Abilities")
    TMap<ECAbilityInputID, TSubclassOf<UGameplayAbility>> OnSpawnBasicAbilities;

UPROPERTY(EditDefaultsOnly, Category = "Gameplay Abilities")
    TMap<ECAbilityInputID, TSubclassOf<UGameplayAbility>> InputBasicAbilities;

//Abilities you learn during game
UPROPERTY(EditDefaultsOnly, Category = "Gameplay Abilities")
    TMap<ECAbilityInputID, TSubclassOf<UGameplayAbility>> AddedAbilities;
void UTfsAbilitySystemComponent::AddInputAbility(ECAbilityInputID InputID, const TSubclassOf<UGameplayAbility>& GameplayAbility)
{
    RemoveInputAbility(InputID);
    GiveAbility(FGameplayAbilitySpec(GameplayAbility, 0, static_cast<int32>(InputID), nullptr));
    InputBasicAbilities.Add(InputID, GameplayAbility);
}

Attribute Set
Is used as a container to save and handle gameplay attribute data. This data is a kind of variable that works with the GAS system. For example I used it for the health of the player. Because of the macro's provided by the GAS plugin you can easily get them everywhere as a sort of static member.

I made sure that all of these attributes got replicated and clamped between values when they get modified.
UCLASS()
class THREEFORSIMPLE_API UTfsAttributeSet : public UAttributeSet
{
    GENERATED_BODY()
public:
    ATTRIBUTE_ACCESSORS(UTfsAttributeSet, Health)
    ATTRIBUTE_ACCESSORS(UTfsAttributeSet, MaxHealth)

    //Config of how property are getting replicated
    virtual void GetLifetimeReplicatedProps( TArray< class FLifetimeProperty > & OutLifetimeProps ) const override;

    virtual void PreAttributeChange(const FGameplayAttribute& Attribute, float& NewValue) override;
    virtual void PostGameplayEffectExecute(const struct FGameplayEffectModCallbackData& Data) override;

private:
    UPROPERTY(ReplicatedUsing = OnRep_Health)
    FGameplayAttributeData Health;
    UPROPERTY(ReplicatedUsing = OnRep_MaxHealth)
    FGameplayAttributeData MaxHealth;

private:
    UFUNCTION()
    void OnRep_Health(const FGameplayAttributeData& OldValue) const;
    UFUNCTION()
    void OnRep_MaxHealth(const FGameplayAttributeData& OldValue) const;
};

Gameplay Effects
I was surprised how easy it was to change GAS variables everywhere thanks to the gameplay effects. This dumbed down an otherwise possible complex problem of communication to a very straight forward process.

Gameplay Abilities
Gameplay abilities can get executed from everywhere that has access to the ability system component and are a very core principle of the GAS plugin.

I linked various abilities directly to custom input ID's.

I used them for all of my melee and weapon attacks. I used animation on the start of ability, and subscribing to event tags that got activated during an animation or when the player collided with another during the animation. These tags I later linked to behavior like applying specific gameplay effect when colliding with other players or shooting projectiles when an animation hit a curtained point.
//Predication key: The one that send out the ability has the prediction key and can therefor already play the animation locally and correct it once if needed the server executed the animation and replicates the data back
    if (HasAuthorityOrPredictionKey(ActorInfo, &ActivationInfo))
    {
        //Plays on server but automatically replicates it to all clients
        UAbilityTask_PlayMontageAndWait* PlayMeleeAttackMontageTask = UAbilityTask_PlayMontageAndWait::CreatePlayMontageAndWaitProxy(this, NAME_None, MeleeAttackMontage);
        PlayMeleeAttackMontageTask->OnBlendOut.AddDynamic(this, &UGA_MeleeAttack::K2_EndAbility);
        PlayMeleeAttackMontageTask->OnCancelled.AddDynamic(this, &UGA_MeleeAttack::K2_EndAbility);
        PlayMeleeAttackMontageTask->OnCompleted.AddDynamic(this, &UGA_MeleeAttack::K2_EndAbility);
        PlayMeleeAttackMontageTask->OnInterrupted.AddDynamic(this, &UGA_MeleeAttack::K2_EndAbility);
        PlayMeleeAttackMontageTask->ReadyForActivation();

        UAbilityTask_WaitGameplayEvent* WaitTargetingEventTask = UAbilityTask_WaitGameplayEvent::WaitGameplayEvent(this, GetMeleeAttackComboEventTag(), nullptr, false, false);
        WaitTargetingEventTask->EventReceived.AddDynamic(this, &UGA_MeleeAttack::MeleeAttackComboEventReceived);
        WaitTargetingEventTask->ReadyForActivation();
    }

    if (K2_HasAuthority())
    {
        UAbilityTask_WaitGameplayEvent* WaitTargetingEventTask = UAbilityTask_WaitGameplayEvent::WaitGameplayEvent(this, GetMeleeAttackTargetEventTag());
        WaitTargetingEventTask->EventReceived.AddDynamic(this, &UGA_MeleeAttack::DoDamage);
        WaitTargetingEventTask->ReadyForActivation();
    }


Networking
I wanted to make this project fully functional both for a listening and dedicated server.

This journey taught me that that every player has an instance of itself locally on the client and a version of itself on the server. I really enjoyed the challenge this brought me of trying to minimize what only needed to exist on the server and/or client.

When working with aspects of the GAS framework, most elements already got replicated over the network in an optimized way. This was very effective but did limit my learning opportunities.

I was very satisfied to be able to implement the replication myself for the inventory component and the lobby. This taught me the basics of how networking got done for the other aspects of my project were I used the GAS plugin.

Lobby
I link an unique slotID to every player spot to make sure that it can't get occupied multiple times.
void ATfsGameState::UpdatePlayerSelection(const APlayerState* PlayerToUpdate, const uint8 DesiredSlot)
{
    if (!HasAuthority() || IsSlotOccupied(DesiredSlot))
        return;

    FPlayerSelection* FoundExistingPlayerSelection = PlayerSelectionArray.FindByPredicate([&](const FPlayerSelection& PlayerSelection)
        {
            return PlayerSelection.IsPlayerLinkedToSelection(PlayerToUpdate);
        }
    );

    if (FoundExistingPlayerSelection)
    {
        FoundExistingPlayerSelection->SetSlotID(DesiredSlot);
    }
    else
    {
        PlayerSelectionArray.Add(FPlayerSelection(DesiredSlot, PlayerToUpdate));
    }

    OnPlayerSelectionUpdated.Broadcast(PlayerSelectionArray);
}
All the players get saved in a custom gameState class. This way the set username, networkID and slotID/team can get easily transferred to the game session.

Inventory
Every item in the game is linked to an unique handleID.
uint32 FInventoryItemHandle::GenerateNextID()
{
    static uint32 StaticID = 1;
    return StaticID++;
}
Using this hash system I can just pass the handle ID's of the items around over the network instead of having the pass the item struct which could put a big strain on the network.

Why Unreal-Engine?
Because my internship experiences made me fall in love with the Unreal-Engine I decided to continue self educating after my internship.

I saw various studios that switched to the Unreal Engine working with the GAS plugin. While learning more about it I figuring out how streamlined it could make the communication of changing data between different objects, I figured that it would be worth it to include this system in this upcoming learning project.

As many, I had been interested in making a multiplayer/networking project from the beginning of my programming journey. I played with some networking libraries/frameworks in the past but none of them really clicked with me or provided me the correct learning opportunities I was looking for. While learning other basics of the engine I felt like I still missed before I could start this project, I realized that the GAS plugin had excellent networking support and made the barrier to entry for multiplayer games even lower than it already was with Unreal.

What's next?
In the short term I am planning on finishing the intractable lootable chests and reworking the lobby to be able to self host games and see a list of currently running games that you can join. I will deploy this project to a server soon, as I believe that this will teach me more about networking and whats needed to launch multiplayer games after development.

Download
To view the project files, please visit the associated project Github page.
Symbol
ReVengine
Solo Project
Oct 2024 - Jan 2025
Example use case(Dooom): GitHub ReVengine-Dooom
Used Skills
  • C++
  • Github
  • Component
    based
  • Multi SDL
    SDL2
  • PhysX for
    collision system
  • DirectX11
  • ImGui
  • SoLoud
  • Stb
  • Glm
  • Visual Studio
A 1993 Doom engine, inspired C++ Game Engine.


Highlighted features
  • Component based system
  • Multi SDL input system, Bind SDL codes to functionality
  • Collision system using colliders of PhysX
  • Resource management, Textures and Sound only get loaded in once
  • A 3D rendered world of 2D png’s with DirectX11
  • HUD using ImGui, Automatically updates by binding memory addresses
  • Sound with SoLoud


Documentation - Getting-Started

Basics
In Game.cpp you will find a standard given function that returns a scene object. This object will be created and passed to the main game loop.

You can add game objects to this scene object. These game objects and only these objects will be processed/executed during run time. Every game object has transform component by default.
Rev::GameObject* exampleObject = new Rev::GameObject{};
scene->addGameObject(exampleObject);
Components can be added to game objects with the AddComponent function.
GameObject->AddComponent<Component class name>(GameObject, Component constructor arguments);
player->addComponent<Rev::CompCollision>(player.get(), physicsHandle, false, false, glm::vec3{0.1f, 1, 0.1f});
Custom components can be created by inheriting from BaseComponent. Functions like Update and Render can be overwritten to create custom behaviors. Examples of this can be found in the ReVengine-Engine/GameObjects/Components.


Render Component
Firstly, create Texture object by calling the load function of the resource management singleton object. Include a name for this texture and the filepath of the png file that you want to render.
Rev::Texture* enemyTexture = Rev::Rev_CoreSystems::pResourceManager->LoadResource("Enemy", enemyDoomFilePath);

Create a standard shader or create your own custom shader by inheriting from BaseShader
Rev::TextureShader* textureShader = new Rev::TextureShader{};

Besides a texture and shader, a render component needs a camera component to calculate the view matrix. A standard camera component can be passed in as an argument or a camera component that is linked to another game object can be used.
Floor->addComponent<Rev::CompRender>(Floor, player.cameraComp, textureShader, floorTexture);


Input Component
An input component can be added to a game object and used to bind SDL scancodes for keys and SDL button for mouse to lambda functionality.
inputComp->BindKeyAction(SDL_SCANCODE_W, [playerTrans]() { playerTrans->MoveForward(1); });


Collision Component
Adding a collision component will add a collider to that game object. This component needs a physics handle. You can get this physics handle by calling GetPhysicsHandle on the current scene you want to render the object in.
scene->getPhysicsHandle();

When two colliders collide the OnContact function of each of those colliders will execute. You can set the functionality of every collider component by calling the SetOnContactFunction. This function will take a lambda with a collision component as parameter. This parameter is the collision component of the object it collides with. Because of this parameter, functionality for both the object itself and the object it collides with can be set.
Rev::CompCollision& bulletColl = *bullet->addComponent<Rev::CompCollision>(bullet, physicsHandle});
bulletColl.SetOnContactFunction(
    [](Rev::CompCollision* other) {
        Rev::GameObject& obj = *other->GetGameObject();
        if (obj.m_Tag == "Enemy") obj.Destroy();
    });


Sound
The sound functionality is part of the Rev_CoreSystems. Mp3 and Wav are both supported file formats. A file only needs to be loaded once and can be played infinitely after.

To load in a sound file firstly include Rev_CoreSystems.h and Sound/Rev_Sound.h. Call the sound object of the core systems and the load function of the sound library. This function takes in a string “name”. This name will be used later to play the sound. As second argument, it takes the file path and file to the sound.
Rev::Rev_CoreSystems::pRevSound->LoadSound("pew", resourceFolder + SoundPew);

Once loaded in, the sound can be played from anywhere by including the Rev_CoreSystems header and calling the PlayRevSound function with the sound name.
Rev::Rev_CoreSystems::pRevSound->PlayRevSound("pew");


HUD
The HUD is also part of the Rev_CoreSystems header. By including this header and Rendering/HUD/UI.h you can start subscribing elements to the HUD.

To display anything on the HUD, call the function SubscribeElement of the Rev_CoreSystems pUI object. This function takes in a string and the memory address of a float value. This results in the values of the HUD automatically updating when the float value from that memory address get manipulated.
Rev::Rev_CoreSystems::pUI->SubscribeElement("Health: ", &healthPlayerComp->GetHealth());

HUDHealth


Adding game objects to a scene during runtime
You can get a handle to the global scene manager in the Rev_CoreSystems. From this handle you can get the current active scene of a scene by its unique ID or its tag. This way you can simply call the AddGameObject function.
Rev::Rev_CoreSystems::pSceneManager->GetSceneByTag("GameScene")->addGameObject(bullet);


Event / Game loop
GameLoop


Report and Critical Reflection

Component-based Gameobjects
I can honestly say that I’m proud of my gameobject-component system. I have made systems like these before, but they always had some deadly quirks. These past systems mostly failed because I ran away from more complex concepts.

This time, I took my time and rediscovered the wonderful world of templates. I even took it a step further by learning about concepts and template arguments.

I used template arguments in my AddComponent function to be able to have arguments in the constructor of the components the user is trying to add. Because of the nature of templates, no error codes would be collected when the user provides wrong arguments to a component. These arguments only get validated while compiling.


Graphics API / Renderer
I never setup a graphics API myself before this project. I went with DirectX11 for this project because I feel like it is a good combination of difficulty while still being low level. Doing this for this project took me a long time. In the process of doing so I relearned various basic graphics programming concepts I believed to have understood before. I believe the time and effort I put into this part of the engine will be worth it in the long term of my software development career.

DirectX has their own math library and enforces you to use this while working with their API. Because I openly used the glm library intended to be used by the engine and user, multiple conversions from glm types to DirectX types must be made nearly every frame. I tried to limit this by using dirty flags and only updating curtained parts when necessary. But I still believe at this point that it would be better to stick with one math library for your whole engine or abstract the graphics specific libraries used away to only a specific portion of the engine.


Input
When I finished the input system, I was initially satisfied with my approach. I have a global input object and subscribe input components to this object. Every frame, the input object loops over all the input components and checks if a curtained SDL code that is bound to a lambda using an unordered map is actively pressed.

While actively using this approach I realized that there was no reason to make this a component. Behaviour you want to execute when a certain key or mouse gets pressed should not be specifically linked to one game object. The input component also has no use case of any of the overwritable functions like update or render other components take great use in. Therefore, I believe a better approach would be to have one global input manager object and input objects that can be freely made and added or removed to the input manager freely.

Another minor but still noticeable observation I made every time I interacted with my own input system was the forced need to include SDL headers. While this is not an issue, I would rather abstract any SDL dependency away from my user and make my own enum class that I would later convert to SDL specific scancodes in the backend.


Collision / Physics?
In previous projects I always ran away from using any physics or collision libraries. In my last game engine, I even went as far as spending two weeks making my own collision system. This system sadly fell apart when being exposed to certain edge cases.

Therefore, I wanted to use a library for collision detection for this engine. After looking over the available options there are on the market I went with PhysX because it’s the most used one in the AAA industry and has the best documentation I could find compared to my other options. After setting it up and computing some colliders I was pleasantly surprised with the existence of Nvidia’s debug tool PhysX Visual Debugger, where I could visualize all the colliders in real time!

After messing around with PhysX some more I came to the realization that the library had way more to offer than I needed and locked itself up in its own actor and transform ecosystem. Earlier in the project I made my own transform component. Every gameobject standardly gets assigned one of these. This made it rather complex to work with a physics library that had its own transform, while I only needed the collision detection functionality of said library. There is no practically way in the PhysX library where I could disable the physics functionality of the colliders while still being able to detect collisions. I ended up checking for each gameobject that had a collider if their transform changed, and if so to update the PhysX transform. This way both different transforms kept in sync with each other.

Once this main issue was resolved I made a collision component where the user can set the functionality when two colliders collide with each other. The user can manipulate both the object itself as well as the object it collides with. In a potential remake of this project, I would not make my own transform component and just fully stick with the physics and transform logic of PhysX. I believe that when I would abstract the PhysX library away from the user, the library has way more to offer to my user than I could every develop on my own.


Camera
In past projects I used provided camera systems and view matrixes without equally grasping the mathematics behind these. I gave myself a couple days to sit down to make my own implementation and understand every step from position and rotation to view matrix.

Issue 1: A camera component can be added to any gameobject the user pleases. This functionality doesn’t make sense as long as there is no correct way to handle the existence of multiple cameras.

Issue 2: Besides this the camera component always must be passed in every render component to calculate the view matrix of this object. This does not make sense since the view matrix of a camera component is the same regardless of what object needs to be rendered.

I could resolve both issues by having one camera manager object. Every Camera component that would be made could subscribe to this camera manager. In the render components a reference to the view matrix of a specific camera could be grabbed from this manager and easily changed when the active camera would change during runtime.


Optimizations
These are the first optimization patterns I would implement if I would continue working on this engine.


Memory pool
Because the primary use case of my engine is doom like fps game. An optimization pattern like a memory pool is essential. Instead of allocating every bullet shot the moment it gets fired, it would be a better idea to allocate a certain number of bullets from the start and just enable/disable them the moment you need them. This way the bullets memory is reusable and there is no unnecessary computing to be done during runtime.


Instance rendering / Fly weight pattern
When starting up my example “doom” game I load in around 100 if the same floor tiles. The texture of this floor tile only gets loaded in once because of the resource management of textures in my engine, but all other components of the floor gameobject get computed separately again for each tile. This is a lot of unnecessary computing for an object that could just be rendered as the same object. This would be a perfect use case of instance rendering, a fairly beginner graphics programming technique.

For mass rendering of objects that are mostly the same but have some variants among them. The flyweight pattern could be an amazing pick.

I would love to implement these and abstract them away from the user to a degree that these patterns get applied without the user even realizing it.


side note
I wanted to prove to myself that I would be able to develop a 3D game engine with the same 2D rending sprites as the first Doom from 1993 had. For the rendering I used DirectX11 and for collision detection I decided to use PhysX as I wanted to get familiar with a more AAA industry standard physics/collision library. However, once I was deeper in development with PhysX I realized that it didn't leave me with lots of freedom and forced me to used their build in actor components to be able to let collisions work.

For a more technical look at the engine and the documentation/reflection I love to invite you to the associated Github readme paper.

After the development of my first game engine(KnipTang-Engine) I was left unsatisfied by several aspects. Part of the KnipTang-Engine felt rushed because of time constrains. This took away parts of the learning opportunity the creation of that engine should have been.

Additionally, I was also relearning DirectX11 at the time. This gave me the idea to challenge myself to combine this new gained knowledge to create a 3D engine. After falling back into the world of indie engine development I was recommended the book "Game Engine Black Book DOOM". This book went in depth about the team behind the first Doom game engine of 1993, id Tech 1 and how they worked around the technical limitations that played a major roll at the time. Reading about this time period of the game industry and how they were able to accomplish such a ground breaking engine at the time was the main motivation during the development of ReVengine.


Manual
Required libs
  • Use Vcpkg to automatically install all needed
  • Download “vcpkg package manager” in visual studio installer
  • $git clone https://github.com/microsoft/vcpkg.git
  • $cd vcpkg
  • $bootstrap-vcpkg.bat
  • Libraries can also be manually installed.
  • Put the required libraries in you IDE and cmake will find them.
  • Required libs: SDL2, Stb, Glm, PhysX, ImGui and any version of DirectX11

How-To-Build - Visual Studio
1. Open the Cmake project with visual studio by right clicking in the folder and selecting “Open with visual studio”.
HowToBuild1

2. In the Visual Studio IDE, Select Tools < Command line < Developer Command Prompt.
HowToBuild2

3. In the Developer command windows, execute $vcpkg install.
HowToBuild3

4. Wait until all the libraries have been downloaded and then close Visual Studio. Open it again with the same method as step 1 and wait until the output window has finished building. Once finished ReVengine-Game.exe will be build and able to execute.
HowToBuild4

Symbol
KnipTang
Solo Project
Jan 2024 - June 2024
Cinque Terre
Used Skills
  • C++
  • Github
  • Self-made AABB
    collision system
  • SDL
  • GLM
  • XInput
  • SDL_Mixer
  • ImGui
  • SteamWorks
  • Visual Studio
Introduction
The first game engine I ever made from scratch.

Description
The creation of this game engine took my engineering, C++, and programming skills to a whole new level.

This project follows the same open-source and freedom philosophy as C++, while still being user-friendly. The level of complexity is fully left to the user themself.

Technical
Kniptang is an open-source 2D C++ Game Engine made with SDL2 and glm for vector math.

The Engine uses a Game Object Component system. This makes it really easy for the user to implement new Game Objects and add Built-in or Custom Components to the Objects. Because of the Open Source nature of this Engine, the Built-In Components can be easily understood and customized to each user's preferences.

Game Objects can be added to a scene. An endless amount of scenes can be easily created, loaded, and unloaded synchronously or asynchronously thanks to the Built-In SceneManager.

It was a real journey trying to understand the complicated nature of what all of the main elements of a Game Engine entail. I improved my C++ knowledge significantly while programming this project. My researching skills developed greatly while trying to grasp and implement concepts like an AABB collision system that checks collision every fixed frame update without causing significant performance loss.

What I learned?
So much about all kinds of different technical fields and concepts. It opened the world of all varying kinds of gameplay patterns and which ones are best to use in what situations and others you should better avoid.

All the different techniques on how you could optimize and be capable of rendering and controlling all sorts of massive infastructors within your applications. Those patterns refueled the passion I had for programming, in the same way excitement I had when I first started out programming. Besides that, this project also taught me the crucial importance of good coding habits and practices, when working with a large code base that will keep increasing in size like this one did.

The aftermath
After finishing this engine I realized how much easier it has become for me to grasp concepts and tools in different game engines. Understanding the ins and outs of how game engines get developed greatly shifted my perception of game development overall.

I can say with certainty that developing this engine has been the most significant learning experience I had in my journey as a software engineer to this point (June 2024).

Resources
KnipTang-Engine was made following the Game Programming Patterns and Beautiful C++ guidelines books.

If you want to find more information about the technical aspects of this project feel free to visit my Github readme paper associated with this project.
Symbol
Form Frenzy
Team Project
Jan 2024 - June 2024
Used Skills
  • C#
  • Unity
  • Perforce
  • Visual Studio
Introduction
Form Frenzy… The first project I would develop in a group setting.

What I learned?
The creation of this piece allowed me to experience the full-length process of developing an indie game title. From brainstorming in panic when all our ideas fell apart after a closer look at them, to scrapping all of them, starting over, and combining our ideas like real team players!

Besides teaching me a large amount about what makes a game stick and how to avoid implementing game-breaking features, the most important lesson I gained while developing Form Frenzy was without a doubt the aspects of the group dynamic that came with it. It taught me about the importance of open, direct communication, the highs and lows of working with others, and the groundbreaking upper hand you can gain when you're not alone to steer the ball in the right direction when it starts rolling.

The Aftermath
Overall I can state that it was a mind-altering adventure working with this team. I will take the achievements I gained with me for the rest of my career, in as well as outside of the industry.

Devlogs & Download
If you want to read more about the process of developing this project, you can read the DevLogs on our itch.io page.
Symbol
Flappy Bird Neural Network
Solo Project
Sep 2023 - Dec 2023
Cinque Terre
Used Skills
  • C#
  • Unity
  • Github
  • Visual Studio
Introduction
For my research project, I tried to create a genetic algorithm that could perfectly play the mobile game Flappy Bird. I used Unity to recreate Flappy Bird and the implementation of the algorithm.
![](https://github.com/KnipTang/FlappyBird-Genetic_Algorithm/blob/main/GIF.gif)

Flappy Bird
Flappy Bird is a fairly simple game where the player controls a bird by flapping. Flapping results in the bird moving up and not flapping leads to the bird moving down. The bird needs to pass between holes of the incoming pipes. By passing between a pipe, the player's score will increase by one. Colliding between the bird and the ground, roof or one of the pipes will lead to the game ending.

Genetic Algorithm
A genetic algorithm tries to mimic the evolution theory through the process of natural selection, crossover and mutation. Every new generation gets better by learning from the best individuals of the past generations. This process keeps getting repeated until a solution is found.


Implementation
Neural Network
Every bird has a neural network. This neural network consists of an input layer, a hidden layer and an output layer.
The input layer has two nodes. The first node takes the length between the x value of the bird and the x value of the center of the incoming pipes. The second node does the same but for the y value.

These values get passed to the 6 hidden nodes. These nodes take the values of the input nodes and calculate/multiply them with the bird's unique "weightsInputToHidden" and "weightsHiddenToInput" values. These unique values decide how well the bird will perform. The closer these values are to the final solution the better the bird performs. These values are the weight matrices or DNA of the bird.

After the calculations, the hidden nodes pass a final value to the 1 output node. The value of the output node is the weight of the bird at that moment. This weight gets recalculated every frame. If the weight is higher than a certain threshold the bird flaps. Otherwise, the bird does nothing and falls down until the threshold is met.
![App Screenshot](https://github.com/KnipTang/FlappyBird-Genetic_Algorithm/blob/main/NeuralNetwork.PNG)

Generations
Every generation has a set population size. This size will decide how many birds will spawn at the beginning of each generation. In the first generation, all the bird's unique DNA values will be randomized between certain minimum and maximum values.

After the first generation dies out and no solution was found in that generation, a new generation will be created from the DNA of the birds with the highest fitness score of the last generation. A fitness score indicates how well a bird has performed. The fitness score in this case is the time a bird survived.

The offspring for the new generation will be created by selecting the best birds and using crossover and mutation techniques on the DNA of the birds to create variants of these birds. This process will be repeated until a bird with DNA that can solve the problem has been created.

Crossover
Crossover is the process of combining the DNA from two-parent birds to create offspring. by selecting random crossover points along the DNA of the parents and exchanging genetic information between those points.
![App Screenshot](https://github.com/KnipTang/FlappyBird-Genetic_Algorithm/blob/main/Crossover.PNG)

Mutation
Mutation introduces small random changes in the DNA of an individual to maintain genetic diversity. In the context of this neural network, mutation involves randomly adjusting the DNA of the newly created offspring. A mutation rate determines the likelihood of offspring undergoing mutation.
![App Screenshot](https://github.com/KnipTang/FlappyBird-Genetic_Algorithm/blob/main/Mutation.PNG)


Result
If the fitness score of all the birds of the first generation is lower than a certain threshold meaning that all the birds directly flew against the ceiling or ground a new generation will spawn with random weight matrices instead of creating offspring from "the best" of the failed birds. A desired result would also be found after a certain amount of time without doing this, but doing so would take more time.

After multiple generations of the genetic algorithm, the algorithm was able to produce birds that demonstrated improved performance every new generation. At an average of only 4 generations, the system can create a bird that plays the game flawlessly. The process of natural selection, crossover, and mutation contributed to the generation of birds with increasingly optimized neural network weights.


Future
To further improve the algorithm, consider expanding the neural network's input nodes to include factors such as the distance between the bird and the upper/lower pipes instead of just keeping the distance between the center in mind. This additional information could expedite the convergence towards the desired solution.
![App Screenshot](https://github.com/KnipTang/FlappyBird-Genetic_Algorithm/blob/main/Future.PNG)


Side note
This project was my introduction to neural network programming.

When I came up with the idea to develop this project I had no clue where to start. I knew that there would be a lot of new concepts I needed to grasp to successfully complete this project.

Besides all the technical concepts, the development of this project taught me something way more valuable. It taught me one of the most important thinking patterns I have learned about programming,
When trying to find solutions for problems you encounter while developing big or even small projects, it's of the highest importance to keep breaking down your problem into smaller pieces. Keep doing this until what seemed to be a gigantic unsolvable problem gets converted into lots of small easily solvable problems that have 9/10 times easy solutions.

If you want to find more information about the technical aspects of this project feel free to visit my Github readme paper associated with this project.