project: Albireo (Academic)

My role: Narrative Designer, Producer

Anchor: Albireo

Engine: Unreal Engine

First iteration of Albireo.

Final iteration of Albireo.

What I did:

Communicated to artists and the engineering team what the player should feel and why.
Developed prototypes for narrative elements such as readable objects, test them, then iterate upon them.
Placed props, environment effects, and enemies accordingly.

I wanted players to feel wary as they explore the hallways of Albireo, keeping an eye on their infection levels and ammunition. Tension was the key emotional mechanic.

In order to prevent players from getting into odd camera glitches and splicing, I placed props in corners or around walls. This also helped guide players with naturally more "open" spaces towards their goals.

Below showcases the areas I designed or placed objects to help tell the story, or guide the player:

The narrative Design:

The following images are "PDA" notes I wrote for the game project, Albireo.

The goal was to create a lighthearted context to the gamespace and hint at a best friend of the main character.

Text: Hey Radial! Happy bday, jerkface! I got your graveyard shift covered so we can play games! Just don't tell my mom that's what we're doing up here. You know. In space. - Max

Text: Hey Radial, You'd think security would clean up after themselves. Tripped on the ammo boxes yet AGAIN. I swear, we could survive anything with the amount of bullets N.A.S.T.A security leaves lying around. Well, anything but tripping. - Max

Challenge 1:

Designing an "invisible" character that would act as a tutorial guide but remain is narratively relevant.

WHY: We didn't want players to think this was a humorous journey and the worry was that an operator with humorous intent would take away from the designed experience.

Result:

The Operator, its writing, and design were cut out of the project.
In examining the efforts it would take to just test this Operator, the time was not something the team could afford.

The idea was after Radial (the player) triggered certain states or showed signs of struggling, the Operator would chime in via dialogue and help the player. The Operator would have personality in guiding the player, conveying subtle hints or sarcastic comments at the player's attempts to survive.

Ideally, the Operator would also become a character alongside Radial (think BT from Titanfall 2). This would give players an external reason to survive and interact with objects in the game. If a fun character spoke to you as a reward, and you survived to continue adventures with this "operator", then players would feel more engaged in the survival aspect of the story.

Challenge 2:

Writing and designing narrative artifacts players would interact with and enjoy.

WHY: Getting players to interact and react positively to written text in a high-tension game is difficult.

Result:

I communicated to the tech team that some sort of glow or emissive effect should be added since the game's overall color palette and lighting were also a bit dark, even if the PDAs were visible.
I learned that putting them near enemies in any proximity, even if players could just hear them, was not useful.
The focus should be on adding to the experience or providing valuable information to players rather than making a fictional character that may or may not be useful to players

At first, players couldn't see the PDA objects, so I placed them in areas near resources, such as ammo, or towards the middle of the player's field of view. The screens weren't bright enough on their own after testing placements of them and if they were, players weren't perceiving them as important.

This effect was also the same when players could hear enemies but weren't sure where they were. PDAs were placed too close to engagements, and this caused players to notice but pass by them. This was because players were more concerned with surviving and did not want to read while trying to survive. Go figure.

Another issue that I noticed was that players might chuckle at Max's comments, but the notes didn't seem to add much to the story. Players weren't valuing the PDAs after about the second time reading one. My focus should have been looking to benefit players THEN engaging them narratively, rather than the other way around.

What I would have done differently:

1. Study more about creating a story inside a tense experience, where players are more likely to get distracted.

2. NOT juggle producing and design in one project. (more on this in Failures)

3. Focus on blending important aspects into the narrative before trying to tell the story.

The next steps would have been to revisit writing artifacts (PDA notes) that make sense no matter what order, are beneficial to read, and give insight on playing the game. The struggle to not only make these "not corny" (as my technical team would often say) but have a character worth investing in while primarily benefitting the player is most crucial.

I'd explore more of Radial's character arc. We spent a lot of time talking about what was possible for artists and how to create a baseline character that the average player could get behind. Because we wanted to go for a broader character, Radial's charisma was late in development. The environment, and how to tell a spatial story were critical in development before the character even had a strong model and texture.

This was my first attempt at narrative design in 3D spaces with an emphasis on thriller/horror elements. One of the challenges with working in a team was waiting for art assets to be completed in tandem with programming features. At one point, for instance, I, among two other designers had requested different types of crates and wall art to help convey the lore of N.A.S.T.A as a corporation failing at macro-management. I learned what to look ahead for in order to not swamp my teammates with requests, and understand the time it takes to produce certain assets.

As a fully remote team, it was difficult to communicate and visualize ideas artists had. We often drew pictures or found references, but I learned that remote work is not my strength. The next steps would involve finding methods to convey narrative techniques over remote circumstances in a more efficient manner. I would ask for help or clarification more often.

What would be next/What I learned:

Homeward Bound Anchor

Homeward bound (academic)

Role: Narrative Designer

The start of the game.

Barks during gameplay.

Description:

Homeward Bound is a 4-player online project where players from different timelines work to defend the resource-generating Groomba, Mimi, and build a new World Engine to return to their homes.

What i dID:

Wrote over 50 character barks, and 4 complete character arcs, and designed the emotional intentions behind player actions.
Designed 4 distinct characters: Pistachio, a chef from New York; Sir Tobias, a noble brawler; Karen, a cow-wrangler and farmer; and Erick, a wizard from another realm.
Wrote all scene dialogue and worked with my programming team to bring the character expression to life with limited art assets.

