Watch Out: A horror game implementing Eye Tracking

Introduction

Eye tracking has always been fascinating to me. The ability to control something using merely your eyes feels a little like a super-power.
After recently discovering a trend of 'react' YouTubers and Twitch streamers adding a circle on-screen that showed their viewers where they were looking, I found myself intrigued by how much novelty this brought to an otherwise quite 'stale' concept.

I have always wanted to develop a video game with a new, 'out of the box' kind of concept. So this got me thinking on how I could take that novelty that eye tracking brought to the 'react' content and use it in a video game context. After some research on existing uses of eye tracking in video games and a brainstorm session on gameplay mechanics that rely on eye tracking, I decided that an interesting, suitable genre to bring the use of eye tracking to would be the genre of horror games.
Because eye tracking isn't that widely used among gamers, the average gamer won't be used to having such a peripheral influence their game. This brings an extra level of unexpectedness, and unexpectedness synergizes very well with horror games.

In this exploratory research project, I will create a horror game with mechanics that rely on eye tracking, in an attempt to provide some examples of how eye tracking mechanics can improve the immersion of a player.

Eye Tracking

While eye tracking may not be very widely used within the gaming industry, I am definitely not the first one to look into eye tracking based game mechanics. In this part, I will list what gamers can gain from eye tracking at all and look at some existing use cases of eye tracking in games.

Why Eye Tracking?

How can gamers enhance their gaming experience by using an eye-tracking peripheral?
J. David Smith and T.C. Nicholas Graham note (1) some of the possible pros that are inherent to Eye Tracking based input systems in video games:

  • Eye-based input is very natural
    • As opposed to having to learn new motoric skills
  • Eye movements are extremely fast and requiring little effort
    • This can impact the amount of time and effort a player has to spend on performing certain ingame actions.
  • The eyes provide context for other forms of interaction (humans often look at things before interacting with them)
    • This removes the need for other context filters.
      i.e. in a voice controlled smart house, you could look at a lamp, and say 'Turn on' instead of 'Lamp turn on'
  • The technology it is based upon is mature
  • Eye tracker components are inexpensive

Existing use cases

From First Person Shooters [(2)] all the way to over the board games as Chess (3), there are many different existing use cases.
An excellent compilation of some of those use cases is provided by Tobii (4), one of the world leaders in the eye-tracking industry. In this chapter, I will list some interesting existing game related use cases in which eye-tracking is used.

Accessibility

  • The Tobii Experience software that ships with the Tobii Eye Tracker 5 out of the box comes with an assisitive mouse mode. In this mode, you can choose to move the mouse by gazing at your screen. This can help in ergonomics during productivity, but also in gaming. It lessens the distance that the user has to move their mouse over during a session significantly. This reduces the strain you put on your hands, which can be helpful in the prevention of RSI. Of course this mode would only work in games where the user has a mouse pointer on screen. You could use it in a game like Terraria to point at the block you want to mine, or in a game like Sid Meier's Civilization V to change the selected tile.

  • In EyeGuitar (5), a Guitar Hero clone, eye-tracking was used to make rhytm based music games accessible to those with motoric impairments. They strived to make gazing the single input required for the game. To do so, they implemented a system where the user would select the band in which the note would land through gaze input. Notes would then be strummed automatically when they hit the bottom of the screen, if the user was looking at the correct band. Though they did achieve their goal of making gaze movement their single source of input, it did alter the gameplay in a significant manner, stripping the rhytm aspect of a rhytm based game, arguably making it less entertaining.
    Though eye tracking did provide more accessibility to the game, they should have tried combining it with an alternative source of accessible input to keep the core gameplay intact, like making use of voice activation, a physical pedal or a big button.

  • In Assassin's Creed Valhalla (6) players can look at a target before pressing an 'aim' button to automatically adjust their aim towards that target, reducing the need for precise inputs.

Immersion

  • Making combined use of head and eye-tracking, Elite: Dangerous (7) offers players extended immersion by making the player camera adjust accordingly. Without having to alter the player's rotiation, the player can freely look towards an angle by turning their head into the direction of their gaze. This is especially important in a game like Elite: Dangerous where you want to keep a good overview of what's flying around you in the heats of battle, without having to move your flight-sim stick.

  • In Assassin's Creed Valhalla (6) dynamic light & sun effects are applied based on the players' gaze. For example, if they were to be standing in a dark room with a bright light shining from a hallway, looking at a dark corner of their room, their eyes would naturally adjust to be able to see a little bit of detail on the walls of that dark room, and see a bright light coming in through the doorway out of the corner of their eyes. However, if they were to look right at the doorway, their eyes would adjust so that they can now details of the brightly lit room, but see darkness on the walls out of the corner of their eyes. As this more closely mimics what our eyes would see in the real world, this improves the feeling of actually being in that place.

  • In Saint's Row [(8)](), UI elements only appear when the player tries to look at them, cleaning up the clutter when they are focusing on something else.

