FeyForayDimmExtra2.png

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, Lead 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)

 

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

Melee2.png

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

Tank2.png
ETankConcept.png

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.

 
 
 

UnitAIMovement.cs

UnitAttacking.cs

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.

BannerBrain.cs

BannerConvertToRift.cs

BannerMovement.cs

BannerOvertake.cs

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

Random 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 brain holds all the information about the current state of the enemy player. These variables affect the different spawn patterns.

React Spawn

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.

 

EnemyUnitSpawner.cs

 
 

EmergencySpawn.cs

ReactSpawn.cs

RandomSpawn.cs

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.

 

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.