VignettingSome words about the bit where the world fades to white outside a certain area.
Flashback vingetting
The idea of limiting where the player could look/go in the flashbacks came up way back when I was experimenting with the 1-bit blur effect. One of the applications there was an "area of effect" to keep the player focused on important items. Blurring was way too distracting but the idea of vignetting the flashbacks seemed like it had potential. My thought process:
Vignetting: Bad1. Limits the player's search space
One cool aspect of the game is how you can explore the whole ship at different moments in time, discovering clues and secrets. Limiting each flashback to a small area nixes that.
Vignetting: Super Great1. Limits the player's search space
This can seem bad near the start of the game but later on, with a large number of flashbacks available, it keeps the player from having to search the entire ship X times for something they may have missed.
2. Faster production
It's much easier to make a flashback when I don't need to pose the entire ship and crew for each one. That makes it more feasible to add individual death scenes where I would've packed multiple deaths together or had them off-camera before.
3. Reduces the level geometry
Cutting away >50% of the ship per flashback gives me way shorter lightmap generation time and faster scene rendering; without having to get clever on the technical implementation.
Verdict: (3 > 1) vignetting is super greatSettled. My first implementation was a fade to black. Looked good but just felt depressing in all that darkness. Also it gave a "spotlight" effect where it wasn't entirely clear that darkness = not there, as opposed to just, well, dark.
Fade to black
Without the shader effect, to show how much geometry can be discarded
Fading to white felt more surreal, and fixed the depression:
Fade to white
After getting this in, I stumbled on a solution to a different and totally unrelated problem...
Exiting EarlyIt was a common request from the first dev build to add a way to exit the flashbacks early, especially on a second viewing. While designing the dialog system I had a bug once where the music and dialog started at the same time. That caught my ear as being kinda neat and so I added the option, on second viewing, to skip the fullscreen dialog playback and jump right into the scene with the music and dialog audio overlapping.
Music and dialog are playing together here. Dialog is subtitled instead of fullscreen.
That gets you
into the flashback quickly, but how do you get
out of it quickly? The game only has one action button so I'd worked out a slightly convoluted way to zoom when near faces or bring up the watch when not looking at someone. Tapping action again with the watch up would start the exit animation.
Fortunately the vignetting gave me a better idea: Just walk outside the scene and the flashback will end.
Walk into the white to end the flashback
Brilliant. Felt good, made sense. There's a rising drum-roll effect and the watch lifts as you walk out; it's also possible to cancel the exit by walking back in.
I took this build to GDC. Of all the people that played, exactly zero walked into the white to end the flashback early. No one even tried. It turns out that fading the whole world to white outside a certain area is like drawing a wall, and players are trained to not run into walls. I talked with a few people at the show about this and someone suggested that I put them in a really small flashback first, to basically force them to wander into the white. A good solution but I don't have a small flashback near the start of the game.
Enter, the door:
Walk into the mysterious door to end the flashback
Yeah! It looks out of place but I'll take that over onscreen instructions or frustrated players any day.
Now, the opposite problem. You see a door like that and you are absolutely compelled to walk into it, first thing, without delay. Nothing could stop the player from immediately strolling through it. Fortunately (again) that's ok because I don't want the flashbacks to allow early exits on first viewing anyways. So the option to skip the fullscreen dialog and the door only appear on second viewing and there's hopefully no problem communicating this implicitly.
Story VisualizationFiguring out the narrative for this game has been tricky. The general ideas weren't too hard to work out but drilling those down to incorporate all the deaths and clues is another thing entirely. The structure is surprisingly complicated due to the severely limited mechanics. I can only drop nuggets of story and identity information when someone dies. And a death is only observable if you can find the body, either in the current time or a flashback. The player is often working backwards through time but they can also find bodies out of sequence. At the top level the game is divided into several large disasters that kill a bunch of crew members around the same time. How do you string all those deaths together in a way that's coherent for the player?
First, a shot of my crew board to illustrate the scope (blurred to avoid spoilers, sorry):
Gotta kill these 60 peeps
I can't work through anything like this without a way to visualize it. Similar problems came up for Papers Please where wrote a couple custom tools to help:
Papers Please custom economy tool
Papers Please custom event tool
I'm all about spending money to solve problems on this game though so I looked at some commercial tools to help with the process (working on OSX here). My first stop was a traditional writer's tool called
Scrivener:
Using this makes you feel like a total pro but it turned out to not be that useful for me. It's designed well for traditional non-interactive story development but doesn't help that much for non-text visualizations, which I need. Next, something more visual:
Better. Scapple is a really simple app that lets you create boxes with text or images and connect them with lines. That's it. Using this I could easily lay out the general progression of events on the Obra Dinn using snapshots of each crew member's face. It wasn't enough to get down to the precise details of who-killed-who and which-body-you-find-when though so I kept searching. Round 3:
Maybe better. OmniGraffle is a (very expensive) diagramming tool with tons of features. Great for visualizing dependencies. The downside is that it's built for office workers and I found laying out 60 crew members with information and arrows was clunky and slow. Playing around in here did give me some ideas about what might be better though. Round 4:
Retrobetter. Monodraw is really cool. It's a diagramming app rendered/edited in ASCII characters. I got surprisingly far with this. Enough to realize
exactly what I needed. Which ended up being a lot like a simple spreadsheet app with a tuned interface:
Timeline, a custom HTML5 story layout tool. Faces & names blurred for privacy.
Another custom tool. Gonna set a personal record here. Each row is a crew death. The game starts at the top and moves down as the player finds each new body/flashback. The columns from left to right represent the time of the death.
Timeline lets me define and visualize when someone died, who killed them, where their body is found, which doors their flashback unlocks, where clues to identity appear, and who is present in each flashback. It's a simple javascript/HTML5/CSS thing that took a few days to put together. Being HTML5, it runs on both Mac and iPad.
Doing this sort of story layout requires a lot of staring at the ceiling and it's been nice taking my iPad to the local coffee shop and working for a bit there. I think this is the first project where I've done any serious work outside the office.
The deaths are all laid out now but there's a few plot holes and questions left here and there. Meanwhile I've restarted implementing all the flashback scenes, after rewriting the Maya tools again jesus for the last time I really hope.
Community
