FMP Devlog – Silent Eyes

MA Games Design – Shijie SONG

About

Silent Eyes is a walking simulator that focuses on the everyday life of a sickly writer in a contemporary setting. Unaware of his own circumstances, you play in the stead of the writer who also happens to be an avid streamer. The game is an experimental narrative experience, that attempts to ask the player questions about the playable character’s situation – rather than answer them.

Inspiration

The game is inspired by the movie ‘The Truman Show‘, a psychological satirical comedy-drama film directed by Peter Weir and written by Andrew Niccol. The film stars Jim Carrey as Truman Burbank, a man who grew up living an ordinary life – unbeknownst to him – takes place on a large set populated by actors for a television show about him.

Since the game has a contemporary setting, it made most sense to try and hilight the possible dangers of online digital media, in particular, in-real-life streams (IRL Streams) which have risen in popularity over the last half-decade. This game is an effort to make the players question our (the stream viewers’) understanding of the situation if something were to go wrong.

Project Aims

Originally this game is about to merge both me and Absy’s FMP theses, which are “How Lock & Key Mechanism can be used to inspire the player’s exploration” and “Unreliable Narrators“. So basically the game is going to have a narrative part, which has a narrator keeps telling “unreliable” things, while using different kinds of Lock&Key mechanisms to control players’ progress and inspire them to explore around different places, which in return, will help the narrative.

Our theses – Research Paper frameworks

Tools: Game Engine / Collabration

For making this game, we used Unreal 5 engine:

For team communication and collabration, we used:

Microsoft Teams (Meetings and Files sharing)

Miro Board (Sharing mindmaps)

Github (Version control)

How we Collabrate?

By using the aboved tools, we are able to have regular meetings (about 2-3 times a week) and keep being sychronized with each other. We usaually use “Meetings -> Execute” type of cycle to do each small step within the game-making progress.

Rather than that, we also meet up several times during class offline, to make sure everything goes smooth.

Development Steps

Before making the game, we made a plan of the whole project. In which there are several steps that would be ideal to do.

They are:

• 1. Narrative and Ideal Experience Design
• 2. Mechanics
• 3. Level Design
• 4. Puzzles
• 5. Adjustments

In this blog, I’m going to break them apart and show you how we exactly execute these steps for the last few months along the way.

1. Narrative and Ideal Experience Design

First, we need a story. This story will be the base of the game, which will most likely connected with every small details in the game. Like: why are we in an apartment? who are we playing as? what should we do as players? why? and stuff…

And most likely, a solid story could provide the most natural way of solving unexpected problems. For example, when we were facing a problem which is letting player get a key clue before they should be able to do that, we went back to the story itself, created a new part of task sequence based on it that could solve this problem, and naturally came with an explanation which obeys the story logic.

For narrative, originally we made the player character (X) has some mental problems (like dimentia), which will make him easily forget the things that happened yesterday. And there is a Y, who is taking care of him. And a Z, who is(are) going to hurt X. X will do things everyday and wake up the next morning, do the smae things until he finds a way out.

Now, they sounds a bit solid.

But still, it lacks a lot of details. For example:

1. Can player see X/Y’s face? Z?
2. What is Z’s identity?
3. How to present information to players naturally?

In the next meeting, we also faced the problem of how are we going to combine our theses in this game.

But that’s also when we figured out a solid game-play.

On Aug 1st, we came up with a thought that, if we are going to do the dimentia thing while not going too deep on that (which is the game Before I Forget was trying to do, simulating the dimentia symptoms), we can put X in the loop.

• X, the player, is going to do certain tasks by following the instructions on the notes that left by Y, like A/B/C/D.
• Before X finish all the hidden(non-necessary) tasks, which are x,y,z, he is not able to escape the loop.
• Everytime X do the x,y,z, he gets a step closer to the truth of being inside a loop.

But how does the story progress? And what about Z, what will happen if Z hurt X? Will X die? How we gonna guide the player?

It seems a lot of new questions are coming out and now, we decided to take a rest. We were going to think of the basic mechanics first and hopefully along that way we can have some ideas to solve them.

2. Mechanics

We are using the “First person adventure system” template from the unreal market, which provides a range of functions that could be useful for us, like interactable doors/drawers, inspections, a first person character. Then we don’t have to spend a lot of time building them all, and fixing there bugs…

As you can see in the above image, we nailed down some of the main features we want in the game and also deleted some. Like we want the player be able to walk definitely, but for crouch/run/jump they are not necessary unless we have some gameplay built around them. That is important and I always found a lot of game developers are putting a bunch of the functionalities into the game while not knowing the reasons for doing that.

