CONCEPT
Carnage at Castle Moon is a Base Defence FPS on the dark side of the moon. The game's arenas and quick, snappy movement are inspired by Quake III, with dash and float abilities mirroring modern FPS games.
KILL THE INVADERS
PROTECT THE CASTLE & YOURSELF
GET A NEW HIGHSCORE
GOAL
MY CONTRIBUTION
CLICK A BOX TO JUMP TO THAT SECTION
LEVEL DESIGN
As a level designer, I worked in close collaboration with the environmental artist from the initial ideation to the architecture pass and polish, as well as all steps in between.
LEVEL DESIGN GOALS
The following three goals were kept in mind for each combat space that was designed, as well as the courtyard in-between. These were kept in mind when creating the paper prototype, but got easier to adhere to as the level became playable, three-dimensional space in Unreal Engine.
VERTICALITY
Each of the three combat spaces should feel distinct not only visually, but based on which verticality they are built on. The player should be able to use the verticality against the enemies.
FREEDOM OF MOVEMENT
Any player should be able to traverse the environment without an issue, but skilled players can use their movement toolset to take more efficient paths between combat spaces.
PLAYER ADVANTAGE
There should be paths that only the player can take through both the courtyard and the three combat spaces. The player should be able to position themselves in a favourable position before enemies enter the combat space.
LEVEL DESIGN PROCESS
My six-step level design process. I go into detail for each step throughout the level design section of this portfolio piece.
CLICK A SECTION TO JUMP THERE
1. IDEATION
Level Design Moodboards were a large part of the ideation process. This step included researching architecture, relevant games, and building upon our in-house concept art.
COURTYARD
LIBRARY
THRONE ROOM
GARDEN
2. PAPER PROTOTYPE
The paper prototypes were made digitally using Miro. This allowed for efficient tweaks and measurements. It is also easier to avoid the page becoming cluttered with information.
CASTLE MOON
The first paper prototype of Castle Moon encompasses the entire playable space, i.e., the level. This gave us a foundation of which areas exist, which paths the player and enemy can take, and the size of the level. The treasury was cut in favour of a garden, in order to provide more environmental variety.
THRONE ROOM
The northernmost area. Doors connect to each other area. A zipline would connect to the courtyard, but this was scrapped in favour of improved player movement.
COURTYARD
The southernmost area. Doors connect to each other area. Two catapults would take the player to faraway locations. This mechanic eventually became the launcher pads that are present in the released game.
LIBRARY
The Library is split into three vertical floors. I therefore sliced each floor, with F1 being ground level, F2 connecting to the central walkway, and F3 being the top floor, with a shortcut to the Throne Room. A zipline would connect to the Throne Room.
3. BLOCKOUT
The blockout was created using a Level Design Kit (LDK) provided by the environmental artist. Assets were added to the LDK in regular intervals, allowing the blockout to be built simultaneously, avoiding a bottleneck.
LEVEL DESIGN KIT
LEVEL BLOCKOUT
An early iteration of the level, fully blocked out using the LDK. This version was fully playable and included all planned locations.
The red dots are launcher pads which launch the player into the air upon contact.
A Navigation Mesh allowed AI enemies to move around the level.
The level was scaled down before work on the architecture pass began, as certain areas proved excessive during playtests.
LANDSCAPE
The landscape was sculpted in Unreal and made up of two parts.
The area surrounding the castle was sculpted like a moon crater, which allows the player to see their surroundings despite the large walls of the castle.
4. ARCHITECTURE PASS
The architecture pass is either done by artists or level designers. In our case, it was a level design task. Blockout assets were replaced each time the environmental artist finished an architecture pass version of said asset.
LIBRARY INTERIOR
DRAG SLIDER TO COMPARE BLOCKOUT & ARCHITECTURE PASS
Combat arenas stayed mostly the same between the blockout and the architecture pass. The primary change was the size of the platform that the heart was on, as this improved player mobility in that space. I worked closely with the environment artists which ensured they knew which assets were vital for gameplay and what changes were needed compared to the blockout assets.
LIBRARY EXTERIOR
DRAG SLIDER TO COMPARE BLOCKOUT & ARCHITECTURE PASS
Exterior spaces often saw significant overhauls between the blockout and architecture pass. Each change served a dual-purpose, as they both increased the immersion and created a diegetic boundary for the player. This can be seen in the increased height of both the library and the castle walls. Nothing from the design was lost when art was added, as can be seen by all paths and entrances being nearly identical in both versions of the library.
5. COLLISION DESIGN
Collision Design requires constant iteration from the first build onwards as walls move locations, windows replace walls, or new assets are added. I added blocking volumes (invisible walls) to make sure the player could not escape the gameplay space and changed the collision of meshes to allow either the player or their bullets to fit through holes.
EXTERIOR SPACES
The gameplay space is defined by the castle walls. Blocking volumes extend vertically from each wall's rooftop.
The slanted rooftops are also part of the playable space, though the player glides off them due to the non-walkable collision that I assigned.
Players may gather high vertical momentum. A large blocking volume was therefore added across the sky to prevent players from flying too far up.
The Player Collision view mode shows the size and shape of all objects and blocking volumes the player can collide with.
Objects that are regularly interacted with has complex collision, allowing the player to shoot through windows or the holes on railings and broken walls. Rooftops, spires, and rocks have simple collisions for the sake of performance.
INTERIOR SPACES
The collision of objects may sometimes need to differ depending on their location. Here, jumping through the windows to the right would lead you back into the level, while the left ones would take you out of bounds.
Rather than changing the collision of all windows to block the player from jumping through them, blocking volumes can be used when necessary.
In contrast, players never need to shoot through the shelves of the bookshelves, so they kept their simple collision.
ENCOUNTER DESIGN
6. POLISH
Before polish, there is a hand-off. In this stage, artists worked on adding environmental props and finalising the level's lighting. I could then begin polishing the level. This was done by giving myself a checklist of things that improve the experience but are easy to miss, such as:
1. Is there z-fighting in the level?
If yes, move the assets or hide it.
2. Are there any floating assets?
If yes, move the asset or adjust the landscape.
3. Can the player see unintended parts of the level?
If yes, adjust the blocking volumes or if time allows: fill in this area with assets.
4. Are there lighting artefacts in the level?
If yes, find out why and let the lighting artist know.
5. Does any part of the level look visually repetitive?
If yes, add decals or alternate assets.
6. Does the average session last shorter than 20 minutes?
If no, tweak the difficulty. Let others test if you have gotten too good.
HEARTS
Being a Base Defence game, the player needs points to defend. In Carnage at Castle Moon, these points consist of three hearts, each in its own, distinct location: a library, garden, and throne room.
LIBRARY
THRONE ROOM
GARDEN
Hearts emit a glow during waves that they are being attacked under. Particles will also begin to float around the heart once the enemies attack it, as can be seen here.
When enemies are nearby, but not attacking, the hearts change colour to purple.
A warning message appears at the start of each wave, telling the player which heart is under attack during that wave. In this case, it is the heart in the Throne Room.
Two hearts can be under attack during the same wave, in which case the warning message at the start of the wave includes both area names.
All three hearts are attacked at the same time in later waves, signified by this message at the start of each wave.
Other messages include: a unique message for the first wave that briefly explains the goal in case they skipped the tutorial messages, and an end-of-wave message so the player knows that they can rest a moment.
The number of hearts active per wave was adjusted in the Wave Manager, which is a Blueprint actor placed in the level.
The active hearts is random, with a small exception for the first three waves. Although the order is still random, the player will have the chance to defend each heart individually before several hearts are attacked simultaneously. This allows the player to memorise areas before the difficulty begins to increase.
ENEMIES
The visual design of the enemies was a collaboration between the narrative designer, character artist, and gameplay designer. Enemy behaviour, however, was designed and developed by the gameplay designer, pathfinding and spawning programmers, and level designer (me).
The enemies come in the form of astronauts in bright-yellow space suits that contrast against the grey and red castle environment. They can be seen travelling in organised ranks on their way to the hearts.
They will chase after a player who gets too close, stopping to attack with their melee weapon if they catch up. Their speed increases significantly when chasing the player. Luckily for the soon surrounded player, one shot is enough to dispatch an enemy. An enemy that loses sight of the player will return to hunting down the heart.
A skilled player will dispatch enemies on their way to the heart to avoid damage that wave. Their colourful suits and flashlights make them easy to spot even when travelling quickly around the level.
The number of enemies was regularly iterated upon throughout the project based on feedback from playtesters.
This was balanced using the Wave Manager, a Blueprint actor in the level. My mindset when pacing the game was to slowly escalate the intensity from the very start. A rising challenge is necessary in short, arcade experiences.
The number of enemies decreases when a new heart is introduced. This allows players to get their bearings rather than being overwhelmed by enemies moving to different areas.
SPAWNING
A Wave Manager in the level controlled the spawning of enemies.
The spawn locations were chosen by placing spawn point Blueprint actors throughout the level.
MAP OF ENEMY SPAWN POINTS & PATHS
HEART ZONES
GARDEN
THRONE ROOM
LIBRARY
Each of the game's three zones was colour-coded. The garden is green, the throne room is yellow, and the library is blue. This categorisation was strictly done to expedite the placement of spawn points and is not visible during gameplay.
Each coloured dot represents a spawn point, with the extending lines showing the paths enemies take to get to the heart that is under attack during that wave.
Each coloured dot on the map has a respective spawn point in Unreal in the form of Blueprint actors, similarly colour-coded. These are not visible when playing the game.
The naming conventions and structure were also important to allow the rest of the team to understand the Blueprint hierarchy.
Each spawn point was numbered so we could efficiently discuss, e.g., "Library2" or "Garden4".
The spawn point order corresponds to their priority. Early waves will prioritise spawning enemies in the first few spawn points rather than the last ones. More spawn points will activate as the difficulty increases.
The spawning and waves were highly customisable. The Wave Manager allowed me to adjust how many enemies spawned the first wave, and how long players have to acclimate before it begins.
The downtime between waves allows players to find an advantageous position. The 1-second delay between enemy spawns gives the player a chance to kill enemies faster than the time it takes for more enemies to spawn.
A bright, blue beam of particles appears when an enemy spawns, revealing its spawn point to the player. As enemies spawn in groups, it is hard to miss a cluster of enemies even if the spawn point is far away or on a different verticality.
PATHFINDING
A navigation mesh (navmesh) was used for enemy pathfinding. A Nav Mesh Bounds Volume covers all areas that enemies may walk on. Nav Modifier Volumes were used in any part of the level where we did not want enemies to walk, as such a volume "cuts" out a hole in the navmesh.
The neon green colour on the ground is a visual representation of the areas covered by the navmesh. The yellow volume is the Nav Modifier Volume.
There are times when the navmesh must be manually adjusted. This can happen when the navmesh covers an area that the enemy AI cannot traverse, which results in an enemy getting stuck. Nav Modifier Volumes have been used along the short railings in this instance.
Another option is to adjust the navmesh in the Project Settings, as changes there affects the entire navmesh. This is a good option for making sure AI characters can walk where they are intended to, such as up stairs.
Nav Mesh Modifier volumes were sometimes used together with carefully placed props to force enemies down specific routes.
Similar techniques were used to separate enemies arriving from different locations but going toward the same location. All AI enemies would otherwise choose the same, fastest route to their destination.
SCRIPTING
A level is more than architecture, it is also events that trigger when moving around the level, or entering and leaving zones. This is where blueprint scripting is especially useful. Below are some of my contributions.
PLAYER DEATH
The game fades out once the player dies. Player input is disabled, and the Game Over level is loaded once the screen turns black.
The game also fades in when the game begins.
ENTERING COMBAT SPACES
All three combat spaces trigger a pop-up box to appear in the top-right corner, telling the player which area they are currently in.
A trigger encompasses each combat space. Location information is sent to a Widget Blueprint when the player enters the volume, triggering a function which fades in the text.
EXITING COMBAT SPACES
The text fades out when the player leaves each location.
Leaving the volume triggers a fade out function in the Widget Blueprint.
