top of page
Mau Lundell
Technical Designer
About:
Fey Foray is a high-paced lane-warfare strategy game. Try to use your forest units to defend against and defeat the invading space robots!
Details:
Roles:
Gameplay Designer, Programmer,
Scrum Master
Time:
7 weeks, January-March 2021
Team size:
6 (3 designers, 3 3D artists)
Tools:
Unity, Perforce, Miro, Discord
Workspace:
Online (Futuregames project with communication through Discord)
Gameplay Coneption
My Contributions
Gameplay Design
Core Gameplay
Balancing
Unit Design
Enemy AI Player Design
Prototyping
Gameplay Blockout
Gameplay Iteration
C# Programming
Unit AI
Player Spawn System
Enemy Player AI
Waypoint System
Animation & VFX Controll
Unit System
A Lane-Warfare Game
The core of the game started as a Tower Defence. But we wanted to stray from the static gameplay that easily comes from those kinds of games.
To enforce a stream of constant decision making we made it into a “Lane Warfare”-type of game where both sides’ unit’s advances. This gave the game a lot more urgency in the choices made.
A "Soft"
Rock-Paper-Scissors
We created the units with a "Soft" rock-paper-scissors type of approach. This made it so that the units had a clear purpose in what they are good and bad at.
It also lets the player experiment with different kinds of strategies because there isn’t one best strategy at all times.
Concepts made by
the amazing Cecilia Örnhult
and Andreja Cordeus Kavcic
The Melee:
HP: Medium Squishy
Damage: Hits pretty soft
Attack Speed: Fast
Beats
Beats
The Ranged:
HP: Very Squishy
Damage: Hits hard
Attack Speed: Pretty fast
The Tank:
HP: A Ton
Damage: Hits hard
Attack Speed: Very Slow
Beats
Having these set guidelines for how interactions between units should turn out made it a lot easier to balance the units against each other.
The Melee
The Seedling and
Balancing Economy
To create a sort of back and forth flow in the game we decided to create an economy system. To create this we added a non-fighting unit; The Seedling.
By planting a Seedling in an energy rift lets you gain economy, and the further away from your base it’s planted the more you get. This decision made it so that we could easily balance the progression of the economy and the difficulty curve of the game.
Keeping the
overall balance
This chart shows how the different mechanics affect each other. Whenever we made a balance change we always kept this chart in mind so that we were aware of what every change might affect in the other parts of the game.
I also made it easy for us by setting up all these variables to be easily available in the editor so we were able to quickly iterate with different stats.
Coding AI
One of my big responsibilities during this project was to code the Units AI. Since this was my first 3D project in Unity I had to keep it simple to make it easier for myself.
To make the Units move in a simple way I used the built-in Navmesh System. By using this prebuilt movement system I could focus more on the design aspect of the attacking.
Press to expand deeper
into the Unit Coding!
Units work,
but aren't great
My biggest issue during this project was that I made most of the unit coding in only 2 scripts, the “UnitAIMovement” and the “UnitAttacking” scripts.
They were problematic because they were clunky and easily broke which meant only I as the original creator was able to change things in it.
Unit
Banner
Code
Doing it Right
When the time came to code another unique Unit I made sure that the code structure would be clear to everyone in the project.
And as such the Seedlings functionality was created with a clear Brain structure with underlying scripts executing specific actions. The Enemy AI Player scripts were also created with this in mind.
Enemy Player System
Finding A Structure
Because the game needed to be singleplayer we had to think about how to create an AI to play against.
When setting up the structure we decided to have a few set actions to take. They were all based upon what we thought an actual player might want to do in different situations.
The Enemy Player
This is the structure we ended up using to try and convey the feeling of an actual player in-game code.
Brain
The brain holds all the information about the current state of the enemy player. These variables affect the different spawn patterns.
Random Spawn
React Spawn
It randomly "decides" to spawn units in a lane. It does it more frequently as the game progresses.
It will prioritize lanes with a lot of units but also tries to create its own sneak attacks.
This acts as the Enemy AIs own decisions. This gives more depth to gameplay since the player also needs to react.
The enemy can "choose" to either react or ignore the players summoned units.
It has a high chance to respond but doesn't always. It is capped so that it will eventually respond. This makes it feel like sometimes your unit is a threat and sometimes it isn’t.
This acts as the enemy reacting, creating more intense battles around the map.
Emergency Spawn
It understands if it's taking a heavy attack and will spawn units to defend against the oncoming threat.
It tries to not spawn too many units to not go bankrupt.
It will prioritize surviving which makes the battle more hard-fought.
Game Interaction
EnemySpawnerScripts
enemy2
Spawning Variables
The types of units and the number of units spawned by the enemy AI are based upon the current state of the AIs health, economy, and amount of Player Units.
These variables helped us create a balance where the enemy AI spawns more intensely as the game progresses. This means that If the player is too slow to set up the enemy AI will win, creating more intense matches.
Balancing AI
We wanted the AI to be able to build some different unit lineups because of the Unit diversity. To do this we create a lot of Spawn Patterns that the AI could choose from.
We found good unit lineups by playing the game, getting a feel for the Units and picked the formations we thought had the most identity. Then we gave them a range to make the AI know what kind of unit to spawn to easily balance the game.
This
or
That?
Scrum Master
I was the scrum master during this project. It has let me really think about how I communicate information to my teammate and keep the workflow up.
Sprint System
My first task as Scrum Master was to set up a structure for how I wanted to convey information to my teammates.
I started with creating a clear backlog, where we had areas of work, prioritization and a clear setup that showed the current progress. This setup helped everyone understand the full scope and kept the workflow up.
Building Sprint Logs
I and the Product Owner sat down for each sprint to build the Sprint Log with the contents needed for that sprint.
We built them with the team's abilities in mind to create even work for everyone on the team while also making sure that everything got finished at the time needed.
Sprint Review &
Burndown Chart
Everyone could bring up concerns and thoughts during the sprint review held at the end of each sprint. This helped us improve on both the good and the bad from each sprint.
I created a burndown chart that clearly showed the progress during each sprint. This helped me when I set up the next sprint to estimate the about of work that could be done as a team each week.
Blueprins
What I'm proud of:
Unit Design
Designing the Unit System was a big task that ultimately turned out great. The interactions between how the player and Enemy player AI can use their Units created a lot of fun gameplay. It was a blast trying to really balance it well.
Unity C# Scripting
I was a bit nervous at the start of the project since it was my first 3D Unity project. But my previous knowledge of Unreal and Gamemaker had me confident that I would be able to be the main programmer and could create something great.
Finding and cleaning up bugs throughout the project felt like a breeze and the end product works like a charm. And I really feel like I’ve gotten a good hang of yet another engine.
Project Structure
This was my first big project where I got to fully be the one in charge of how to structure the workflow, and it worked out great. With the help of my previous project structures, I felt like I was able to create a Scrum environment that everyone on the team could benefit from.
bottom of page