Gameplay design, scripting, UX, general design
Project length: 7 weeks
Team size: 6
Fey Foray is a strategic tower defence-like game played in lanes. The game was created as a school project at Futuregames and is developed with Unity.
The fairy king has called for your aid! Command the native fairy units to stop an invasion of alien robots. Summon your troops in the lanes to counter the waves of enemies, gather resources and push back the enemy force to stop the onslaught.
Core loop & player agency
To keep the scope relevant the team focused the first week of production to narrow ideas down and find focal points in the different propositions. Thanks to this we could keep our focus directed on the game’s core loop.
The core loop is fairly simple. The player summons units on a lane, the units walk in one direction and start fighting enemies in the corresponding lane.
To expand territory and gather resources the player can summon a seedling who takes over tiles, making them ‘friendly’. On certain tiles the game summons energy rifts, a resource gatherer, that seedlings can convert into a steady income. …and so it goes.
The simple core and the player agency is the design pillars of the game.
I wanted straightforward mechanics that are easy to learn. The simplicity of the mechanics, where you more or less just summon units, made me put a lot of attention to make the player feel he has agency over the game.
Player agency was implemented through a dynamic, controllable, camera, loosely restricted player movement and an active interaction to gather resources. A lot of testing went into making the player choice matter more than in the choosing of a lane. Most of the iterations to create player agency were scrapped and we found a middle way where the core loop is the central part of the game.
Scripting in C# & HDRP custom passes
In this project we did not have any programmers so me and another team member split the scripting tasks between the two of us.
My contribution in scripting focused on GUI, sound level-& resource manager and complimentary tasks.
The project started as a HDRP project in Unity and we were soon stuck with shaders not working accordingly. I took on the task to solve the lane and troop outlines and spent an time researching the HDRP pipeline and custom passes in Unity. After some prototyping with different settings and shaders I got it to work.
When concepting the AI system I tried to to make responsive but not overpowered.
The first iterations used an AI with direct response only and the players spawning made it react. It acted as a soothsayer which made the game unbalanced. My aim with the new AI was to create a balanced experience where the AI didn’t respond ‘faster’ than a human player would and it was to make decisions based on factors other than a direct response.
The AI core is based on 3 states and a set of responses to player actions. A combination of the three states creates a feeling that the AI is responding to player actions but is not overpowered in its choices and behaviours.
One of the bigger tasks I got to do in the project was the GUI functionality.
The aim of the GUI is to create a seamless human-computer interaction and match the flow of the game.
- A solid core loop is key!
We spent some time to iterate on a core loop for quite some time before actually starting building the game. The time spent on designing before building saved us working hours and prevented miscommunication.
The choice of using the HDRP pipeline was not researched enough to choose it for this project and it bottle necked us quite badly. The choice of version was based on hearsay and in retrospect I would rather see the research being made by ourselves to fit the intended game.