Week 6

Week 6

At the halfway point of the project I feel as though I’m still a little further behind on the level design than I would like to be, however many of the core mechanics are either fully completed or just lacking additional polish in the form of audio and particle effects. My focus for this week was to finally connect both sides of the map to each other in a fashion that would allow me to expand outwards from a single path, as well as to fully implement a power system and fix the blueprint errors I was getting from the UI section of the door and electric switch blueprints.

As previously stated, the two sides of the map have finally been connected. This was done by using a reasonably tight corridor, akin to those found in the CoD zombie maps “Moon” and “Five”, which connects two rooms similar in size to that of the room at the top of the stairs in the double staircase room. Each room has a couple of windows and share a single random weapon box location. The whole area is being treated as one room as to make the cost of getting from the spawn room to this room equal. There is a third doorway in the corridor with a door which costs 1250 points, which will eventually lead to an engine room of sorts where the power switch and a teleporter mainframe will be. I also added a small tutorial room in place of a window in the starting room, as per the advice of my tutor. Said tutorial room will have the player spawn with 500 points facing a door which costs 750 points, zombies will then spawn at the window behind them, forcing the player to kill the zombies and increase their points so that they can afford the door and enter the map properly. 

New tutorial room, with the door the player will be facing when they spawn.
New tutorial room with window that will be behind the player once they spawn.
Door to tutorial room from former spawn room.
Door from double staircase room leading into new area which connects both sides of the map.
Corridor behind door leading into connector room.
Connector room across from the corridor as seen above.
Connector room from the opposite corner of the room.
View from connector room into corridor connecting both sides of the map.
View of corridor from opposite end.
Doorway into room at the end of said corridor.
View into other connector room from corridor doorway.
Second connector room with new random weapon box location.
Second connector room from opposite corner.
View into second connector room from upstairs area.

The power system is an integral part of the CoD Zombies experience, having been included in all but 2 of the 10 zombie maps featured in World at War and Black Ops. As such, I decided to finally implement it this week. Aside from the usual UI Widget creation, player collision and player interaction sections of the blueprints, all the blueprint is doing is setting a “PowerOn?” variable to be true, which is then checked in every other blueprint that requires it, and “activates” them so that they are available for use. At present these power dependent blueprints include BP_Juggernog, BP_StaminUp and BP_ElectricTrapSwitch. Since I had been having blueprints errors with the remove from parents nodes in the BP_Door and BP_ElectricTrapSwitch assets for a while, I decided to put the creation and removal of all UI widgets on custom events that can be fired from wherever, which seems to have removed all blueprints errors.

BP_PowerSwitch in game (unlit)
BP_PowerSwitch’s blueprint.
BP_ElectricTrap with updated custom event being called for UI.
BP_Door’s updated UI blueprints.
BP_Door’s updated blueprints.
BP_ElectricTrapSwitch’s updated blueprints.
BP_ElectricTrapSwitch’s updated blueprints for UI.



This week also saw me begin working on wall weapons. Wall weapons in CoD zombies are weapons that can be purchased off the wall in exchange for points, with the amount of points required correlating to the effectiveness of the weapon. For example an Assault Rifle would be between 1200-1500 points, whereas a Pistol would be between 250-500 points. All weapons used are those created by my collaborator. Before I could begin on the blueprint proper, I had to first create chalk outlines for each weapon in photoshop before creating materials for each weapon in UE4. Each material was then added to a plane in the blueprint actor. The weapon meshes were then added to fit inside the chalk outline, where their visibility will be set to none until bought.

Grenade Launcher outline
Pistol outline
Assault Rifle outline
Sniper Rifle outline
Shotgun outline
RPG outline
Weapon outline material. While this one specifically is for the Assault Rifle, they all share the same material blueprint
What the BP_Weapon_Outline’s look like in game before being purchased.
BP_Weapon_Outline’s in game after being purchased.

And finally, here are 2 videos made to highlight the random weapon box, power system, electric trap, juggernog, and the windows. The weapons and zombie AI shown were created by my collaborator.

Week 5

Week 5

This week my plan was to finish building and adding preliminary lighting to the double staircase room I began building last week, and to began creating the random weapon box. 