The process in a nutshell:

Start with a mindset of adaptability and trust. This was a smaller team.
Discuss methods of “what features of narrative can we do” as a team.
Develop characters that made sense within the genre and gameplay.
Write. Write. And keep writing.

I started this project with the mindset of flexibility. Since I'm not a programmer, we discussed methods of implementing story elements such as dialogue or JRPG-style dialogue boxes early on in the development process, as I was also the only designer.

Once we figured out core methods of how these characters would emerge in a high-action setting, I began thinking about the genre of the game, and how this could result in interesting characters and gameplay that was not only engaging but also made sense.

I began by considering 4 characters and defined their generic roles: word-playing chef, arrogant wizard (who conveniently knows what's going on in-game), tough-skinned farmer, and a brawling jouster. I chose these roles because they represent traditional types of playing styles, such as the mage, melee DPS character, tank, and ranged players.

Then I started with their backstories and why they needed to return to Earth from Pansulla. From then onwards, I spent most of my time writing dialogue and barks for each character that accurately expresses their personality while informing the player of needed information.

Below is a list of barks and dialogue exchanges I wrote for various states of the game. This was probably the most fun I had in creating this part of the product, even though much of it did not make it into the final build.

Challenge 1:

Writing distinct voices that were useful during gameplay.

WHY: Each character was meant to be unique, yet they also need to convey the same information at given times, such as asking for help.
I felt like I wasn't experienced enough to write so many different barks for the same thing in four different variations.

Result :

The barks I wrote were implemented after many iterations of them, and are in the game despite its cancellation.
After iterating on all four characters, reading them out loud, and constantly balancing functionality and voice, the barks present are ones I'm proud to say are in the game.

Despite my initial struggles to write distinct voices with similar contexts, I managed to succeed past this. I focused on that balance of voice and function as a lesson from Albireo, where I found myself focusing too much on voice in conveying narrative.

Challenge 2:

Writing scenes that were functional, interesting, and conveyed the narrative's context while remaining short.

Beyond the gray

Role: Narrative Designer

Anchor 3: BTG

WHY: Condensing important information in a logical, interesting way is a challenge for any writer.

Result :

Most of the scenes didn't make it into the game, but the text I did write can be found in the sheet above.
Proofreading was critical - even if it's not in the game, having someone read the lines will tell me when dialogue is doing what it needs to.

I learned a lot about how much time it takes to write for four characters in tandem with a smaller team, who could progress faster than a larger one. If I were to do it again, I would focus on the character's depths earlier on and establish their role in the world earlier, since this was what led to their final iterations of dialogue.

Engine: Unity Engine

Description:

Beyond the Gray is a side-scrolling 2D game in which you navigate an abandoned factory in search of friends like you to escape into the open air. You are among a special type of character - you turn into a bird when you venture into the sunlight.

What i did:

The project's overall goal was to produce, design, and plan a project from the story's treatment and written production plan to its final ship-ready build. I met this goal, as I wanted to tell the story of an airplane lost in a large, open space, searching for colorful friends in a dreary atmosphere.

Of course, this means I wrote the design document, a one-page treatment, production plan for 14 weeks, and developed this project within the planned 14 weeks.

The process:

Find the "fun" (mechanic)
Find the story
Plan, develop, test

Find the fun: The "turn" of this project (and its mechanic) of changing into a bird when the sun is interacted with was my implementation and creative idea for the main mechanic. I wanted players to feel small, but unafraid to explore their surroundings.

I came to this decision for two reasons: scope and context. It was easier for me to understand scaling if the player was smaller relative to the world. Furthermore, I knew the story's narrative was "a bird-like creature escapes into the outside world, in search of friends and escape".

Find the story: Going for a simple design of "navigate out, with friends or not by moving around" was easy, but at the time, a technical and design challenge I could face. My process often involves looking for inspiration and a deeper story to tell before beginning development. This is because I knew this project was a start-to-finish kind. I refused to leave it behind.

I landed on basic room-like levels by looking at other platformers, often ones with procedurally-generated "rooms" or levels. Games like Binding of Isaac require players to move through rooms that tell a story. Similarly, I wanted to try this kind of design, but with a more relaxed pace and different art scheme.

Plan, Develop, Test: After developing a weekly production plan for the 14 weeks allotted, I stuck to it as best I could. I tested the game around week 5, looking for confusion in players.

I asked these types of questions, recording and reporting on data:

Where were they confused and why?

Do players recognize the emotional tone, and are they experiencing it?

When do players make comments on their character? Environment?

After assessing these types of inquiries, I'd spend every other week addressing them as I continued development.

Moving forward:

Programming is not my strength and I had never used the Unity game engine to the same extent as I had for Beyond the Gray. Implementing the "jank" methods versus the more stable ones were mistakes I made early on, often retracing my code to fix issues in all levels repeatedly. I struggled to understand data preservation across levels, so the game lacks aspects one would expect in a typical videogame, such as pausing/saving features.

I would have spent more time testing mechanics and developing prototypes if I had to redo the language of C# within Unity. I spent more time in planning, since this is a strength of mine, in the sacrifice of developing to foresee difficulties in overall development. For this, I suffered setbacks and the game lacks the polish it needs. I learned that getting one's hands dirty early on in both being unafraid to make mistakes and learning within plans is valuable.