I am a student Digital Arts and Entertainment (Major Game Development) at Howest (Belgium).
My focus is mainly on gameplay programming , I however also know my way around the graphics pipeline and the insides of a game engine.
If your next project is game-related and you think you could use my skills, don't hesitate to contact me!
This is what I do
I am currently studying Digital Arts and Entertainment, Game Development major.
C++ Coding
Experience in both basic and advanced coding concepts in C++.
C++ implementations of both DirectX and Nvidia PhysX in an engine
Unity 3D
Prototyping and developing games in Unity3D.
Unreal Engine 4
Prototyping and Developing games Unreal Engine 4. Experienced in UE4's own blueprint system.
Lorn is my biggest project yet, it was a 5-man project with an enormous scope for the timeframe we had.
We set out to create a survival-themed game which lasted about an hour to play from start to finish so we could deliver an experience anyone could enjoy.
This project has taught me a lot about properly designing and creating a game from start to finish and was a giant excercise in teamwork and trying to set up proper systems to push actual content into the game.
I was in charge of all the players interactions. (running , crouching , weapon management, proper projectiel collision, etc.) I am most proud of the work I put in a weapon system that allows you to easily create new weapons and thus push out content. The basics of this are explained below.
We had another main programmer who was creating all the AI and one of our artists was helping out with the UI and basic scripting, we had 2 other artists who were mainly creating all our props and designing the world.
Weapon System in UE4 blueprints
We decided to fully program the game in blueprints , as this allowed our artists to understand our code and even write some code themselves. The fact that they had some experience in UE4 blueprints proved to be a lot of help as they could help in prototyping the game.
Our main idea was a survival game were you had to explore the world and could find different sorts of items which could aid you in your adventure. To make this idea work we figured that we needed a very robust weapon/item system which we could use to easily manage our inventory and with which we could easily create new items.
The absolute base of our system is a blueprint called "interactable". In the world, our player checks against interactables to see if he can "activate" them, then our interactable itself decides what it has to do, if its a lightswitch it can affect a nearby lightbulb, if it's a door it will open or close or maybe ask for a key to be opened with. It could even be a weapon which will then be added to your inventory. All these different behaviours are decided based on booleans which are set in the interactable blueprint.
On top of this "interactable" class we have several different classes. Doors and switches are simple interactables with their code put in the "activate" function. Inventory items however can be either "items" or "weapons". Weapons can be equipped where as items can not. When items get put in the inventory, their world mesh and collision simply get disabled. When dropped, we can reenable the mesh and collision and drop it at the player's location.
As a third layer we have the actual weapons, these all start from a very simple "baseweapon" blueprint. This contains base empty functions such as "reload" or "fire". Even a melee weapon has a reload function , but it does nothing , this is simply because our player calls whatever "baseweapon" he has equipped and calls the fire or reload function. Then the weapon does the rest itself.
To equip a weapon you have to open the inventory and drag the weapon in the desired "hand" slot. this allows our player to make tactical choices based on his needs. One player could choose to carry a 2-handed rifle, another an axe in his left and a revolver in his right and yet another player may carry a revolver in his left and an axe in his right because he likes this feeling more.
This item system was a lot of fun to make and design and really made me appreciate the power of blueprints.
Judgment was a 5-man Unity project consisting of 2 artists and 3 programmers. As the most experienced game developer, i tried to take the lead and stood in for most of the gameplay design. I tried to think about the several features and gave the other 2 programmers ideas of how to possibly implement them, while leaving them free to do their own thing.
I myself was in charge of programming all the behaviour that had to do with the main character itself , such as the different combat abilities etc. I also helped the artists in implementing the animations and adding root motion to them.
Client:
Date:
2/20/2017
Type:
Game development
Duration:
120 days
Technology:
Unity
Reactive Melee Combat in UE4
This was a research project in which i explored multiple succesfull melee combat systems and their respective tricks to create a good feelign of impact. This was followed by an implementation in UE4 . I started out by implementing a raytrace collision system for melee combat and Physically Based Animations .
To set a goal for myself , I tried to correctly angle and postion shields with an IK system to solve problems percieved in several games concerning block animations.
There is a full paper which you can download below , as well as a video on the implementation
I created a WPF application in C# which allows you to open .d2s files (native diablo 2 save files), edit them, save them and then play them yourself. This was all done according to the MVVM design pattern and involved reading in a binary file and doing a lot of bitshifting.
More information about the actual implementation can be found on my personal blog. There is also a code snippet in the images below.
Video:
Client:
Date:
1/3/2017
Type:
C#
Duration:
14 days
Technology:
C#
PressJToFire
This was a short 2-man project in Unity3D. I programmed most of the stuff which had to do with the player and enemy movement and spawning. Although this was a rather simple game and most of this was just an excercise in teamwork and getting used to unity , i'm quite proud of it because the game actually turned out pretty fun and really feels like an old school highscore hunting game.
Feel free to download the Design document I made in the style of an old game manual. You can also download a playable build below (15mb).
This is a small game I made in a school gamejam. It's a revamped 3D version of the classic game Asteroids, made for Google Cardboard in Unity. I played more of a utility role in which I made placeholder assets, implemented sound and helped with the main design.
As in any gamejam , we were given a limited amount of time to finish the project ( 2.5 days ) and the sole requirement was that it was made in unity to be played on google cardboard. As we were a team of 5 programmers and no artists , we knew we could have some problems in the art department
This project was really fun, right from the start we faced problems which we had never encountered before. Namely , how in chtulu's name do you make a fun game when you have only 1 button to press. The only real genre of game we could immediately think of was an on-rail shooter with a lightgun.
So , we set forth to make our remastered version of asteroids for VR. Due to us not having an artist in our team , we decided to get some 3d assets in the game ourselves. I primarily made everything inside the cockpit and a teammate did the outside assets (planets / asteroids) Seeing as we had little time, we decided not to unwrap anything and just put different shading groups and materials on stuff so we coudld later fix this in unity.
Although our art certainly isn't all that nice to look at , we ended up quite happy with the end result. Mainly because it properly conveys the mood we were going for and serves great as a first mockup so we could focus on the game itself.
This was a rather quick and small project, but a fun one nonetheless . This made me really love the idea of gamejams.
