Below you can find a selection of prototypes I have designed and built as an exploration into different systems, mechanics or concepts. These prototypes mainly serve as learning projects or simply as a fun outlet.

——————————————————————————————————–

Project Anathema

LATEST UPDATE (03-10-2024):

Anathema – Update playlist — WATCH HERE —

A retro FPS with gameplay and an aesthetic that takes me back to the early PC FPS games but with a modern twist. The game will feature high quality lighting and effects while using sprite-based enemies, weapons, characters and props, placed in a fully 3D environment.

Aiming will take a backseat in the game and the gameplay will focus more on movement and weaving through enemy fire.

The intended gameplay will focus more on forward momentum and player resource management. The player will fire fast weapons while the enemies will fire more slow moving projectiles. Additionally, the game will not be linear and will focus on light environment puzzles, minor back tracking and exploration.

The prototype is entire build in Unreal 5.4 using C++. The first iteration was main meant for setting up the sprite based tech and figuring out a working pipeline.

The weapon is a Flipbook that has two sprite animations rendered within Blender. The enemy sprite set taken from the game Hexen but will be replaced later by sprites of my own.

Anathema Enemy setup

All the enemies will have a base C++ class from which each will be derived from. This base C++ class is made with the Character as base. It then has a FlipBookComponent as its RootComponent, a custom AttributeComponent (ActorComponent), another custom component which handles sprite facing and an UInterface for spawning effects etc. .

In the Editor, a new Blueprint is made deriven from this class for each new enemy that is made. In the editor all the content used by the enemy can be added, in this case all the different flipbooks for all the enemy animations. The flipbooks are added to a custom flipbook component that takes care of which flipbook to play in regards to the direction of movement and the location of the player.

The custom made directional flipbook component can be added to any actor that requires multiple sprite angles and contains logic for swapping sprites based on specific conditions. For example, the enemy projectile uses the exact same component.

The Face Player component will make sure the sprites are always facing the player. In the AttributeComponent, the enemy stats can be set like Health.

In the Enemy Template, for each Tick the enemy location is determined as well as the location of the player. Based on these vectors we can calculate the angle and determine if the enemy is facing left or right. (I do not claim to know the exact calculations here, I had to search the internet and do a lot of debugging ;))

Once we have the angle and direction, we can set the Flipbook.

Am sure this is not the greatest code every written but it works great for what I need and it seems easy to maintain. Its been great fun working on this project and I am extremely motivated to keep going so I will post more updates in the future.

——————————————————————————————————–

Forlorn Deep

A card game dungeon crawler. The concept revolves around the player navigating procedurally generated dungeons filled with monsters while building up their deck with cards. The main hook is the player gains new cards by defeating monsters. When they defeat a monster, they receive a random card from the defeated monster’s card deck.

The more stronger monsters they defeat, the more powerful the player’s deck will become, the more dangerous dungeons they can conquer.

Each turn the player has 2 action points they can use to play specific cards. Some cards cost 1 or 2 action points to play while others are free.

Alternatively, the player can flip the card for a generic use instead which cost no action points. These cards allow for a basic number of movement points or a weak attack.

Forlon Deep it’s gameplay loop completely revolves around making interesting decisions with your cards. The player’s deck will be shuffled each time the player has no more cards to draw. Since the player’s deck can grow large due to the monster cards being added, the player can choose to permanently sacrifice cards to gain short term benefits while also culling their deck from cards they no longer need.

By burning cards, a meter will fill that unlocks extra actions the player can take in their turn. For example, the player can gain an additional action point to play an more powerful card or they can use the meter to heal themselves.

During play, the player can also put cards in their reserve belt which locks cards into their hand. These cards can be played once each turn and will not get shuffled into the deck which allows the player to create quick play strategies while using the main deck as a source for additional power.

The prototype was also a great exercise for me personally to delve more into concepts like procedural generation, Astar pathfinding and AI behaviour trees.

The prototype contains a fully procedurally generated dungeon, AI that can navigate the dungeon and play relevant cards from their deck, and a card generation system that generates cards based on data from CSV files.

