Memory Leak / 2024
|
"Memory Leak" is a third-person survival game with roguelite and tower defense elements where players control Roberto, a robot with no memory who must survive in an abandoned factory, haunted by hostile monsters. To survive, players are able to build turrets with different effects and utilities, unlocked and collected throughout their games, as they approach the unravelling of the mystery surrounding the factory and the apocalypse.
Genre: Survival, Roguelite, Tower Defense Engine: Unreal Engine 5 Team Size: 9 Duration: October 2023 - January 2024 (3 Months) Platform: PC (Itch.io) |
|
My roles:
General Game Design:
- Participation in Ideation processes of mechanics, theme and characters.
- Balancing of turrets, enemies and game economy statistics.
- Design and Writing of the game's tutorial.
- Main Menu design:
- Menu system flow
- Menu pages transitions
- Creation of the narrative concept.
- Design, Writing and Implementation of the game's opening and closing dialogues.
- Pitch Document - Blockout and Writing.
- Game Design Document (GDD) - Blockout and Writing.
Special Roles:
- Vision Holder of the project.
- Digital production of all the two-dimensional assets used in the project with MediBang software (Photoshop's free counterpart).
Documentation
Memory Leak - Pitch Document (EARLY VERSION)
|
Memory Leak - GDD
|
Development Process
"Memory Leak" was produced as the final academic project in a mutidisciplinary team for my Game Design degree at the Digital Bros Game Academy. The production process was supervised by the course's core trainer, Derek Hartin, virtually representing the role of the producer. The production stages followed the industry pipeline from initial concept to game release.
0. Brief Analysis
At the start of the activities (October 2023) the team received the design brief. The main requirements of the project were that the game should belong to the survival genre and feature three-dimensional assets and gameplay.
Before entering the ideation phase, the team held a meeting to analyse the brief, study its requirements and research more information on the specifics of the survival genre. This meeting was essential to get the team members on the same page, leading to a more efficient ideation session.
1. Ideation
The Ideation phase took the team one week. After the ideation and convergence sessions, each team member exploited the results of the brainstorming to flesh out their ideas for the game in terms of themes and mechanics, in accordance with the brief.
With a final round of voting, the week ended with the team's approval of the idea behind "Memory Leak".
Having chaired the Ideation and Convergence sessions, I proposed to the team the modalities in which these phases could be organised. With the approval of the other members of the group, the Ideation Session consisted of a brainstorming session divided into four sections focusing on Theme, Main Mechanics, Characters and Gameplay Perspective.
For each of these focuses, the team members wrote down their proposals, taking advantage of a few minutes of silence and concentration. At the end of this short period of time, each member listed their ideas, which were then written down and placed on virtual post-it notes organised by category.
Since one of the main advantages of brainstorming is that listening to the ideas of other participants can inspire other proposals, each member of the group collected notes on any additional ideas that arose during this phase, which were then added to the others.
In the following session (Convergence Session), the team gave subjective ratings to each idea collected, based on which the proposals were skimmed and refined.
0. Brief Analysis
At the start of the activities (October 2023) the team received the design brief. The main requirements of the project were that the game should belong to the survival genre and feature three-dimensional assets and gameplay.
Before entering the ideation phase, the team held a meeting to analyse the brief, study its requirements and research more information on the specifics of the survival genre. This meeting was essential to get the team members on the same page, leading to a more efficient ideation session.
1. Ideation
The Ideation phase took the team one week. After the ideation and convergence sessions, each team member exploited the results of the brainstorming to flesh out their ideas for the game in terms of themes and mechanics, in accordance with the brief.
With a final round of voting, the week ended with the team's approval of the idea behind "Memory Leak".
Having chaired the Ideation and Convergence sessions, I proposed to the team the modalities in which these phases could be organised. With the approval of the other members of the group, the Ideation Session consisted of a brainstorming session divided into four sections focusing on Theme, Main Mechanics, Characters and Gameplay Perspective.
For each of these focuses, the team members wrote down their proposals, taking advantage of a few minutes of silence and concentration. At the end of this short period of time, each member listed their ideas, which were then written down and placed on virtual post-it notes organised by category.
Since one of the main advantages of brainstorming is that listening to the ideas of other participants can inspire other proposals, each member of the group collected notes on any additional ideas that arose during this phase, which were then added to the others.
In the following session (Convergence Session), the team gave subjective ratings to each idea collected, based on which the proposals were skimmed and refined.
Virtual whiteboard after the Convergence Session
The collected and skimmed ideas then formed the basis of a final conceptualisation phase in which each participant produced and documented a full game concept. These more complex ideas were then voted on and the concept for "Memory Leak" was selected.
2. Pitch and Prototype
In order to simulate a realistic context, the pitch and prototyping phase was short, with a time limit of just over a week after the end of the previous deadline . The fast pace of this step was useful to test us students' rapid prototyping skills and encouraged us to think of the prototype as just that, a piece of dirty code, useful only to test the validity of the chosen idea.
At this stage, the programmers developed a first, rough and simple build based on the Pitch Document (download) written by myself and the other colleagues in the design department. From the beginning, communication played a key role. In fact, I was actively involved in drafting documents to formalise the specific nuances of the desired mechanics and to cover details that, by their very nature, could not be covered in the pitch document. I was also in constant contact with the programmers, accompanying them as they worked. This enabled me to quickly resolve any doubts that might arise due to inaccuracies or missing details in the written documentation.
Once the first playable version of the prototype was complete, the team took an Iterative Approach where:
This cycle was then repeated from step 3 to step 1 until the end of the prototyping period, when the final build for this phase was delivered to the core trainer.
Despite positive feedback from the testers, the team encountered a major problem with "Memory Leak" at this step. The core trainer's analysis showed that the game and its concept were inadequate to the brief, which strictly required a survival game.
This "negative" experience was a hard blow for the team, which, after the starting genre analysis, was confident that our product would meet these requirements, but a second analysis, in the light of new information, highlighted the key problems with our design.
For example, the way the tower defense elements were designed resulted in static gameplay and a lack of exploration, which is instead a relevant component of the survival genre. Turrets could be built by spending in-game currency that was released when monsters died, but this led to a gameplay loop in which the player could recoup the resources spent on their defence simply by defending themselves, clearly encouraging the static nature of the experience.
Enemies were designed to chase the player relentlessly from the moment they spawned, leading to action-packed gameplay where the player had to manage hordes and grind down large numbers of enemies with turrets. This dynamic, typical of action games, took away the survival experience from the player, which should instead be characterised by a slower experience, in which the player should instead feel a growing anxiety due to the need for resources and fear of the enemies that could easily lead them to game over.
Facing the consequences of our mistakes and investigating design solutions was, in my opinion, the most formative experience in the development of this game. Myself and the rest of the design department were faced with a real design problem for which we had to find effective solutions in the shortest possible time. Several meetings followed in the two days after the core trainer's feedback, and once the fundamentals of the problem were clearly understood, it was easy to redirect the design towards the survival brief.
The biggest change introduced at this stage concerns the way in which turrets are constructed. In the final version of the game, the player will be guided to explore the game environment in search of materials such as gears, metal and circuits, which are essential for the construction of turrets. Depending on the model, the turrets will have different construction requirements.
Monsters have been redesigned as more solid and dangerous entities that move around the game environment shrouded in darkness. Rather than blindly chasing the player from the moment they are created, they now have sight and hearing, which, combined with a basic AI system, results in less arcade-like dynamics.
2. Pitch and Prototype
In order to simulate a realistic context, the pitch and prototyping phase was short, with a time limit of just over a week after the end of the previous deadline . The fast pace of this step was useful to test us students' rapid prototyping skills and encouraged us to think of the prototype as just that, a piece of dirty code, useful only to test the validity of the chosen idea.
At this stage, the programmers developed a first, rough and simple build based on the Pitch Document (download) written by myself and the other colleagues in the design department. From the beginning, communication played a key role. In fact, I was actively involved in drafting documents to formalise the specific nuances of the desired mechanics and to cover details that, by their very nature, could not be covered in the pitch document. I was also in constant contact with the programmers, accompanying them as they worked. This enabled me to quickly resolve any doubts that might arise due to inaccuracies or missing details in the written documentation.
Once the first playable version of the prototype was complete, the team took an Iterative Approach where:
- Builds were given to testers who filled out feedback forms created through Google Forms to report technical bugs and share their experiences by answering targeted questions designed to minimise response bias,
- The feedback collected was analysed and translated by the design department into detailed reports aimed at correcting the design to achieve the desired aesthetics, dynamics and mechanics,
- The programmers then used these documents to determine the practical implementation of the required features and/or the possible correction of those already developed.
This cycle was then repeated from step 3 to step 1 until the end of the prototyping period, when the final build for this phase was delivered to the core trainer.
Despite positive feedback from the testers, the team encountered a major problem with "Memory Leak" at this step. The core trainer's analysis showed that the game and its concept were inadequate to the brief, which strictly required a survival game.
This "negative" experience was a hard blow for the team, which, after the starting genre analysis, was confident that our product would meet these requirements, but a second analysis, in the light of new information, highlighted the key problems with our design.
For example, the way the tower defense elements were designed resulted in static gameplay and a lack of exploration, which is instead a relevant component of the survival genre. Turrets could be built by spending in-game currency that was released when monsters died, but this led to a gameplay loop in which the player could recoup the resources spent on their defence simply by defending themselves, clearly encouraging the static nature of the experience.
Enemies were designed to chase the player relentlessly from the moment they spawned, leading to action-packed gameplay where the player had to manage hordes and grind down large numbers of enemies with turrets. This dynamic, typical of action games, took away the survival experience from the player, which should instead be characterised by a slower experience, in which the player should instead feel a growing anxiety due to the need for resources and fear of the enemies that could easily lead them to game over.
Facing the consequences of our mistakes and investigating design solutions was, in my opinion, the most formative experience in the development of this game. Myself and the rest of the design department were faced with a real design problem for which we had to find effective solutions in the shortest possible time. Several meetings followed in the two days after the core trainer's feedback, and once the fundamentals of the problem were clearly understood, it was easy to redirect the design towards the survival brief.
The biggest change introduced at this stage concerns the way in which turrets are constructed. In the final version of the game, the player will be guided to explore the game environment in search of materials such as gears, metal and circuits, which are essential for the construction of turrets. Depending on the model, the turrets will have different construction requirements.
Monsters have been redesigned as more solid and dangerous entities that move around the game environment shrouded in darkness. Rather than blindly chasing the player from the moment they are created, they now have sight and hearing, which, combined with a basic AI system, results in less arcade-like dynamics.
The player collects resources by destroying machines scattered around the environment. At the bottom right, the UI shows the resources possessed by the player and the construction requirements of the equipped turret.
3. Vertical Slice
After the final iteration on the prototype, updated according to the latest feedback from the core trainer, the team began the development phase towards the vertical slice milestone. With a new deadline of three weeks, the aim was to produce a version of the game that represented a complete slice of the product. The final build of this phase would therefore show all the mechanics in action, presented with advanced effects and aesthetics (a good level of polish).
The team's focus during these weeks was to identify the strengths and weaknesses of all of the game's systems, using new iterations of feedback and development in the search for organic and fun gameplay, while stripping the design of redundant or ineffective aspects.
This phase also saw the creation of the Game Design Document (download). As the team's vision holder, I played a central role in the creation of this document. Based on the external resources written by all the designers, my job was to curate a collection that could be easily accessed and navigated by all team members to provide any information about the game on request.
Delivering the vertical slice was a great satisfaction for the team. We were able to see the design of Memory Leak take shape, build by build, and participate in the creation of a product that had the desired effect on the players, who, although represented exclusively by our friends and family, seemed to genuinely enjoy the experience.
The Game Design Document, although less refined in its aesthetic presentation than in its content, was still a source of pride for the designers on the team, as we (and I personally) were pleased with its level of detail and structure.
4. Polishing
The polishing phase was the last before the final delivery of the "Memory Leak" project. The aim of these last three weeks was to produce a complete game, exhaustive in the implementation of its designed mechanics and with a level of aesthetic refinement suitable for a possible launch on the market.
My role in this phase was to follow the programmers in the last steps of the implementation, analyzing and reporting player feedback, aiming to solve the most serious bugs in the game.
To date, after the final delivery, "Memory Leak" is not free of bugs, but the known problems are few and none of these fall into the highest danger classes.
5. Final Considerations
I believe that "Memory Leak" was a very educational experience for me. Working as a game designer in a multidisciplinary team in the context of Unreal Engine 5, with a fast pace punctuated by various deadlines, has been an important testing ground for my hard and soft skills.
After the final iteration on the prototype, updated according to the latest feedback from the core trainer, the team began the development phase towards the vertical slice milestone. With a new deadline of three weeks, the aim was to produce a version of the game that represented a complete slice of the product. The final build of this phase would therefore show all the mechanics in action, presented with advanced effects and aesthetics (a good level of polish).
The team's focus during these weeks was to identify the strengths and weaknesses of all of the game's systems, using new iterations of feedback and development in the search for organic and fun gameplay, while stripping the design of redundant or ineffective aspects.
This phase also saw the creation of the Game Design Document (download). As the team's vision holder, I played a central role in the creation of this document. Based on the external resources written by all the designers, my job was to curate a collection that could be easily accessed and navigated by all team members to provide any information about the game on request.
Delivering the vertical slice was a great satisfaction for the team. We were able to see the design of Memory Leak take shape, build by build, and participate in the creation of a product that had the desired effect on the players, who, although represented exclusively by our friends and family, seemed to genuinely enjoy the experience.
The Game Design Document, although less refined in its aesthetic presentation than in its content, was still a source of pride for the designers on the team, as we (and I personally) were pleased with its level of detail and structure.
4. Polishing
The polishing phase was the last before the final delivery of the "Memory Leak" project. The aim of these last three weeks was to produce a complete game, exhaustive in the implementation of its designed mechanics and with a level of aesthetic refinement suitable for a possible launch on the market.
My role in this phase was to follow the programmers in the last steps of the implementation, analyzing and reporting player feedback, aiming to solve the most serious bugs in the game.
To date, after the final delivery, "Memory Leak" is not free of bugs, but the known problems are few and none of these fall into the highest danger classes.
5. Final Considerations
I believe that "Memory Leak" was a very educational experience for me. Working as a game designer in a multidisciplinary team in the context of Unreal Engine 5, with a fast pace punctuated by various deadlines, has been an important testing ground for my hard and soft skills.
Get In Touch
Please feel free to use my email address or contact me on LinkedIn if you would like to get in touch.
EMAIL / marzeddusimone@gmail.com
LINKEDIN / https://www.linkedin.com/in/simonemarzeddu
EMAIL / marzeddusimone@gmail.com
LINKEDIN / https://www.linkedin.com/in/simonemarzeddu