Potion Seller
Potion Seller is a 2.5D side scroller where you play as the often-looked-over, side character shop-keep the Potion Seller. As the only townsperson willing to stand against the demon enemies, you must fight your way with potion-based combat to defeat the final boss known as "The General".
This project was created with fellow team members of the group known as Blue Autumn Studios and took six months to create.
-
Platform: PC.
-
Software: Unreal Engine, GitHub, Jira, Trello.
-
Creation Length: 6 months.
-
Playtime: 10 minutes.
Responsibilities
-
Designed and scripted AI enemies.
-
Created and assign team members tasks.
-
Designed and implemented a versatile camera system.
-
Designed and scripted multiple potion types for player to use.
Ice Spike Potion
Creating this potion was one of the greatest difficulties when it came to implementing these potions. The original design stated that there needed to be a potion which would spawn spikes that aligned to any type of surface, flat or angled.
In order to produce this result, there needed to be multiple line traces and vector math to calculate these angles. To start, each spike is it's own actor that can be spawned into the world. Once the projectile from the player hits the ground, a master spawns in these ice spikes.
This master then determines where the next spike will spawn with two line traces. The first is horizontal and spawns a good amount above the spikes. If this one is hit, then the current spike is spawned based on the normal of the surface.
The second line trace goes down from the middle of the horizontal to a great distance below. This one is only spawned if the horizontal did not hit. This indicates that the ground below is perpendicular to the horizontal trace. In which case the next spike is spawned at the hit location of this second trace. This process is then repeated on a loop depending on how many spikes you want spawned.
While it certainly isn't perfect, it produced the intended result. To make it better, I would try to figure out how to stop them from sticking into the ground as well as be able to bounce off of enemies rather than sticking to them.
Camera System
From the start, it was important that our camera system looked and felt good. In the end, I created a floaty yet responsive camera system that allowed for easy manipulation depending on the situation required for the level.
This system works by constantly getting the player's location every tick and interping towards this new location. What makes it feel smooth is the rate at which the camera follows the player which creates this floaty following movement.
The base camera system I created was however, a little limited in it's abilities. It became apparent that there would need to be a greater ability to tweak it's state for level designers as well as special use cases such as locking the camera's position.
The main issue was that the camera needed to be easily manipulative when it came to the height and distance from the player. To solve this issue, I added additives to the camera's initial location that our level designers could easily manipulate in editor rather than needing to go into the blueprint to edit these values.
Based on our design document, locking the camera occurs by having the player enter a region where they must defeat a small horde of enemies in order to progress. With this in mind, I started by creating a volume that would trigger this camera locking whenever the player entered it. This would allow the level designers to simply place it in the level to use. I then placed a second camera that is smoothly transitioned to once the player walks in to the volume. Similar to the base camera, there are easily manipulative values that the other designers can use to achieve their desired distance and height from the player. Once the player exits this area, they are smoothly transitioned back to the following camera.
Enemies
A variety of enemies were created to add opposition for the player to use these potions on. The variety of attacks and movements of these enemies was designed for the player to be able to prioritize the different types during combat.
Patrol System:
I designed and implemented a patrol system for the enemies, enabling them to move between multiple designated waypoints. This system significantly enhanced the realism of the enemies' behavior, making them more dynamic and less like stationary security alarms.
Boss State:
All enemies were also equipped with a boss state. With this state, the enemies always know where the player is and is constantly aggressive towards them. The purpose of such as system is so that they can be spawned in a wave fashion whether it's in a locked location in the map or during the boss fight. Locked locations allow for a mix up in the experience from the standard running, jumping and fighting towards the end of the level. During the boss state, its used to signify the change in the bosses phases and to separate the combat by having the player focus on multiple enemies rather than one boss for a determined period of time.
Demon Bird:
The initial design of this enemy only had it constantly flying towards the player when seen. However, playtesting revealed that this enemy was way too difficult and didn't allow for the player to recover from it's attack. In order to reduce this affect. To address this issue, I introduced a feature that enables the bird to perform multiple patrol cycles above the player's head after each dive, providing necessary breathing room and balancing the gameplay experience. This is also what would be considered a high priority enemy for the player and would require for their attention to be drawn to this enemy first before the others.
Goblin:
Similar to the design of the Demon Bird, the Goblin's initial design only had him constantly run towards the player after seeing them. This also didn't allow for a break in the gameplay. So with this enemy, I designed and implemented it to charge at the player after seeing them, hitting them with it's spear and then retreating from the player. This break once again gives the player time to react and fight against them. This enemy would have been considered of medium priority for the player.