Complete the story structure

The next week we went back to finish what we left of the story thing, that’s when we decided to put the “streamer” theme into the game. It is something like Truman’s Show, though I came up with this idea before I watch the fim, but there was something different.

• The player is going to play as X, whose life is being streamed by Y and Z.
• But the player doesn’t know X is unaware of this.
• Y is the care-taker while Z is the stream holder, they use X’s life to stream and get profits.

So basically the player is going to watch a ‘show’, in which X eventurally will find out the truth by himself and figure out how to get out of there.

And 2 weeks after that, we decided to make a level script, which has all the details of tasks in game and how the player is going to do them and in what sequence. Also making the story more completed by thinking of more details and made plans for the next few weeks.

Also, I went to play some games that could inspire me recommended by Absy, like Before I forget and Marie’s Room.

This makes me realize the need of playing those, is that you may find out something that you definitely don’t want in your own game. For example, while playing the Marie’s Room, I found that the PC password note under the doormat in this game is actually blocking almost 20% of the players, and this game was meant to be way easier than that.

The problem was that the doormat is so hidden (right under the entrance door frame and the player is going to just walk by most likely) and most of the interactable stuff are in a different height level, which the player can easily see in their view without needing them to look down/up in a large angle.

So that gives me a warning of hiding something under the doormat. If we want to do that, we need to make sure that the doormat is most likely can be spotted by the player naturally first, and there definitely should be a hint telling the player that it could be interacted (like outlines). And indeed, we managed to do that in our game.

Looks easy right? But however, this small details and its way of mindset could definitely help reduce a lot of “stupid” mistakes.

3. Events (puzzles)

A huge part of the game is its events. As X, player is going to have something to do, they could be something to watch or interact. And that will also determine what are the things that player can do, what they need to do, and what they can not do.

Based on a template we made, we continued created more detailed events:

Then we put them into a certain order:

And for the details of each events, we further made more structures that could help us create their codes and functions, like this one:

Along the way of making level design, which I will put on the next chapter of this part of blog, we make this graph accordingly, to make sure all events and props are in the right places.

And for the events, we came to almost the final version of it:

Then we have this graph for our ending of the game:

4. Level Design

For this, we first searched for some visual references:

This helps us to find more relative assets and layout of the rooms, there are more but I’m not showing them here for the sake of saving some spaces.

For starter, we made a greybox level, which is based on a edited and real room layout:

The reason why we put a square rounded main corridor in the middle of the flat, was to make player feel “weird” and “wonder”, but that failed at last when we playtested it a few times, in presenting am ideal sequence of how the player is going to see each room based on their tasks.

And later in the iteration we changed the apartment floor layout into this:

But as you can see, we were going to have a reception, so we decided to have another floor for it and for the garage (later part of the game). And this was complex, but still is a good reference. So based on this, we changed to this:

This was more solid, and we can control the game progress as we want, and the player can go to a different room without a lot of rotations. But the bathroom is not needed because we don’t have anything inside there, and that’s why it became the storage later, which also provided a natural solution for the problem I mentioned at the beginning of this blog.

For the reception (ground floor), I came up with this first:

This is based on the ground floor of my current living building – New cooper point.

But still, there are problems:

• We want the player to see the final “locks” as soon as they get off the lift. Which are the garage door and the reception door.
• The mailbox should be just on their way when going to collect the food.
• There is a eavesdropping event at the reception desk, and we want the player hear that when they go to collect the food.
• Cut the non-necessary part of the scene.

Then, it became like this:

There are 2 versions, one in blue one in red. We picked the red one at last because we think it is more interesting to play, and we could put another plot in there. And the ideal experience will be:

When the player first comes down the ground floor, they will see the garage door and the back door of the reception, but they are here to “collect the food”.

So, when the player go to the front desk, they will see the food package on the table, and a trashcan with a note in it (not marked in the aboved image cuz it was a later decision).

At the reception desk, the player will:

1. Hear the staff talking inside the reception room.

2.Found the computer bin password in the trashcan beside the desk.

And when the player take the food upstrairs and get the information from the bin inside the PC, the narrator will tell the player to go to find his wife, in order to do that, he has to go to garage.

When the second time he goes downstairs to the ground floor, the back door of the reception room is opened. That’s because the staff finds out that X has found the truth and want to escape, so they went upstairs to catch him by taking the other lift. So they dramatically by-passed each other.

