Meltdown Blog

Development Blog of my participation in the group project

About: Blog based on my contribution and work towards the team project Meltdown. 

Description: The project from design and scripting to art and implementation was broken up into have main tasks between each member. This blog documents my progress and completion of each task assigned to me during the start of development.

Duration: 3 Months

Interaction Direction: Please click on images to enlarge and right click open link in new tab, to see full resolution version.

Task 1: Game-playloop planning and creation

Task 1 Planning: Gameplay loop

Task Definition:

I will be designing and developing the game-play loop process for the game including UI the end/game over screen. Currently, their will do no main menu as it is currently being planned to develop a physical in-world selection system


I first began by researching games that would have similar style game-play to our chosen game idea (Meltdown: find all the survivors before the light runs) to get an idea of how to structure the game-play loop. One game looked into was an escape from Tarkov whereupon choosing a map you are spawned into the world and must survivor and scavenge against other players under a limited amount of time, while having to find the extraction point assigned to you upon spawning to keep all the loot you have found before the timer has run out.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board as shown above.

Screenshot of the wire-frame planning above

Above is the screenshot of the currently planned gameplay loop for the game

Task 1 Development: Prototyping

 During development I first started by setting up functionality within the Game-mode (BP_PersistentGM), where I decided to make a quick prototype while waiting for the torch and NPC’s and their required manger systems to be made.

I first began by setting up a custom event that would be triggered as soon as the player leaves the Main-Menu level area and level one loads in from the level streaming manager (made by Matt Trent). Which then starts by counting down.I then created an end game widget which will display end game statistics like torchlight left and whether the player had escaped or failed due to running out of torchlight.

After setting up the end game widget with debug functionality I then began setting up the previously made end game condition function which currently creates and displays the end game widget along with calling an initialization function the gives the Ui a game mode reference so that it can call certain functions in the future from player button interaction.

Then I finally set the game to paused so that the torch won’t continue to tick down in the future. So that when the player escapes it won’t say they lost when straight after displaying that they have won. This may change in the future depending on how my teammate sets up the torch. I then made a quit event that ends the game in the Game-mode which is called from the widgets end game button and will be called from within the pause menu in the future.


Screenshot of the quit game button

Screenshot of the testing event and timer for testing the end game conditions

Screenshot of the debug widget used for testing the end game condition inside the Gamemode

Screenshot of the prototyped End Game Condition Function

Task 1 Development 2: Adding Functionality

 After developing the prototype gameplay loop and waiting for the torch and level stream manager to be completed, I was told due to each level streamed area needing a room manager to spawn in a certain number of NPC/Keys and handle which ones have been saved/picked up. This was needed due to each area unloading each time the player would leave the area. This meant I had to implement the loop with a way of collecting information from each area before the player left it. So that the end condition would know how many NPC’s where saved from each level streamed area/level before they were unloaded.

To do this I decided on an overlap event from the room a manager the information would be passed to the game mode on a dispatcher, and stored in a struct array for each room manager. I first made a struct with a variable for the ID of the manager how many NPC’s wherein the area and the amount the player had saved along with an Init variable for if the player had entered that area before escaping.

I then developed a function which would initialize each room-manager on the start of the game and within the menu level area. With functionality that would update the struct array on an event dispatcher which is called each time the player saves an NPC (instead of the original plan with the overlap event).

I then updated the functionality of the end condition to loop through each room-manger within the array and count how many the player saved in each room on a for-each loop, with a check to then see if the player has saved all the NPC’s in the level upon escaping. 

I then made a Macro which adds the end game widget (created on the premade event begin play initialization chain) to the screen with a custom init event that passes through whether the player saved everyone, missed NPC’s, or the torchlight ran out.

While developing I realized the player would also need to specific Ui elements should on the screen (win screen Ui) based on new design decisions made to our game while scoping down the size of the game. Which I will also work on during this task. I then also updated setup the functionality within the widget to update the text and turn elements on and off based the end conditions.

After I added events within the Game-mode which are called within the widget and pause menu (soon to be made) buttons for returning to menu level and retrying which needed to reset the player at a certain point within one of the streamed levels.

Screenshot of the Inishlization function within the game over widget