Gameplay enhancement

  • In Far Cry 6 (9) the player can spot enemies through a pair of binoculars not just by centering the camera on the enemy, but they can simply gaze at the enemy, no matter where they are in view of the binoculars. This makes the process of spotting an enemy feel a lot more natural and mimics the actual experience of looking through a pair of binoculars.

  • In Use of Eye Movements for Video Game Control (1), J. David Smith and T.C. Nicholas Graham make a suggestion to improve the game Madden NFL 06. Currently, the game has a system in place where the player needs to get vision on the character they're trying to make a pass to to make an accurate pass. As there is no natural way of translating vision to a 2.5D experience, the developers implemented a cone shaped UI element that highlights what direction the character is looking at. Now, instead of just playing a game of football, you are trying to control some UI elements direction. Thus, they propose to introduce a more natural feel to this system by replacing it with a system where the player would just gazeat the character they want to pass to instead.

We can learn from these existing use cases what might work and what might not work, and base our design for novel mechanics upon those findings.

Hardware

Eye tracking technology is widely used in fields such as market research, but over the last years, it has also seen a rise in use in the entertainment industry. Commercial eye tracking products marketed to gamers have become more readily available. There are a few main contenders available on the market.
For this project, I need to decide which hardware is the right fit. In my hardware proposal, I go into further detail on the available options. The proposal draws the conclusion that the Tobii Eye Tracker 5 is most likely my best option due to its popularity and available SDK, so that is the hardware I will be using for this project.

Horror Games

What makes a good horror game?

For this, we should dive into what makes 'good' horror. This is by no means an easy question to answer, and the time allotted for this project is too little to make even a dent in the whole truth, but in the interest of keeping the scope to a reasonable level, I will simplify the discussion by listing a few named elements in existing literature.

For example, Elements of Horror (10) by Noel Carroll is a good place to start. It describes a lot of different elements that form the backbones of horror stories, and goes into detail on various common story arches. In my opinion, one of the most important points from this article is that regarding the theme of your game, some knowledge is better left undiscovered. You want to give the player just enough information to have a sense of purpose, but don't want to spell everything out for them. A truly great horror game has the player filling in their own blanks, as not knowing is scarier than knowing. This feeling is elaborated upon in the subchapter 'Hans is afraid of the unnameable' in the Powers of Horror (11) by Julia Kristeva.

Talks with game directors of horror games can also be quite insightful, such as this interview (12) with Thomas Grip (the creative director behind titles like Penumbra: Overture and Amnesia: The Dark Descent) where he mentions how less can be more, taking the simple mechanics of Slenderman as an example. Besides knowing what makes horror good, it is also important to know when horror is not good. Alistair Hope has a great talk (13) on the problems that come with Whiteboxing horror games, a problem I have definitely encountered during this project (more on that later).

Then there's opinion articles such as this piece (14) by Chloe Prince which list her opinions on what makes a horror game good. She provides a great counter-argument against the argument of leaving players in the (figurative) dark: Sometimes it can be extra terrifying to know that something scary is about to happen. This allows for a larger build-up in tension, and thus a higher tension release.

From what I gather, the right conclusion to draw here would be that we can't draw any factual conclusions. Horror is an extremely subjective topic. What scares one person might be hilarious to another. Developers can however take a good look at existing, time-tested tropes, and combine them in a custom manner to craft their own horror story as they see fit.