Now player goes into the reception room, finds out a secret file inside a folder on the table, which is the staff instruction file but has the locked safe code on it.

X opens the safe, get the garage key, and he can now go to the garage.

Cameara Cuts

Within the game, there are 3 camera cuts. They are for better narration and transition of the game flow. Making those are kind of the last second call but at the end I think we have done a great job. They went smoothly and there’s good audios and sound effects with them.

I picked a few of them here in the blogs.

I made them with the sequencer inside the Unreal engine. It was a good feature but somehow it keeps crashing the engine and I have to frequently save every changes in the cut to make sure nothing will get lost…

One huge difficulty I faced was how I presented that X was samshed on the back of head and faint.

I got this idea and there are some inspiration from Xintong Ye:

• When X got knocked out, he will first hear a huge and low-key sound, and head will shake as the sound pass a few frames.
• X might find it hard to keep balance so he staggering towards a few steps, he might turn his head down a little bit and then he will fall down to the ground.

With this list of moves, I was able to make that clip. And it finally looks like this (with sound):

After that, X will get dragged by the guy who knocked him out, which is the staff, and all the way to the lift, then at the end player will hear the lift coming, and that’s when it fade out. Which means X got put into the lift again, back to the beginning the game where we also starts in the lift.

Locks & Keys

There are a lot of keys and locks, and they are connected with the narractives.

For some keys which are not that obvious, I put a bird stand beside, not only to tell player there is something always beside the stand, but also connected with the “trapped” idea which indicates that the player is always trapped here. (Same as the bird cage in the garage secret room.)

For PC, which I made another whole different system, that player need to use password for its login windowand the bin.

When player get into the PC, they will find their PC is offline. That’s because they haven’t enable their router and wifi. So they have to find the router and enbale it in the PC by clicking on the little wifi button, just like we usually do in real life.

And we used the transition of a cut to tell player, that they can get the vinyl (which they can’t before they order the food because the character can’t reach the top of the shelf) after they order the food and try to walk out of the flat.

There are some also in the ground floor, those are available to check in our game video.

Playtesting

Till here, I’m happy to say that our most of the work and progress are put into this blog.

For Playtesting session, I’ll just refered to Absy’s record, which is also based on every playtesting session of our game: (From Absy‘s Blog: https://absy2201.myblog.arts.ac.uk/2022/11/30/silent-eyes/)

The Playtest for this project ocurred mainly in three stages;

In the first stage we mainly play tested the interactions and player controls – the goal was to see if players were comfortable with the controls for the interactions and were able to perform them seamlessly multiple times. This is the stage where we made changes like:

• Players need not visit the inventory to use an item, such as needing to use a key to unlock the door.
• Players are provided prompts when Items are Added to their Inventory
• Players need not interact twice for compound actions, such as unlocking then opening a drawer.

In the second stage we play tested the players progression through the game. This is the stage where we identified issues with our version of the level layout and level flows. The major changes as a result of the playtest were as follows:

• Changes to the Floor plan of the apartment and the reception area to make movement through spaces faster, yet retain the sense of exploration and investigative nature of the game
• Addition of a Subtitle System for the dialogue
• Additional lighting to hlep highlight important objects or points of interest within the scene
• Addition of Cut Scenes at the Start, Middle and End of the game to better explain the plot
• Vartiety of Bug Fixes, both for those that blocked progression and deminished the player experience

In the third and final stage we were mostly testing for the stability of the project as a whole and for performance across a range of available devices.

The periodic and rigorous play testing provided us with great feedback that both helped us fix/better the player experience along with proving us with important information about the players experience vs the intended experience.

Conclusion

Personally, I would say that I am satisfied with this project we’ve been made. We’ve conquered a lot of problems and also learnt so much from them. Making this game brought me these:

• Get to learn most of the blueprint using methods in Unreal 5.
• New dynamic lighting system: Lumen is tried. But it is so expensive.
• How we plan the project step by step is important because we are most likely to be really lazy if we don’t do that and execute them carefully.
• We should always know what exactly we want to make, and make sure our teammates know all the time as well.
• Using Github definitely help a lot with Version Control when multiple people are engaging the project’s code and files. And that also helps with our devlogs.
• 2-3 times of meetings per week is necessary, and every meeting we should make plans for further moves. This helps us stay in the creating work flow.
• When making new stuffs or decisions, make sure to have a available period of time and stay alone to think them clearly. Creating things a lot of time, for me at least, need to be alone and relaxed.
• Other stuff I might not think of right now, I’ll just re-fill this when I get them later…