CS377G – P2: The Future We Deserve – Edwin Pua

Link

 

(Please play my game before reading this report! This paper assumes you’ve already played the game and contains major spoilers. Headphones are strongly recommended. Code is the name of the class, all caps.)

URL: https://memorycafe.itch.io/in-the-lighthouse-over-the-stars

 

Overview

 

In the Lighthouse Over the Stars is a game about isolation at the edge of space. Here, you can embrace the past and witness the end.

When thinking about what themes I wanted to communicate using my game, I knew I wanted to do something related to life’s transient value. This is a common thread between a lot of my favorite narrative games (Stillness of the Wind, Beeswing, etc.). These games have done so much for me, forcing me to think about what it is I want to do before I die. I wanted to try to evoke the same feeling in the people that play my game.

And given this project’s dystopia theme, I thought about some of the media I most recently consumed: Planetes and Still There. Both of these revolve around space lawlessness, and how normal people get caught in the crossfires from both society and the universe. Planetes in particular centers around the dangers of space debris, which I thought was an evocative design space worth exploring.

 

 

From here, I thought about how I could combine these two. The idea popped in my head, “What would it mean to get caught in a debris accident and die alone in space? What would that person think about in their final moments?” Thus, In the Lighthouse Over the Stars was born.

 

History

 

10/16 – Tiny Playable Prototype

 

Playtesters: Pedro, Jose

 

My first prototype was a paper prototype in the form of a computer terminal with selectable options such as the ability to eat food, play checkers, send an SOS, and so on.

 

 

Since one of the primary goals of my game was to make the player feel lonely and lethargic, I designed the prototype to have glacial pace and force the player to wait. For instance, when sending an SOS, they would have to wait a long period of time before being told there was no connection. 

Or when selecting the checkers option, a menu with the ability to choose between ‘CPU’ and ‘Human’ – choosing ‘Human’ would lead to a screen that would perpetually say ‘Searching…’ until the player decided to return to the main menu, while ‘CPU’ would start the game instantly.

Sure enough, Jose described the waiting they had to do as “excruciating,” which was intentional! Even in this prototype, players could tell that they were stranded and lost, given by the implicit information of the game providing options like “Send SOS” or “Food”.

I also got feedback that helped shape the game’s direction. Jose told me they didn’t really “feel like they were in space” and wouldn’t have known the game’s setting was in space unless I told him. Pedro told me that “the premise was dope” and that he could definitely see the primary gameplay loop behind using the terminal day after day. However, he warned me to keep the scope in check – for instance, implementing checkers just to communicate to the players that there was no around to play checkers seemed like way too much work for so little narrative reward and information.

I felt very similarly to Pedro. Implementing a whole hunger and thirst survival system just to communicate that rations are running low didn’t seem worthwhile (plus, it doesn’t make much sense to consume food from a terminal). Both the food and checkers options were quickly cut.

My next steps from here were to create a more space-like atmosphere while also writing the dialogue choices that would constitute the game’s chat system.

 

10/18 – Prototype Outside Class

 

Playtesters: Chris (Stanford Alumni)

 

For my second prototype, I playtested an example dialogue tree. My initial plan was that the main character would meet someone else in space, and the player could make branching dialogue choices.

Multiple problems arose:

• Dialogue was not engaging. Given that the two characters were meeting for the first time, I wanted them to first engage in small talk. However, Chris the playtester seemed disinterested in the discussion the two characters were having. This was a big red flag because long stretches of boring dialogue can shatter immersion, especially in a game where atmosphere is meant to be one of the primary appeals.

• Illusion of choice. Some choices I presented to Chris held very little weight (e.g. “I miss home.” vs. “I miss my family.”) Indeed, the subsequent dialogue following Chris’ decision would be unchanged, regardless of what choice he picked. This made Chris apathetic to the whole experience.

• Conflicting goals. Meeting someone else in space makes the atmosphere significantly less oppressive by making the setting less desolate (e.g. Chris says, “Oh, so I’m not really that lonely after all.”)

It was clear at this point that writing dialogue was not my strong suit, so to fix this, I decided to pivot my narrative early, keeping the main character alone for the majority of the game and cutting the dialogue communications feature. Of course, this meant that the player’s primary form of interactivity with the game would be gone, so I had to brainstorm other ways the player can drive the story forward.

 

10/23 – Playable Prototype

 

Playtesters: Amy, Jennifer, Cole

 

For this prototype, I switched from paper to my gaming framework of choice, Love2D. Here, I successfully implemented an in-game terminal with four working options: Protected, Mail, Radar, and SOS. 

 

 

• The Protected option is a password input that would give the players an overarching problem throughout the game they can solve, and entice players to read in-game text carefully. At this point of the game, though, the reward behind the password had not yet been implemented, and players would not be able to learn the password until the end of the game, which was also not yet implemented.
• The Mail option is the meatiest part of the game, containing emails that give insight to the main character’s background. This was one of the main ways I replaced the dialogue system.
• The Radar option, which shows any objects or anomalies near the player’s lighthouse. This option is more relevant for my future plans for the story – as of this stage, the radar is merely a static display that highlights the character’s isolation.
• The SOS option, which allows the player to send an SOS signal. Similar to the radar, the SOS would be more relevant for story reasons later. As of now, it functions similarly to the SOS option of the paper prototype – forcing people to wait before letting them know that there is no one around to connect to.

 

Everyone unanimously praised the game’s tone, with Cole saying that she “loved the music” and “the little boops on hover”. (Neither of which were created by me, all ambient tracks were created by Ben Burnes for the game Still There.)

 

However, from this prototype, I identified two major problems:

 