As the double staircase room was so large, I decided to add a couple of small bonus rooms at the top and bottom of the staircases and multiple windows so that it wasn’t just blank walls. The small room at the bottom of the staircase contains a little corridor then window, and is designed to just seem like a blocked off corridor, whereas the the room at the top of the stairs is much larger, and will eventually be filled with shelves.

Large double staircase room with lower and upper extra rooms pictured.
Large double staircase room pictured from top of stairs.
Top of stairs area with box location pictured.
Extra room at top of stairs interior.
Extra room at top of stairs interior.
Extra room at top of stairs interior.
Extra room at bottom of stairs interior.

This week I also finally began creating the Random Weapon Box, better known as the “Mystery” Box. In Call of Duty, the Mystery Box is a wooden crate that can be opened for 950 points. Once opened, the box will cycle through a number of weapons while playing a music box tune. It will then land on a random weapon that the player can either swap for their current weapon or leave if undesired. After a random number of box uses, usually between 8 and 12, the box will give the player a teddy bear, which signifies that the box has been used too much and will move to another box location chosen at random somewhere in the map.

For this blueprint, I used logic from a YouTube tutorial (https://www.youtube.com/watch?v=K5xv5NZEj9k&list=PLdhUb7-wFwSZyDb1vvWjuG-TGhWT2C5tJ&index=7&t=0s &  https://www.youtube.com/watch?v=pteIxvj41vU&list=PLdhUb7-wFwSZyDb1vvWjuG-TGhWT2C5tJ&index=6&t=0s) mixed with logic I used for other level mechanics, although incidentally the tutorial does not cover actually giving the player a weapon so this is something that I will look to work on and add next week. The repeating logic is that of the now standard on collision box overlap it casts to the player and checks that they are in a collision box before creating the UI prompt for the box, and on end overlap it removes it from parent. For this particular blueprint I decided to set the adding and removing off the UI in custom events which could be called from anywhere easier. During this section of the blueprint I also check to see if the box is currently set to be visible through a branch.

During the interaction section a series of branches are checked ensuring that the box is open and that player is in the collision box and has enough points for the box before opening it and removing 950 points. Once opened the UI prompt for the box is removed and at the end of the blueprint a custom event to open the box is called.

Collision and Interaction section of random weapon box blueprint.
Box UI section of blueprint.

Once called, Open Box sets the box open variable to true and begins a sequence, firstly setting the is closing variable to false and playing a timeline that opens the lid of the box by rotating it. The sequence then goes through a delay which is set through the variable box open duration, then sets is closing to true and box open to false, before reversing the lid opening timeline. Once finished a branch checks if is closing is true, where it then goes into a switch on int which is set by a random integer in range which is currently set to give the box a 1 in 12 chance of moving when opened. If it does move a custom event “Move Random Weapon Box” is fired.

Open Box section of random weapon box blueprint.

Once the “Move Random Weapon Box” event is fired a branch checks whether show random weapon box is true or not, which then sets the players points to have the 950 points they spent on the box back since it’s now moving. Following this all BP_RandomWeaponBox actors of class are gotten, which is then followed by setting a temporary integer variable twice while find and and length arrays get all the box locations in the map and minus the current box being used from the array. Following the second set temporary integer variable a branch checks whether or not the new box chosen is the same as the current one. If true to cycle repeats itself to get a new box, and if false a delay is then fired followed by a set show random weapon box as false and then finally a custom event to toggle show random weapon box, turning on the visibility for the new box location. Initially I planned to have the box have a small animation following it moving using a timeline to have it float up into the air and spin away, however for a reason I couldn’t determine the random weapon box would only successfully move once with the animation in use and wouldn’t reappear after moving the second time. As such, until I can figure out why this is it’ll just disappear and reappear. If I cannot fix the issue at all I’ll probably just have it disappear in a cloud of lightning using a particle effect.

Move Box section of blueprint, part 1.
Open Box section of blueprint, part 2.

I also created a custom emissive material for the text on the mystery box (two question marks) that strobes between white and off-white.

Emissive material for text on top of box.
Random Weapon Box in game.
Random Weapon Box location in game.



Week 4

Week 4

For week 4 I really wanted to push my focus purely towards level design and getting an idea of what I wanted to do for the rest of the map, and how I was going to really showcase my level mechanics in a unique and fun manner. Unfortunately, due to being out of town for a couple of days I didn’t get as much work done this week as I would have ideally liked, which means that next week I’m gonna have to really get my head down and work hard to get back up to speed.

Said previously mentioned level design work was based upon expanding along the path out of the door in the lower spawn room area, working on a large upstairs room, as well as beginning on the path from the upper area of the spawn room, creating a room that would really highlight the electric trap, before beginning work on a large room centred around two “grand” staircases leading to another upstairs area.

Large room to centred around two staircases leading to an upstairs area. Still in the process of making this room.
Small corridor leading into “grand” staircase room.
Small room designed to highlight the electric traps positioned well above the ground either side of the centre wall.
Another picture of the electric trap room with light and switch on wall.
Large L shaped room up the stairs from the lower spawn area path as seen in the last post.
The same as above but with lighting.
Electric trap room with lighting.

I also updated the Electric Trap blueprint so that the switch could set and activate two traps simultaneously.

Updated electric trap blueprint, which includes a new branch checking an editable boolean variable to see if the trap is a double trap or not, before activating either just one or two electric traps.

Week 3

Week 3

For week 3 I wanted to shift my focus onto expanding the map beyond the initial starter room, as well as go back to the Window mechanic and polish its blueprint so that it worked as intended for both the player and the enemy AI. 

Expansion of the map began in the form of a corridor extending outwards from the door on the lower floor area of the starting room. Said corridor then has a door in between 2 windows into the next area of the map, as well a small room to the left of the end of the corridor, where I will eventually place a random weapon box location. Both the corridor and the end room have windows in them. 

Small room before doorway into corridor proper.
Corridor beyond small room. The main path of the map continues through the room on the right while the room at the back will eventually contain a random weapon box location.
Room at the end of the corridor. Not fully lit as I’m unsure how I want to light it for when the random weapon box is in.
Other side of back left room.

The room behind the door also has a window in it, as well as a doorway to a staircase which takes the player upstairs. This where the map expansion ends for now. All new areas are lit, though more lighting will potentially be added going forward depending on how I want to do the lighting once the level is done. 

Back view of corridor from doorway of back left room.
View of windowed room on the right from inside it.
View from the bottom of the staircase.
The top of the staircase.
View from the top of the staircase.
View of the top of the staircase room and through the doorway where the level will continue.

As previously mentioned, I wanted to go back to the BP_Window mechanic this week and polish it so that it both worked as intended for the player and for the enemy AI. Previously, the player could repair the barricades on the window but only had to press F once on it for the full window to repair as the blueprint didn’t stop once initially fired, whereas the intended function was for the player to have to stand by it for the full duration of the barricade repairs. The same basic idea also applied to the zombie AI tearing down the barricades, with the barricades only disappearing if the zombie was in the collision box. If killed it would stop. 

To start on this I duplicated the existing BP_Window and focused on the zombie side first, adding a new collision box for the enemy AI and setting it so that on begin overlap it would cast to the AI_Character and set the boolean variable “AI In Collision Box?” to true. Then it would check a branch to see if it was true, followed by a delay and then another branch checking if Pipe 1 (barricade 1) was removed. If false it would fire a function to remove pipe 1, and if true it would go straight into another branch checking if pipe 2 was removed. The remove pipe functions also set a boolean variable “PipeX_Removed?” to true. This process repeats for all the pipes, while constantly checking if the zombie is in the collision box, with the variable being to set to false upon component end overlap.

The new player repair window portion of the blueprint works in much the same way. After the event interact function is fired upon player interaction with the window, it casts to the MainCharacter, after which it checks if they are inside the collision box, then checks if Pipe 1 is removed. If true, it fires the function “Pipe1_Repair”, in which the boolean variable for “Pipe1_Removed” is set to false. This process again repeats for the 6 pipes, until at the end where the boolean variable “Window Fully Repaired” is set to true and the repair barricade widget it removed from parent. 

Default state portion of BP_Window_Fixed.
The player collision, UI & repair window areas of BP_Window_Fixed.
The AI collision & barricade removal portion of BP_Window_Fixed.
Pipe 1 Repair function within BP_Window_Fixed. There are 6 versions of this function for each of the pipes, with all of them being identical.
Pipe 1 Remove function within BP_Window_Fixed. There are 6 versions of this function for each of the pipes, with all of them being identical.

Although the BP_Window mechanic is now working pretty much entirely as intended now, there is still a glitch wherein if the player enters their collision box while the zombie is in theirs and breaking down the window the zombie will stop breaking down the barricades. I don’t know what is causing this to be honest.

After finishing up with the blueprint and testing it to ensure it worked properly, I went about replacing all the existing BP_Window’s in the level with BP_Window_Fixed. My next priority is ensuring that once the window has been fully broken down the zombie can climb through into the map. Since the zombie AI and any potential animations for it are not my concern I plan to just set the collision for the lower portion of the barricade to none but just for the zombie (if that’s possible) and have them just walk into the map, although having the zombies walk through doorways has been an issue this week. It seems that the nav mesh is being cut off by BP_Door’s placed in the level, which stops zombies being able to walk through them. This has been partially fixed by using NavLinkProxy’s, however these cause the zombies to walk back and forth between doorways before walking through them properly.

Week 2

Week 2

Following the modular kit environment tests and subsequent creation of a starter room for the map from week 1, I decided the get the creation of a new skybox out of the way. As the map is set on a spaceship in the Cygnus constellation it would obviously have to be in space. After some research for what colours to use I used a program called “Spacescape” to create a skysphere texture which could be imported into UE4. The raw material was then added to a material, which was added to a new skybox blueprint, which was then placed into the level.

The exterior of the level in the new skysphere.
The raw texture of the skysphere export in the new skysphere material.
The raw skysphere material exported from Spacescape.

After implementing the new skybox into the level I began working on another level mechanic, the electric trap. In CoD Zombies the electric trap is traditionally a device placed above a doorway or narrow corridor which when turned on shoots bolts of electricity downwards, killing anything that passes under it when activated by its switch which is usually just next to it. Although there are several variations of it across all zombie maps, I based mine on the original as seen in the map Verruckt

The electric trap in the map Verruckt in World at War.

I decided to create the electric trap and electric trap switch as separate blueprints actors, with each BP set as a variable in the other so that they can communicate with each other in level and allow to have multiple in the level. The electric trap switch works in much the same way as most of the other level mechanics I’ve done in that once the player enters its collision box a UI widget is displayed prompting the player to “Press F to activate electric trap for 1000”. Once the trap is activated a series of branches are checked to see if the player is in the collision box and that the trap isn’t on cooldown or currently active. Once these are passed a custom event in both the BP_MainCharacter and the electric trap proper are activated. After this a boolean variable for the trap being activated is set to true and a delay timer for 30 seconds begins. After this the trap activated bool is set to false and a trap on cooldown bool is set to true. Another 60 second delay follows this before the trap cooldown is set to false again.

Once the custom event in the electric trap is activated, a series of functions which fire line traces which constantly check if they are casting to the player are fired. If a line trace hits the player it sets their health to 0.1. After 30 seconds all the functions are cleared and the line traces are turned off, deactivating the trap.

BP_ElectricTrapSwitch and its UI widget prompt in game.
BP_ElectricTrapSwitch in editor.
BP_ElectricTrap in BP viewport.
BP_ElectricTrap firing line traces in game.
BP_ElectricTrapSwitch’s full blueprint.
BP_ElectricTrap’s full blueprint. I do feel as though I haven’t been as efficient and clean with this blueprint as I could have been but it works for now.
1 of the 5 Bolt Trace functions within BP_ElectricTrap.
1 of the 5 Bolt Trace functions within BP_ElectricTrap.
1 of the 5 Bolt Trace functions within BP_ElectricTrap.
1 of the 5 Bolt Trace functions within BP_ElectricTrap.
1 of the 5 Bolt Trace functions within BP_ElectricTrap.

Following the implementation of new AI enemies into the project, I added small spawn rooms to the back of the windows in the level so that the zombies have a space to spawn in. Following this I am going to working on the BP_Window once again to ensure that the AI zombies can enter a collision box and tear down the pole barricades on the window, before entering the level.

Small spawn room behind the BP_Window’s throughout the level in unlit mode. These rooms have no lighting so they’re too dark to screenshot in lit mode.

Week 1

Week 1

In accordance with my project plan, my first port of call at the beginning of my project was to work on the core level mechanics with the most important of these beings the purchasable doors and debris and the repairable windows/barricades, as well as also setting up a points variable in the first person character, as well as a crude health system. Points are gained by shooting/killing zombies, with 10 points awarded for shooting them, 60 for killing them, 100 headshotting them and 130 for melee killing them.

Before getting into the level mechanics, I’ll show off the blueprints within the player character. 

Health Regeneration blueprint within BP_MainCharacter.
Custom events for when a window is repaired, which adds 10 points to the players total, and for when the player dies, as well as a dev tool that adds points to the player so that mechanics can be tested.
The interaction blueprint within BP_MainCharacter, through which all interaction with level mechanics is handled. The player and mechanics communicate via a blueprint interface and ray tracing. Also pictured is the functionality for handling the custom events for BP_Juggernog, BP_StaminUp and BP_Door, as well as the sprint functionality.
The damage function within the player, which when called will subtract 0.2 of the players health. Depending on whether or not they have Juggernog this will either kill them in 2 hits or 5.

The way the purchasable door/debris blueprint works is that when the player enters the collision box a widget is created with the prompt “Press F to buy door for (price)”. The price of the door is an integer variable which can either be set to be 750 points, 1000 points or 1250 points. A series of branches checks to see what the door price is and displays the corresponding widget on screen. If the player has enough points to open the door, they can press F and the corresponding amount of points will be deducted from their amount. This will cause the door to move upwards on a timeline. Once a door is opened it is open permanently.

(Above) BP_Door in game                  (Above) BP_Door’s blueprint.  BP_Door's in game UI widget. (Above) BP_Door’s UI widget in game.   

In all iterations of Call of Duty: Zombies, the way the repairable window/barricade works is that zombies will spawn behind the window, which is fully barricaded with 6 poles at the start of the game. If the zombie is not killed it can tear down all the poles, at which point the window is fully open and the zombie will enter the map. Once poles have been torn down they can be repaired by the player, who will gain 10 points for each pole repaired.

As I began developing this asset before I had any AI to spawn behind it, I decided to just work on the player interaction for now, and would come back to this asset to finish once I had access to AI enemies. As such, at the beginning of the game the blueprint is set to set all of the poles visibility and collision to none. When the player enters the collision box a widget is created prompting them to “Hold F to repair window”. Upon pressing F the poles have their visibility and collision turned on one by one until all 6 are “repaired” at which point the widget is removed from parent. While this works fine for now, the blueprint for it quite messy and inefficient. It also doesn’t work as intended as the player only has to press F once to repair the whole window rather than holding it, so this is an asset that I’m going to go back to soon.

BP_Window repair prompt, displayed when the window has any poles missing.
BP_Window in editor, fully repaired.
BP_Window blueprint, part 1. Currently long, messy and inefficient.
BP_Window blueprint, part 2.

Perk-A-Cola’s are an important part of the Call of Duty: Zombies experience, and well before the beginning of the project I’d had the idea to recreate a perk system in UE4 just to see if I could. The result was a fully functional “Juggernog” perk. A play on the word “Juggernaut”, Juggernog increases the players health, meaning that rather than dying in 2 hits from a zombie, it takes 5. The blueprint for this starts of very similarly to the door and window in that once the player enters the perk machine’s collision box a widget is created, displaying the prompt “Press F to buy Juggernog for 2500”. Upon pressing F, branches are checked to see if the player has equal to or more points than the 2500 required, and whether or not they already have the perk. If true and false respectively, a custom event within the player character blueprint is called increasing the players health from 0.4 to 1. This also effects the players health regeneration blueprint, which checks on event tick if the players health is still is designated maximum amount, steadily increasing it if its lower than max after a delay after taking damage.

BP_Juggernog in game with UI widget prompt.
BP_Juggernog blueprint.

A second perk was created shortly after Juggernog was implemented as I figured it’d be easy enough to add. Stamin-Up increases the players sprint speed and stamina, as well as decreasing the cool down on stamina regeneration. Although we don’t as of yet have a stamina system for the player, setting their sprint speed to be higher for longer once the perk is purchased was simple enough to add. The blueprint works almost identically to Juggernog’s, and will be updated once a stamina system is implemented, although this as well as all other perks will be done my collaboration partner, as it falls under the umbrella of player mechanics more so than level mechanics.

BP_Stamin-Up in game with UI widget prompt.






BP_StaminUp blueprint.

While much of this week was spent working on level mechanics, I also wanted to begin conducting environment tests with the modular kit I was to use in order to get a better understanding of how best to use it, especially as it was quite a large one. After studying some of the example maps that the modular kit came with, I went about creating a decent sized room that could act as the starter room of the map I was to make. Starter rooms in CoD Zombie maps traditionally have 4-5 windows and 2 doors, and typically set the theme visually for the rest of the map. With this in mind I opted for a medium sized rectangular room with 4 windows strewn around each corner and side of the room, with 2 doors at either end giving the player 2 choices of path to go down. I also opted for one side of the room to have a large window to show off the space skybox, which wasn’t added until week 2. The lighting, although not final for now was added as a result of playing around to see what could work well going forward, as temporary lighting for the level was needed anyway given how dark it the modular kit/skybox are. It mostly consists of spotlights, with some point lights being used for some of the wall pieces. I wanted to keep it dark and creepy but have everything be perfectly visible for the player.

View of the starter room from the corner. The 2 boxes in the centre of the floor are placeholder enemies that are spawned at the beginning of each round. The skybox which can be seen out the windows was not added until week 2 and will be discussed in a separate post.

Games Design Project – “Heart of Cygnus” – Intro & Pre-Production


Welcome to my development blog for my games design project, “Heart of Cygnus”. This blog will be updated weekly for the next 12 weeks and will showcase the development process for my project.


For this project I will be creating a Call of Duty: Black Ops (2010) era Zombies map in Unreal Engine 4. “Heart of Cygnus” takes place upon the eponymous research vessel, investigating strange activity emanating from the black hole Cygnus X-1. As the ship is drawn into its event horizon, all but one member of the crew falls dead before being reanimated as zombies, forcing the sole survivor, the player, to fight their way through hordes of the undead.

As an aspiring level designer who’s previously created multiplayer style maps in UE4
inspired by Call of Duty & Halo, I was eager to focus my project towards designing a level based around an existing IP in UE4. I also wanted to recreate some existing mechanics as to show off my level & mechanic design and implementation abilities while putting my own spin on a game that I have great respect and passion for. The decision to focus on the Call of Duty: Zombies gamemode, in particular the World at War (2008) & Black Ops (2010) iterations, was made as I feel that these games were the peak of the Call of Duty Zombies gamemode, with maps big enough to provide an enjoyable and challenging experience without feeling over the top or like a chore to play like in later iterations of the gamemode. For me it provides a good basis with reasonable scope as to what I could realistically build over the next 12 weeks.

Despite being quite well acquainted with the zombies maps of World at War (2008) and Black Ops (2010) I will be going back to play and analyse them to gain a better
understanding of their flow, critical paths, use of lighting and use of space, as well as
researching the development cycle of both games to see & understand how they were made. I’ll also be analysing other games that have levels/maps of a similar design and style, such as Metro, S.T.A.L.K.E.R., Dead Space and Left 4 Dead to gain a better understanding of how these games build a world around their critical paths, and look to take influence & understanding from their methods environmental story telling. I’ll also be looking for literature regarding this topic to aid my research, as well as sci-fi movies & TV series such as Futurama, Star Wars, Alien, Event Horizon & Star Trek for inspiration with regards to architecture & environment building in space ships.


Before discussing any of this projects pre-production & development it must be noted that this project is in collaboration with another designer, who will be creating the fully functional gamemode/gameplay mechanics such as enemy waves, round counter & powerups, and player mechanics such as the guns/ammo system, melee attack, zombie AI and points system. To ensure that neither of us are dependent on the work of the other however, we have split the project in half with myself creating a level that function independently of the core gameplay mechanics that the other designer is developing, while said core gameplay mechanics can function independently regardless of the level they are in.

The first port of call before beginning development properly was to compile a list of all the assets I would need to fully create a Call of Duty: Zombies level. This was done in a spreadsheet as to be easily editable. It’s pictured below as of the 12/2/2020 along with a key.

Another point of urgency before development could properly begin was the need to source a free to use modular kit from the Unreal Marketplace. Fortunately one of the few free ones available was Modular Sci-Fi Season 2 Starter Bundle, which fit the bill perfectly.