Process Behind the Game
Brainstorming the Idea:
The first thing I do when making a game is to brainstorm. Specifically, as a Narrative Designer, I tend to focus on forming a general plotline of the story based on the scope and features of the game. Since I knew the scope of this project was smaller due to time constraints, I decided to continue adding to the Reversed series. But instead of a whole game, I wanted to work on a little preview, or interlude, before the next big installment in the series (Spoiler Alert: When Mike and Ken encounter one another after their reincarnation). During ideation, I wanted this game to give players a glimpse of Mike and Ken before their reincarnation, while hinting at their reunion for the next game.
Once I figured out the general plot of the story, I then created a pitch document to plan out the map design and game features. I was inspired by dungeon-crawl games for the first level when Mike escapes from the Koyangi Offices. There would be guards that players would have to fight and lock puzzles to solve to get to the next room. As for the second level, I decided to have a whole chase sequence to continue the more rapid, exciting pace of this game, leading up to the boss fight with the Goddess.
The first thing I do when making a game is to brainstorm. Specifically, as a Narrative Designer, I tend to focus on forming a general plotline of the story based on the scope and features of the game. Since I knew the scope of this project was smaller due to time constraints, I decided to continue adding to the Reversed series. But instead of a whole game, I wanted to work on a little preview, or interlude, before the next big installment in the series (Spoiler Alert: When Mike and Ken encounter one another after their reincarnation). During ideation, I wanted this game to give players a glimpse of Mike and Ken before their reincarnation, while hinting at their reunion for the next game.
Once I figured out the general plot of the story, I then created a pitch document to plan out the map design and game features. I was inspired by dungeon-crawl games for the first level when Mike escapes from the Koyangi Offices. There would be guards that players would have to fight and lock puzzles to solve to get to the next room. As for the second level, I decided to have a whole chase sequence to continue the more rapid, exciting pace of this game, leading up to the boss fight with the Goddess.
Testing Ideas:
After planning the game, I created an empty Unreal Project to test out some of my ideas before whiteboxing the level. Specifically, I played around with the simple combat, lock puzzle, floor pressure plates, and UI. I believe testing your ideas is helpful in the design process because I see this as a stage before whiteboxing. Whiteboxing, for me, is more like implementing the bare bones of the game, in which a common example is laying out the level with basic blocks before putting in the final assets with all the textures. But by testing out ideas in more of a sandbox project first, it allows me as a designer to experiment with my ideas from my pitch and see what can be done and if any changes need to be made. However, I don’t do all of my coding at this stage! I only code or lay out a small portion of it, that small portion typically consisting of the more challenging, or likely problematic down the line, elements in creating the game. For example, when experimenting with the lock puzzle, I wanted to specifically test changing the rotation during certain increments and getting them to align. Therefore, I created some simple art for the locks and played around with the widgets and code, testing how to change and check each lock’s rotation, as well as see if the images reflect the correct rotation. Some changes I had to make were the scaling of the green lines on the locks and the lock's alignment on the screen so that they were perfectly aligned and rotating in the center. |
Whiteboxing:
After testing some ideas, I started to whitebox both levels using simple geometry. The only art implemented in this stage were the player character sprite - as a reference for sizing objects - and the UI art used for testing in the previous stage. I mainly focused on the space and environment by creating the rooms in the first level and placing temporary “buildings” in the second level to map out the player’s path for each level. There are barely any props or detailed assets in this stage.
After testing some ideas, I started to whitebox both levels using simple geometry. The only art implemented in this stage were the player character sprite - as a reference for sizing objects - and the UI art used for testing in the previous stage. I mainly focused on the space and environment by creating the rooms in the first level and placing temporary “buildings” in the second level to map out the player’s path for each level. There are barely any props or detailed assets in this stage.
Writing the Script:
When writing scripts, I first like to write it out in a Google Document or Word Document before implementing them into Excel. When writing and reflecting on my script, I prefer seeing them on a document instead of small data cells. In addition, I use the former as the “drafting” stage with the script, in which I am writing and then making edits to the dialogue. That way, once the script is finalized, it is easier to implement the dialogue into Excel with all the right variables, such as scene name, character name, animation boolean, etc., because there are fewer changes that I would have to make.
When it comes to writing the dialogue itself, I referenced the maps I drew for each level in the pitch document to plot my story beats. For example, in reference to the map for the first level (i.e., when Mike is escaping the Koyangi Offices), I decided to have a story beat for the alarm trigger in room 4 because that is immediately after Mike enters the vent and right before the first lock puzzle. That way, players can get acquainted with the environment and characters in the first 3 rooms before diving into the timed challenge that starts in room 4. I also wanted to work on shortening my dialogue, since I tend to write long sequences of dialogue in my previous works. That is why referencing the map also helped me space out the dialogue based on the room so that it goes back and forth between dialogue and gameplay (lock puzzle, combat, etc.).
When writing scripts, I first like to write it out in a Google Document or Word Document before implementing them into Excel. When writing and reflecting on my script, I prefer seeing them on a document instead of small data cells. In addition, I use the former as the “drafting” stage with the script, in which I am writing and then making edits to the dialogue. That way, once the script is finalized, it is easier to implement the dialogue into Excel with all the right variables, such as scene name, character name, animation boolean, etc., because there are fewer changes that I would have to make.
When it comes to writing the dialogue itself, I referenced the maps I drew for each level in the pitch document to plot my story beats. For example, in reference to the map for the first level (i.e., when Mike is escaping the Koyangi Offices), I decided to have a story beat for the alarm trigger in room 4 because that is immediately after Mike enters the vent and right before the first lock puzzle. That way, players can get acquainted with the environment and characters in the first 3 rooms before diving into the timed challenge that starts in room 4. I also wanted to work on shortening my dialogue, since I tend to write long sequences of dialogue in my previous works. That is why referencing the map also helped me space out the dialogue based on the room so that it goes back and forth between dialogue and gameplay (lock puzzle, combat, etc.).
Coding Systems and Tools for Integration:
Some of the systems and tools I programmed were the dialogue tool, lock puzzle tool, enemies, floor pressure plates, and parent event tool. As I continue working on the Reversed series, I’ve been improving my dialogue tools to efficiently implement and run dialogue events using data tables, data structures, and functions. For example, I have a data structure based on the Excel I have for the dialogue, that way I can pull the name of the character, profile image, and lines of dialogue from the chosen row. The data structure also includes the scene name, so in the details panel, I can simply put the scene name in the public variable and the tool will grab all the dialogue for that particular scene into a data structure list. I also created a parent event tool that made it easier to create child events, such as when the treasure chest opens or when the alarm is triggered.
Some of the systems and tools I programmed were the dialogue tool, lock puzzle tool, enemies, floor pressure plates, and parent event tool. As I continue working on the Reversed series, I’ve been improving my dialogue tools to efficiently implement and run dialogue events using data tables, data structures, and functions. For example, I have a data structure based on the Excel I have for the dialogue, that way I can pull the name of the character, profile image, and lines of dialogue from the chosen row. The data structure also includes the scene name, so in the details panel, I can simply put the scene name in the public variable and the tool will grab all the dialogue for that particular scene into a data structure list. I also created a parent event tool that made it easier to create child events, such as when the treasure chest opens or when the alarm is triggered.
Level Designing:
Once everything is laid out, written down, and coded up, I would then bring everything together and implement them to the level. For this particular project, my process was implementing one type of tool at a time depending on priority. For example, I would first place and set up all the dialogue for level 1 before placing the lock puzzle because other tools will later need to reference the dialogue tool. The same goes for the second level, in which I would place the floor pressure plates first because it is right before the final boss fight, but only after setting up the dialogue.
Once everything is laid out, written down, and coded up, I would then bring everything together and implement them to the level. For this particular project, my process was implementing one type of tool at a time depending on priority. For example, I would first place and set up all the dialogue for level 1 before placing the lock puzzle because other tools will later need to reference the dialogue tool. The same goes for the second level, in which I would place the floor pressure plates first because it is right before the final boss fight, but only after setting up the dialogue.
Implementing Art, Lighting, and Audio:
In this stage, I replaced all the whiteboxes with assets I kitbashed together from the asset store and added props, lighting, and audio. Storytelling is not only done through the dialogue, but through the environment as well, so I made sure to focus on how the art I implement affects the tone.
For example, the Koyangi Offices use dominant gray tones, such as the floors and cluttered desks, to create a mundane atmosphere. This contrasts with the bright red user interface overlaid on the screen, which brings attention to the information presented and emphasizes the theme color of the game. However, Mike blends into this environment in similar dark clothing, whereas in Reversed, Mike really stands out against the brightly colored buildings and sunny backdrop. In fact, Reversed: Interlude focuses more on darkness than light because it focuses on a dark (pun partially intended) time in Mike’s life just minutes before he died. At this moment, he is not the begrudging detective we know from Reversed but a criminal from a secret organization who is tasked with killing the president. And because this mission has such high stakes, I used a lot of action, spy-themed music to heighten the pressure and emphasize the fast pacing in which these events take place.
In this stage, I replaced all the whiteboxes with assets I kitbashed together from the asset store and added props, lighting, and audio. Storytelling is not only done through the dialogue, but through the environment as well, so I made sure to focus on how the art I implement affects the tone.
For example, the Koyangi Offices use dominant gray tones, such as the floors and cluttered desks, to create a mundane atmosphere. This contrasts with the bright red user interface overlaid on the screen, which brings attention to the information presented and emphasizes the theme color of the game. However, Mike blends into this environment in similar dark clothing, whereas in Reversed, Mike really stands out against the brightly colored buildings and sunny backdrop. In fact, Reversed: Interlude focuses more on darkness than light because it focuses on a dark (pun partially intended) time in Mike’s life just minutes before he died. At this moment, he is not the begrudging detective we know from Reversed but a criminal from a secret organization who is tasked with killing the president. And because this mission has such high stakes, I used a lot of action, spy-themed music to heighten the pressure and emphasize the fast pacing in which these events take place.
Playtesting and Bug Fixing:
Throughout this process, I am constantly playtesting to look for bugs or places in the gameplay that can use improvement, such as increasing the player’s speed or decreasing the delay between the lasers shot by the enemies. Oftentimes, I am playtesting small chunks at a time, such as only playtesting the floor pressure plates in the chase sequence, before playing through the whole game. I find the small chunks helpful because I am focused on one particular aspect of the game, whether it be the dialogue, one of the puzzles, or even the flow of the gameplay in a particular room. In these smaller playtest sessions, once I see an issue, I go straight into fixing the bug before playtesting once more. On the other hand, when I am playing through the whole game, I will write down bugs or flaws that I notice and finish the game before working on making improvements.
One major bug I fixed was with the floor pressure plates, in which if the player steps on 2 green ones within a few seconds, the player continues to run at a faster speed. After looking through the code and much trial and error, I learned it had something to do with how I was checking the delay, so I created a parent floor pressure plate that kept track of whether a player had already stepped on a floor pressure plate within a certain time frame. If the player has already stepped on a floor pressure plate, either add to the delay time or change the speed and refresh the delay time depending on whether it is the same type of pressure plate as the previous one. If the player does not step on a pressure plate during the time frame, then the player's speed returns to normal.
One major detail I added for environmental storytelling was adding rain for the second level. The rain particle effects not only went along with the thunderstorm ambience but also foreshadowed the moments that lead up to Mike's reincarnation. Though rain often represents sorrow, rain also represents life and washing away of sins, which symbolizes how, when Mike reincarnates, he is a detective and not a criminal. The rain also brings forth anxiety accompanied with Mike's encounter with Ken. With the added layer of complexity that rain brings to the environmental storytelling, I believe it strengthens the story as a whole and how it is experienced by the players.
Throughout this process, I am constantly playtesting to look for bugs or places in the gameplay that can use improvement, such as increasing the player’s speed or decreasing the delay between the lasers shot by the enemies. Oftentimes, I am playtesting small chunks at a time, such as only playtesting the floor pressure plates in the chase sequence, before playing through the whole game. I find the small chunks helpful because I am focused on one particular aspect of the game, whether it be the dialogue, one of the puzzles, or even the flow of the gameplay in a particular room. In these smaller playtest sessions, once I see an issue, I go straight into fixing the bug before playtesting once more. On the other hand, when I am playing through the whole game, I will write down bugs or flaws that I notice and finish the game before working on making improvements.
One major bug I fixed was with the floor pressure plates, in which if the player steps on 2 green ones within a few seconds, the player continues to run at a faster speed. After looking through the code and much trial and error, I learned it had something to do with how I was checking the delay, so I created a parent floor pressure plate that kept track of whether a player had already stepped on a floor pressure plate within a certain time frame. If the player has already stepped on a floor pressure plate, either add to the delay time or change the speed and refresh the delay time depending on whether it is the same type of pressure plate as the previous one. If the player does not step on a pressure plate during the time frame, then the player's speed returns to normal.
One major detail I added for environmental storytelling was adding rain for the second level. The rain particle effects not only went along with the thunderstorm ambience but also foreshadowed the moments that lead up to Mike's reincarnation. Though rain often represents sorrow, rain also represents life and washing away of sins, which symbolizes how, when Mike reincarnates, he is a detective and not a criminal. The rain also brings forth anxiety accompanied with Mike's encounter with Ken. With the added layer of complexity that rain brings to the environmental storytelling, I believe it strengthens the story as a whole and how it is experienced by the players.