Game and Interactive Design

My Game Design Process:
When I first joined the project, there was already an outline for the story and a clear goal for the software. Some interaction goals had been identified as well since they were relevant to the project’s storytelling. However, the specifics of the game had not yet been determined. To start the process, I brought a list of questions to the team.

Questions from the initial meeting:
• Does a design doc already exist, if not can we begin one now?
• What is the purpose of this game?
• What are the mechanics under consideration?
• What core mechanics can make the game stand apart? 
• What perspective is the game?
• What role does narrative play?
• Do components of the gamer need to be utilized in the research of brain emulation research?
• Is there any reason to consider multiplayer? 
• Are there any limitations of the engine to consider in our design? 
• To what extent can we break reality for the sake of gameplay? 

As the game mechanics are essential to the success of the project, I have conducted research on potential mechanics to discuss with the team. These mechanics will be informed by the story, but they must also be able to stand on their own, be enjoyable, and be easy to understand without the story. As we develop mechanics, we need to consider how they will work in play-by-play situations, maintaining the plausibility of the story while providing interactive elements that drive the player towards their goals.
Many successful games have core mechanics that are the hook. In this document, I suggest core items that may serve as the hook for our game, while also providing variety in gameplay to support each situation. I have not included basic features that are already common in games, such as menus and minor details.
Given the heavy emphasis on the story in this game, I believe that the primary interactive mechanic should be a dialogue tree. Allowing players to choose their responses and interactions will require them to pay close attention to the story, potentially improving its conveyance. To build upon this mechanic without overwhelming players with tutorials, I have categorized the mechanics and suggest using them in a modular fashion. By doing so, players can retain an understanding of how the mechanic works and how it adapts to new situations.
Since there is a lot of story to unpack, I recommend a focus on conversational mechanics. These can vary from speaking in person to email, social media, or text, providing players with a way to interact while also learning more about the story. As new situations present themselves, new abilities can be added to the core mechanics to support them. I took all the scenes written for the story and examined them for what could be converted into interactions. I was then able to come up with lists of possible mechanics for each event. 

I have prepared a presentation that includes written outlines on the left and proposed controls, questions, and suggestions on the right. Working with the team’s feedback, I have refined these ideas before moving forward. Below are some samples from the presentation or you can view the full Initial Mechanics’ Report here.

From my total proposed list, the team discussed which mechanics to keep, change, or refine, and I began prototyping ideas. Since the ERS engine was still under development, I used assets from Mixamo and Unity to build demos to demonstrate various mechanics. The primary mechanics I wanted to prototype were the core ones that others would be built off of. The hook mechanics of this title will be hacking and the dialogue system. 

Player movement is a crucial mechanic that requires careful attention. As it is a frequently used action, it is essential for it to feel natural and be easily accessible to the player. Since players will primarily position the character to interact with NPCs and other elements, precise control is necessary to ensure smooth and effortless gameplay. This fundamental mechanic serves as the basis for introducing additional movement modifiers throughout the game, such as camera control and actions like jumping. By establishing a solid foundation for player movement, we enable further modifications as the player explores the virtual world. This approach ensures consistency in control inputs while allowing for evolved actions that seamlessly integrate with the gameplay, eliminating the need for players to relearn controls as they progress through the game.

Another crucial mechanic that plays a significant role in the game is the “interact” mechanic. This mechanic involves triggering predetermined animations when the player interacts with elements in the game. It serves multiple purposes, such as introducing story elements through examining objects and seamlessly transitioning the player into different game modes without requiring them to control nuanced movements in between. The “interact” mechanic has a wide range of applications and is further elaborated upon in the Game Design Document (GDD).  

The dialogue system plays a pivotal role in conveying the story through interactive elements. To ensure its effectiveness, I aimed for versatility, allowing the same mechanic to be utilized in various situations. This approach prevents the system from becoming monotonous for the player. The dialogue system is designed to be employed in player-to-NPC conversations, phone calls, emails, and text messages.

During my research on implementation methods, I came across the open-source Ink plugin. I successfully demonstrated its functionality in Unity and determined that it could also be integrated into our ERS engine. Furthermore, I outlined a streamlined process for the writers to focus on writing using the Inky app, simplifying the implementation of dialogue for the development team. Included below are examples of Inky scripts, a visual representation of the dialogue tree, and a Unity demo showcasing the system in action.

To facilitate a subset of interactions, I proposed the inclusion of devices within the game. The phone, along with its related apps, offers a simplified user interface and serves as a central hub for these interactions. This includes functionalities such as the navigation system (GPS), communication tools, and the camera app. Integrating these features adds variety to the exploratory sections of the game and helps guide the player along the intended path when necessary events occur.

Hacking is a prominent aspect of the game, and in studying the main character (MC), I suggested the inclusion of a device that he has personally crafted. Considering the MC’s passion for trains and his technological expertise, I designed his device to resemble a conductor’s pocket watch. The concept behind this device is that it allows him to discreetly perform hacking actions in public. This design choice influenced the mechanics surrounding hacking itself. I proposed that the MC already has prewritten scripts for hacking, and by manipulating different rings on the device’s user interface, he can access these scripts. This approach adds a gamified element to the hacking mechanics, incorporating feedback and presenting the player with a puzzle-like challenge of assembling the scripts.

