Deconstructing Our Experiment with Immersive Poetry

This weekend, the Interface3 team was over in Glasgow for Culture Hack Scotland.

In the last blogpost, we talked a little bit about the concept. In this blogpost, I wanted to shed a bit more light about the design process and offer some insights into how we managed to pull it all together.

To refresh everyone: we developed an interactive experience based on Edwin Morgan’s Stobhill. It was designed to be dark and immersive: reimagining Morgan’s poem for the 21st Century and hopefully opening it up to new audiences that poetry normally wouldn’t reach.

Why this project?

When we first looked at the dataset a few days before the hackday, I noticed that the archives of some of Edwin Morgan’s poetry was available. My first experience with Morgan’s work was at school, during our Higher English class, with the beautifully written Stobhill. Up until then, I always thought poetry was just clever people, writing in rhymes, about the world. Then out of nowhere, came this provoking piece of storytelling in the most unusual form. It made a big impact on me as a teenager. On asking around the office, it appears several of us had the same experience. For literature that made such an impact on us, we wanted to see whether we could retell the story in an interactive, immersive manner.

Turning 5 pages of poetry into an experience

We finally got a copy of Stobhill on Thursday, and set about thinking about we can reimagine it on a digital platform.

It wasn’t exactly easy.

Our initial questions were:

  • Where will the experience be set?
  • How should the storytelling be structured?
  • How can we push it beyond someone reading the poem over the top of a 3D environment?
  • Who is the character/protagonist? And why are they there?
  • What is the protagonist’s backstory?
  • What emotions do we want the player to feel when playing the experience?
  • How much interaction should the audience have with the environment?

All this was new to us. Narrative led games are something we’re still learning about and realising we need more help, I spoke to the theatre group DropHound about the idea and got them involved to help with the narrative.


Creating the Backstory

Our initial ideas were to make the protagonist a reporter, going into Stobhill Hospital, and have the story unfold through a series of audio logs that can be found.

But we struggled to explain why the reporter was there, why the hospital had no people and why the character was bothering to find out about the story. Not having plausible answers to these questions didn’t sit well with us; we knew the key to an immersive experience is not having the player question what was happening on-screen.

After grappling with this for a while, suggestions emerged that maybe the character could be a little girl dared to go into the hospital. Having a child protagonist would give us much more creative freedom around the player’s exploration. We also tried to imagine the organisational impact on the NHS if an incident happened in real life. We thought that the hospital could be shut and the building abandoned. The last piece of the backstory was complete when we analysed the poem in-depth. It was striking how much the Porter’s section conveyed gulit, and concluded that he naturally wanted to destroy the evidence/logs so he couldn’t be incriminated in the crime. His carelessness in destroying the evidence would explain the scattering of the story in our experience.

Finally, we also wanted to give the player a bit of guidance in navigating the vast environment we would design for them. To do so, the little girl would be holding a teddy bear – one that came alive when they walked into the hospital. Throughout the experience, the teddy would talk to you, giving instructions as well as adding to the subtext of the story.

We were ready for the hack day.


Designing the game together (Friday night)

While our backstory was fairly solid, there was still a lot of details to be decided at the start of Culture Hack.

Our first task was to design the levels in detail so that the developers (Chris and Chris) can set up the layout.

As a result, Paul, Lillis (DropHound) and myself spent all of Friday night deciding:

  • how many sections there are,
  • what happens in each section,
  • what parts of the poem will be told in what sections,
  • what each of the section looks like,
  • what the ‘feel’ of each section is.

Cue 3 hours of looking at hospital layouts on Google, and planning out in minute detail where each room was, how big it is, what could be in them.  Then we overlaid printed cutouts of the poem onto the plan. The whiteboard looked like this:


We decided on 3 sections: first was an expansive section conveying the facts behind the incident; second was a shorter, but tighter section telling the background to the incident; third would the a basement section leading the player to the incinerator. Each would be more claustrophobic than the last.