Based on the findings, these following topics seem to be the most important factors of a good horror game, in descending order of importance:

  • Setting/Theme
    • Where is the game set? In what time period?
    • Although there is no setting that can be defined as the 'creepiest', it is important to first think of a general theme for your horror environment. This will form the backbone for all the other design aspects, so that the visuals, auditory experience and story are cohesive.
  • Visuals
    • How does the environment look? What do the characters look like?
    • It is very important to get the visuals of your game right.
      If your environment feels too 'safe', it is hard to get scared in it. You can however choose to specifically play into this: by creating an evil twist on an otherwise safe space, this can sometimes create an extra unsettling feeling. An example of this would be Poppy Playtime, a horror game set in a kids' toy factory. The environment is seemingly very kid-friendly, yet extremely creepy due to the toy factory being deserted and lit in a gloomy manner.
  • Auditory
    • What does the player hear, and at what moment?
    • Almost as important (if not more important, it was hard to choose), is the auditory experience. Soundscapes can have an immense psychological effect on a player. Music is a very powerful tool for artists to convey emotions. Just take the amazing score of one of your favourite movies. I will take thescore for Interstellar by Hans Zimmer as an example. The space station docking scene (15) in that movie always gives me goosebumps when I watch it. Watch it again with the sound muted, and it's nowhere near as spectacular.
    • Audio can also be used to influence the story without the use of visual cues. It can for example be quite unsettling to hear a monster you can't see.
  • User knowledge
    • What does the player know about the scene he's in?
    • As said before, it is great to give the player access to just the right amount of information. You want them to not feel completely lost, as this might demotivate them to progress the story any further, but you also do not want to spell everything out for them. You have to keep some form of unexpectedness. Even in situations where you specifically let the player know something is about to go down (i.e. the sound of incoming footsteps), you can still play with the players knowledge of the situation: You could for example let out the knowledge of what is approaching the player, or have a different, silent monster come out of a different angle.
  • Story
    • Stories are a great way of being able to set goals for the player to achieve, and lure them into scary situations.
    • A creepy story can be unsettling to the player.
    • The story is of less importance in the horror genre, as a horror experience with a weak storyline can still be scary. However, the story is definitely a great tool to influence the above named level of 'user knowledge'. A good story sets the player in the right mindset, and can thus enhance the way the user experiences all these other influencing factors.

What added value does eye tracking offer in horror games?

This is what we are going to find out during this project. For now, I can list my hypotheses.

After a brainstorm session I came up with the following two mechanics:

  • (Dis)appear on gaze
    • Hide or show objects based on the current gaze position of the player.
    • I think this could be used to either scare the player using jump scares, picture looking into a mirror and only having the jump scare trigger as you look into your own eyes.
    • It could also be used to play psychological warfare with the player: you could show them an unsettling object but ensure that they can only see that object from the corner of their eyes. Your brain only shows the center 40% of your vision, and estimates the rest, which further enhances the implications of this mechanic.
  • Do not allow player to gaze
    • Reach a fail state when the player gazes at an actor for too long.
    • Not being able to look at your enemies can bring an extra scare factor of not being able to pinpoint exactly where they are.

I will list some of my ideas that did not make it here:

  • Move an object through gazing
    • It felt like it didn't have a true place in my experience: I could not think of a suitable way to implement it into the story without it feeling as being put in there as a gimmick.
  • Aiming a weapon using your gaze
    • I felt it was better to let the player feel a little helpless by granting them no form of self-defense.
  • Save yourself from a fail state by looking directly in the eyes of the monster.
    • The idea here was to force the player look at something they would rather not see. Some people look away from their screens when they get scared, or a scene containing gore is shown. I chose to scrap this idea as it kind of conflicted with the 'do not allow the player to gaze' mechanic. My idea originally was to not be able to look at certain monsters, and if they did, they would come grab you by the throat in a 'jump scare' sequence. You could then survive this sequence by keeping your composure and confronting your fears.
      However, I felt it was confusing to players to first punish them for looking at the monsters, and then rewarding them after. I did eventually find a way to morph this mechanic into something a little less confusing thanks to a suggestion by an acquaintance, which brings me to my next point:

It's always a good idea to gather some insights from other people, as they can look at your problem from a new point of view. So after asking around for inspiration, discussing the idea of implementing eye tracking into horror games to acquaintances (some of them with a background in gaming, some of them without any personal game experience), a few ideas came up, of which I picked out the strongest one:

  • Actors that simulate the behavior of the Weeping Angles from Doctor Who.
    • These Weeping Angles move towards you at any given time when you are not looking at them.
    • I think this can provide some extremely stressful situations where the player is forced to look into the eyes of an unsettling character.
    • This is similar to the last named 'failed' idea I came up with myself, but removes the confusing factor. By implementing the 'force gaze' mechanic on a different enemy type, instead of trying to combine it with an already existing one, it is more easily conveyed to the player that this actor reacts in a different way.

Some other ideas came up, but weren't picked due to concerns regarding feasibility or time investment. Others were experimented with but scrapped.

  • Have an object in the game that grants you the ability to turn an area around your gaze point into an alternate reality version of your main scene.
    • I did experiment with this for a while, but couldn't find a simple way to combine the two different versions of the scenes at the same time. See the next chapter for more info.
  • Have a character speak different dialogue based on whether you're looking at them.
    • This would mean that I had to write a conditional dialogue system. While a very cool idea, I chose to scrap this idea solely due to time/scope concerns, as the story is at the bottom of my list of priorities.

Building a horror game

Time to build a horror game! In this part, I will talk about my design process during the development cycle of this project.

