RETRO-TAC (Development Name) is a FPS Immersive Sim. You play as an abandoned agent continuing your mission, stopping an organization from completing their plans on enemy grounds. Explore open maps, infiltrate complex enemy bases and play tactically to save the country from certain doom.

2024-02-12 13-55-10.mp4

PROJECT DETAILS

ROLE | Game Designer & Project Manager

TOOLS | Unity, Miro, Confluence, Jira

DURATION | 4 Months

TEAM SIZE | 5 Members

RESPONSIBILITIES

Creating Designs for Resources the player and Enemy uses
Concept Maps and One-Page Designs for the relationships Resources have with each other
Designing the philosophy of how we implement secret areas into the game's world
Storyboarding processes of how game mechanics function in the game world
Creating Enemy AI designs and detailing their playstyles against the player
Designed information presented in the game's HUD, Loadout and Pause menus
Concept Art and Prototype Art for the game's current UI
Maintaining and organizing documents through Confluence
Detailing Meeting Agendas, Hosting Meetings and taking down Notes
Creating the team pipeline and maintaining said pipeline through Jira
Detailing the pipeline through team documents accessible through Confluence
Onboarding new members with visual presentations

DESIGN PHILOSOPHY

This was my first time working as a Game Designer in a genre I was unfamiliar with. This was an opportunity to see how my design philosophies and processes mesh with different genres, and what I need to change. The rules I followed for myself was the following:

How can I make the player understand game mechanics through in-world signifiers?
How can I design hidden systems to be intuitively learned through trial and error on the player's part?
How do I design the game space to match how gameplay and mechanics function in this genre?
What should I change about my design approach in designing systems and conveying mechanics?
How does the player expect their designs to function in a genre like this?
What tropes in this genre can I use to enhance my designs and philosophies and bring it into an FPS Immersive Sim context?

DESIGN PROCESS

DESIGNING THE SPACE TO DRIVE THE PLAYER

In studying how FPS games function, and the appeal they give to the player, I learned that the space the player inhabits is essentially a system. How the player moves in the space and the limitations that the space imposes on the player, forcing certain behaviours from the player. Early on in development we wanted to implement secrets into the game world. I saw this as an opportunity to bring my skills and beliefs as a designer and adapt it to the context of an FPS Immersive Sim.

DEFINING THE SPACE AND MECHANICS

In researching how to design the space to contain and lead to secrets, I looked to games that encourage exploration and are known to be praised for hiding secrets.

After my research, I designed how the space can lead the player to certain behaviours to help in finding secrets.

The layout of the land, mechanics like enemy patrols and affordance tools like color or symbols can all be used to drive player behaviour to look at the environment in the context of searching for clues that can help the player in progressing their character.

This is done through using player expectations. Players divide spaces in FPS games to always have something of purpose within them, even if the purpose is changing movement in a certain way.

Using those expectations to lead the player in areas we want them to go will also make the player feel like they have discovered secrets through their own efforts with little or no guidance. The player feels rewarded and we can intensify secrets later on in the game for players who want this reward again.

RESOURCES AS GAMIFIED SYSTEMS

In researching FPS games, I saw how Resources, mechanics like HP Pickups or Ammo Pickups, could be used in a more gamified context to drive player behaviour. I say gamified in the context of creating systems to drive player behaviour and emotions without worrying too much about consistency with the real world. Players generally accept and expect these systems to act in service of the gameplay rather than adhere to simulating real life understandings of gunplay.

USING RESOURCES TO MANAGE DIFFICULTY

Resources in our game are Health Pickups, Ammo Pickups and Shield Pickups. These Resources helps the player greatly in fighting against enemies. Resources are scattered across the world or drop from enemies.

The usefulness of Resources and the rate at which they drop will heavily influence how the player approaches every enemy encounter. I know we wanted to create a game focused on tactical gameplay, yet in this part of the design process that wasn't clearly defined.

I created multiple designs that exist on two opposite ends of the difficulty spectrum. High Drop Rates and Low Drop Rates on Resource Spawning exist on two ends of a spectrum that determines how many options the player has in approaching enemies.

Less options through Resources means more tactical play. I made sure to highlight the functionality of the Resource Drops and let the team know how drop rates effects the difficulty for the game.

I deployed many new diagrams I wasn't used to in order to present this system. This was to grow as a designer and to try and bring my experiences as a designer to a genre I'm familiarizing myself into.

ENEMIES USING THE GAME SPACE

In designing the Enemy AI I knew the most important aspect to design was how Enemies use the game space. My research led to many enemy types, all with unique mechanics, but I noticed that they always manipulate the game space in some way, or the player's use of the game space. I was most excited to design this, since I love designing combat and I feel this was a great chance to bring aspects of myself as a designer, my philosophies and approach to design, into the context of FPS games and have it synergize with the genre.

