Sponsored By

Q&A: How a part-time team turned Hamlet into the time-looping Elsinore

Elsinore developers Connor Fallon and Eric Butler discuss the underlying simulation theory behind their Shakespeare-themed game, and how Golden Glitch Studios handled part-time development.

Bryant Francis, Senior Editor

September 11, 2019

12 Min Read
Game Developer logo in a gray background | Game Developer

This summer Golden Glitch Studios finally launched its long-in-development Elsinore, a Shakespeare-themed adventure game that puts players in the shoes of Ophelia as she tries to rewrite the ending of one of the Bard's most famous tragedies.

It's a fun, low-budget look at the possibilities of simulation-driven narrative design, and in a set of unique circumstances, it was developed on a part-time basis by a group of triple-A developers, PH.D. candidates, and beyond. 

After launch, designer Connor Fallon (who works at ArenaNet by day) and Eric Butler (who just finished his PH.D.) dropped by the GDC Twitch channel to discuss the process that brought Elsinore to life. It was a broad conversation that involved tackling Shakespearean themes and the unique bugs that come from narrative simulation games. 

If you're curious about how Fallon, Butler, and their colleagues created a Shakespearean narrative simulator, or what it was like developing a game mostly only on Sundays, check out the Q&A below!  

Inside the design of a choose-your-own-Hamlet game

Butler: We’re basically trying to combine a choose-your-own-adventure to a simulation, that’s what got real interesting in the project. That was the first major hurdle. And so what we spent a lot of time on at the beginning was coming up with a good way for Katie and Connor, the writer and designer to control this.

And thinking about how these events could be scripted, and how what the relationship between them—we went through a lot of iterations where at first it was like you were just writing some JSON files like “oh this event happens, then this other even can happen.”

Kind of like a standard choose-your-own-adventure chain, and it just didn’t let us get the simulation bits we needed. So eventually what we turned to is a model where— the game state and all the events we built on it are built on top of states.

Sort of like the mental states of the NPCs. So the things that you’re changing as a player and the things the events are predicated on and the state change are like…what Hamlet knows, what Hamlet wants to do.

So like Hamlet wants to investigate his [stepfather], right? His stepfather wants to avoid Hamlet. What we did is we built a scripting language and a bunch of related tools to control that in all the scenes it specifies event changes and what they accept and what the don’t.

I’ve actually spent a lot of time working on that aspect. Most of my time was spent building these tools used to control the simulation. 