Screenshot of the return to menu and retry events within the GM which get called from the game over UI and will be called by the pause menu in the future.

Video demonstrating the prototype game-play loop escape conditions.

Video demonstrating the prototype game-play loop loss condition.

Screenshot of struct setup

Screenshot of the room manger data collection function with a custom macro for finding the right room to update

Screenshot of the updated end game condition

Screenshot of the room manager for each loop function collected the amount saved

Screenshot of Macro updating the Ui with relevant information to show the player

Screenshot of the updated version of the end screen UI

Task Append - Modifying Design/ Debugging Issues

One issue was the amount of AI characters to save showing as zero when the player would click retry or play the game on a second interaction. Which just needed to be set to 10 on the retry event, due to the removal of the other levels and room managers, the return to menu event and functionality was no longer needed and was removed instead the retry event now handles setting the player to the starting spot.

Screenshot of the retry event and removed back to main menu event in the event graph.

Task 1: Reflection / conclusion of development

Videos below are only for demonstrations of the final gameplay loop and the win/loss conditions.

Task 2: Level Design
Task 2 Development 1: Planning and research

Due to discrepancies within the team, I choose to take on the task of quickly redoing the level design within three days so that the artists could get a general idea of the layout and look so that they can begin developing lighting environmental textures model assets.

I first began to look at the general process of designing a level based on developers in the industry and looking at their top-down two dimensional as designs examples of how my design should be presented. I first started by looking at a level design tutorial by Alex Galuzin where he states to gather as many reference images of landscapes layout and related imaginary to the topic of the design you’re trying to create as possible. As examples, he uses mood boards to gather an interpretation from existing environments and structures of what he plans to create.

I then looked at Indie game developer Daniel Duh’s portfolio’s work where he shows a general process of how he designs and plans a level.  His planning has inspired me to take the same approach of using callouts on the layout to quickly and easily give explanations to certain parts of the design and certain gameplay elements parts of an area of the level may influence.

After researching the general design process, I then began gathering example imaginary based on research into real-life power plants and nuclear reactor plants, along with top-down floorplan layouts. Which I made into mood-boards to show to the artists within the team. I then made a population/visual plan for certain elements/areas within the design of the level. Using imagery from the 2017 game Prey which I felt uses similar assets and art style that artists are planning to achieve in the environment.

Screenshot of the environment plan I made

Screenshot of Daniel Duh’s level designs

Screenshot of mood board I mad of existing imagery of nuclear powerplants

Task 2 Development 1: Initial Top-down Block-out layout

After researching I then began plotting out a general design layout within photoshop. I decided to do this as a top-down view based on the references I looked at during my research as well as clearly preceding the general idea to the team. I then incorporated the corridor’s and lobby menu/staff room areas into the design as they currently exist within the prototype version of the game as a working concept (made and designed by another team member).

After presenting my design to the team we decided to shrink the map to just one area, due to time constraints. With all members deciding on choosing the Reactor area.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

For developing the end screen I looked into existing titles ending screens and developed a wire-frames mood board.

Task 2: Development 2 Level Layout Population and placement plan

After receiving feedback from lectures, we decided to scrap the corridor’s and lobby menu/staff room areas, due to the possible not being enough time for the artists to create assets within and these areas needing specific assets that are likely not going to be used with the reactor area its self. I then updated the design and planned where each of the NPC’s and keys would spawn. Taking into consideration that keys will need to spawn in areas the player can access and not behind the doors or within the areas they are needed to unlock. After planning the placements for the important gameplay-related elements, I then planned the general placement for each asset that will be made by the artists within the level.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

For developing the end screen I looked into existing titles ending screens and developed a wire-frames mood board.

Task 2: Reflection and Conclusion of development

I feel I was able to quickly design a sensible but fairly simple level design plan for me within a short amount of time. I feel that although my designs use techniques from other designers looked at in my research post above, they don’t show information as clearly and need a different font / lighter background colour around the callout text as well as formatting so that the text and lines don’t intersect. If I had more time during the process, I would have also taken terrain of the map into consideration planning and labelling areas that may have been raised or lowered like the walkways with colour coding.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

Task 3: Narrative Manager / NPC interaction for player
Task 3: Planning

First this task I will designing and development the narrative that will be displayed as text popups for the player to read. Before planning I decided to look at how other games present narrative dialogue One game I looked was Neo Cab a story-driven game which uses narrative text popups and player decision-based text, along with diegetic Ui to help give the player visual indications to parts of the story being told by the narrative.

When I started planning, I first decided to have a procedural name system which I felt would fit in well with the existing procedural skins which change randomly on the characters (which were set up, my other team members). I also decided on choosing Russian/east European names to use for the NPC’s as felt it would fit in well with the style of the characters and theme of the game. After choosing names I decided I would also generate the text which will be shown in the NPC’s speech bubble randomly.

I then decided to aid the player through the level and give them clues if they are new to the game/its their first playthrough to append hints of text which would be set for each character’s spawn location. This I plan to give hints to location of other NPC’s and the location of keys throughout the level.

Video of the game researched for dialogue/narrative design.

Screenshot of the table plan for the randomly generated Names and narrative lines.

Screenshot of the set lines which will always exist at the same NPC spawn location and be appended to the generated lines of text.

Task 3: Narrative Manager / NPC interaction for player

I first started by creating a blueprint called narrative manager which will hold all data relating to the narrative and the functionality to setting up the NPC’s names and dialogue. I then made a function inside the game mode which spawns the manager and calls an initialisation function. I then set it so the function would be called inside the pre-existing init spawn managers function made by another teammate.

I then set up the manager with text arrays for storing the planned names and NPC’s lines in. Which will then be accessed by selecting a random id from the array to and passed onto the NPC’s widget on load. I plan to do it this way due to the widgets being diegetic and attached to the top of the NPC’s in world. I then set up the initialise event which if called from the GM, which sets a reference to the GM and the player controller for later use within the functions the event also calls.

Above image show the function for randomly setting each charactor name and text line to each NPC in the game on spawn

Screenshot of narrative manager spawn function

Screenshot of the event binding with the init event for the spawn managers

Manager inint event

Above image display the branch for if the NPC spawned is the first NPC thew player will encounter, setting the NPC's text to a default line.

Task 3: Development 2 UI integration

After working in the narrative manager, I then began work in the narrative widget, setting up a basic widget layout to test the text and names before the graphics for the UI is added. I then set up a custom event for taking the information with an if statement for whether the widget belongs to the first NPC or needs to take in the randomly assigned narrative and set the text.

I also added an append to add the hints after the random text through the NPC reference passed through. I then for the hint that will be appended modified the public variables of the characters placed in the level with the correct hint text and set the animation states while testing the narrative system within the prototype stage of the game.

Above shows the test UI umg widget for testing the speach bubble

Above shows the events for setting the assigned name and speak text to the widget spawned with each NPC

Above image shows the public test varibles for testing the UMG UI widget within game

Task 3: Reflection/Conclusion of development

From the final prototype show in the video below, apart from a few bugs like the same of the generated names appearing twice, I feel the overall result works well within the scope of the game and the final outcome meets the desired plan from my first post. I also feel compared to the industry example looked at, although both systems don’t show much similarity man system of using diegetic text around the NPC’s works in a similar manner in presenting narrative in a style that adds immersion when there are not enough resources to used recorded voice acting. For my next task I also plan to have the text presented in a speech bubble that will fit the art style of the game.

Video demonstration below of the system working below.

Task 3: Append

While testing and testing with members from other groups we noticed that for some NPC’s and some of the randomly generated dialogue. To fix this I modified my previous initialisation function for assigning names and dialogue within the Narrative Manager.

Screenshot of the tweaked nodes while

Screenshot of the remove index node added to remove the elements so they won't be selected again

Task 4: UI Graphics and Textures
Task 4: Planning and research

For this task, I will create different graphics for specific UI elements within the game, along with repeatable graphics for the buttons within widgets. I also plan to create diegetic in-world Ui panelling/ floor graphic to present additional information about the level/game-play to help guide the player while playing. I will also search for a royalty-free font to use for the text within the game’s that fits the radioactive disaster meltdown theme.

