top of page

5th Game Project

Engine: TGA2D (school's in house)

Timeframe: 8 weeks (half time)

Team size: 14

Genre: 2D Top Down Adventure

Use your otherworldly powers to explore a mysterious corrupted world on a quest to save your dear dog from an unknown monstrous entity.

My Contribution

The Player

One of my largest tasks was creating the player - Thorwald - and about all mechanics corresponding to him. This includes movement, attack combos, shooting and more. The player was made with different components belonging to a player object that worked both individually and together to create the player behaviour. For example, there was a component responsible for movement, another for melee attacks and then another for shooting.

When creating our player, I took a lot of inspiration from how things were done in our reference game Hyper Light Drifter, trying to mimic the player behaviour. Also, for this project, we added controller support to complement the usual keyboard and mouse. This meant for the player that some behaviour had to be tailored specifically to when playing with a controller and vice versa. It was a good learning experience to develop a player meant for both keyboard and mouse as well as controller - as the decision lead to different ways to handle input and finding ways to make the player feel good.



In Thorwald's arsenal, you have both his sword but also his monster arm capable of shooting out elemental projectiles. Advancing through the game,  the player finds upgrades to his arm, letting him shoot a new element which impact both the world and combat in their own unique way. I worked with implementing all the abilities and their mechanics into the game - both for combat and puzzles - except the ability to freeze water, which another programmer solved fantastically.

Functionally, the abilities were implemented as different projectile-objects inheriting from a base class. This made the implementation of multiple abilities simple from a coding perspective, as the interface for both shooting and choosing (almost) any number of abilities already existed. The subclasses could then have their own unique behaviour and affect the world differently.



Another big task of mine was, once again, the collision system. Following my recent work with collision in the previous game - Forknight - I still had a lot of thoughts about game collision and how to make it better in this project. The implementation was at start kind of similar to how I did it before, but by writing most of it from scratch I found some new ways to do things and adjusted to support collision for both AABB and circles.

One big new feature in this "Collision System V2" was the inclusion of dynamic collision handling. As we started to have some fps-problems mid project, we noticed the player tunneling through thin colliders in the world. As this wasn't acceptable, I took it upon myself to finally implement dynamic collision handling, after regretting not doing it in Forknight. It was quite the time consuming process as I didn't have any earlier experience with how it works, but after both help from peers and some extensive googling, it worked! It fixed our collision problems and the player couldn't go through any more walls.


Save Files

As this game was a longer adventure game compared to the shorter more compact games we had created before, I really wanted the game to feature save files. The ability to save in a game is something that I've always felt makes the game more legitimate and important in a longer game. Therefore, in the last week I implemented it, with autosaving between rooms. It may not be the most important feature overall to have in our games made in school, but to me it felt really good to finally be able to save in one. This was also another great learning experience for working with the filesystem and JSON as well as a way for me to get some insight into how it can be done, for future reference.

bottom of page