top of page

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


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.


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.

Screenshot of the daily stand-up board
A set of post-its planning out three game ideas


  • 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.​

A moodboard

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.

A set of post-its in different categories in game development

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.

A set of post-its planning out the design of several aspects of the game

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.


  • 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.

Screenshot of the deadline schedule

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.



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.



The player is a monstrous knight in an organic, living castle. Visual effects and environmental details should be filled with blood and organic material.



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.

Illustration of the castle, the knight and symbols for health in the form of hearts

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.

Illustration of the knight shooting an astronaut

Kill astronauts

Run between the attacked points and kill all astronauts that spawn before they reach the hearts.

Illustration of a bloody knight hand in the front of Earth

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.

A gif of the movement prototype
A screenshot of the values exposed in the editor
A gif of the final 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.

A gif of the dash ability


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.

A gif of the glide ability


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.

A gif of the prototype spawning system

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.

Screenshot of the wave system documentation


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.

A gif of the spawning effect
A gif of the heart lighting up

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.

A gif of the heart starting to bleed
Product Owner
Gameplay Designer



May 13


May 19

First Playable

May 25

Pre Alpha

June 2


June 9

Pre Beta

June 16


June 21

Gold Master

First Playable
A gif of the first playable

First playable showing simple AI and shooting.

Pre Alpha
A gif of the Pre Alpha

Pre Alpha build where AI now targets the player when player shoots at them. Gliding and moon gravity jumping was also implemented.

A gif of the 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
A gif of the 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.

A gif of the 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
A gif of the final game

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.

Next Project

bottom of page