Setting

First, I chose a setting. For this, I took some inspiration from The Stanley Parable, a game which is not a horror game, but does put you in an eerie setting. Because in The Stanley Parable, the player, playing as Stanley, walks through a seemingly completely deserted office. This always felt a little offsetting to me: a place that is normally full of people suddenly being completely empty.

More inspiration came from the Netflix show Stranger Things, where each location has it's 'upside-down' counterpart: a much slimier, darker and grimier version of reality. There are sharp contrasts between the 'normal' and 'upside down' versions of each location. In some scenes of the series, the camera switched between these two realities, strengthening the unsettling effect of the horrible 'upside down' version.

So, after a little brainstorm and combining these ideas, I came up with the concept to have my game take place in an office setting that has both a 'good' and 'evil' version. In the 'good' version, the player finds themselves in a seemingly normal office, with nothing out of the ordinary. However, the player at some points switches between the 'good' and 'bad versions', allowing them to discover the true nature of this seemingly plain office.

Visuals

I spent a lot of time trying to get the visuals for this project right. I used free assets from the unity store where possible, as I did not have enough time allotted to create every asset myself. Even with that decision, I spent a lot of the allotted project hours to work on the visuals for this project. One might even say too many, but more on that later.

I decided quite early on that I would stick to a low-poly art style, so that if I did have to create any assets of my own, I could do this without worrying too much about detailing the model and could use simple flat colouring for my textures.

I started off working on the project by creating a simple whitebox office environment. I simply used Unity's Cube object and scaled it using a set increment so that everything in my scene could line up perfectly. I do not recommend doing this, as it caused some unforeseen issues with lightmapping later. After adding a simple character controller, I took a walk through the environment to get a sense of the scale, and adjusted the player scale accordingly.

Having set up this whitebox environment, I would normally go on to add some gameplay mechanics (in this case, eye tracking based mechanics), make sure the game's core gameplay loop exists, and then test said game.

However, I discovered that this normal development cycle would not really work for my project. To test whether a game is scary, it needs some scary elements in it. However, my whitebox prototype was nowhere near scary! It turns out that prototyping a horror game is quite hard. Earlier I named the talk by Alistair Hope (13), which provides some great insights on the issue. I wish I had seen that talk earlier! He describes pretty much exactly what I was afraid of. During the development of Alien: Isolation, the developers finished up their whitebox prototype, did a playtest, and found the results of that playtest to be staggeringly bad. The testers simply did not feel scared. So they had to compromise and polish their whitebox prototype visually, kind of defeating the purpose of whiteboxing. While nothing changed in their core gameplay, they performed the same playtest again, now with assets that create atmosphere added to the game, and the results were much more succesful. Playtesters suddenly jumped at the sight of the Alien.

I realized that I had to create some atmosphere before I could get reliable playtest data. So I tried to add some premade assets to the store and coloring/lighting the environment.

First I added some lights and materials to the room:

Then I created some simple scenery, to make it look like the scene actually takes place somewhere 'real', added some mood lighting and added colourful fog.

This scene felt pretty right, but as it was just a single small room, I could not get a real sense of adventure. So I decided to copy the room over a few times, trying to expand the environment a little bit. This is when I ran into my first worldbuilding issues.

Because I tried to place different cubes next to eachother, when I tried to bake the lighting these seams would show up. Neither overlapping the objects nor aligning them perfectly with no gap in between fixed this issue.

In an attempt to circumvent this issue, I tried modeling a room in Blender, and using that room as a modular building block.

I did the same for a hallway piece, making sure every vertex is perfectly aligned with where they're supposed to meet the room piece. Even this method resulted in some horrible lighting artifacts! Not wanting to waste anymore time on trying different world building techniques, I decided that - since the scene is quite small and low-poly anyway - I would just model the entire environment as a single model. Not great for performance, but at least it would fixed my lightmap issues. So I got to work, and after a few hours, I finished the environment model:

UV-unwrapping and texturing it was quite easy as I stuck to flat colours.

I then created a prefab of some office furniture using some downloaded assets, and some simple models which I did model myself (like a fridge, a trashbin, and a radio from an old project).

I created a couple variants to not make each room feel the same, such as this one:

And then placed some prefabs around the rooms.

Next up was altering and animating some downloaded character models, to create my first NPC to interact with. The asset came with different materials for different parts of the model, I altered the model and UV-unwrapped it so I could swap the different materials out for a texture atlas, and then painted a few variants of the texture atlas to allow me to have some difference between the characters:

I then added a simple 'sitting typing' animation:

And added some prefabs that would be the 'evil' versions of these characters, simply by adding an emmissive layer that adds glowing red eyes:

After placing each actor, I added lighting to the scene.

Then, I parented the contents of the scene under a new gameobject, copied that parent, calling the good version 'daytime' and the evil version 'nighttime', and changed some of the materials and light colours. I also replaced the daytime actors with the nighttime versions.

I could then toggle between the daytime and nighttime versions of the scene by enabling / disabling the parent objects, changing the skybox material and fog colour.



Getting the lighting right is where I spent most of my time on this project. I kept running into lighting issues which made the scene look terrible and broke immersion. The worst part being, I'm not happy with how the final lighting turned out. The visuals still feel nowhere near creepy enough, no matter what I tried I could not get there. I would have to spend a lot more time fiddling about with different lights, swap out my assets and materials, add some post processing effects, and heaps more. I completely underestimated how difficult it would be to create a creepy office scene. More on this will follow in the discussion.

The only part of the scene that was in my opinion somewhat succesful is the basement, which I filled with some shipping containers, boxes and pallets, then I made things a lot darker, placing only a single spotlight on a chest (indicating to the player that the chest is point of interest), and placed some NPCs.

Auditory

The visual part of this project took up so much time that I did not have much time to create an immersive soundscape. Instead, I simply downloaded some assets that came 'close enough'. Thus, I will not go into much detail on this topic. I will however list some of the sounds I put into the game:

  • Typing noises for the NPCs
  • A distortion effect for the initial scene-switch jump-scare
  • Papers being shred
  • Heavy breathing for the stalker in the window
  • Some ambient looping noise for during the 'evil' scene

If I had more time, I would have liked to add more sounds to enhance the immersion, like more random ambience, doors creaking when they open and give the player some audible footsteps.

Eye Tracking Mechanics

Initially I thought I would be up for a pretty interesting technological challenge, to try and get eye tracking to work with Unity. Tobii however has already provided a quite extensive Unity SDK, allowing developers to quickly integrate eye tracking into their games. They even had some example scenes which made it easy to figure out how to use their SDK.

The first mechanic I tried implementing was to show or hide an object based on whether the user is looking at that object.
I created a box collider to act as a trigger zone for the script, which the GazeAware component relies on. Then, implementing this mechanic was as simple as setting the gameobject activity equal to gazeAware.hasGazeFocus.
I added a flag that inverts the result, making the script either hide an object or show it based on whether the box collider is gazed at.

public class GazeTarget : MonoBehaviour
{

    private GazeAware gazeAware;
    public Transform target;

    public bool visibleOnGaze;
    public float maxRange;

    private Player player;

    // Start is called before the first frame update
    void Start()
    {
        gazeAware = GetComponent<GazeAware>();
        player = GameObject.FindGameObjectWithTag("Player").GetComponent<Player>();
    }

    // Update is called once per frame
    void Update()
    {
        if (Vector3.Distance(player.transform.position, this.transform.position) < maxRange)
        {
            target.transform.gameObject.SetActive(visibleOnGaze ? gazeAware.HasGazeFocus : !gazeAware.HasGazeFocus);
        }
        else
        {
            target.transform.gameObject.SetActive(false);
        }

    }

    private void OnDrawGizmos()
    {
        Gizmos.color = Color.yellow;
        Gizmos.DrawWireSphere(this.transform.position, maxRange);
    }
}

I used this to add an NPC in the window which is only visible out of the corner of your eyes: if you look near it, it dissapears. This was surprisingly unsettling to experience, you cannot get a good look at whatever is looming in the corner of your eyes.

The second mechanic, disallowing the player to look at certain objects, also makes use of this GazeAware component, but adds a little timer, ensuring the accompanying OnGazedAt() method only triggers after the user has looked at that object for some set triggerTime.

private void Update()
{
    if (!gazeAware.HasGazeFocus)
    {
        timeStamp = Time.time;
    }
    else
    {
        if (Time.time > timeStamp + triggerTime)
        {
            OnGazedAt();
        }
    }
}

I added a simple 'throat grab' animation that plays whenever the player looks at the NPCs for too long, which also triggers a fail state, after which the player has to reset the level.

Finally, the third mechanic, forcing the player to look at an enemy to make it stop moving, was also quite easy to implement. We simply move the enemy towards the player on the FixedUpdate frames where the player isn't gazing at an (extra generous) collider around the 'weeping angel'.

    private void FixedUpdate()
    {
        if (! gazeAware.HasGazeFocus)
        {
            Vector2 playerPos = new Vector2(player.transform.position.x, player.transform.position.z);
            Vector2 parentPos = new Vector2(parent.position.x, parent.position.z);
            if (Vector2.Distance(playerPos, parentPos) < 2f)
            {
                CaughtPlayer();
            }
            else
            {
                Vector2 dir = (playerPos - parentPos).normalized;
                Vector2 delta = dir * Time.deltaTime * speed;
                parent.position = new Vector3(parent.position.x + delta.x, parent.position.y, parent.position.z + delta.y);
            }
        }
    }