ENEMY STATES & SPACE INTERACTION

I kept how Enemies interact with the game space small in scope while still keeping spatial interactions interesting. I created three enemy types that use the same infrastructure in mechanics, yet function differently to different situations in AI behaviour.

Enemy AI will look at the space they inhabit and move differently and interact with level elements differently based off inputs from the player's position in the game space.

These rules are hidden. The player has no information on Enemy Types and how enemies behave. I want the player to learn from experience. Keeping that fog of war on the exact rules on Enemy Behaviour will keep the player careful and enable the player's mind to play more tactically.

Enemy AI and the tools the player has through level objects and Resoucre Drops will create an experience where the player grows through tactical growth. Game progression is measured through how well they understand using the environment to face against enemies.

DESIGNING THE UI FOR PROTOTYPING

In joining the team it was my understanding that I would be designing gameplay systems and mechanics. When UI was being brought up as a concern in development, I was surprised when it was my task to design the UI for the HUD and updating the Loadout Menu. It was an opportunity to grow and a chance for me to grow as a designer completely outside of areas I'm used to, so I welcomed the challenge and I was extremely grateful for the opportunity.

UPDATING THE LOADOUT MENUS

When updating the Loadout Menu, I researched the functionality of Loadout Menus in games within the same genre, and studied the aesthetics of older FPS games. I changed the layout of some elements of the UI to better fit the tone and ease readability.

Since there already was a Loadout Menu in the game, my process was focused on improving any flaws I noticed with the menu and enhancing the experience as much as I could through the design of the menus.

MISSION SELECT UI

Creating the layout for Mission Select was an important task. I wanted to fulfill two requirements: setting the tone of the game for the player and creating an UI Menu that communicates relevant and updated Mission Info to the player to guide player behaviour.

I was worried my designs may not have coexisted with the aesthetics of the game. In my research, I've found that my designs can exist in older games. I had to find a good balance of communicating what certain areas of my UI meant while still trying to make the UI diegetic with the game world.

HUD INFLEUNCES MINDSET

The most important aspect of UI that I designed was the Player HUD. The HUD tells the player information about the Player Character and the World, and chooses to hide information related to those aspects as well.

Information that the HUD tells the player will dictate how the player understands the game. Situations they approach, plans they have and the understanding of how game mechanics will effect them are all done through the HUD.

I wanted to tell the player necessary information but not have that same information allow the player to play comfortably. Tactical gameplay is creating plans around uncertain knowledge, knowledge that you do have and keeping your plans adaptable.

In order to achieve this experience I made the HUD display necessary information while staying abstract. The player understands what is going on, but they don't know any details for mechanics like Health. Details related to player vitals would provide too much information for the Player and keep them playing comfortably.

Aesthetics was also key in keeping the player in the mindset of playing as a tactical soldier. This was my oppurtunity to blend aesthetics with design.

PROTOTYPING THE UI

Towards the end of our time for development, there wasn't enough time to bring artists to create UI from the designs I've made. I used a template to create my designs and tried to follow as much of the original design as I could.

I still wanted to try and achieve the effects my design had on the player in the original system with this prototyped design. It challenged me to look at my design and see what was necessary to keep and change to get the same results I wanted from the player.

PROJECT MANAGEMENT

SPRINTS AND USER STORIES

I have worked with some members of the team on games before, while others were working with us for the first time. I took initiative in detailing the team workflow for our game. I met with all team memebers and assessed the time they would have per week and the level of commitment they were willing to put into the game individually. After detailing this information, I created a workflow that fit the team's and the game's needs.

I wanted to focus on User Stories since it's an automated process that helps in unifying team goals and vision. It can be done on a bi-weekly basis and it only requires the team to meet once a week.

KEY TAKEAWAYS

BE READY TO WORK OUTSIDE OF YOUR COMFORT ZONE

Game development is unpredictable. Surprises will mean extra work and not every member will be available to do extra work.
Tests your understanding of how your designs will exist outside of the context you work in.
Expands your skillset and allows for you to have greater ownsership of the systems you design.

DESIGNS AREN'T UNIVERSAL

Players respond to mechanics differently depending on the genre. You need to understand how mechanics exist in certain contexts and why they succeed/fail.
Testing your designs in a different context and seeing how to make them work expands your understanding of game design and the games you can produce.
You have a better grasp of player behaviour and learn things exclusive to that genre that you can't get from anywhere else.

ALWAYS WRITE DOWN YOUR PROCESS

Writing things down brings a universal understanding on how the team will function throughout development.
Helps the team feel like the work their doing is "real". Boosts morale and team motivation.
Easier to commit to greater tasks and ideas with solidified processes.

Page updated

Google Sites

Report abuse