In the original story, gun turrets were deployed throughout the city following the terrorist attacks. However, I felt that this portrayal didn’t align with the intended realistic response of the city. I did consider how this original concept could work mechanically, which could have been a variation of tower defense.
My proposal aimed to leverage the existing hacking mechanic by utilizing police drones stationed nearby in response to the incident. By hacking into these drones, players would gain control over them, mirroring the player’s own controls. The primary difference would be the addition of a reticle and the ability to engage and neutralize the terrorists attacking the university. This revised mechanic not only builds upon the current input systems but also maintains a higher level of believability within the game world.

As the game progresses, the player transitions into an emulation within the virtual world. While the visual representation may change, the mechanics remain consistent. The primary challenge lies in altering the visual presentation of actions while retaining the same control scheme. In the left image, you can see a screenshot from the Unity demo where one of the three dials is used to select code. On the right, there is a visual representation of a similar concept, where the player interacts with terminal panels as data to select code, aligning with the theme of virtuality.

Working on Eternal Souls has been an exciting journey, where I had the opportunity to contribute to various aspects of game development, particularly in level design and mechanics. Collaborating with the talented team, we set clear goals and planned meticulously to create an immersive and engaging experience for players. From designing the environment to crafting dialogue systems and implementing innovative mechanics, I strived to maintain realism, express the game’s tone, and ensure player immersion throughout. The project incorporated storytelling, intricate interactions, and the seamless transition between the virtual and physical worlds. By leveraging open-source tools like Ink and Unity, I was able to bring our vision to life and create a compelling gameplay experience. It has been an invaluable learning experience, and I look forward to future endeavors in the exciting field of game development. You can view the Game Design Document here.

Weapon Balancing:
While I had some input on the types of weapons used in the game, they were fairly reliant on the games that came before. SMGs, Rocket launchers, Sniper rifles, melee, and so on. My primary role with weapons was to work with the other producer to refine their specs as well as balance the weapons for use in the game. We would perform experiments with the prototype builds to compare the range of weapons and amount of shots they took to dispatch other players within the given time of the first encounter. The ultimate goal was to find balance so that this competitive multiplayer remained fair, yet fun.

Various weapon stats we modified to reach this goal include:
• Ammo count – How many shots the weapon can carry
• Range – How far the weapon can fire
• Damage – How much damage each shot does
• Fire rate – How fast the weapon fires those shots
• DPS – How much maximum damage the weapon could execute at optimal conditions.
• Shot focus and scatter accuracy – Accuracy of shots fired based on the range of the shot fired
• Accuracy multipliers – Headshots on most weapons other than “one shot” weapons had damage increased for these hits

We had to give each weapon a set of advantages and disadvantages against other weapons and environments. Weapons like the sniper rifle we best suited for the player who could place themself at a distance from other players but would not fare as well in a narrow passage with blind corners against a shotgun-armed player. These weapons also had an impact on level design where sections of each stage provided an opportunity for players with preferable play types to use these weapons in environments that suited their advantages.

Mobile Device Firing Mechanic
I contributed to the development of the controls for Archetype by generating ideas and visually conveying existing concepts to the team during the game mechanics prototype phase. One challenge we faced in creating a first-person shooter game on a mobile device, particularly during the early days of touch technology, was how to handle all of the player inputs. Although the iPhone supported multi-touch, we were still limited by the technology. I was tasked with researching our options and presenting them to the team so that we could choose the best option. We reached a compromise by allowing players to fire when their reticle hovered over an enemy player. This reduced friendly fire incidents and allowed players new to this type of gameplay to participate with lower skill level requirements. To provide more strategic options for skilled players, we enabled firing by tapping on areas of the screen without controls. This allowed players with melee weapons and those that caused splash damage to use them to their advantage. Below are some sample images of one of my proposed concepts for implementing the system, which considered animations and firing angles.

Developing Gametypes and Features
I also had input on game rules and modes of game types. As a team, we selected the core game modes that would be included in the initial release. I continued to maintain lists that included new game types and their descriptions, including proposals from other teammates. Additionally, I created concepts for new weapons and items that could be included in future DLC. I also developed new free features that could be included in future updates, often focusing on quality-of-life improvements to make the existing game more enjoyable.

One example of a feature I designed was based on future plans for clans. The working name was “Buddy Feed” and aimed to improve the social nature of the game by allowing users to compare their stats with their friends’ lists. While there was already a global leaderboard, being a small fish in a sea of players could be discouraging to some. By comparing themselves to a smaller pool, players could set more realistic goals and may be motivated to engage in more active gameplay.