Planned Graphics Asset list:

  •  Buttons for the menus
  •   Logo for the menu or as an in-world Ui presented on the floors
  •  Background for the pause menu and end screen that fits the original wire-frame
  •   Floor diegetic graphic to present text on
  •  Wall diegetic graphic to present text on
  •   Font
  •  Torch graphic for the fill bar
  •   Speech bubble for the NPC names and dialogue

While researching I first looked at existing graphics within mobile and indie titles to get an idea of how to scope the detail and complexity of the assets I will create I then collected imaginary to make a mood board of the general style I’m looking at creating. I then began reading through tutorials, blogs and different documentation on how to develop and present the graphics within a rustic industrial way to suit the nuclear power plant environment. I then began collecting royalty free textures focusing on metals and warning/danger textures layer on and manipulate within photo-shop


Above is a tutorial I looked in creating grunge and dirt overlays and/tools for texturing.

Above is a screenshot of the warning line danger mood-board.

Task 4 Development 1: PSD development

I decided on first creating textures pack from free source textures I have acquired from the internet At the start of this task I first started by creating a background graphic for the end screen and the pause menu. I then using the same theme format and look to keep the graphics consistent began creating a button graphic. I then decided to test the graphics in engine against the text that will be displayed within the border.  

After previewing in engine against the text I decided on asking another team member Tom Griffin from another group who is proficient in graphical art and UI developing in UE4. He told me I should use a darker background texture within the border of the graphics and a less striking colour scheme for the stripes, to aid in making the text more readable and clearer to the player. He also suggested I find another font to use for text elements like the written information displayed to the player on the end screen and NPC speech bubbles that are more refined and clearer to read as a sentence or paragraph.

Taking this into account I improved the design of the graphic with a metallic texture linked in my research post above and added a few my grunge overlays to darken it and break up the pattern. I then improved the button texture but reversing the border and line stripes as the text can be bigger within the button. I created three different formations of layers for on hovered on clicked and a background layer for the text to overlay. I then using the shape tools within Photoshop developed a speech bubble outline for the NPC bubble graphic and a torch outline.

Above show a iteration of the speech bubble texture

Above shows a iteration of the torch light graphic using different shapes to create the layout.

Above shows a iteration of the torch light graphic with the energy bar lines added

Above shows the final iteration of the UI background texture

Screenshot above of the base warning danger lines texture

Above shows progress made with the first iterationof the warning background UI graphic

above shows progress made with the first iteration of the warning background UI graphic

Above shows a iteration of the warning lines background texture.

Task 4 Development 2: PSD development and improvement of graphics

I then refined the design of the buttons improving the hovered pressed and background texture. I then began overlay textures and adding a faint grunge effect to the light layer for the fill bar. I also used the same format as the buttons using different layers and masking the fill bar layer that will animate up and downwards. 

I then in a similar fashion to the end screen background developed a longer rectangle version for use as a sign as diegetic UI for displaying information to the player. I then created a final version of the speech bubble which I made in a similar fashion to the end screen background and torch. 

I then found a new font for use with long readable information from the feedback I received before. At the end of the process, I decided to make a logo to use at the start of the game as a floor sign along with being a logo for the website.

Above show the basegraphic for the button

Above show the highlighted/hovered over graphic for the button

Above shows the pressed graphic for the button

Above show the logo made with the modifited UI background.

Above screenshot the font being used for in game instructions and narrative UI elements.

Above shows the final iteration of the speech bubble graphic.

Above shows a larger modified background graphic made to use as a in world texture.

Above shows the final iteration for the torch graphic.

Task 4: Reflection/Conclusion Of development

Overall im very happy with the results and final outcome of the graphics I developed for the game taking into consideration I have little experience in developing graphics for games. I feel the feedback I required from the first iterations of the graphics I made helped greatly in improving my work and the final outcome of each texture graphic I created along with the feedback I acquired from Tom Griffin. I feel that the graphics like the logo and inworld ground/wall texture graphic I developed are publishable game-ready assets that are of the same standard and quality of the game assets looked at during my research and the images shown with the mood board I developed.

Task 4: Append

