next »

[Pagan]

Hi, Sorry if you have mentioned this in the past, but have you considered using sailor tattos in order to help the recognition of the individuals? As Samuel O’ Reilly, a 19th century tattoo artist said: “a sailor without a tattoo is like a ship without grog: not seaworthy.” And a tatoo can tell so many tales. If it is visible of course. 

[ActualDog]

Incredibly interesting update. I know everyone keeps saying it but the attention to detail you're putting into this game is super inspiring. It's really cool to get such an in-depth look at your process for all these things. Especially as someone who hasn't done a lot of full pipeline 3D dev but is starting to get into it more, it's all really fascinating.

The game's looking fantastic!

[dukope]

Hi, Sorry if you have mentioned this in the past, but have you considered using sailor tattos in order to help the recognition of the individuals?

I had big plans for tattoos but it's another thing that suffers from the game's low resolution. Adding the manifest sketches made me realize the importance of obvious diversity that would show up in a rough sketch of the crew. Anything less than a huge tattoo unfortunately doesn't help much there.

There will definitely be tattoos though, and in one case they're critical to determining a sailor's identity.

[Panurge]

All 60

I will be expecting a dapper and discreetly-branded line of Obra Dinn clothing and I will be declining to take no for an answer. In the meantime, I await your Fall collection with steepled fingers.

[hendrikk1]

Really love to play his game, is there any demo update ? 

[EJlol]

Hi, Sorry if you have mentioned this in the past, but have you considered using sailor tattos in order to help the recognition of the individuals?

I had big plans for tattoos but it's another thing that suffers from the game's low resolution. Adding the manifest sketches made me realize the importance of obvious diversity that would show up in a rough sketch of the crew. Anything less than a huge tattoo unfortunately doesn't help much there.

There will definitely be tattoos though, and in one case they're critical to determining a sailor's identity.

What about scars, missing eye's, fingers, etc?

[muffintooth]

Just wanted to chime in and say the demo looks great, and Papers Please is great. Thanks for doing this!

[blahmoomoo]

How was Day of the Devs? I noticed a clip of this game in the mini doc video.

[dukope]

How was Day of the Devs? I noticed a clip of this game in the mini doc video.

Apparently everything went well at DotD. These events really like to pile up around this time so I was actually showing the game at PAX Australia that week. Big post to follow...

[dukope]

PAX Australia

It's been quiet here for a while - blame PAX Australia and Day of the Devs which kept me working around the clock for the last 2 months in preparation for the shows in early November. I kept it pretty low key because Obra Dinn is not a great expo game. The external deadline was a good milestone to push myself into finishing the last major core mechanic, though. Since the dates for PAX and DotD overlapped I ended up traveling to PAX and just handing off a build to the DotD guys.

The booth. Cozy with a couch to suit the game's slow pace.

Looking out. Opposite Vlambeer

As part of preparing for the show, I had to order a bunch of stuff for the booth: printed curtains, signage, PC laptop, 55" TV, controller, headphones, etc. Not a huge deal but painful to sort out while also crunching on the demo. 

I arrived in Australia the day before PAX to meet Rami Ismail and Adriel Wallick strolling up to their empty Vlambeer floor square with exactly zero preparation. Rami looked around and said, "Let's buy two TVs and we'll cut out a logo from fabric or something". 