Story/Progression

I did not come up with much of a story, but I did come up with a way to give some goal to the player. You start off in a normal office environment, doing some menial office tasks. After a while, you get a glimpse of the 'evil' version after completing one of the office tasks. When you then get back to your desk, the scene completely switches over to the 'evil' version of the scene. At this point, the player is tasked with finding a key in a nearby office, forcing them to encounter some of the 'do not stare at them' NPCs and the dissapearing man in the window. Once they find the key, the player is tasked with venturing into the basement, where one of the 'moving statue' provides an obstacle for the player to get to a treasure chest (which represents the 'finish' of this project), all the while being crowded by more 'do not stare at them' NPCs.

To progress the story, I simply used UnityEvents linked up to a ProgressionManager script. Whenever the player does something to progress the game (like for example they collect some documents they had to pick up), it simply lets the ProgressionManager know to trigger the next event. For a small amount of events, this works quite well and saves development time for a custom system. However, as soon as your game starts getting larger, this system will become more and more inadequate, as it becomes less overseeable.

User Knowledge

As I did not build up much of a story, the decision to handle user knowledge was pretty easily made. I simply told the user what to do to progress, and nothing else. This made the limited amount of story that does exist open for interpretation, while providing the player with a goal to strive towards to.

Testing

I did one playtest session at the end of the project during the project summit meeting. I observed the testers while they were playing, interviewed them afterwards, and also asked them to fill in a playtest survey.

The test plan was as follows:

  • Tell the tester they are about to play a horror game that uses mechanics based on eye-tracking. Do not give any additional information about the mechanics or the game.
  • Calibrate the eye-tracking profile for the tester.
  • Let the tester play through the experience and observe.
  • Short open interview with the tester, what are their first thoughts that come to mind?
  • Ask the tester to fill out a questionnaire.
    • This questionnaire first tries to establish what type of gamer the tester is : do they view themselves as having a lot of experience with playing games? Do they enjoy the horror game genre at all?
    • Then, I ask them...
      • ... a few questions about what spoke to them the most of horror games they might have played, to establish whether they like action or atmosphere related horror more.
      • ... about the emotions or feelings they felt during the playtest, to get a better understanding of how my game made the users feel.
      • ... to list elements that made them feel more immersed, and do the same about elements that might have broken that immersion.
      • ... about their most intense moment during the game to understand what makes them experience horror in my game.
      • ... whether they have noticed the mechanics I was trying to playtest, and whether they added to the game, to learn whether the mechanics were promising.
      • ... to list some ideas on how they would improve the game in a manner that has nothing to do with eye tracking, to get an understanding of where my game is lacking 'traditionally'.
      • ... to list some ideas on how they would improve the game using eye tracking specifically, to get ideas for further possible iterations.
    • Finally, I ask them on 'a scale of 1-10, based upon the demo, how likely do you think it is eye tracking would make a good addition to a horror game?', to find an answer to my research question.

Results

There were six responses to my questionnaire. I also got to observe and interview some more people than those six.

Those who filled out the questionnaire were mostly fairly familair with games.High scores were expected in this category since the summit audience consisted of (mostly) game developers. One tester only plays games casually with friends, but never alone.

Responses to 'On a scale of 1-10, how much experience do you have playing games?'

The testers were not extremely experienced with horror on average, but there were some outliers. The average lies around an intermediate level of experience. They did generally gravitate towards liking the horror game genre as a concept though.
However, one playtester was in particular not accustomed to playing horror games and even said they hate them, giving a score of 1 on both of the following questions.

Responses to 'On a scale of 1-10, how much experience do you have playing horror games'?

Responses to 'On a scale of 1-10, how much do you like playing horror games?'

Some of the horror games the testers listed as having experience with are:

  • The Walking Dead
  • Dead Space
  • F.E.A.R.
  • Little Nightmares
  • The Last of Us
  • Resident Evil
  • Poppys Playtime (only the demo)
  • Five Nights At Freddys
  • Slender Man
  • Amnesia
  • Phasmophobia
  • Resident Evil

There is an interesting mix of horror tastes here, once again supporting the idea that horror is an extremely subjective topic. It ranges from being heavily narrative based to heavily action based.

