Galdr: Forgotten Songs
Explore a foreign land, subdue the corruption that is devouring it, and solve environmental puzzles through magical songs. Galdr is a third person adventure puzzle solving game where you use a flute to cast different spells that interact with the environment to progress forward. Move objects, possess entities and grow vines to unravel the mysteries of this strange world.
My Roles
Lead Programmer, Tech Designer
Team Size
13
Engine
Unity
Timespan
4 Weeks
The Concept
I was the lead programmer on the project. On top of that, I also took on the role of helping design systems and tech for the game. The first thing we did was sit down and discuss with designers what spells we needed so that we could be able to iterate more easily forward.
We originally settled on four spells;
Growth - make something move or rotatePush - make something get pushed by physicsLight - light up an object, activate itControl - take control of an entity or objects
Each spell has a target and a type where the target is what type of object/entity you want to hit whereas type is if it should be long range or concentrated but hit multiple.
As a programmer, my role on the project was to implement the different spells in the game. I quickly prototyped the basic implementations of them and set up examples in a testing scene so that designers could start working on the actual puzzle pieces before we got any assets to play with. I also mocked up basic AI for the enemies, so that they could attack the player.
As a designer, I sat down with the other designers to discuss the scope and limitations of the project. We wanted versatility, but also visual clarity of what each spells could do. We quickly realised that the spells were a bit confusing to discern. Therefore we simplified them into "alter", "possess" and "activate". The single/multi targeting was cut out, we never found a scenario where we would want to hit multiple things at the same time. I think we really benefitted from having close discussions across disciplines to see what we wanted to do as well as what we actually could do for the game.
I wanted a scalable and flexible spell system in the game. While my fellow programmer implemented the calls for the spells, I made the magic itself happen. Every object that can be interacted with with a spell has a component inheriting from the base class SpellTarget. SpellTarget is then cut up into multiple subclasses like Alter_Move, Awaken_Flower, Possess_Devourer, etc.
They inherit the same core functions and implement their own versions of what should happen. The serialized variables make it very easy to edit what the object should do, such as how far an Alter_Move object should move, and in what direction.
I found the tags system in Unity relatively annoying to deal with. There is no flags system for tags, each object can only have a single tag attached to them. Therefore, I decided to make my own. I created the "MultiTags" enum that enables objects to have multiple tags at once, and then you just use a compare method to see whether the object has any of the matching tags.
This worked well for the game as in some cases we wanted to be able to check if an object was "Alterable" or "Nature" so that it would react differently to spells, or things like highlights.
The most popular spell ended up being Possess, which naturally meant I also spent the most time polishing it. The spell lets you take control over dormant enemies within the level, which grants the player the ability to do different things. The Thornshell allows you to grab and throw the player character, which lets you cross obstacles and gaps. The Thornshell also doubles as a weight you can put on top of buttons, holding doors and such open, further increasing its versatility.
The Devourer on the other hand lets you consume entities above it like the player or Thornshells, then go to another location and spit them out. I made it especially distinguished from the Thornshell by making it unable to weigh down on buttons, and also being smaller and in the ground, meaning it can go under objects. I believe that these things set them apart from each other and improved puzzle diversity and complexity.
Overall, this project helped me learn more about prototyping systems and setting up examples for designers to further implement. In previous projects I usually ended up both creating the code and setting up the final prefab, but in this case I was able to set up the base example prefabs and then hand it over to another designer to implement the visuals and specific use cases.
If I had more time, I would have liked to polish the logic even more, as the magic system had to be rewritten multiple times on both the casting & implementation side, we would have likely benefitted from more communication and playtesting.