On the first day of the show, I noticed the huge TV I bought a month in advance (with LoG's help) was 4K @ 30Hz, which looked like creamed dogshit running my 640x360 60Hz game. The frame rates didn't match up so there was tons of tearing and stuttering. Meanwhile Vlambeer's last-minute booth looked and ran great. Luckily, Rami has a heart of gold-dipped diamond and let me swap one of his smaller 60Hz TVs for my huge 30Hz one. Lesson: Don't prepare, just be Rami.


Build Updates

Obra Dinn is a bit of a slow burner in that the player starts out lost and confused, learning the mechanics as they play. This is not great for a busy expo where people are watching over your shoulder. But, PAX is not going to reschedule their show to give me more time to hit a milestone so booking a booth there was a great way to force my schedule.

In this case, I wanted to get a few more flashbacks fully completed (most of the game is at least blocked out), and add the last of the game's core mechanics. In the old public GDC demo, you wander around the boat for a bit, finding skeletons. The gun deck opens up after one of the flashbacks and you head down to end the demo. This was a quick way to end things but wasn't final. Instead, a new mechanic is introduced in the kraken flashback to push things forward.

BUNCH OF SPOILERS BEYOND THIS POINT

It's too late. You've already seen the gifs.

Phantom Corpses

Instead of finding more skeletons on the ship, the game makes a major pivot after the deathbed skeleton and requires that you find corpses in the past and "pull" their phantoms to the present.

Flashback corpse "pull" effect.

Pulled corpse phantom on the current-time ship.

Flashbacks marked on the manifest deck map, with animated death chains.

The phantoms use the same maze blur effect as the magically opened doors to signify ~from the past~. Once pulled, you can walk up to any corpse phantom and view their death flashback, just like with a skeleton.

This whole phantom thing is a bit convoluted but I need a way for the player to follow the chain of deaths in a sensible way without littering the ship with skeletons and locked doors. The three options were:

1 - Auto Drop
Like the doors, just visiting a flashback would drop any corpse phantoms in the present.
Good: Simple, consistent with doors
Bad: No challenge or clear awareness of what's happening; corpses are more spread out and less obvious than doors so it'd be easy to miss if they just magically appear somewhere without any particular callout.

2 - Inception Style
Finding/activating a corpse in a flashback immediately jumps you to their death flashback.
Good: Simple, easy to understand
Bad: I feel like returning to the ship often is important to ground the player and balance the game's presentation. Environmental audio/animation, manifest access, etc are only available outside flashbacks and going for a long time without these would get tiring. And, unless it's combined with also dropping phantoms, revisiting flashbacks at the ends of long death chains would be confusing/time-consuming/annoying.

3 - Key Style
Finding/activating a corpse is like finding a key. Return to the present ship to visit the newly unlocked flashback.
Good: Adds an additional mechanic of actually finding corpses in the flashbacks
Good: Can switch to Inception Style after the pulling animation for special cases
Bad: Convoluted and needs explanation, at least in its current implementation. More on this in the problems section below.

My strong preference was for Auto Drop, but the end-game and a few flashbacks would really benefit from Inception Style. Key Style lets me combine both of these - I can jump directly to a flashback after the pulling animation in cases where the corpse phantom wouldn't be accessible otherwise. This wouldn't be worth it except I really like the ending I've worked out, which requires Inception Style.


Correlating Manifest

The big manifest update I posted about earlier is in this build, with a few tweaks.

Muster page with fate details.

Sketch page (still a placeholder render) with visage details

Deck Map page with death details

I simplified a lot of the UI and tried to streamline the functionality as much as possible. But even looking at these flashing animated gifs now I'm confused. Watching people play with this highlighted the structural problems, mentioned below.


More Flashbacks

The PAX/DotD build has two new flashbacks, both set during the kraken attack, that lead to the gun deck where the demo ends. I would've
liked to include a few more but it turns out that most players didn't even get that far. And two is the minimum required to clear the "learning" phase of the game - beyond that things continue on as just a logical/observation puzzle. Hopefully it was enough to watch how players fared through this demo to know how they'd get on with most of the game.


Better Controller Support

Like Papers Please, this is a desktop-first game. Unlike Papers Please, I'd like it to be easy to exhibit publicly. That basically means supporting a controller instead of keyboard/mouse. 

Lamination. Quality.

This wouldn't be a big deal except for the manifest. I spent a week or two cleaning up the input to support both mouse/keyboard and controller, mostly focusing on the manifest sketch and deck map. I originally wanted these to use a grid-based up/down/left/right selection method but the characters in the sketch and markers on the deck map are placed totally freeform. Going up from one control then down again doesn't necessary return you to the original control, making getting around with a d-pad frustrating. Instead, I've made a virtual cursor that you can move with the mouse or the controller's analog stick.

Cursor on the analog stick

Problems

Watching PAXers play the game, most of them for the first time, highlighted a few problems.


Manifest Confusion

The Manifest is made of 3 main pages: the muster list, the crew sketch, and the deck map. Each of these pages scrolls vertically and has L/R buttons in the bottom corners to navigate between them. Each page also has a details popup for each crew member or death. I drastically simplified this whole system before PAX but it seems I didn't go far enough. Players were confused about the separate pages and navigating between them. I'll change things around to make this more clear.

A good suggestion from one of the players (I forget who, sorry!) was to make the pages animate sliding left/right while navigating. I've been avoiding this sort of flashy animation so far but it may be worth adding these navigational clues here.


Manifest Overload

Picking up the manifest is the "Ah ha" moment when you realize what this game is about. With the GDC demo manifest, you get a huge list of names and it's a nice "oh shit!" too.

With the latest manifest you get a huge list of names, an image showing every crew member, maps of all 4 decks of the ship, and a sea chart showing Europe and the coast of Africa. I'm not a practicing socialist but that's bordering on excess.

One solution would be to have the player find additional pages for the manifest as they play. That turns the game, at some level, into an item hunt. It probably wouldn't be so bad except that I'm worried players would hit a wall somewhere along the line and think, "well, there's just some manifest page I haven't found yet" - instead of focusing on finding corpses and solving identities with what they have in hand. This is also why you're initially faced with rooms full of drawers and cabinets that you can't open: to make it clear to the player about what kind of game this is/isn't.

I don't have a solution for this yet but it ties into the next problem so maybe I can package-deal them out of my life.


Invisible Game Mechanics Pivot

After the GDC demo content, the game takes a turn and (implicitly) requires the player to start looking for corpses inside flashbacks. No problem. Except that right before this turn, the game just told them to determine the fate of everyone on board and gave them a 50lb manifest to do it. The player is heavily focused on using their newly-found manifest to solve the 5 identities they've seen so far. Flipping around the pages, reviewing flashbacks, puzzling through who is who. And since there are no more obvious skeletons, this is where they circle round and round. It's mostly wasted effort since only 3 of the 5 identities are solvable at that point. I added a bunch of timed hints to try to smooth this out. Nobody reads hints, even when shown large, unskippable, against a black screen.

What I want to happen is that the player, seeing that massive manifest and all those names, tells the manifest to go f itself and carries on checking out cool new flashbacks. Gradually as they play they'll fill in an obvious name/fate or two until their own OCD will tickle them enough to push them into filling out the whole list. Then the manifest becomes a useful tool for reviewing and correlating everything they've seen.

This might've worked out ok in the current build except the corpse you need to find in the first kraken flashback is inexplicably hard to see. Players walked right past it so many times and let me tell you this is a hard thing to watch for 3 days in a row. I'll bet if I just make that first flashback corpse more obvious (the player's hand raises when near, just like with doors/lanterns), this problem will mostly go away. Instead of exiting that flashback and carrying on with the identifying, they'll be swept up into finding more corpses and following the chain of death.


Unity Collision

I'm using Unity's CharacterMotor and FPSInputController with a bunch of tweaks for the character movement. Everything works ok on my dev machine but apparently this code takes "the floor is solid" as a loose suggestion instead of a hard rule. I ran the PAX build on a PC and the player would frequently fall clear through seams in the floor and get stuck or drop to lower decks.

As a last-minute panic fix I constructed a huge solid block of collision under the top deck, leaving only one hole down the fore stairs.

The floor is solid

Because the game uses separate scenes for each flashback, getting this change to propagate across all of them could've been a huge headache. Luckily, I spent years slaving away to get the pipeline for this cursed game into shape so rebuilding all the scenes was relatively smooth and quick. I won't say all that work has finally paid off but there's a whiff of suggestion here.

Not that it totally fixed the problem. There's a tiny sliver of the fore hole that the player can still walk over where the collision code flips me the bird. Of the ~100 or so people that played the demo, 2 of them dropped down to the gun deck there and I had to restart their game.

I'm on the verge of rewriting the movement controller to use navmeshes instead of physics casts for floor collision. The ship's floors are relatively simple and limited so this kind of solution might work ok to resolve the problem for good. Haha.


Release

Unlike the GDC demo I'm not planning to release this build publicly. There's a bunch of stuff that would need to be fixed up and I'd rather just push on to the final release instead.

[JobLeonard]

Better Controller Support

Like Papers Please, this is a desktop-first game. Unlike Papers Please, I'd like it to be easy to exhibit publicly. That basically means supporting a controller instead of keyboard/mouse. 

Lamination. Quality.

You're making the right choice regarding this game, but your comment on Papers Please feels a bit silly to me: the tangible interface of the mouse was a crucial aspect of that game's gameplay.

In fact, I think that if you want to exhibit a game like that properly, one should drive that point home even more and make the whole context support the mood of the game: set it up in a boring cubicle, use an old-fashioned CRT, and a worn down mouse with a ball and a mechanical keyboard.

Yes, that might be harder, but as far as I'm concerned it's a piece of art and it deserves the proper context

[dukope]

...You're making the right choice regarding this game, but your comment on Papers Please feels a bit silly to me: the tangible interface of the mouse was a crucial aspect of that game's gameplay.

Yeah I meant "For Obra Dinn that basically means supporting a controller instead of keyboard/mouse."

For Papers Please the solution was the iPad touch version, which was way easier to publicly demo without sacrificing the UI's intent. Unfortunately that version didn't exist until after I'd mostly finished demo'ing the game publicly.

[JobLeonard]

... whoops, had not considered the aspect of you showing off demo versions to the public

[DireLogomachist]

Luckily, Rami has a heart of gold-dipped diamond and let me swap one of his smaller 60Hz TVs for my huge 30Hz one. Lesson: Don't prepare, just be Rami.

Rami is such a chill dude. I'm so glad the indie games scene has him around.

[FrancisT-1000]

Just had a bit of a thought as to how you might alleviate the 'manifest overload' problem. If you do go with the idea of having the player find new pages as they go along, the whole 'item hunt' feeling could be lessened by letting the player know how many pages there are to be found in the first place.

Another idea was to separate the muster list, crew sketch and deck/world maps into three more distinct physical artifacts. So you'd end up with more of a 'resources' page instead of having it all be bundled into one massive Manifest tome.

Also a big fan of the idea of having the page turning being animated. I don't know if I'm imagining there being a sound effect for the page turning, but having it be animated as well would ground it a lot more in the game world.
(game looks amazing, can't wait to play it!)

[Thaumaturge]

Unity Collision
...

I don't know Unity's character-controller or physics systems, so take my thoughts with a grain of salt. That said, are either jumping or falling important elements of your gameplay? If not, perhaps simply remove them, having the controller keep its current height when it finds no floor beneath it. I did something similar for a game-jam a little earlier in the year, and found that it seemed to produce a pretty stable result. (Albeit that I was creating a simple controller more or less whole-cloth, rather than altering an extant one.) In short, as best I recall, the logic looks something like the following:

Each frame, perform a line-segment test (or an infinite ray-test, discarding the result if it's too far away), looking for the floor. If it's found, set the controller's height accordingly; if not, just continue on.

You might want some invisible walls for unprotected holes, such as open hatches (which would presumably result in the player seeming to walk on air), and areas where an undesired "step" might be present (such as at the sides of descending staircases).

[Gradius]

Perhaps just set the gravity to 0 for the player and handle staircases manually?

[dukope]

[add page numbers or separate sections into separate items]

Showing page numbers is a good idea. There wasn't room for them in the PAX build but I'm redesigning it now to include them. Splitting all the pages up into separate items is currently marinating. I'll move on with a single manifest but yeah maybe there's a good point where I can say "it'd be better to find the sketches here instead of including them from the start".

[Physics suggestions...]

There's no jumping or explicit falling but there are slopes and up/down stairs. A lot of this could be tweaked and optimized in a casting-based controller. In my mind though, a navmesh-style solution is absolutely explicit and would basically just close the book on any problems - or at least move them out of the programming phase into the modeling/design phase. With a small-ish static ship, that might be an easier phase to deal with.

I had a quick look at Unity's navmesh system and it looks pretty useful. I'd need to write a bunch of pipeline tools around it but that's one of Unity's really strong points.

Perhaps just set the gravity to 0 for the player and handle staircases manually?

This might work in a few cases but there's enough slopes to require lots of manual tweaking. Some flashback scenes tilt the entire ship while the player remains upright for example.

[Thaumaturge]

[Physics suggestions...]

There's no jumping or explicit falling but there are slopes and up/down stairs. A lot of this could be tweaked and optimized in a casting-based controller. In my mind though, a navmesh-style solution is absolutely explicit and would basically just close the book on any problems - or at least move them out of the programming phase into the modeling/design phase. With a small-ish static ship, that might be an easier phase to deal with.

I had a quick look at Unity's navmesh system and it looks pretty useful. I'd need to write a bunch of pipeline tools around it but that's one of Unity's really strong points.

The system that I outlined actually works pretty well with slopes, as I recall, and I believe that stairs should only really call for a means of reducing the suddenness of descent and ascent.

I recall only two significant issues with the system as I implemented it (aside from not having jumping or falling): it moved too quickly for my liking on very steep slopes, and forced the player downwards a little on a very tight, somewhat steep, spiral slope. The latter may, however, have been in part due to an interaction with the physics system that I was using to prevent interpenetration.

However, if navmeshes are likely to work better for you, then fair enough! ^_^

[mtarini]

Game-making skill level: dukope.

I just read through the  last three updates, so I'm just dropping a line to repeat, once more, how much your craft and skill is appreciated, and, even more so, the effort you undertake to reveal large parts of what's going on behind the scenes. I wouldn't know which aspect to praise first: the capability to envision completely different and unexplored game concepts, or the mad skillz to turn them into reality. Everything, from algorithm-based art to cleverly designed game tools, is truly inspiring. Like, how you fine-tune a complex system of smart game-play mechanisms, or find technical solutions which are always smart, conceptually simple, clean and effective. Or, the care you take to keep it well grounded in the realm of playable games, the player experience always in your mind -- this is what it takes to turn a visionary idea into a real game (as opposed to, just an interesting art experiment, which would be so much easier). 

So, thank you a bundle for sharing.

One specific comments:
The current "place-holder" everybody's portrait looks so cool. Most other developer would just keep it for the gem it is. Are you sure you want to replace it with some hand-made impression by some however-good artist? The current image is also very well integrated with the rest of the art style (by construction) -- I understand that this would be more fitting for a photograph, which it cannot be, but it will be hard preserve the style consistency with something which must also comply to the look of a XIX century drawing... good luck!