While having different participants within the team and supervisors play-test we found a number of issues with the game-play loop in terms of coding bugs but also issues where keys and NPC’s where not being reset on retry and restart events from the UI buttons. I found these issues to be caused by the first iteration of the room manager(Made by another member of the team) functionality being set up for the level streaming system that has now been removed.

I resolved these issues by having the event called from the game-mode instead of overlap events from the player moving through collision as shown by the screenshots below.

I then helped place assets with my other team members in the scene. At the end of the development process a quick setup a scene to record a short GIF for the games websites page banner.

Above is the start scene made to create the gif

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

For developing the end screen I looked into existing titles ending screens and developed a wireframes mood board.

Task 5: implementation graphics and improvement of UI widgets
Task 5: Planning and Research

For this task I will be implementing the graphics I have created into each UI widget I have developed as well as other widgets other team members have made while tweaking and adding new functionality to gain the desired effects with using the graphics. I also plan to develop a torch graphic much like the one used in the game Prey(2017) for the current energy fill bar.

I then researched the best practices in utilizing UMG widgets in UE4 and implementing graphics properly, along with the correct process of converting textures to be usable as UI elements. I also looked at how to make materials compatible in widgets as I plan to develop a panning energy effect on the torch along with visual cues to show when torchlight has been gained through saving NPC’s and when torch light is being taken through interacting with hazard traps.

Above shows a screenshot of UE4 learning material lokted at.

Above shows a screenshot from the the game PREY, 2017.

Task 5: Implementation of Graphics

I first started this task by removing the old test background and replacing it with the new interaction along with replacing the text with the more refined font I had found previously based on feedback from a fellow team member on making the information more readable on the screen.

As also shown above I then saved out the button turning the layers on and off within photoshop to so that each layer would be imported as separate PNG’s for use in the widgets button events for changing the graphical appearance when the player interacts with the buttons. I then set up an overlay structure to contain the button in a neat sensible format. After I then modified the HUD made by another team member implementing the graphics and font elements.

I then modified the pause menu placeholder text and graphics made by another team member who made the framework. This meant I also had to tweak the functionality slightly to work with the new overlay hierarchy system within the widget I had made to format the buttons. I modified the hierarchy of the widget layers within the NPC dialogue widget and implemented the speech bubble graphic.

Above show the intergration of the graphics and font into the player end UI screen

Above shows a image of the button graphics being implemented into the Umg Widget.

Above shows the graphics being implmented into the HUD overlay

Above displays a image of the prototype pause menu

Above displays a image of the the graphics being implemented into the pause menu

Above displays a image of new blueprint node setup inside the UMG widget.

Above shows the implementation of the speech bubble graphic.

Task 5: Improvement of UI widgets and finishing implmenetation

In the same fashion to the buttons, I saved the torch out as separate PNG layers for use with UE4 widget fill bar. I then implemented this into the premade torch child widget made by another team member. I then developed a panning masked material with different parameters for speed colour and an if statement within the material for controlling a sine flash effect. For use with informing the player of losing torchlight and gaining torchlight.

I then made three different material instances for switching between within the widget and updated the functionality within the torch widget for use with these. I then developed a diegetic placeable sign that has a public text variable that can be modified in the engine for displaying different information to the player and developed the diegetic logo version to go with this.

Above shows the the logo digetic graphic.

Above shows the torch graphic being implmented into the torch HUD overlay widget.

Above displays the torch dynamic material.

Above shows the folder view for the torch textures and materials

Above shows the blueprint for change the torch colour and speed based on the level of battery charge.

Above shows the the events used for controlling the torch dynamic materials.

Above shows the function for changing torch light colour.

Above shows the digetic widget blueprint.

Above shows the init blueprint for the digetic floor graphic

Above shows the construct events for the graphic blueprint

Task 5: Improvement of UI widgets and finishing implmenetation

The overall process of implementing the graphics went smoothly apart from the buttons which at first had some clipping issues which I managed to resolve with putting each element and the text into an overlay. I feel the final outcome of the textures looks fantastic within the engine and the visual animated cues of the torch work really well to inform the player on the torch being affecting and their time remaining while playing. I also feel that the functionality and look of the widgets are of similar industry quality to published mobile games and current indie titles.

Video demonstration above of a walkthrough of the completed game and working UI widgets with implemented graphics