Overview

Building on our individual pitches, each team was tasked with presenting their group's idea that will go on to become their synoptic project. Our group decided on a merging of each pitch into one "new" idea. When incorporating each person's pitch (discussed further below), the main concerns when developing our new combined idea were ensuring that we didn't 'muddy' the overall concept of the game and related it back to the theme of reflection. Additionally, some pitches were more intergrally incorporated than others (Mine, Archie's, and Nathaniel's) primarily due to their stronger links to the brief than others.

Technical Description / Explanation 

Within the first few meetings we held during the week and a half we rapidly honed in on what elements from each pitch we wanted, and then assigned different workloads to everyone. I entirely worked on the slides related to creating mechanics in the game along with creating a small prototype of the interaction system that will be used during the puzzle segment at the start of the game. Work was mostly distributed based on our roles. Our two artists focused on inspiration, moodboards, and concept art-related slides, while Nathaniel, our producer, worked on all of our documentation slides. 

My input on the pitch was almost entirely contained to mechanics, including developing the ideas when in the discussion phase and then presenting them on the slideshow. I had some minor input on other elements of the game, such as the story, but I left most of the more design-focused discussion up to my team. The biggest design-related element of the pitch that I had input on was the setting of the game - a train station and train - which comes from my solo pitch.

The concept for our game is that you play as a "mirror hunter" whose job is to seek out and prevent people of incredible malice from hurting those around them. These people, through their tainted inner-selves, are able to access the "mirror dimension". The mirror dimension is a reflection of the real world, showcasing this by warping everything that enters it. People who travel to the mirror dimension warp to look more like their inner selves. For example, the boss of our vertical slice for this game is a train conductor whose inner self looks like a large train monster. The main character views themself as a knight defeating evil, and as such may look like one when fighting in the mirror dimension.

Mechanically, the game is similar to RPGs like Persona, Mario & Luigi, Pokemon etc. The player, after solving a puzzle to get their train to arrive, will fight the conductor in the real world. The player gets their action, the enemy then does their larger, more powerful action, and the player is prompted to dodge it. This starting segment is intended to be deceptively easy, as the entire mechanic of the mirror dimension is that difficulty ramps up when the player is dragged into it by the conductor. Difficulty ramps by increasing damage dealt, attack speed, projectile speed, etc.

At the end of my segment of the presentation, I created a small prototype that showcases the interaction / puzzle mechanics that will be seen in the full vertical slice. To create it, I made a simple blueprint in Unreal Engine that looks for when the player enters a certain distance from the console. When a player enters this range, the blueprint makes a spinning interact text visible above the console with the corresponding keybind for the interact action. When the player presses the interact key (handled within the player's blueprint, triggering a function within the console blueprint), a widget that has been created and connected to the player's viewport is made visible and mouse control is unlocked. When the player interacts with it (it's a simple test puzzle), it's hidden again, and control of the camera is resumed. The player can also refuse to interact with the puzzle by leaving the interact area. This prototype was made fairly rapidly, and as such is a bit unoptimised (and also doesn't fully reflect how the system will function within the full demo). For example, I could easily modify the code of the spinning text to be a while loop within the overlap flip-flop so that it doesn't waste computer resources spinning the text while it's hidden.

The development of creating the interaction system and console blueprints was fairly simple. To set up interactions, I added a new input to the Input Mapping Context and bound it to the E key. I then added functionality within the FirstPersonCharacter blueprint that checks for all the blueprint classes in the map and uses a function stored within the blueprint that triggers the puzzle if the player is within its sphere collision radius. The blueprint itself uses a flipflop to hide and unhide the text label that displays the interact key when the player is within range. I store the visibility of the text label to use when checking if the player is within range or not, and then trigger the puzzle if they are. The puzzle is simply a widget stored in the player's pawn that is hidden and unhidden.

Reflection

Group feedback - "Well done on the presentation of your idea. Your group worked well together to present your ideas. Overall you gave clear insight into the overview, target audience and visual style of your game. Your inclusion of a video that explained the core gameplay loop helped to demonstrate the inner workings of your game, further providing clarity. One area to consider is the objective and the goal for the player. What will success look like and what do they achieve when completing your game? You should consider this before moving onto pre production- giving concrete goals will increase the user experience and player retention."

The most applicable section of our group's overall feedback to me is the need to consider player objective and goal, as they tie directly into the design of TDR's mechanics. Going forward, I will discuss with my team to decide on how we will further implement player objective into the overall core gameplay loop. One idea that has already been discussed is implementing some sort of "rank" (akin to the letter grade that Ultrakill provides to the player for doing well) at the end of the boss battle to reward players for playing smart (e.g. defeating the boss in a low number of rounds, never getting hit, etc.). Additionally, this rank idea also hits the second segment of criticism that was provided to our pitch - "what will success look like and what [does the player] achieve when completing [TDR]?". Success, in my opinion, could be directly tied to the player simply getting a good rank at the end of the vertical slice. It could also be story linked - for example reaching the end of the battle and 'saving' the conductor from the mirror dimension's corrupting grasp.

Positive feedback also mentions that our group works well together when presenting our ideas. I fully agree, and believe that our team is incredibly cohesive. Even when disagreements arise in how we should proceed with the project, I've never felt as if my team has been uncooperative or intentionally malicious. Additionally, I feel as if I have been given free reign to work within development mostly by myself, which gives me the freedom to use my own personal workflows that operate best when working solo.