Fallon: There would be things where we thought we had it down and [we'd] go "Oh no wait, we really need a way to be like 'hey if you’re on a pirate ship you shouldn’t trigger any of the events that are happening away from the ship,'" right?

Because then you’re just going to get dragged off to the castle— actually I just fixed a bug where there was one that we missed. But there’s a lot of interesting spatial stuff there that we kept having to iterate over the system, like what are we missing in order to flesh it out a little more?

From a narrative and design structure, the way we approached creating a lot of content was, we kind of had two terms we used for events, which was spines and plot clouds. The spine events— the original spine is basically “hey this is the play of Hamlet,” right? If you do nothing, these events are all structured to flow into each other without any input from the player.

Butler: You can [see in the game] it's going to say like, "Gertrude now knows XYZ." What it’s actually showing you is the game state that’s changing, that’s then changing the events. All the events are scripted in terms of those things.

Fallon: We had quite a bit of discussion as to how not computer-y we should make those. What they’re doing is exposing the computer’s systems. And the less computer-y we make them...the less obvious it is that it’s actually a systematic thing that we’re showing you, right?

What we ended up with here was where we’re in the middle. They’re written out but you can still kind of tell that it's reporting a state back to you. 

There’s a ton once you start actually changing things. But even if you don’t change anything, there’s a lot of questions like “what does Gertrude get up to when she’s not on stage in the original play?”

Like Brett and Irma are two characters that would be around the castle, the cook and the handmaiden, but you don’t see them in the play so there’s stuff around them. Originally when we were in the very early stages of this game, you were able to immediately start changing everything.

And the problem that we ran into very quickly with that is players thought they were responsible for stuff in the original play, and there’s this thing of if you’re in a time loop trying to change something, you needed to understand what you’re changing. 

So we went through a lot of iteration trying to figure out what’s the right amount to— we still want the player to get that sense of like they’re able to change stuff and you are able to change stuff, right? 

But in this first loop getting through the main events of Hamlet and getting a sense of what the stakes are and who the main players are enough so that the second time through you have enough action items instead of being kind of directionless.

Helping players drive Hamlet off the rails

Fallon: I don’t think it was ever our goal to make players feel safe pushing off the path, cause pushing off the path results in like…horrible deaths. But you feel encouraged to do so cause you’re learning new things every time you do so.

About these players and the world, so it encourages you to push past those boundaries into that dangerous territory if that makes sense. I guess that’s a way of feeling safe? But safe was not really the feeling we were going for.

Like, what will happen beyond this threshold if I go for it because I can just always try again. And that is where a little bit of safety comes from. But the things you’re trying are often dangerous things. 

Butler: So I’ll say I’m not a literary theory expect, but like one of the things I think we were trying to hit on with this game was like…part of what makes tragedy compelling and then ratcheting it up a notch, so like…a basic way to describe it is when I’m watching a Greek tragic play or whatever I’m sitting in the audience screaming at the main character. Like I can see exactly how their tragic flaw is going to get them killed! And I’d be like “If only you knew this information.”

And then we made a game where you could go tell them this information. And then there’s something else to do with it. And then you just do this in a loop, over and over again. 

Fallon: I remember way back when when I was in college before I even started at Schell Games, I was in Jesse’s game design class and he was talking about how tragedy is extremely difficult to do in games, because if something bad happens you just try again.

And this game in many ways is a direct challenge to that. Cause you try again, and that’s part of the tragedy, instead of a way to escape the tragedy. 

Developing Elsinore part-time

Fallon: I guess where I’m at is what was it like sitting in that slow-moving bubble, I guess? Like moving forward and trying to reach and endpoint you were comfortable with. I think one of the things that’s notable is we frequently underestimate how much progress we made, and then go play and old build and go “oh wow it’s way better now than it was 3 months ago.”

And also because we all have day jobs we were kind of shipping things, which helped us not feel like “Oh no we’re trapped working on this one thing,” we also had other things going on. 

Butler: It was amusing to see the rest of the industry—it felt like everyone was moving a bit faster like there was one point where suddenly a bunch of time looping games came out—

Fallon: Right like this E3 like two time-looping games were announced, and then Outer Wilds came out and then it’s like “Well, time loops are in now!”

Butler: Fun fact, the artist on Elsinore— you mentioned the art, the lead artist of Elsinore was also the lead artist for Outer Wilds. He shipped two time-looping games in one month. 

Fallon: And he got hired on Outer Wilds I think partially based on like his work on Elsinore, which is…just how the timeline worked out! [Laughs]

Butler: I’m really happy we chose the art style we did, it’s literally just hand painted which is why we used an isometric camera, so that way it wouldn’t be tied to— like this is the only thing that made sense. 

How could we make a game that looks great with this level of polish with a single artist and the answer is—

Fallon: Two artists. We had two artists. But it’s a 2D painting that projected on a 3D model which is kinda neat. So that’s how we did the real-time shadows and stuff. 

Butler: Yeah so building out a 3D world and then painting on top of it. Then we put it all back. I was very happy that it worked. Cause it was a contest of background artists coming up with like…what are the things that would be manageable for a really small team to do but give this huge impact? 

I guess that’s the nice thing about working every Sunday, is that we don’t have a lot of time to actually build stuff compared to a full-time dev but we have just as much time to think about it. And so a lot of development process was different than other stuff I’ve done, in that you’d think of an idea be like “oh that’s great maybe I’ll get to it by next weekend.”

And by the time next weekend rolled around your idea had matured enough to where you realized you should be doing something different. It’s dumb, and you should throw it out. And this saved us a whole bunch of time.

Fallon: It’s easy to point out like…to notice things that would have been like yeah we might’ve sunk more time into polish if we were working on it full time. It would be a very different game if we were full time cause there’s a lot of risky things we did, that if our lives were depending on them, we might’ve avoided.

As Eric was saying like there were a lot of systems that we were like, we don’t need or we iterated on or that we got because we had the time to really reflect on and think about what we were doing. Katie I think had this great quote way back when where she said like one of the things she was most proud of was because of that time, every time we had to choose between the easy thing and the interesting thing, we picked the interesting thing.

And I think that’s very much a product of our work schedule. 

Butler: I found that this process, the importance of thinking about what you should be doing next is really critical especially in the way it was when I was doing research where you’re kind of bumbling around in the dark.

You can work as much as you want but the important thing is to constantly be reflecting on is the work I’m doing right now the most important thing for me to be doing? Is it the thing that’s going to push me closer to where I think I want it to be in the future? What’s the question I need to answer now?

And that’s the kind of approach we ended up taking because of the work schedule.

Fallon: I think it’s worth noting that a big part of why we were able to do the once a week thing— there's two key reasons. One, that’s very much the structure that we had in Game Creation Society (from when we started in college), in that we were making them over the course of a semester. But in order to get things done when you had school work you kind of had to have designated work sessions, right?

And the other one is like…instead of just meeting and checking in, we actually had like we’re all sitting down and working over Skype together so that we could talk to each other, and we all know that we’re making progress. And that again was part of why we were able to sustain this for 6 years instead of burning out.

Butler: Even in that regard we were very lucky and privileged in that a lot of us were close friends and colleagues. Like my wedding party was basically the Elsinore dev team, more or less. And so hanging out like once a week was a good excuse to keep up with friends I never see who live in different parts of the country.

I think that was kind of really important. I don’t know if this would have worked if I just formed a group with some strangers. Or it would have had to be approached differently or spent more energy trying to keep the pace up. Because it was very important that almost every Sunday we made some amount of progress. 

For more from Fallon and Butler on the making of Elsinore, check out the full chat with them below! 

About the Author

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like