An example of a concept I proposed and developed was a modified version of Capture the Flag. At the time, no other developers had a CTF mode, but we anticipated that competitors would come up with their own versions. One of my teammates suggested using the flag from our existing axe model, and I took that idea and fleshed it out in a presentation called BFA, which stood for Big “Fabulous” Axe.

In the presentation, I explored different scenarios and solutions for implementing this game type, including questions like “Should each team have their own axe at their base?” and “Should this game mode have its own new maps?” I also suggested different goals for the player when they have an axe and discussed how we could integrate this new game type into our existing game, as well as what would be needed at a minimum to make it work.

I also expanded my suggestions to include changes to the UI and HUD that would be needed for this new mode. Overall, my concept aimed to create an engaging and unique gameplay experience for our players while staying true to the core mechanics of our game.

Due to being a small team on Archetype there were lots of opportunities to contribute to the game design. Through this title I was able to create ideas as well as focus on documentation for the game. There I was able to learn, and contribute to the project. What was important was the teamwork and how we each could suggest ideas for the betterment of the game and others could flesh out the concept to make it fully realized. Through this, the game was a success.

Nori and the 8 bites
Nori is a character I designed many years ago, and I have fleshed out a world for him and the characters that inhabit it. There were short time constraints to building this demo, and while I wanted to experiment with hand-drawn animations, the time frame was better suited for pixel art. Below is the most up-to-date design of Nori as well as the pixel art that was derived from the main design.

Goals

The goals for this project were dictated by the limitations of time. I quickly assembled a list of possible mechanics and goals and distilled them into a design document to focus on development and avoid feature creep. The goals for this demo were as follows:

• The visual design would be pixel art that is reminiscent of the capabilities of the NES and SNES.
• The game would be an action platformer that combines jumping and shooting.
• Challenges would be introduced singularly to allow the player to learn them.
• When a new challenge is introduced, an escape route for the player must be provided so they are not punished too quickly for failure.
• Difficulty would increase as the player progresses.
• The game would feature a world boss.
• The game must exhibit character through its design and animations. 

Story influences gameplay
The story for Nori influenced the gameplay mechanics. Story and gameplay can work together to create a cohesive and engaging experience for the player. By having a clear story with defined characters, settings, and goals, it becomes easier to make decisions on what mechanics to include in the game. It also helps to create a sense of immersion for the player, making them feel like they are a part of the story and the world in which it takes place.

For my initial list in my design doc, I explored all possible mechanics. These mechanics included movement, platforming, and types of combat. I distilled this down to a core set that I felt I could focus on and refine. Below are images of some of the proposed ideas. 

Core Mechanics
I selected a set of possible mechanics and refined them to fit the game. Below is a sample of sprites that relate to these mechanics:
Idle: Nori bobs and blinks to give the impression of personality and liveliness.
Movement: Nori can run and backtrack to any unblocked part of the level.
Jump: Nori’s jumping height is based on the size of one tile, and this is taken into account for all platforming challenges.
Spitfire: Nori eats chili peppers to gain the ability to spit fire, allowing the game to function as a shooter without the need for a weapon. SFX and animation provide feedback to indicate that the ability is working.
Life System: Nori dies with a single hit, and players are given feedback through sprite animation and audio. Nori starts with three lives, but players can earn more by finding hearts. Hearts are placed in higher-stakes challenges to encourage risk-reward behavior.

Challenges
Challenges in the game are divided into two types: enemies and platforming challenges. These challenges are introduced in a specific order to help players learn and feel accomplished once they pass them. First, a single enemy or platforming challenge is introduced by itself, allowing the player to see how it works from a safer distance. Next, the challenge is clustered with more enemies or placed in a way that changes the challenge. Lastly, the challenge is combined with other challenges, whether they are environmental or other enemy types.
There is a variety of enemy types, each with its own patterns and characteristics that are visually identifiable to the player. Some enemies walk, fly, or jump in a pattern, while others shoot projectiles that the player must avoid. All enemies are weak to Nori’s fire attack, so the player must observe their patterns if they want to clear the area of monsters.
Each world in the game is finished with a unique boss that presents new puzzles and challenges for the player to beat. Beating a boss allows the player to earn a more powerful chili pepper, which levels up Nori’s attack.

In addition to platforming, obstacle challenges include pits, lava, vertical fireballs from the lava, and horizontal projectiles from statues. These types of challenges require more precision movement from the player and can be more challenging when an enemy is present on the screen. Due to Nori losing a life in a single hit, all hazards are made clear visually so that the player is not risking a life to test a passage. Platforming challenges are introduced in the same way. For example, if precision platform jumping is introduced for the first time, it is not far above the ground that way if they miss the player can quickly try again. This allows them to better hone their skills before they progress to more difficult repeated areas of platforming that will have a greater consequence for missing.

Conclusion
My goal in all this is to create a game that is fun, challenging, and has heart. I want the player to be interested in Nori’s world, and characters and want to see more even after the game is complete. This prototype lends itself to a greater vision of the project that I plan on revisiting and releasing. If you want to read more on the design of Nori, you can check the illustration section. If you would like to read about level design for the game you can read about it here.