Week 2 – Design Intention

Exercise on Essential Experience

On Monday we did an exercise of analysing an existing game’s design intention and how the developers choices support these.

This game has very clear subject matter – you work at an immigration checkpoint for a fascist state.

Papers, Please intends to immerse the player in the environment described above, with audio and visual motifs clearly based on the USSR. There is an emergent design intention of hopelessness – this is supported by the design choices of a repetitive/mundane closed game loop and the constant reminder at the end of every day of by how little of a margin you are able to support your family. While your actions do heavily affect the story/events and what ending you get, these are either winding up imprisoned or dead, or simply aiding an organisation larger than you (whether that is the government or the resistance group EZIC). This is also underlined by the repeated occurrence of terrorist attacks, which over time desensitizes the player to the shocking nature of this once again immersing the player in the experience of living in a fascist state – of the individual being powerless compared to those with more influence, or having to make great sacrifices to overthrow them.

MDA Analysis

Mechanics: approval/denial of entry, reading and analysing documents, important choices

Dynamics: supporting Arstotzka/EZIC, follow/disobey rules

Aesthetics: emotional responses to consequences/outcomes of actions (eg. guilt, pride etc.), underlying sense of hopelessness

Applying this lens to my game idea

The class & lecturer’s analysis of Unpacking‘s essential experience & how it uses “show not tell” gameplay to tell a story gave me an idea for how to condense one of my ideas from last week to have a realistic scope for a student project and make the design intention clearer.

While the world exploration & NPC interaction was the springboard for this idea, I feel the experience I wanted to design lies in exploring the question of identity with the body-horror-esque idea of replacing body parts. During this session I had an idea inspired by how Unpacking uses the actions you’re performing and the items you interact with to tell the story rather than being dialogue heavy.

Switching the focus from obtaining the parts to attaching them to the robot’s existing body as a design choice would make the experience more focused on the above central theme and more realistic to develop in one semester.

The gameplay loop could switch between brief visual novel/talking sections between the robot and his mechanic to provide context on characters and their relationships and goals, and piecing the new parts with the robot’s existing body. This part could involve simple logical puzzles – maybe certain parts of the robot’s body need to be rotated or opened to attach parts, or some power modules need to be turned off.

This idea allows for a more flexible game length – you could split it into a few levels, eg. new legs, arms, torso then head. With each “level”, the player would be replacing a more integral part of the robot, eventually being forced to confront the loss of the robot they’ve gotten to know throughout the game – or maybe being presented to the choice to preserve him.

These aren’t set in stone, but provide options for pillars that could support my desired intention & experience.

Intention & Experience

I’d like the player to feel a gradual, strong sense of discomfort and loss from the bodily changes/borderline mutilation they enact on their robot character.

I would like players to experience the tension between the desire to achieve a goal and the cost of attaining it.

I want players to consider questions of body, identity and conformity through the metaphorical nature of the body-horror genre.

Discussion

After discussion with Vanissa and Issy, we came up with another idea that would make the tension listed above a more consistent and prominent part of the experience. Rather than being set in the workshop, the player could already be in the training program for the space mission. Throughout, they could be presented with the choice of upgrades – if you upgrade, you don’t fall behind and are more likely to make it on the crew, but maybe other characters you had/form relationships with have varying negative reactions to it as you start to lose what is integral to your character. Alternatively, if you choose not to upgrade, you could fall behind in certain aspects. There would be different characters urging you (in subconscious or outward ways) in different directions, and perhaps like Life is Strange, it could all culminate in one big final choice that determines the outcome for your character.

Vanissa suggested I try making something – whether it’s a storyboard or sketches or a powerpoint – to get a clearer idea of what feels right for this vision and what direction it should go in.

We both agreed it’s still a struggle to keep the idea to a realistic scope, but I will research the key elements I want the game to explore and create an experience of, and try making something to do with the game. By doing both of these, hopefully I can have a better idea of the experience I want the game to create.

Additional Iteration

We did an exercise on Tuesday of iterating on our current idea with different genres, however none of the ideas really grabbed me, and I struggled quite a bit with thinking of other directions to take it in.

Considering core element & prototype

After Monday I felt very stuck on what the game would actually entail, and how to execute my desired experience in a scope-conscious way. I discussed this with Jordan and some peers and they reminded me that while advice is useful, I’m not obligated to follow everything to the letter, and it’s important to keep what I really want this game to say and achieve as a vice to hold on to while developing the idea.

With this in mind, I was able to brainstorm with them and land on a solid gameplay loop and prototype idea that are both feasible for our time constraints.

GAMEPLAY

1. Visual Novel sections. Each stage/level will be bookended with a short exchange between the robot (player character & protagonist) and their mechanic. There may also be brief dialogue while obtaining and attaching parts.
2. Obtaining parts. At the start of each day, after talking to their mechanic, the player will go into the world and find the part they’re looking for. It may be simple as buying, or they might need to dumpster dive, steal or craft. There could be NPCs that the player interacts with multiple times, however the inclusion of this would depend on time.
3. Attaching parts and seeing change. The action of attaching/upgrading/replacing parts would be conveyed through small puzzles. For example, some parts may need to be rotated or a certain system may need to be powered off. Then there would be a wide shot showing how our character now looks after the upgrade.

The core of the game is the story and narrative beats. As the player strives for the goal of qualifying for the program, there’s a building sense of unease, with a final realisation/climax at the end. To achieve this, throughout the game the player could be upgrading/replacing a part more integral to their identity, as mentioned earlier in this post. The game may end with replacing/erasing the memory core, but with the game ending before the process is over, leaving it sort of open-ended while still achieving that sense of losing identity that’s at the core of the idea.

Then in terms of prototyping, Jordan suggested making a condensed version of the narrative in Bitsy, seeing if the beats and climax have the desired impact without the fluff.

Tech Session

I booked a 1-to-1 session with Ross this week to seek guidance on resources to build technical skills and knowledge, and also for what engines/tools would best suit both the prototyping and development of my idea.

Since I’m starting with basically zero programming knowledge, I want to have a resource I can go to throughout the year to develop myself in a language/engine/skills that are widely applicable and useful while also (relatively) easy to pick up. In terms of prototyping, I can use Bitsy, but I’d like to see if there are other options for accessible tools that might still develop my technical knowledge.

Ross gave me various things to look into for both prototyping and skill development.

https://school.gdquest.com/courses/learn_2d_gamedev_godot_4/learn_gdscript/learn_gdscript_app#lets-get-started

Ross sent the above resource to help me learn GDScript, the programming language used in Godot. He also heavily advised not to get stuck only following tutorials, and to learn by both research and practice.