Carnage at Castle Moon
This game was made as a game project during the first year of studies at Futuregames. It was made by a team consisting of designers, programmers, artists and QA at the school. My main role was Product Owner, but I also worked as a Gameplay Designer.
Project length: 7 weeks
Year: 2022
Team size: 14
Engine: Unreal 4
My roles: Product Owner, Gameplay Design
Game Summary
Description
Carnage at Castle Moon is a single player FPS. You play as a monstrous knight that is part of a living castle on the the moon.
You will be challenged with waves of astronauts who try to destroy the hearts of the castle. Your goal is to survive as long as possible and get a high score.
Trailer
What I did
For this project my main roles were Product Owner and Gameplay Designer.
Product Owner
Organized the team
The team worked remotely and most of the team members had never met before. Because of this it was important to foster a team spirit and active collaboration.
-
I encouraged being online during work hours by always being active myself and making sure to talk to everybody daily and help out where I could.
-
During the daily stand-ups, if anyone was blocked or didn't know what to do, I always addressed that after the meeting.
-
Whenever someone was ill or missing, I kept in contact with them to make sure they were okay and also brought them up to speed when they were back.
Ideation
-
After brainstorming lots of different ideas, we settled for these three that we explored even further.
-
Everybody split up in teams to develop the ideas further.
-
To give us a better understanding of scope, I encouraged thinking of the idea using the following properties:
-
Story
-
Genre
-
Mechanics
-
Game Loop
-
Scale
-
-
With those things figured out we had a good understanding of each idea. The game we then ended up working on was decided by vote.
Moodboard & Styleguide
-
For the moodboard and styleguide, I created this structure where everybody could add and change details during the project.
-
The top row has concept art and the bottom row has a moodboard.
Backlog Construction
-
When the idea and moodboard was done, the team was ready to start working, but we still needed a backlog.
-
As this was a school project and we were using the SCRUM methodology, it was important to invite all team members to plan out the backlog.
-
I created this structure and gave everybody some time to fill out user stories in each category.
-
After that we had a discussion about the notes to make sure nothing was contradicting something else and that we could all agree on the vision.
-
From this result, we wrote tasks in the backlog.
Game Design Document
For this project I chose to use Miro for the Game Design Document.
-
This tool was already used for ideation and was provided by the school.
-
This made sure it was easily accessible by everybody on the team.
-
I created a very simple layout and kept information brief. The goal was to make it easy to digest to encourage the team to use it.
-
This structure also made it easy to update after new decisions was made.
-
I regularly asked the team for feedback to make sure the GDD was according to plan.
Scope
-
The semi-realistic art style chosen for the game made it important to scope the game right so it could be finished on time.
-
This was done in the initial planning, but when the most important gameplay elements were in place I also called a meeting to decide what features to include. I listed all features that had been discussed and asked the team to discuss what to keep.
-
This helped us focus on the features that would add the most to the game.
Set deadlines
-
At the start of the project we would use agile methodology to create and divide tasks.
-
After a couple of weeks it became clear that this was not enough to finish on time.
-
I started having meetings where we set deadlines for important tasks.
-
This helped us finish the game on time.
Gameplay Designer
Design Pillars
The player steps into the shoes as the villain and has to defend three weak points in their living castle. These points share one single health pool with the player and increasingly difficult waves of enemies must be stopped.
Defense
To allow for fast-paced gameplay and movement the level should be small and open with contrasting colors for important objects and enemies. The player should have high mobility and enemies should be killed with one shot.
Fast-paced
The player is a monstrous knight in an organic, living castle. Visual effects and environmental details should be filled with blood and organic material.
Gore
A unique setting where medieval fantasy meets future astronauts in a war that has raged on for a long time.
Colliding worlds
Core Loop
The goal is to defend three points on the map from waves of enemies, with the difficulty increasing each wave.
Protect the castle
The castle has three hearts across the level that must be protected. Every wave a certain number of these hearts is under attack.
Kill astronauts
Run between the attacked points and kill all astronauts that spawn before they reach the hearts.
Get high score
Each astronaut killed adds to the score. The player gets their score when they eventually is defeated and if it’s high enough, it gets added to the high score list.
Gameplay Design
Work Method
I did the Gameplay Design in collaboration with one of the programmers. The goal was to give the player high mobility to be able to quickly move between the hearts when several of them are attacked at the same time. To get a feel for the movement for the game, I started out by doing a prototype with the Unreal first person template and making adjustments with Visual Scripting.
After that I had a discussion with the programmer who then started working on the movement system in C++. During the rest of the project we would have meetings regularly where we discussed improvement and details. We figured out the appropriate values that could be exposed so that I could tweak the character movement to the player’s liking. I played the game daily and also did playtests with external players to get feedback on the gameplay.
Movement
The movement speed is fast and the player has a high level of control. To achieve this, we made the player fall down faster than they jump up. We also gave the player high level of air-control and the ability to jump higher by holding down the jump button.
Dash
The player has a dash ability that allows them to dash in the direction they are looking. The cooldown for this is very fast, so it feels practically unlimited. This was important to let the player move quickly between attacked hearts. To add to the game feel and clarity, I made an effect for the dash that changed the FOV of the camera and spawned speed lines during the dash.
Glide
The player can also glide by holding down the jump button. If the player is falling, they will slow down and start gliding. There is no limit on how long the player can glide, which also serves the purpose of giving the player high mobility when multiple hearts are attacked.
Wave System
For the initial playtesting I prototyped a simple Wave System with Visual Scripting. This version had only spawning enemies, but no progression and very simple elements of randomness. The actual Wave System was done in C++ and was much more complicated, so we needed something quick to be able to playtest the game properly.
For the real Wave System, one of the programmers was assigned to develop it. To get started we had a meeting where we wrote down every step of a wave. This could then be used by all team members when implementing some part of the system, like dialogue triggers for example. The system was then continuously playtested and adjusted during the rest of the project.
Readability
Because of the high pace it was important that the player could easily understand what hearts are attacked and where enemies spawn. For the enemies we made them yellow to be easily seen and made a big particle effect that can be seen by the player from far away.
For the hearts we split it up into two stages of danger. The first being when a heart is included in a wave. A sound is played and a dialogue pop-up appears telling the player what hearts are under attack. The hearts also light up and a smoke effect is played at their base.
The second stage is when a heart is in immediate danger, which means enemies are close to it. A dialogue pop-up appears, a sound is played and the hearts starts to bleed and turn to a deeper red.
Process
Schedule
May 13
Pre-production
May 19
First Playable
May 25
Pre Alpha
June 2
Alpha
June 9
Pre Beta
June 16
Beta
June 21
Gold Master
First Playable
First playable showing simple AI and shooting.
Pre Alpha
Pre Alpha build where AI now targets the player when player shoots at them. Gliding and moon gravity jumping was also implemented.
Alpha
By the Alpha build, we had implemented a Blueprint version of the coming spawning system, which proved difficult to code. A health system was in place. Movement was also tweaked further and a dash was implemented.
Pre Beta
For the Pre Beta an animation system was added to the enemies. The AI pathfinding was also improved and some VFX was implemented. A score system was also in place.
Beta
For the Beta, all features was now in place. Dialogue boxes with important information was now implemented. Still, players found it difficult to know where to go and which hearts where in danger. They also found the astronauts hard to see.
Gold Master
Beyond polishing the game with VFX, lighting, post-processing and audio, we also made some adjustments. The astronaut color was changed to yellow and a location prompt was added to tell the player what heart they where close to at the moment.