Forlorn Deep – Dungeon Generation

The game is entirely made in Godot 4.0 and uses Astar Navigation to assist with the generation of the randomised dungeons. It is still fairly basic but it can already generate some interesting dungeons to navigate.

When the game starts it will first set a start position for the player. Then create random rooms based on a minimum and maximum size. The room amount is now set as a hard value but can be made variable later to increase or decrease the dungeon complexity.

Each generated room will be given an ID and will be stored into a dictionairy. Its tile coordinates are put in an array to be added to the Room ID key. This data can then be used later to add content etc.

After the rooms are generated, they are all connected with walkways. We use the room dictionary and Astar to find the paths between the rooms and fill it in with walkable tiles.

Then we grab all the rooms and whenever a room is of a large enough size, we put in a monster.

The final step is to close off the remaining tiles with sprites that have collision.

We skipped over a few steps but you now have a rough idea on how I generate the dungeons.

——————————————————————————————————–

2D Brawler

Inspired by games like Towerfall and Duckgame, I wanted to make a 2D party game but with more depth in its systems much like a regular fighting game.

The concept of this particular prototype revolves around a super meter that can be used to power several actions.

The player’s base actions are:

• Shoot (with autolock)
• 360 degree melee

• Shield and Parry (The shield can block all incoming projectiles and when used at the correct timing it can parry melee attacks and even reflect rockets)
• Rocket Fire
• PowerUp

The player can fill the super meter by hitting the other players with the basic actions like Shooting and melee. Once they accumulate enough super power they can fire a rocket or PowerUp to enhance their basic actions with additional features.

For example, the basic Shoot can now fire through walls or the player can fire a massive laser that instantly kills all players within.

Using the super meter accomplishes a breath of different moment to moment tactics gives the game a refreshing layer of depth.

The game supports game modes like Capture the Flag, One Flag CTF and death match and can be played with up to 4 players.

——————————————————————————————————–

Zone Shifter

Because I have a deep love for arcade games and Shmups in particular, I have made several Shmup prototypes. One of them is called Zone Shifter.

In this prototype I wanted to shake up the genres mechanics slightly by pushing the player away from enemies instead of trying to point-blank shoot them. In addition I want to have the player try and have as much enemies on screen as they can handle instead of trying to continuously clear everything as soon as possible.

Its main gameplay loop is that the screen is divided into two equal halves and the player can shoot left and right.

The player will want to shoot enemies that are in the opposite half. The catch is that enemies will fly into the screen from both sides.

To ensure the player will want to shift sides the scoring system as-well as their survivability is coupled tightly with this mechanic.

Shooting enemies on the other side will grant power ups that will make the player more powerful.

In addition, the enemies are worth more points when shot on the other side. The longer they are active, they will accumulate even more points so risk taking is awarded.

——————————————————————————————————–

Invader Labs

As a continuation of the basic systems from Arabilis, this prototype took a detour into the auto battle game realms.

In this roguelike tactical game concept the player grows monsters and uses them to invade a city and try to demolish the heavy fortified capitol building. In the concept the player will play through multiple levels and gain upgrades to their monsters to counter the ever evolving defending forces.

The player is continuously receiving a random monster seed that needs to be planted into the procedurally generated “lab”. By matching the colors and connecting the dots (like in Arabilis) the monsters will grow until they are eventually big enough to be send to invade the city.

Each city has a selection of different defending troops that attack and defend specific zones.

Whenever there are no monsters in the city, they will attack the monster warp portal. When it gets destroyed, it is game over and the player will have to continuously send in monsters to defend the portal and clear the defending troops.

The battle itself is entirely automated and the player will have to make sure they send in the right monsters at the right time.

To destroy the capitol building and win the level, the player will have to invade the city with bomb monsters. They are extremely vulnerable monsters that can only attack the building. Timing is crucial to make sure they make it across the battlefield.

The prototype is still very work in progress and still lacks some of the planned systems. Monster upgrades and additional incentives for the player to be efficient with all monsters are planned to be implemented.