What elements of those games stood out to the testers the most were some of the following:

  • The narrative and storytelling (the feeling of having something actually happen to you)
  • The uncomfortable feeling that the theme gave them.
  • The sound design making it feel like someone's actually around the corner.
  • Having to make choices were both outcomes are terrible.

From this I can gather that the feel and immersion is indeed extremely important in a horror game, these are all elements that heavily rely on the player getting pulled into the 'flow zone'. Making them forget that what is happening is not actually happening to them. This also makes me think that storytelling might be much more important to the horror experience than I originally had thought.

The testers experienced a few emotions during my playtest:

  • Boredom: Quite a prominent one. Having to repeat the same task as the start of the game was not very fun.
    • I had actually purposefully planned for the players to get to just the right level of boredom, so that I could get their guard down for the very first jump-scare. After seeing hearing them talk about them missing some incentive to keep going however, I do agree that it needs to be at least a little more inviting to play. I should have at least made some variations on the menial tasks. You dont want to players put the game down before it even began.
  • Curiousity: They were excited to find out what influences the eye tracking system would have on the game.
    • This is good! I wanted players to get that feeling of 'this is new to me and I have no idea what I can expect from it'.
  • A feeling of uneasyness: when the mood switches over to the evil variant, and ambient creepy sounds start playing, they were put in a frightful mood.
    • Also very happy to hear this, I did put a lot of time and effort into getting the scene to a point where this would be the case, so I am glad to hear that that time did not go to waste, even though it could have definitely been better.
  • Confusion: Not sure whether the eye tracking had an impact on the game in the early 'friendly' stagesof the game.
    • An interesting point came up during the interviews about this as well. The first few minutes of my experience had nothing to do with eye-tracking, which made it impossible for people to quickly test those features. It is probably a better idea to have the thing you are trying to test as the very first feature they encounter.
  • Scared: When they were initially first caught by one of the enemies, people did jump. They also did not like not being able to look at the dissappearing man in the window, though some testers did not notice this until I pointed it out to them.

The testers listed the following elements as being benificial to the immersion:

  • A believable, relatable setting.
    • Made it feel more likely that this could have happened to you.
  • Not having the freedom to look where you want to.
    • This made the NPCs feel more 'alive' or responsive to some playtesters, and definitely brought some fear.
    • This also had an interesting downside: Some players would walk into the room, just looking at the floor entirely to circumvent having to look around at all. To combat this, some measures should be taken to stop the players from missing out on a lot of the horror elements and cruising through the game unscathed. Maybe some kind of punishment should be implemented for trying this technique, or incentives to look up need to be added. This is actually why I initially implemented the concept of having to search for a key in the rooms where the NPCs reside.

Some elements distracted them from the immersion:

  • The animations of the characters were too static and had no transitions.
  • There was no reason behind having to shred the documents.
  • The dissappearing NPC dissappears too quickly, and should have a fade effect applied to it instead.

Not all playtesters experienced all the present eye tracking mechanics:

  • Some testers did not notice the dissappearing NPC in the window as they ran by him too quickly.
  • Some also did not get to the part with a green eyed NPC as they were caught by an enemy before being able to get the key.

The playtesters did think that the mechanics that they did encounter added to the immersion of the game. The green eyed NPC however did seem to need some more work to feel reliable, some playtesters looked right at him to stop him and then walked straight into the NPC, still getting caught in the process as the fail state was a simple distance check only.

I got some interesting ideas that playtesters had to improve the game without eye tracking mechanics:

  • Implementing a better storyline, like you are shredding documents for some malafide business.
  • Implementing fluid animations so that it wouldn't feel like you were instantly game over
  • Implementing more of a social puzzle bazed on dialogue instead of a collection sequence.

And some very interesting ideas on other ways of implementing eye tracking in horror games:

  • You can stop things from happening when looking at them.
    • Like evil only happens when you look away from it.
  • The world starts tearing up when I look at a point for long.
    • Like a visual shader effect that makes the user feel like they are spreading corruption by corrupting whatever is near their gaze.
      People do different things when you look directly at them.
    • NPCs react based upon your eye contact with them. Some people do not like eye contact, some find it confrontational, some might react aggressively based on whether you keep staring.

Finally, I asked them 'On a scale of 1-10, based upon the demo, how likely do you think it is eye tracking would make a good addition to a horror game?'

The responses are pretty promising! It looks like the mechanics I came up with still need some work and to be tested in the right setting, but do definitely make the testers curious to see how a final product with this technology would play like.

Discussion and conclusion

Testing is an important part of every development cycle. This is why I regret only doing one playtest session at the end of this project: this leaves me with no time to iterate upon those ideas.