The rest of the team did some background work on setting up the project and drew a room. (Incidentally, we were using Unity3D, a cross platform games engine and coded in C#.) At 10pm, Dave (Sound engineer) arrived late night after work and we brainstormed more about how sound fitted in. At 11pm, we got the last train back to Edinburgh and to get some sleep.


Starting Development and getting voice recordings (Sat AM)

Saturday morning started with Chris (our Tech Lead) joining us. On arriving into the venue at 9am, we found a tired but happy Dave with 2 mins of music plus a bunch of eerie sound effects.

With the outline of the levels set, the real development can begin. Here is where we learnt our first technical lesson: check the sync-ing across machines before the hack day starts! The dev team painfully attempted to sync the project across two machines but failed repeatedly because of a combination of wifi and unity’s asset server. They spent Saturday morning trying to fix this.

The sound team (Dave and Johnnie), meanwhile, began to source and get voice actors for the audio logs. They went off to find the voice actors.

Together with Lillis and Paul (who were still busily writing the dialogue for the teddy), all four worked out the background to each of the characters’ audio logs (e.g. the Doctor’s account would be recordings of his case notes, the Mother’s account would be recordings from her sessions with a counsellor etc) and got the recordings made.


Pulling everything together (Sat PM)

With the recordings done, Dave went about editing all the sound files together.

With the bulk of their work done, Lillis, Paul and Johnnie wrote up the game design (especially for section 2, which we vow to build at some later point). They also wrote the presentation and designed the slides.

Meanwhile, the dev team was still struggling to get the machines to sync. At 12.30pm, we hadn’t even finished building one of the levels! But we did have some audio and collison scripts sorted, so we weren’t completely behind. Finally, Chris and Chris got the sync-ing and we can begin to actually build everything out. With time running out, we made the strategic decision to only build sections 1 and 3. Chris D took charge of section 3, and Chris M took responsibility for section 1. I was looking around for 3D models and objects to populate the levels with.

From 1-3pm, we added attempted to pull in all the assets (graphical and sound) that we had. Chris M did an epic job of drawing the expansive section 1, then populate it with hospital beds, chairs, table, desks, lights. In the meantime, Chris D set about pulling together the voice, music, and sound effects for the last section and create the flashing red lights for the incinerator room.

In the last hour (3-4pm), when we finally got all the assets into Unity, we set about going through it and making a directorial pass at the experience. With section 3, Chris D and I painfully went through the game so that the player would arrive at the incinerator just as the Porter’s account finishes (we adjusted the speed of the player). We also added in a flickering effect where images would be flashed across the screen. They were designed to appear so quickly that the player would be left wondering ‘did I see that or did I imagine it?’ The flashlight was also turned from white to red to reflect the flame of the incinerator.

Chris M, meanwhile, had several walkthroughs of section 1. We found it quite easy for the player to get lost in the expansive hospital so we had to add quite a lot more objects to give the player more references to navigate from. He also themed each of the room where an audio would be found to ensure that we add to the richness of the atmosphere (for instance, there is a hospital bed in the middle of the room where the Mother’s penultimate audio log is located). The sound effects had to be placed cleverly for maximum effect.

At 4.30pm, we downed tools. The games were compiled, ready to present to the world.


The Reception (Sat eve)

I thought our game was pretty well received. I have to admit, it wasn’t exactly a light hearted presentation, but most people ‘enjoyed’ it. A few people commented on how harrowing and dark section 3 was. Some people expected us to put a big scare in the middle of it (in hindsight, maybe we should have …)

The CHS organising team (from Sync) gave us a special mention at the presentation ceremony for producing so many assets and for being so productive over 24 hours. It definitely made it worthwhile.


Lessons Learnt:

  • Playing with other people outside of your industry is fun! We learnt so much working with Paul Hughes and Lillis Meeh from DropHound theatre group. They turbo-powered our creativity.
  • In terms of game design: don’t be precious about ideas – be open, play nice and keep talking. Be respectful of others.
  • Imagine you’re playing the experience before any code is written. It’s quicker to change on the whiteboard than it is in code. (We talked and acted out bits as we were designing the levels.)
  • Make sure you check the sync/data storage options prior to the hack day.
  • Split roles and responsibilities clearly. I put a lot of details above regarding who did what and when to give a better idea of how we allocated tasks. We got so much done because everyone had a very specific role.
  • Have a strong team lead. This was particularly important to 1) make sure we finished something on time 2) made directorial decisions.
  • Design the whole experience, then get the design team to prioritise what parts are important. This helped the developers prioritise where to start.
  • Split by sections, rather than functionality. Splitting into sections meant that we always had something to demo at the end.
  • Have regular check-ins across the teams.


We’ve still yet to do a full team post-mortem, but for anyone that wants to do something similar, I hope that you found this account useful when planning something similar. If you have any questions about process, or about the game please feel free to drop me a line!

Leave a Comment