Creating Day and Night

The demo of “What Makes You Tick – A Stitch in Time” is releasing soon (March 18th), so it seems as good a time as any to discuss some aspects of what’s on the way. So, one of the big features of Stitch is that we built the world to be playable at both day and night, with player-controls for switching between the two. While this feature was one of the most painful aspects of game production, it was ultimately one of the most rewarding as well.

Day and night at the Ravenhollow docks.

I believe it was Matt (my partner on Stitch, and inspired by his childhood of playing Zelda games) who initially proposed the idea of time changes during an early brainstorming session. While I didn’t object to the idea from a tech standpoint, I also didn’t really expect to go through with it… In my experience, massive labor-intensive features generally have a way of working themselves out of a product. Only later did I realize my oversight: massive features only work themselves out of client projects where the client doesn’t want to pay for a grandiose vision. Unfortunately, features do not work themselves out of your own projects unless you heart-wrenchingly cut them (hence the reason we are each our own worst clients!). While I remained leery of the idea, Matt wrote it into his first draft of the script and it became a lock-in. However, that’s not to say that we didn’t make ANY cuts. Matt’s first version of the script actually included three times of day: sunrise, daytime, and night. Wow – that would have been a ton of work (I emphasize that now that we’ve implemented ONLY day and night). Thankfully, it was a pretty easy decision to cut back to just the two; mainly because:

  1. We were concerned with making the world so faceted that the player would miss connections between the different times of day. We decided that a player would have plenty to figure out with only two times to work between.
  2. After some early artwork tests, it became clear that the original idea of rendering all scenes as daytime and then just adding color overlays for the alternate times was not going to work. The artwork looked very flat, so we were going to need to render every lighting scheme as a custom painting (and two paintings for each room was enough!).

So after the day/night concept was locked in, it was time to think through the technical solution. One “easy” idea that was quickly thrown out was to create two separate instances of the world: one in daytime, one at night. While the idea seemed lucrative because of its simplicity (just swap the player into the same point of the other world instance, right?), it just didn’t make sense. We had a ton of puzzles planned, and while some puzzles were unique to day and night, the majority would be universal between times. That meant that all universal puzzles would need to be coded, tested, and debugged twice (once for each world instance)… and that doesn’t even take dialogue into account. The world is full of dialogue responses, so each world instance would need to be edited and maintained separately. Finally, multiply this scenario by roughly 20 rooms and you’ve got an extremely formidable challenge. So, that got me thinking of sneaky alternatives to pull off day and night without the development overhead.

This led me to build a layer setting within the Lassie engine called “frameOffset”. The concept is pretty simple: Lassie assigns a MovieClip as the image of each layer within a room, then tells that clip to go to a frame based on the layer’s current display state. Adding a “frameOffset” basically tells the layer to figure out which frame it should display, then go to that target frame +X. This allowed us to start building all graphics with day and night states, where the night graphic was placed on a timeline frame immediately following its daytime counterpart. At night, all dynamic layers receive a frameOffset of “1”, which causes them to go to the frame after their baseline daytime state. Suddenly, this process became a whole lot more manageable: create all rooms once, then just track whether their graphics should be skinned as day or night. Of course, we still needed to add lots of conditional logic to control puzzle behavior between day and night, but that was a minor endeavor compared to what it would have taken to maintain separate world instances.

Overall, time-of-day was a tough process that made for twice the art production, extra programming, and a general feeling of exponential complexity. I’ll admit, I had a moment of weakness where I tried to narrow the scope of day and night down to just work within the center of Ravenhollow (about 3 scenes). However, Matt never budged on keeping the whole world playable in both times of day, and he was right. It IS better this way. We think our fans will really enjoy act 2 of Stitch (the largest act), where day and night is fully utilized. While we’ll be introducing the time switching scenario in act 1 (the demo area), the process will be linear so that the world state only changes once. However, in act 2 the player gets complete control of the clock!


1 comment so far

  1. Tucker on

    It was totally worth it. Added a lot of production value.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: