Interactive Design

Game and Interactive Design

I have had the opportunity to work on various game projects and hone my skills in game design and mechanics. Through these experiences, I have gained valuable knowledge and insights into the process of creating engaging gameplay and compelling stories. While I am still on a junior level, I am passionate about game design and always eager to learn more.
In this section, you will find examples of the game projects I have worked on, including my role in each project and the mechanics I contributed. These projects range from narrative-driven games to action-packed adventures, and each one showcases my ability to think creatively and strategically when designing gameplay. I hope you enjoy exploring my work and seeing my growth as a game designer.
BrainGenix – Third person story driven game
Archetype – Mobile Multiplater FPS
Nori and the Curry Caper – 2D Platformer
Design Constraints – Turning a dice game into a digital tool


Third Person Story Driven Game

BrainGenix (BG) is a multi-departmental effort that aims to develop software for Whole Brain Emulation (WBE), which involves replicating all the important functions of a biological brain by simulating its internal dynamics with a high level of detail. The purpose of this game project is to support research in brain emulation and eventually allow interaction with brain emulations. As the primary game designer, I contributed to various departments on this project.


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.



Multiplayer FPS

Archetype was a competitive FPS on IOS. The game was designed to allow multiplayer up to 5v5 over the 3G network. While I acted in many roles on this project, I also worked with the team to develop mechanics as well as refine mechanics designed by the other members of the team.


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 & The Curry Caper

Action Platformer

Nori and the Curry Caper was my senior project at SIUE and I handled the entire development of the game. The goal of the designs was to provide a challenge that called back to that of classic 8-Bit games as well as told the story of this world through its environment. This was a love letter to retro platformers as told through Nori’s world that I created.


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.


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 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.

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.


Design Constraints

Turning a physical game into a learning tool

This program was the result of a student-funded project I was awarded by SIUE. For the project, I was to develop a teaching tool based on a dice game created by Barb Nwacha. I handled all aspects of the project from start to finish. Here I will focus on the mechanic design but if you are interested in the User Experience aspects of this you can read more about this project here.

 The purpose of this application is to teach typography by limiting students’ choices and forcing them to work within their constraints to complete an assignment. This approach aligns with the design principles of Massimo Vignelli and Johannes Itten. The following outlines the process we followed to create this project.



The original concept for this game was a physical dice game. The player had a cup for shaking and tossing the dice. The dice then had a combination of typographic rules that the designer would use to develop a graphic design project. My challenge was to adapt this concept into an application that would allow teachers from around the world access to use this as a teaching tool. 

• Needs to be easily distributed globally for teachers and novice users.
• Intuitive and easy-to-use controls
• Entertaining to use
• No audio – Relies on visuals
• Completed under limited time constraints

The first challenge that we needed to resolve is the distribution. Originally the client wanted this released as a mobile app. This provided some logistical challenges for them, especially with upkeep and platform dev. After exploring all the pros and cons we decided to go with a web-based application. It could be maintained locally and easily updated. Having established the platform we could then consider the control scheme for the app and how to best implement it.  

Interviews and research
To create the best solution for the client, I conducted interviews with stakeholders to understand their needs and incorporated their feedback into my research. My process involved developing prototypes to explore effective and engaging interactions. Using Adobe XD, I would create initial concepts and then build working versions to test with stakeholders and gather feedback. I conducted blind usability testing with both stakeholders and testers and then provided them with a written persona that explained how to use the app. This allowed us to compare notes and assess how intuitive the controls were. Below are a series of prototypes whose sole purpose was to test and explore different ways of handling user input. 

Through building prototypes, we found a widely used control scheme that could accommodate a full range of skill levels. That same control scheme could translate from a web browser to a mobile device. The solution was simply selecting an object that represents a parameter and dragging it to a designated area to confirm the selection. This motion is something anyone who had used a desktop computer or mobile device has experience with so the learning curve would be low. From my research and testing, I wrote a short design doc that would establish all the goals for the software design so that it was built for those requirements and avoided feature creep so that we met our schedule goals as well. You can view the document here.

Visual Design

Since this tool could not rely on audio, we needed to create a visual representation of a machine to give the impression that it was processing the user’s choices. Through animations, we could provide feedback to the user, letting them know if their actions were executed. The client wanted a machine that looked like it did something but also had a whimsical element to it. As this was a tool that taught typography, the machine’s design drew inspiration from past typesetting practices.

To make the machine’s operation clear, we labeled it with “Insert Parameter” and added a port on the top that would bob up and down to draw the user’s attention to the right place to place the parameter. In addition, we made sure that the port size matched the size of the icon designs, which were used to represent different parameters. The icons had labels to ensure that users knew their purpose, but their visual designs also made them easy to recognize at a glance.

To inspire the design of the machine, we collected visual inspirations which helped us incorporate the right elements into the final design.

Machine Design

In Adobe Illustrator, I designed a machine in parts that could be animated. The goal was to create a call to action that relied on the visual affordances of the machine. I wanted it to be both functional and charming, so I added a whimsical touch to the design. The gears turn, the dial moves back and forth, and the machine chugs up and down as if it is producing something. The dial and gear rest where eyes might be, and the keyboard is in the place of a mouth, giving the machine a bit of personality.

To make the interaction intuitive, I aimed to allow for user discoverability. I wanted to invoke wonder and curiosity in the experience, so I added a flashing text that says “Insert Parameter” and an empty port to indicate where something should be placed.

To ensure that the animation and interaction worked well together, the machine was implemented into Unity and tested thoroughly.

Project Completion and Key Takeaways
With the end of the URCA program, I completed the project within the timeframe. I also met all the goals we set out in the beginning to achieve. Through our research and implementation of this project, I found the idea of constraining the user’s choices to be a useful tool in application and game design. Too many choices can be overwhelming and while having limited choices might not appear optimal on the surface it can allow for more user creativity as well as allow them a more direct path to their goals. I also found the foundations of User Experience and Usability to be essential in developing digital experiences for users. You can try out the application here.