• Visibility – Players often had to squint or lean into the screen in order to read text. Small text size combined with the high rasterization on the chromatic aberration shader I applied to the terminal created an uncomfortable user experience.
  • To fix this in later prototypes, I decided to increase the size of the terminal, increase the font size, and decrease the chromatic aberration.

 

 

• Confusion/Boredom – Feedback on the game was mixed. For instance, Amy said that she liked that I wasn’t being over-explanatory and berating the player with exposition, while Jennifer said that “she didn’t really get what was going on” and wanted more context.
  • Additionally, because three out of the four options weren’t really implemented fully, there just wasn’t much to do after reading all the entry logs in the Mail option.
  • To fix this, I decided to add clickable objects to the background in later prototypes. This gives players like Jennifer some means to visualize the setting and glean information about the player’s psychology via philosophical musings. I also kept the soliloquy lean enough so that players like Amy wouldn’t tune out from all the text. (Although I do think in my final version of the game, I could’ve been more judicious with the length of my script.)

 

10/28 – Refined Prototype

 

Playtesters: Mayshu, Nils

 

During the weekend leading up to this prototype, I spent the bulk of my time primarily writing the script for my game in a Google Spreadsheet. I wanted the game to take place over several distinct chapters, where on each chapter the player can interact with any option on the terminal or any option on the background before going to sleep and proceeding to the following day, reminiscent of the Branch and Bottleneck narrative structure. 

 

 

 

To keep the game’s pace flowing and interesting for the player, I wanted the game to slowly evolve, with background item lore and terminal options changing over the course of the game.

 

However, because this was a writing intensive exercise, I hadn’t implemented the script yet in game by the refined prototype due date, so my prototype at this stage is not too different from the 10/23 one. That said, I was able to implement a few changes since then:

 

• Asset Display – The background now contains clickable objects that reveal text on click. Although most text for assets had not yet been implemented, my intention was for them to contain allegories and aphorisms that meaningfully connect to the character, transforming the objects from mere item into symbol.
• Mail Response – Mails can now be responded to – however, they will always fail to send. This has the dual purpose of highlighting the aforementioned goal of isolation while also implicitly revealing information about the main character via his email signature.

 

Some feedback I received for this prototype:

 

• Less Atmosphere – Although some temporary background objects were finally implemented in the game, my crude drawings of them were a bit distracting when juxtaposed next to the atmospheric computer terminal. (I forgot to save pictures of what these crude drawings looked like, sorry about that.)
  • To fix this, I decided on a new methodology for creating assets. Instead of drawing them, I employed a laborious process where I took a stock image, applied a watercolor filter, grayscaled it, inverted the color, and made the background transparent.

    

     

  • Inspired by games like Lucah: Born of a Dream and If found…, I also gave these assets a two frame animation cycle by slightly perturbing the asset pixel values. I hope these changes to the art made the game seem less sterile and more otherworldly, animated, and alive.

 

 

• Boring – Nils mentioned that “it was a little boring to read some of the text, especially in the Mail.” This makes sense – some of the mail entries were largely just unimportant filler. So I decided to remove a few of the less crucial ones and trim the text that both Mayshu and Nils seemed to mostly skim – this way more attention is given to the mail entries that truly matter, such as Gael’s.

 

11/02 – Final Game

 

By the final game, I’ve finally implemented all the script to all assets and split the game into chapters. I also added a slew of new features that didn’t get a chance to be playtested but hopefully made the game better, such as:

 

• Dynamic Music – In my desire to improve pacing and give each chapter a more distinct identity, each chapter has its own song (from the Still There soundtrack by Ben Burnes). I also experimented with lack of music as a means of creating tension during dramatic moments, making SFX feel much more potent.

• Narrative Triggers – By the middle of the game, I had an intuition that the gameplay loop of checking the terminal, checking the backgrounds, and going to bed would become monotonous, so I thought Chapter 4 would be the best moment to mark a turning point in the character’s psychology. I wish I could’ve put in more narrative triggers in the game that subvert the player’s expectation of the game’s flow.

 

Reflection

 

I learned so much over the course of this project, including but not limited to:

 

• Problems With Scope and Perfectionism – Even after slashing the scope of my project by about half, I still wasn’t able to implement about 50% of what I wanted to do with my story. My codebase is a whopping ~3600 lines long, and I spent about 30 hours a week on this project. I did it partly because it was fun, partly because I was so intent on executing my vision for the game. I have many regrets, mostly because I’ve fallen behind in other classes.
  • Now, I am much more wary of “expanding” a game, because it will always require exponentially more work than I might initially realize. Funny how it’s easy to overestimate your own abilities in game dev.

 

• Limitations of Love2D – I enjoy making games with Love2D – it’s much lower level compared to Unity or Godot, and you have to code lots of things from scratch, but you gain a lot of flexibility and freedom. Love2D is also the gaming framework I’m making my personal game in, which is why I did this project in Love2D – to gain experience.
  • However, there is definitely a huge convenience tradeoff – in Love2D, making a button involves printing a rectangle, detecting a click, checking if the click is within the bounds of the rectangle, then finally executing the button’s function. This doesn’t even include things like hover behaviors. Meanwhile, Godot comes with an included Button class straight out of the box, just give it an image/text to display on the button and code the onClick() function. This made UI development extremely hairy, and made me much more cognizant of Love2D’s weaknesses.

 

• Art Born Out of Necessity – The developer behind the game A Short Hike famously said that he didn’t know how to draw, so to make his game he focused extensively on a cohesive color palette and simple 3D shapes to make his assets.
  • This really surprised me because A Short Hike is a very beautiful game. It made me realize that even though I lacked drawing skills, I can still get creative with the way I make my art and assets. I can use my artistic limitations as an opportunity to give my games more visual identity.