Lux Postmortem

ifcomp2018-game

#1

A spoilery postmortem of Lux.

Ideas, rejected ideas and development

I started working on Lux more than two years ago. It’s my first piece of interactive fiction (other than a short assignment for a university course), and the long time in development was partially due to my inexperience.

I wrote the script before I decided on the game system. That was not really a wise design choice, but it ultimately worked out all right when a friend pointed me towards Twine, which had all the functions I needed. I quickly learned the basics and, with the help of the wonderful Twine community, implemented everything I had put in the script.

The core idea I had for Lux was to write a game with an unreliable narrator, where the usage of the text medium is explained by the protagonist being blind. From the very beginning, I wanted to have two endings – one, where you follow Odys, which is easier to get, but “bad” – though the player may not know it; and the other, hidden ending, where Sandra gets her sight back and confronts the AI. The challenge was to make the first ending feel like a legitimate conclusion, but with a hint that – maybe – something more is going on, and the second ending not too easy and obvious, but also not impossible to reach, with some completely arbitrary plot twist. I decided to make the “bad” ending abrupt, evem slightly unsatisfying. At the same time, I aimed to place hints throughout the early part of the game, which would suggest to the players that Odys is not honest with us and his story about the attack might not be true. Many moments hint at the dilapidated state of the station, which is crucial for the real story. Odys himself was supposed to be friendly and comforting, with answers to our questions which are just plausible, but not completely convincing. I wanted the players to first get to like him (early in the game, trusting him turns out to be the right way to go, when jumping down the hole in the technical corridor), then to start suspecting him. Odys, even though he’s only an AI, is a much more developed character than Sandra, who was intended to be, basically, a vessel for the player’s agency (as, depending on the ending, Sandra is either smart or very naive, I thought it would be hard to develop her as a consistent character, and if I described her thoughts and feelings in more detail, it could provide the players with hints I wanted them to get from exploring the station instead).

I think Lux may be summed up as a game about piecing together events that already happened. There’s a lot of scattered backstory to discover. The station crew, who are dead when the game begins, are characters on their own, with distinct personalities, who influence the events in many ways.

I also had some ideas I had to reject, because the game was starting to get too big and too ambitious. One such idea I had early on was to implement another (partially) alternative path: after regaining sight, Sandra could either make that known to Odys (which would turn him hostile), or hide the fact from him. In the latter case, Odys would still help us and rooms would contain both graphics and Odys’ descriptions, which would often be jarringly discrepant. Some actions of the player (for example, asking about something Sandra couldn’t have known about if she was blind) would, however, alert Odys and switch him to “hostile mode”. This was a cool idea, but it would take a lot of additional work to implement, with many possible “reveal moments”, and I was worried I won’t be able to finish the game, so I ultimately rejected it.

After I completed the first draft of the story, I started working on the puzzles. I wanted to implement an inventory system similar to what’s found in point and click games, but simpler. Working on the puzzles was a lot of fun, even though some turned out to be challenging to implement in Twine – especially the maze and the reagent puzzle in the laboratory.

Then I had to create the graphics. I’m not a professional, so I decided to go for a simplified, clean look, because that was something I thought I could pull off. I’m quite happy with the final graphics – they’re not great, but they do their job. And they’re much better than the original lazy pixel art I made.

What worked better than I expected

Some reviewers mentioned they really liked the maze navigation puzzle. It came to me as a nice surprise, as (after working on it and testing it for many hours; sometimes I thought the exit directions changed on their own when I wasn’t looking…) I started to view it as unnecessary and thought people might find it annoying.

I also think the text only/images and text idea worked well. Regaining your vision is an important part of the plot, and accompanied by a significant change in the presentation of the game. I got some comments from players who really liked that moment, and I’m very happy about that.

What could be improved

One thing many reviewers complained about is the inventory system. It can be accessed only from the main screen of each room, which causes a lot of unnecessary clicking. This is a valid complaint; I decided to limit the points of access to inventory, because I was afraid of issues with variables, plus the Inventory passage already had a ton of links coming from it, but for my next Twine puzzle game I’ll have to work on a more user-friendly system.

Another frequent complaint was that there are timers on the text, and that they’re too slow. Originally, Lux had no timed text, but a friend suggested I could use timers to better show we’re playing as a blind person: when Sandra enters a new room, she can’t interact with anything until Odys describes the surroundings to her – but this only happens when we visit the room for the first time. Once Sandra gets her sight back, timers on room descriptions are gone. I think it’s a great idea, but I screwed up the implementation by making the timers far too slow. After getting feedback on this, I significantly sped up the timers and updated the game. As for timers on dialogue, I agree they don’t add anything to the presentation, and could be removed.

Some people also remarked Sandra is not fleshed out enough as a character. As mentioned above, I had a reason to write her this way, but I agree this may not be to everybody’s liking and I understand the complaint.

Conclusion

Overall, I’m glad I entered Lux in the competition. I was hesitant to do this because the game is so long, and I knew many judges might not finish it in 2 hours, not to mention seeing the other ending. It turns out I shouldn’t have been so worried! I’m really happy many people enjoyed my game and played it to completion, or stated they wanted to complete it after the IfComp. I’m also grateful for all the helpful comments and valid criticism. I sure learned a lot from the Comp! To put that to practice, I’ve already started working on another Twine text adventure, which, I hope, will be more polished technically (it will also likely be significantly shorter).

Most importantly, I’d like to thank everyone who played Lux. You people make it worth spending time writing games!


#2

Hi there, Agnieszka,

My name is José, and I’m a Portuguese literature and language lecturer at Warsaw University. My research is about writing interactive fiction with Twine for language learning. I found, played and really enjoyed Lux. Not bad 10th place for your first go at IFComp. And you really did some nice things with Twine.

Anyway, I was wondering, if you’re in Poland, I would love to invite you to come to Warsaw University and talk with my students about creating IF with Twine. It could be either in Polish or English (or Portuguese if you speak it :slight_smile:)

P.S. I tried contacting you through luxadventuregame@gmail.com, but the emails just came back.

If you’re interested just write me a line to j.dias@uw.edu.pl

Thanks

José