Unfortunately, only about half of those who playtested filled out the survey. This left me with a mere four responses. I decided to do another two playtest sessions with friends over the weekend. More playtests were difficult to organise as I needed to be physically present during those playtest sessions with them the required eye tracking hardware. Thus, my sample size for the questionnaire is quite small (N=6).
The results from the playtest were promising, where even someone who hates horror games thinks that eye-tracking would probably make it even more horrible (in a good way!). But they also need to be taken with a huge grain of salt, as the sample size is too small, and these are only results of the very first iteration of a novel concept.

It has become clear to me that developing a horror game is no easy feat in just a short timespan. You really need to take as much time as you can get to get the atmosphere just right. Maybe with more experience and access to artists who can take off a lot of the workload for the designer, then this may become less of an issue.

For the research of eye-tracking in games, it would have probably been a better idea to choose a game genre that relies less on getting the atmosphere right, so you can easily churn out whitebox prototypes and focus on the eye tracking mechanics instead. I just simply spent too much of the allotted time for this research project on things that were not related to my research.
That said, I am still quite satisfied with the project: it has not become the full experience that I had initially hoped for, and with hindsight I can see that I massively overestimated the amount of effort required to get it to that point, but I did manage to complete my goal of finding out whether eye tracking could offer an enhancing effect to the level of immersion of horror games.
Even in this crude concept horror project that did not turn out as sacry as I wanted it to, eye-tracking was a very interesting addition that made the testers have an itch for more.

I think my goal of providing a few examples of how eye tracking could be used to improve the level of immersion in horror games has therefore been succesfully reached. I think the potential of eye-tracking mechanics for the horror genre has definitely been highlighted by this project. Though not an absolute truth, I think this research provides a decent point of entry for those who want to look into this technology in the future.

Sources

  1. Smith, J. D. & Graham, T. C. N. (2006). Use of eye movements for video game control. Proceedings of the 2006 ACM SIGCHI international conference on Advances in computer entertainment technology  - ACE ’06. https://doi.org/10.1145/1178823.1178847
  2. Antunes, J. (z.d.). A Study on the Use of Eye Tracking to Adapt Gameplay and Procedural Content Generation in First-Person Shooter Games. MDPI. https://www.mdpi.com/2414-4088/2/2/23
  3. Louedec, J. L., Guntz, T., Crowley, J. L. & Vaufreydaz, D. (2019). Deep learning investigation for chess player attention prediction using eye-tracking and game data. Proceedings of the 11th ACM Symposium on Eye Tracking Research & Applications. https://doi.org/10.1145/3314111.3319827
  4. Tobii Gaming. (2022c, september 14). Games | The Next Generation of Head Tracking and Eye Tracking. https://gaming.tobii.com/games/
  5. Vickers, S., Istance, H. & Smalley, M. (2010). EyeGuitar. Proceedings of the 7th International Conference on Advances in Computer Entertainment Technology - ACE ’10. https://doi.org/10.1145/1971630.1971641
  6. Tobii Gaming. (2022a, juli 15). Assassin’s Creed® Valhalla + Eye Tracking. https://gaming.tobii.com/games/assassins-creed-valhalla/
  7. Tobii Gaming. (2022d, september 23). Head tracking and eye tracking in Elite Dangerous with the Tobii Eye Tracker 5. https://gaming.tobii.com/games/elite-dangerous/
  8. Tobii Gaming. (2022b, augustus 23). Eye and head tracking in Saints Row with the Tobii Eye Tracker 5. https://gaming.tobii.com/games/saintsrow/
  9. Tobii Gaming. (2022a, juni 10). Head tracking and eye tracking in Far Cry® 6 with the Tobii Eye Tracker 5. https://gaming.tobii.com/games/far-cry-6/
  10. Carroll, N. (2014). The Philosophy of Horror: Or, Paradoxes of the Heart. Routledge.
  11. Powers of Horror: An Essay on Abjection. (1984). Columbia University Press.
  12. The Dos and Don’ts of Making a Horror Video Game. (2014, 30 oktober). Vice. https://www.vice.com/en/article/gq83dm/the-dos-and-donts-of-horror-game-making-323
  13. Building Fear in Alien: Isolation. (z.d.). GDC Vault. https://www.gdcvault.com/play/1021852/Building-Fear-in-Alien
  14. What Makes A Good Horror Game? (z.d.). TheGamer. https://www.thegamer.com/what-makes-a-good-horror-game/
  15. Movieclips. (2021, 8 april). Interstellar (2014) - Spinning Space Station Docking Scene (7/10) | Movieclips. YouTube. https://www.youtube.com/watch?v=87zCgfIccXM

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts