Escape from Castle Galdor

Escape from Castle Galdor is an action game taking place in Virtual Reality. In the game you take on the role of a powerful wizard escaping Castle Galdor. As you traverse throughout the game you will find ingredients used for crafting spells that will help you defeat the enemies of the castle.

My main objective was to create a spell system. Two main spell classes were created, with which we could change variables like firing speed, travel speed and particle effects. Other objectives included inventory, pickups, movement, health and world events.
Project Information
Lead Scripter
Game Designer
Team Size
4 Design
7 Artists
Unreal Engine 4.14
Production Time
7 Weeks
Action RPG
PC(Oculus Touch)

Modular Spell Targeting System

The electricity system is based on targeting. The player could aim towards a target location and upon firing, the spell would instantiate on the targeted location.

When the player picked up an orb for a long range targeting spell, a particle effect lets the player know where the spell will land. While holding the fire button, haptic feedback of the Oculus controllers would start playing with increasing strength over time to indicate a charging spell. Just before the spell was fully charged the feedback would stop and then as the lightning hits the ground, the controller would shake slightly to give the player feedback of a spell hit.

Upon hit a different base spell class would instantiate that would have its parameters such as damage, particle effects and element being sent to it from the orb the player holds in the their hand. This being a non projectile spell, a particle effect would spawn on the target location along with the damaging sphere. Just like the other system, important variables such as damage, particle effects and radius of the damage sphere would be sent from the spell orb.

View blueprint

Spell Projectile System

The spell projectiles in the game are all based on the same spell class. Each spell orb in the game carries variables that it sends over to the hand that picked it up. Upon firing the projectile, these variables could include the information about the speed they travel with, which particle effects to use, how much damage to deal and so on. Upon impact the spell would spawn a damage sphere. This sphere would send out damage to each enemy it collides with based on the distance to them.

By making a base spell class for the projectiles we could create multiple spell orbs with different variables and thus create multiple different spells, increasing development speed and efficiency.

View blueprint


The inventory held all of the spells and ingredients and followed the rotation of the player. Once crafted and picked up, the spells could not be dropped. If you released a spell from your hand it would fall back into the inventory, preventing the player from losing them. Once placed in the inventory, the spacing between the items are adjusted, preventing overlapping and making it easy to pick up the correct item.

View blueprint

Chain Lightning

The lightning spell has a large collider that detects enemies and their position. The particle system then used vector parameters to control the location of the start and end point of the lightning effect. From the spell blueprint I sent the locations of each enemy that was hit and spawned a new chain effect for each location, creating a chain of electricity. After the spell had been casted, a small delay was added before the chain lightning particle was activated for added intensity.

View blueprint

Post-mortem & Takeaways

Escape from Castle Galdor was a huge learning experience when it came to performance related challenges, such as motion sickness, having a very limited amount of dynamic lights and making a game for a new platform.

Motion sickness was varying from player to player. Having free movement in VR can provide better gameplay if one is not prone to motion sickness, but we chose to go with a teleportation-style movement to make the game appealing for a wider audience. I would have liked to make it an option if we had the time.

Performance always had to be checked, the light settings had to be tweaked, particle effects had to be performance-friendly and materials had to be optimized. This provided many limitations in the game design, such as not being able to always provide visual gameplay feedback, in order to maintain a stable frame rate.

Because magic was at the core of the gameplay experience, ideas for different spells we could include really went wild. The spell class was made to handle a large range of spell combinations, but we agreed on starting with three and then implement more if we had the time. We later on decided to stick with these spells and try to polish them as much as possible. I do believe that it was the correct decision to go for quality over quantity.
Back to Top