Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

1045296 Posts in 42346 Topics- by 34089 Members - Latest Member: mariagarcia

September 23, 2014, 12:27:26 AM
  Show Posts
Pages: [1] 2 3 ... 14
1  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 21, 2014, 02:04:27 AM
Hey guys. Apologies for the lack of updates here. I'm still working away but there's been nothing stand-out interesting to make a big post about. A few small tidbits:

  • The characters have texture detail & shading which loses clarity from the blue-noise dithering's poor range. At the moment I'm experimenting with using bayer dithering on the characters and blue-noise dithering on everything else. Looks ok.
  • I think I'm gonna try to get some professional voice acting done for the game.
  • Writing the music has been hard. I've got 4 or 5 melodies worked out but they don't have the right feel so I'm still noodling on that.
  • 640x360 1-bit dithered visuals don't hold up well when stretched fullscreen on a 27" monitor. This is probably the most serious problem facing the game right now. There are a few things to try but nothing's ideal. I'll just power through and ignore this for now.
  • Some good news: My next big post here will likely include a playable build.
  • Bad news: That won't be for another month. My goal is to have the first 10~20 minutes playable and submitted to IGF.
  • Depending on how things progress and which stuff gets done first, I may post something playable before the IGF build just to test the visuals and maybe allow walking around the top deck of the ship.

dukope, I have a question about implementing Ulichney's void-and-cluster dither. My implementation seems wrong but it also seems to work. I posted about this in my forums but I wanted to run it by you as well.

I didn't dig into your code, but my 2nd and 3rd phases look more different than yours. IIRC, the logic needs to invert between the two. Before phase 3, I invert the actual buffer, then start filling tightest clusters instead of largest voids.
2  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 01, 2014, 09:41:38 AM
Layering Without Layers

(Warning: Technical)

Because the character texture UV maps ended up being so complicated, I figured it's easiest to paint the textures directly in 3D for this project. There are two choices for which tool to use for this: Maya or Photoshop. Actually there are a bunch more but I don't want to shell out money and learning-time for another program.

Some pros and cons:
  • Familiar viewport controls
  • Simple color switching between black & white
  • Quick brush sizing controls
  • Paint directly in the full Maya scene
  • Layers!
  • All the convenient PS tools
  • No layers!
  • Can't paint if material is assigned to more than one object
  • Need to export to .obj for painting
  • Most useful when painting a single object
  • Terrible viewport controls
  • Two 3D paint modes: slow or inaccurate. Pick one.

There are objectively more pros for Maya. The viewport controls are especially important since I found it extremely hard to switch between the natural one (Maya) and the batshit crazy one (Photoshop). And as always, some of Maya's quirks can be worked around with MEL scripts.

Unfortunately, the thing that really hurts Maya is the "no layers" bit. Maya can only paint in RGB directly onto a flat png/tga/etc texture file. That's probably enough in most circumstances but in this case, the character textures are built out of (non-destructive!) layers to reduce the workload.

So building a new character texture is as easy as stacking up the clothes and adding a unique layer on top for the face and custom details like tattoos or scars. The character model geometry is built in a similar way, using matching blend shapes to get the clothes geometry to match up. There's nothing special going on here, but the reliance on layers does make it much harder to work around Maya's 3D painting limitations.

Not giving up though.

Compositing Tool

In choosing Maya over Photoshop, the first step was to write an external layer compositing tool. This takes the different layer images and composites them together to give the final image; a very simple implementation of what Photoshop does in-app for layering. I wrote the tool in Haxe since it's perfect for the job. Images are specified as a series of layers in XML:

<image id="Sailor01" source="Naked" publish="true">
<layer image="PantsPantaloonsDark"/>
<layer image="ShirtLong"/>
<layer image="Sailor01Custom"/>
<image id="Sailor01Custom" paintBase="Sailor01"/>

Running the tool processes each image to load the layers, composite them together, and save out a final PNG for use by the game. Pretty basic stuff. This tool also manages the single paintable texture that Maya's 3D paint tool affects. This lets me easily swap which texture I want to paint on without copying files around manually.

No Alpha, RGB Only

This is the last big problem with trying to get layers out of Maya's 3D paint tool. Since it can only paint in RGB, there's no alpha channel to refer to when compositing layers in the external tool. That's a pretty big problem. If this were a full color game that'd be the end of it. Luckily though, again, I can lean on the grayscale-only nature of the art and get the equivalent of a 4th alpha channel out of just RGB.

One way to do this would be to start with a black canvas and paint in shades of blue and purple:

This method allows encoding full alpha and value into RB with a simple decoding algorithm. Paint in blue where you want black, paint in purple where you want white. Adjust the amount of red in your brush to control how bright the final value is. And since the green channel isn't used, it can contain a copy of any underlying layers to make painting easier:

The external tool comes in handy here again. Each image can specify what to put in the unused green channel for the painting base reference:

<image id="Sailor01Custom" paintBase="Sailor01"/>

So this all works great, technically. Artistically it's a mess. Painting in dreamcoat colors gives me a headache and makes it really hard to judge how the final composited image will actually look. There's something better right?

Using "Math"

If we sacrifice the easy to decode part, it's possible to get a much more natural value/alpha encoding out of RB. The trick is to invert our starting channels, so one of them tracks darkening and one of them tracks lightening (more or less). If we start with a pure blue canvas, painting in black will darken the blue channel - painting in white will lighten the red channel. Getting the value and alpha out of this requires solving a simple 2-unknown, 2-equation system:

I say "simple 2-unknown, 2-equation system", but it took me a long time to figure this out. The solution came when analyzing a black-to-white gradient with a perpendicular alpha fade, on top of a solid blue background, in Photoshop:

The right image encodes all possible values of value and alpha on a blue background.

Converting the right image to an equation based on the input value (V) and alpha (A):

R = lerp(V, 0, A) = V*A
B = lerp(1, V, A) = 1 + V*A - A

2 equations, 2 unknowns:
V = R / (R - B + 1)
A = R - B + 1

Since this method still just uses the red and blue channels, the green channel is available for previewing lower layers and is a lot easier on the eyes now:

And in actual usage, the end result allows painting with black/white on any layer like so:

To erase something from the current "layer", I paint it with blue then re-run the external tool, which recomposites everything and updates the texture. In the same way, I can change whatever clothes this guy is wearing, re-run the tool, and have it extract/recomposite the layers without affecting the values I've painted.

Trouble > Worth?

This whole thing turned out to take a lot more time and effort than I expected at the start. In retrospect it probably would've been sensible to just put up with Photoshop's limitations and get advanced layering from the start. But part of what I like about making games is A) solving small well-defined problems, and B) writing quick, focused tools. I got to satisfy both of those with this layering system and the custom nature of the solution slots well into the pipeline I've been building on.
3  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 01, 2014, 09:34:03 AM
Made a huge post. Moving it to the next page.
4  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 22, 2014, 03:21:58 AM
Blend Shapes!

Blend shapes!

It turns out that Maya's blend shapes are uncharacteristically useful. While most morph target/blend shape systems limit you to vertex position adjustments, Maya allows you to make topological changes to the original mesh, then back-port those changes to your blend shapes. This allows a sort of non-destructive workflow since you don't have to get things perfect the first time. And this awesome feature is included in Maya LT, thank Ra.

I was able to bang out a bunch of clothing variations using this technique. Adding edge loops for clothing edges was trivial. Skin-weighting the verts to work well with all variations is a little harder but doable. The biggest downside is that some blend shapes (and the final composed model) may have geometry they don't need since they all get updated to share the same topology. A small price to pay for this workflow.

Body size, pants, and shirt variations applied as blend shapes.

Finding this gives me a much more positive outlook on getting these characters done without an obscene amount of fragile work. I'll use the same blend shape process for face/head variations, attach accessories as separate objects, and compose the textures manually after drawing the relevant parts of each variation once.
5  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 20, 2014, 07:33:51 AM
It's great that you write such detailed devlog, very interesting read.
Also newer versions of Photoshop had some tools for painting directy on 3D models, but they probably are far from perfect.


I completely forgot about Photoshop's 3D tools until your post reminded me. Just tried them out in the latest CC. As you guessed, they're far from perfect. So far from perfect, in fact, that they're terrible. All the photoshop layering stuff is there, which is great, but it doesn't load FBX (so I have to convert FBX->OBJ/DAE), the viewport controls were designed by a blind monkey, and neither of the two paint "modes" works right - one doesn't paint on half the model no matter what I do, the other is hilariously slow and inaccurate.

I give it 5 more years before it's usable.
6  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 19, 2014, 06:16:51 PM
Character Work

I've been spending most of my time recently on the character workflow. The game will have close to 80 fully modeled/textured characters (plus variations) so there's some challenge is figuring out how to create all those without an insane amount of work. 

I usually try to avoid standard game mechanics and visual styles in order to avoid direct competition with other, more resourceful teams. Working in the typical way to model, uv map, texture, rig, and animate characters scares me because it could easily swallow all of my energy trying to match expectations.

When it comes to the 3D human characters, I was originally thinking to use a hyper-stylized design to help with this. My idea was to texture only the face and leave the rest of the body black. That'd let me cut a lot of corners for the modeling and rigging too, since pure black obscures any interior details and I'd only need to worry about the silhouette.

Stylized texturing - Face only

When I tried this out it felt weird and unfinished. I may still go back to that and try some more, but in the meantime I decided to fully texture one character and see how it looked.

Less so

That sits pretty well in-game and matches up with the rest of the visual style better. I'm pretty worried about making 80 of these though so the workflow is going to be pretty important. Also, there are no internal lines/wireframes on the character at the moment. I'll play around with those at some point.


There are a couple things I have going for me, resource production-wise:

There's no color
I just need to worry about getting the shapes and shades right. Maya's 3D paint tool is also drastically more useful when you're just painting with black and white. If you select black for the paint color, holding CTRL lets you paint in white. So there's no annoying palette to go back and forth to.

The game is low resolution & dithered
Even if the player wanted to, they couldn't get a super close look at the models. There's a lot more room for error on my end.

The characters aren't elaborate
These are all sailors with very basic clothing. Most of the work will be focused on the faces, which I can sketch pretty quickly.

Characters won't have traditional animation
This'll get explained later when I talk about the core mechanic (still prototyping).

Painting in 3D

Terrence Stamp + Kevin Spacey + Abe Lincoln. The triumverate.

On this project I'm gonna paint the character textures in 3D. This'll be a first for me - in the past it's always been very simple UV mapping that was best textured in Photoshop. Now that the models are more complex I thought I'd try just painting directly in 3D.

Maya's 3D Paint tool is pretty good in use. Of course there are all kinds of stupid limitations (you can't easily paint a model that's already been rigged), but I've been able to work around everything so far with a touch of MEL scripting.

I use a small Wacom Bamboo tablet for drawing and I've found it pretty natural to paint directly on the model. The big saving grace is the game's black & white palette, which saves me from having to do any color management in Maya. I just have my swatch set to black at 10% opacity. I can easily build up shades with repeated strokes or pen pressure, and holding CTRL gives me a white brush for highlights/corrections. And because there's so much post-processing going on with the lighting and 1-bit dither, I can work to my style (fast and loose) when building up the texture.

It's easier to get this right when painting directly on the model.

Character Dithering & Lighting

One consequence of the character style is that the characters will be more heavily dithered than the environment. Seeing some amount of detail in the characters will be important to the game's mechanics, so I didn't want to go fully undithered like much of the ship.

More texture dithering & brighter/harsher lighting on characters

Because the game's post-processing handles lighting and dithering differently already, I'm able to treat characters specially and light them more harshly while also giving their texture more range (the ship textures are saturated towards white.)


Base character model

Now that I've taken one character through to the game, I'm working to create a base character model that can be tweaked and retextured for the rest. I may make some basic variations of that (skinny, short, tall, etc) first. This is a case where non-destructive editing would come in handy. Would be nice if fixing certain things in the base model would propagate up to the variations. As it is, I'll need to get the base models as close to perfect as possible before making any variations. If any problems come up it could mean either tons of rework or just accepting the faults.

One thing I need to get right on this base model is the clothes. Adding clothes requires adding geometry, changing much of the shape, leaving space in the texture for added bits, and correctly weighting all the verts. Alot of stuff that can go wrong down the line.

Also, I don't really know the ideal facial structure to use as a base. In the best case I can just push/pull verts from this one shape to get a bunch of different heads. But If there's some critical detailing or edge loops to make that easier, I won't really know until later.

UV Mapping

UV mapping in Maya

Maya has really good UV mapping tools. There's the cavaet that it trips up when UV'ing an already-rigged model, but besides that things are really nice. The "Unfold3D" feature makes it kinda enjoyable to go through, mark your UV edges, unwrap, adjust uv shell scales/rotations, then run auto-layout to arrange everything nicely. I've only done one character so far, but already learned from a few mistakes.

Tweaking the UV map

There were a couple problems with the first mapping:

1. Too many shells. Eg: arms, legs, and hands are split front-to-back. This creates visible seams on the outside and makes duplicating left/right in Photoshop more difficult.
2. The texel density isn't balanced well. Areas closer to the player (hands, arms) should have more texels since they will ultimately take up more screenspace.

A common trick to get more efficient texture usage is rely on the model's symmetry to mirror the left/right UVs. For this game, though, unique texturing across the model is important for some necessary details so I can't use that technique. Instead, the plan is to paint one side, copy it to the opposite side, then add unique details. That process is a lot easier if the UV map is laid out nicely and has fewer shells. My first UV map required lots of fine-tuned repositioning in Photoshop to copy/paste pixels from one side to the other. The updated mapping makes this process much easier.


I recorded another timelapse of creating, testing, texturing the character over a couple days. No annotations this time.

7  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 19, 2014, 02:23:35 AM
Have you ever heard of Softimage GATOR system? I had an XSI guy demo it to us at work once, it was really impressive... I think it's pretty much it's what you are talking about... however I have never used it myself in production.

I looked it up. Damn. I've heard good things about Softimage for a long time. Their editing workflow looks fantastic and non-destructive. And of course Autodesk just killed it.

On a side note... for some reason I kept thinking about this project last night,  and I couldn't keep my mind from coming back to the case of The Queen vs Dudley and Stephens.

Thanks for the tip! The wikipedia article is chilling. It's an interesting case but the circumstances were so extraordinary that I don't feel much connection with the ambiguity. I prefer more everyday mundanity in my life or death decisions.
8  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 15, 2014, 03:12:30 AM
For your next project you could take a look at Houdini [...]

I'll definitely include Houdini on the list, thanks!

what do you mean by "destructive 3d modelling" ?

Every 3d app I've seen follows an old school "do it right the first time" philosophy. Editing a model, adjusting a rig, painting skin weights, etc. All of these things make step by step changes that can't be undone except sequentially. And if there are non-destrutive/non-sequential ways to do things (Maya's construction history or Max's modifier stack), many operations require you to collapse those edits in order to work properly.

Destructive editing like this is by far the easiest thing to program so it's no surprise that's how all these old apps work. But I'd really like to see a modern app using a more forgiving design philosophy to put the burden on the tool and not the artist. Node-based editors like Houdini go some of the way there, but nodes have a tendency to focus on minutiae that matter to programmers' logical minds, not artists' workflows.

Imagine something more like Photoshop layers - not just to show and hide objects, but to group edits. So if you're going to work on the face, you can create a new edit layer and make all your changes there. Or make a new layer when you start rigging. If you want to try again, just hide that layer and you're back to the original mesh. Just like in a layered PSD. You could also:

- Duplicate and group edit layers to get a really nice non-destructive workflow.
- Pull parts of edits from one layer and put them in a different one to try different iterations of one particular area.
- Collapse edit layers together once you're totally happy with them.

Max's modifier stack is the closest I've seen to this but the UI is really poor and it's mostly focused on per-object edits. The ideal non-destructive editor wouldn't be easy to implement but the usability would be through the roof. A guy can dream.

It was a few years since I rigged a proper character in Maya so I don't remember the exact steps, but you can export the skin weights, then tweak the rig, and import the weights back to the model.

The in-app way to modify a rigged mesh is to copy your skin, edit the copy, reskin it to the skeleton, copy the weights from the original, then delete the original. A huge pain. I recently just got a skin weight export/import script that makes it much easier. The only catch is that Maya LT doesn't allow file writing from MEL Grin. Had to edit the script to print out the file contents to the script console, then manually copy/paste it into the file. Still faster than the in-app method!

Secondly, one way of improving shoulder deformations is to not use the standard T-pose, but instead give the model a more relaxed pose. I've even seen FPS models which were modelled with (almost) 90-degrees bent elbows, which makes sense if all they will be doing is running around with guns.

Yeah I really wanted to use an A-pose instead. IIRC, all the Uncharted characters are rigged in A-pose. But Unity-friendly rigs should always be in T-pose, and I actually need the full shoulder range for what I'm planning with these characters.
9  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 14, 2014, 07:37:23 PM
I don't want to be that kind of guy, but I hope you will consider using Blender on maybe, your next project. Having feature that 'should be there but isn't there' isn't that much fun.

I'm pretty sure Blender (or any tool really) isn't immune to small feature gaps. Switching to another package would just be trading one set of quirks and workarounds for another. The important thing for me is how hard it is to get around these limitations. So far Maya LT hasn't been that bad. But I will definitely go back and resample Blender and others after this project.

Blender scares me a little bit personally because it's open source and there are no limits to what you can fix yourself. At least with Maya LT I can say "this is unfixable and I need to work around it and move on." With Blender I could spend days editing the actual source or writing elaborate plugins. Fun but counterproductive.

My real problem with all these tools is the destructive nature of the editing. When I have some more material for it, I'll probably make a post about exactly how this negatively affects the entire project and how it could be so much better.
10  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 14, 2014, 07:08:56 AM
Fortunately the old Polycount wiki is still alive, great topology examples there:

Oh man, score! The shoulder stuff is basically what I ended up with already, but the face topology examples are really useful. I went through and made a few tweaks and edge loop changes based on that. Actually I had to force myself to stop - I could happily tweak face verts forever.

I don't think I'm a fan of the color changes, personally I preferred the plain white and black color scheme over the more bluish and brown variation. I know there are people that do like that though so I'm hoping that it's an option.

I haven't quite decided how to handle the palette yet. The blue/brown is some experimentation for slightly less contrast. It'll probably change again.

Maya LT vs. Maya

Maya LT is missing a bunch of features from the full version but it's been pretty good at including what I need so far. There are a handful of little missing things that you are naturally meant to want, once you start using the app more. The biggest is probably python scripting. Not having that precludes using a lot of popular scripts. I've managed around this limitation by sticking to MEL scripts and writing anything I can't find online.

Today, I hit another little thing that turned into a huge pain in the ass. The HumanIK biped character rigging system is thankfully included, but the Maya LT version doesn't allow the transfer of animation from one rig to another and HumanIK keyframes can't be copied/pasted like normal keyframes. Normally this wouldn't even come up, except that editing a skeleton after it's rigged (tweaking joint positions) requires regenerating the rig and losing all your animation.

Another one of those shitty destructive workflow things where you can't go back and make changes past a certain point.

The "Bake to Control Rig" option is missing from Maya LT. Have fun re-animating everything.

I was able to work around this by writing another custom script to go through each rig control to copy/paste the keyframes with the right parameters. Since it's a straight copy, there's no rig retargeting that the "Bake To Control Rig" would do. But it's enough to let me at least shift the joints around a bit without losing everything.

11  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 13, 2014, 07:45:39 AM

Character Modeling

I've finally started to prototype the gameplay for this. Part of that requires getting some characters in the game, so actually creating those has been my current task.

I need relatively low-poly realistic characters to represent the crew on the ship. The last time I modeled human characters was ~15 years ago in 3dsmax so I've been pretty worried about keeping up with current expectations. I watched a bunch of instructional videos on character modeling, started with a reference, and spent a few days modeling.

Reference (including sack) and after two day's work, 2684 triangles (sans sack)

The game is pretty low res at 640x360, so low poly models seem reasonable. I wanted something even lower than what's here but I noticed that the silhouette is still critical at low res and getting that right requires more triangles. Hopefully I won't need LODs or anything complicated when there are ~80 crew members on board. The model still needs a lot of polishing (and clothes) but it's enough to start prototyping.


Following tutorials and researching construction methods, it was interesting to see the wide range of techniques that artists use. For the face in particular there are two main factions. Some use box-modeling to start with a basic structure and fill it out with more and more detail. Others use straight-up poly modeling to lay down quads from the start and build out around the entire head. In each case, the main goal is to generate clean geometry with nice edge loops around the flexible parts of the face.

Eye & ear details will be in the texture.

I used the box modeling technique here since it felt a little more natural to me. Took forever but was relatively straightforward. I just kept tweaking verts until it looked ok. Something interesting I found is that it's much easier to see what's going on in flat-shaded mode. With so few polys, smooth shading looks terrible and makes tweaking the details really hard.

With fire we kill it.

Maybe this is actually a problem with my modeled shapes and using flat-shading is just a crutch to hide that. Probably!


One particular area that I had trouble with is the shoulders. It's easy to make them look good in a static T-pose but to support the wide range of natural movement is a lot harder. On my first try I just modeled the shoulders as usual and matched the poly density of the rest of the body. Unfortunately, I found it impossible to get it looking good for all the different twists.

Initial shoulder

I think it'd be possible to add some helper bones and maybe driven keys to get different areas of the shoulder/clavicle to compensate for the distortion. That didn't seem very sporting (and too hard anyways) so instead I:

  • Added a bunch of geometry on the shoulder to smooth things out
  • Manually transfered some of the movement to the clavicle
  • Tweaked the shit out of the skin weighting

Updated shoulder

And even so there's still some unnatural pinching and stretching. I think I'll wait until I've put some clothes on before worrying about it more.

Full Body Rig

For the player's hand I made a custom rig of joints and controllers. For the full body stuff here, I've decided to use Maya's builtin HumanIK system. Seems to be working well enough. The support for non-modal FK and IK in the same rig is really nice. It's still a pain in the ass to make changes or edit the skin mesh, but not so much that I'm getting too frustrated yet.

HumanIK rig.
(His dome looks a little coney here. Gotta fix that.)
12  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 13, 2014, 05:52:24 AM

This is a great resource, thanks! I just went through the entire list and found a few good sources. I wish more of them sold individual sounds instead of entire libraries though. I don't necessarily need 6GB of chain sounds - just one or two choice ones.

This is why sites like Pond5 or SoundDogs are useful. They're just distributors for different audio vendors so the quality can span a pretty wide range. But they let you search/preview/purchase individual sounds, which is ideal for my case. They're not exactly cheap either - but you can save a lot of $$ by just buying the files you need.

The biggest problem I've found with the big distributors is not the poor quality but the loss of uniqueness, since whatever you find has often been used (and reused) many times before in other stuff. I guess that's also the advantage of hiring a sound designer with his own collection.

I enjoy putting this stuff together though. Learning new things and making mistakes is all part of the fun. Not saying I do the best job, but I wouldn't even bother with making games if it was a "hire other people to do all the work" deal.
13  Feedback / DevLogs / Re: Even the Ocean (demo available. follow-up to Anodyne) on: August 12, 2014, 07:52:21 AM
Cutting it out [...]. A good lesson is just minimize, minimize, minimize, cut back. seems to wokr well for design overall but also i've noticed it helps a lot in music too. probably art in general, hm.

Cutting stuff is the best tool for figuring out what defines the game and what makes it good. The more you cut, the sharper that definition becomes. I love cutting stuff. My past self was an idiot anyways - he wasted countless hours on the stupidest stuff. I have no reservations about throwing his work in the trash and making it easier for me and my bud, future self.
14  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 07, 2014, 07:42:24 AM
Maybe a different dither for each material..?

I really love characterful dithers like this. I was originally planning to vary the dither on materials but changed my mind after realizing that the ultimate goal is to reduce the amount of dithering altogether. Any texture imparted by a different dither would only be visible in a narrow band of the lighting gradient. IOW, not worth the trouble.

One question, will this game has some kind of replayibility?

I'm not sure yet. I'm leaning towards no, but there may be a way to get a little bit of replayability in there.

So where is the ship gonna be located? Will it be in a harbour (meaning you would have to model a backdrop-city-thing) or out on the ocean?

It's "just outside port" for the specific reason that I don't want to have to worry about showing any kind of harbor/city/whatever backdrop.
15  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 06, 2014, 07:09:24 AM
Thanks for the positive notes everyone! Those big posts are a lot of work so I'm glad you enjoy them. Writing them is a pretty good way to decompress after finishing a big feature though so I'm not complaining.

Will the game have different weather conditions (heavy wind, rain, thunder,...)?
Are you planning on having seagulls?
Are you the only person on the Obra Dinn?

Different weather conditions: Sortof, but not as you think
Seagulls: I thought about leaving them out to accentuate the isolation, but now I think I'll put a few in. I'll probably also add a bit of the ship's bell.
Only person: NO COMMENT

Will the footsteps be dynamic depending on the deck you're on? I wouldn't expect to hear much running on the top deck.

At the moment, I'm not planning any footstep variations beyond what I've got. But the ship isn't fully modeled yet so there may be cases where a different floor surface could use a different footstep sound. If you mean about switching running/walking sounds, then no. There's no running in the game - it's all walkin.

Title Blue Noise

Meant to post this earlier. The title screen with blue noise dither.

16  Feedback / DevLogs / Re: Return of the Obra Dinn on: August 05, 2014, 10:10:47 AM
Environmental Audio

In contrast (Hand Clap) to the low definition visuals, I'd like the audio in this game to be pretty high def. That means using realistic sounds and mixing for everything. Ideally the player could close their eyes and forget they're playing a black and white low resolution indie game.


Luckily for me there's a solid set of iconic environmental sounds associated with wooden sailing ships:

  • Wind
  • Flapping sails
  • Stretching rope
  • Lapping water
  • Creaking wood
  • Woody footsteps

Putting those together in a static mix gets you a nice above-decks scene. The hard part is dynamically positioning and mixing them all together to make the ship seem real as you move through it in first-person.


There are a couple problems with trying to do complex ambient sounds in a 3D game. First is that basic 3D positional sounds aren't that useful. Most ambient audio doesn't emit in a sphere shape from a central point. Or if it does, then you need a lot of point sources scattered around to get the right sound.

Second problem is how to handle positional modulation at all. Because ambient sound comes from all around, you'd want that to modulate as the player turns their head. The proper solution is 5.1 surround - where the position information covers the entire 360 degrees and not just L/R.

So I just need to find a source for 5.1 ambient sounds.

Sourcing Audio

For the last few years I've been using Freesound.org as the primary source for audio in my games. The files there are rarely usable as-is, but with a little tweaking and combining you can get good stuff. Freesound doesn't have a lot of coverage though so I've also used SoundSnap.com (paid) to fill in the blanks.

I went back to those sites for this game and found them almost completely lacking. Very few useful footsteps, no usable lapping water, stretching rope, sails, etc. Kinda surprising.

I asked one of my pro audio designer friends where they get these kinds of sounds when they need them and his answer was: "We hit our back catalog, record them ourselves, or order them from a foley professional." Hmm... Well that would be cool, but I don't think I'll go that far. These aren't the kind of unique sounds that need custom recording. I just need to find a good source.

After a bunch of searching (All sound effect websites are straight out of 2001), I came up with 2 good ones: Sounddogs.com and Pond5.com. Both of these are expensive from the perspective of an indie developer. Based on the success of Papers Please though, I have more resources to use money in order to save time like this. So instead of searching for hours and hours for just the right free/cheap sound then processing it to fix things up like I used to, I'm just finding the right paid sound, buying it, and doing less processing. I still don't have a lot of expenses (no big team, no office) so it's really not much in the end. I think around $300 for all the sounds I'll need.

Anyways, one potential problem is that all paid sound effect sites only give you a low-fidelity preview of the audio. Already a few of the clips I've bought have turned out to have problems that were inaudible in the preview.

After finding exactly zero 5.1 sounds, I gave up on getting surround sources and settled for stereo.


So now I've got stereo audio sources and I don't want to use 3D sound spheres. How to position the audio? The first thing is to consider the environment. It's a smallish ship with 4 decks stacked vertically. Only the topmost deck is open, and there's a set of cabins at the rear. If I break it down:

  • Top deck - open
  • Aft cabins - closed
  • Gun deck - closed roof/walls, open gun portals, near waterline
  • Lower deck - closed, partially underwater
  • Cargo deck - closed, underwater

Each of these has a different ambient sound to them, but what's really important is the transitions: How the ambience changes when going into the rear cabins on the top deck, for instance.

Sound Rooms

In order to get all these ambient sounds going in each different environment I created a fairly simple component called a "SoundRoom":

Boom. SoundRoom.

The goal is to be able to position the ambient sound around the player wherever they are. Instead of playing individual 3D sounds, I play all environmental sounds on a loop in 2D and manually adjust their volume & pan as the player moves around. SoundRooms let me specify how that should be done based on the position and orientation of the audio listener.

Some games use environmental modeling with raycasts or geometry but I figured the ship was simple enough that boxes would be enough. I'm sure this technique has been used in lots of games. It's simple and it works well.

For each SoundRoom, I specify the audio clip that it modulates along with the properties of the 6 walls. Each wall has a setting to define how it affects the pan and volume of an ambient sound as the player moves around inside:

  • Solid: No affect on the sound inside the room
  • DirectionalSource: This wall emits the sound
  • DirectionalDestination: This wall receives the sound
  • DirectionalPass: This wall affects only volume and not position
  • DirectionalRoom: This wall uses another room to calculate position/pan
  • AmbientSource: This wall has pan=0 (to transition from open ambient to directional)

Each of these types was added by trial and error as I built out the SoundRooms and needed different features for directing the sound.

When laying out the soundrooms, I set each wall to whatever type will direct the flow of sound through it in a realistic way. During gameplay as the player's position inside the room changes, I interpolate between the properties on each wall to generate the final volume and pan for each ambient sound affected by the room.

Wall Interpolation

One interesting challenge that came up was how to actually interpolate between the volume and pan settings for the surrounding walls. The normal thing you use when dealing with 2D stuff is basic bilinear interpolation.

Bilinear interpolation

Unfortunately, bilinear interpolation interpolates between the corners. What I want is to interpolate between the edges. Trying to figure out what to even search for was a little tough, but I eventually found something called inverse distance weighting which did the trick.

Inverse distance weighting

Inverse distance weighting is normally used to interpolate between discrete points but it also works in any case where you can calculate a distance between two things - Like between a point representing the player's position and an edge representing a wall.

Implementing the solid walls is as simple as ignoring one edge's contribution:

The right side is a solid wall, ignored for the interpolation

One big advantage of this setup is that I can dynamically change the wall types. So the ambient sounds can change realistically when doors open or close to let in or block out different neighboring environments.

Editing in Unity

I've been constantly surprised with how easy Unity makes things. When laying out the SoundRooms, it's useful to have in-editor features like wall snapping, duplicate+flip, sound flow visualization, and more. All of this was trivial to implement in Unity's scene editor.

Sound flow visualization.

The system they have for seamlessly adding features to the editor is really great. As a former tools designer I'm often impressed by what's not only possible, but easy to do in Unity.

Spheres Too Why Not

Fairly quickly I found a case where elongated spheres would work better than boxy soundrooms. For those, I added a SoundSphere component that implements the same basic systems as the SoundRoom but uses a scalable sphere for the area.

Wind+water sounds through the gun portals

Rolling Off

As mentioned, I found the key to making the ambience feel right was to get the transitions right. Rooms where the audio changes from being all around to coming from just one direction sound great.

The other big win is with changing the audible frequencies as the player moves between open air and interior spaces. The technical term is rolloff I think. Basically, given an ambient sound, the high frequencies are more directional and can't penetrate walls. The lower frequences have less directionality and can be heard through walls.

This means that as you step into the cabins for instance, the high frequency portion of the wind and wave sounds should trail off, leaving the low frequency rumbles. What's really nice is when, during this transition, the high frequency part maintains its directionality - "this sound is coming through the door to the outside, which is to my right."

After some experimenting, I found that it doesn't take much to nail this effect. At the moment, I have only one ambient sound that does this rolloff - the main wind+waves loop. All other ambients are localized enough that simply fading them in/out is enough.

Unity includes an AudioFilter that can be used to apply a highpass or lowpass filter. But because I also want to split the positional handling of each portion, I need at least two sounds playing anyways. It makes more sense to just pre-process the original audio file to split it into separate "-Lo" and "-Hi" parts, which can then be played/panned separately without expensive AudioFilters.


This is a first person game so aside from the ambient sounds, there's a constant beat of footsteps as the player moves around. Changing these up to represent different surfaces really helps to make the ship feel more real.

It's a pretty small ship area-wise so I don't need too many footstep variations. So far I've got normal, grate, stairs, and carpeted footstep sounds. To specify which surfaces make which sounds I'm using a simple derivative of the SoundRoom: the Zone:

A zone for setting footstep sounds to "grate"

I think most games associate footstep sounds with textures or geometry. To determine which sound to play, you cast a ray down from the player, see which texture it hits, then look into a mapping of texture names to sound names.

This game has so few textures though, and so few different surface types, that I decided it'd be easier just to create little oriented boxes around the surfaces to specify which non-default footsteps to play. At runtime, I test the foot position to see if it's inside any zone and if so, use that footstep sound. Along with the footstep I also randomly play a light creaking sound every once in a while on foot down.

All of em

Audio File Editing

Since moving my development to OSX ~5 years ago, I've used Audacity for editing audio files. It's a great program, easy to use, multiplatform and with lots of features. The only downsides are that it's slow and all of the edits are destructive. Making lots of little tweaks or testing different things is harder than it should be.

I was all set with my typical workflow in Audacity when I started to think about alternatives. As mentioned above, I have a little more money to work with on this project. I like that Audacity is free but I'll bet there's more efficient tools out there if I'm willing to pay for them.

Sure enough, Adobe's Audition fits the bill perfectly. It's part of Adobe Creative Cloud, so the "rental" thing is a little off-putting. But the features and workflow are so good that I think it's worth it. In particular the sound and reverb removal features have already saved my ass.

Some Examples

A few places to show the SoundRooms in action.

Two of the aft cabins. High frequency wind+waves sounds
can enter through the door at the left or the window at the
bottom right. At the top right, the blue circle represents a
positional transition to pan=0 as the sound fades to the
main room, where it comes from all directions.

Stairs connecting the top deck with the gun deck.
Multiple soundrooms are used to fade out the high
frequency wind+waves audio as you descend the stairs.


I experimented briefly with Unity's AudioReverb component but couldn't find anything that sounded very good. I think it would be nice to have interior reflections when you go below decks though so I'll probably go back to this at some point and try again.


I recorded a short walk through the different environments. No visuals, just audio. After all that work it sounds pretty average really. I feel sorry for sound designers. A lot of effort to create and place sounds just so the player hears what they expect and doesn't notice anything unusual.
17  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 31, 2014, 07:26:25 AM
The Motion of the Ocean

I sat down a few days ago to start hooking up some of the ambient sounds, including the creaking of the boat as it rocks back and forth on the ocean. That got me sidetracked with figuring out how to actually make the ship move with the waves. The goal is to have the player feel like they're on a large, gently rocking ship in the open ocean. Gently both because it's a calm night and also because I don't want players to get motion sickness.

So to move the ship, the first thought is to just move the ship. Fortunately I know from experience that trying to actually move the ship is a bad idea. It's a ton of colliders, it's been lightmapped, and all the meshes are marked as static to enable framerate-friendly batching. Fancier games can have the whole level move around, but not this one. The ocean movement is so subtle anyways that I figured I could just fake it: Keep the ship/level stationary while moving everything else: the camera, the sky, and the moonlight.

Unity scene with sky sphere and main moonlight parented to a single node.

The first step was copying the sky scene into the main scene with the ship. The sky scene was previously used to render skybox textures offline but I'd always intended to get it rendering dynamically per-frame so I can add clouds and stuff. Now that the sky sphere is in the main scene, I can also move it around to make the horizon change, which in turn makes it look like the ship is pitching.


To calculate the motion's ocean, I had originally planned to just hook up a few sine waves and be done with it. I'm sure that would've worked fine, but I've been simulating things recently so why not try simulating a buoyancy model to drive the movement. I got about 2 lines of code into it before recognizing that this has probably been done before. Sure enough, there's an existing buoyancy model for Unity that works great. I dropped it in and a few tweaks later had a nicely buoyant brick on a little patch of ocean.

Buoyant Brick

For the wave shape, I combine some higher amplitude low frequency sine waves with smaller high frequency sine waves. The buoyancy model then uses physics forces on the brick to make it float naturally. Instead of rocking the ship directly, I put this little brick hidden off to the side and run the simulation there. Each frame I take the brick's matrix, invert it, and feed into the parent of the sky and moonlight, which makes the horizon and lighting pitch as if the ship itself was moving.

The effect is pretty subtle with just the sky and light; and disappears completely when neither the sky nor the moonlight is visible. So it also makes sense to wave the camera about a little bit too. I eventually decided to offset just the camera's vertical position, based on the brick's matrix from 1 second in the past. That makes it seem like the camera lags behind the movement of the boat, which feels about right.

Vertical camera movement + sky sphere motion

That's probably enough for the ocean movement. I've since moved on to implementing the environmental audio and unsurprisingly it seems unlikely that I'll need to synchronize the ship's visual rocking with the creaking sounds. Oh well, this task would've come up sooner or later anyways.

Environmental Audio on a East Indiaman

Setting up the audio has required a lot of technical work that I didn't expect. I'll go into some detail on that in an upcoming post since it turned out pretty interesting.
18  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 26, 2014, 07:39:12 AM
Some Dither Testing

Although I generally like to experiment with stuff like this, my primary goal with changing the dither algorithm is to improve how the game looks after being compressed to video (and uploaded to YouTube). I understand the talk about authenticity, but I'd be happy with either of these dithers from an artistic or stylistic perspective. So what's left now is to figure out which one looks better after being compressed, uncompressed, and scaled for viewing.

To test the two techniques, I recorded a quick video with both Bayer and Blue Noise dither matrices and uploaded the lossless video to YouTube.

Comparable frame at 480p. No nearby keyframe.

Comparable frame at 720p (cropped). Nearby keyframe.

At 480p with no nearby keyframe, the blue noise holds up much better. Bayer cross-hatching introduces color shifts and smearing artifacts due to whatever's going on in the compressor. On the other hand, Bayer looks better at 720p when the full resolution is available and there's a keyframe.

In the 720p case, the problem comes when the video content is scaled by the browser. Because Bayer uses a regular grid of pixels, even if it decompresses perfectly, it scales very poorly. With nearest neighbor scaling, the pattern starts to mosaic as it shrinks. Blue noise has no pattern to create this effect.

If I had to decide right now, I'd pick blue noise. The game isn't finished yet though so I'll revisit this later when the content is more final. The whole thing may become less of a problem anyways. For one, the sky won't be a smooth gradient in the end, and that's where the dither is currently most egregious.

About your hand moving to interactive objects, is it triggered only by proximity? Proximity + horizontally centering the object in view? Do you also have to look down a little bit for the hand to approach the door handle?

Yeah it's based on proximity and view angle. You have to be looking in the general direction of the handle, but not directly at it.

My brain prefers Bayer too. I find the squares, pluses and crosses of the skydome aesthetically beautiful.

I like Bayer too, but the main issue I'm dealing with is beyond how the dither appears in the game. I think if I can't get videos and images of the game to look acceptable in the wide variety of cases where they might appear then I'm pretty much screwed.
19  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 25, 2014, 06:15:51 AM
Dither Upgrade

Been playing around with different dithering algorithms. There are two basic classes of dithering techniques: ordered and error-diffusion. Ordered is just using a repeating pattern to threshold your pixels. Error diffusion reads each pixel sequentially and updates the threshold value based on the accumulated error of how far your b&w image is from the original grayscale. From the wikipedia article on dithering:

Floyd-Steinberg and Atkinson are both error-diffusion algorithms. Atkinson was a programmer at Apple in the old Mac days and his technique was used for a lot of Mac Plus imagery. It looks awesome.

Unfortunately, error diffusion requires reading the image sequentially as you adjust your thresholding error - something that's not possible with shaders. As a result I've just been using the bog-standard bayer ordered dithering.

After checking the wiki article again though, I noticed the ordered blue noise technique for the first time and thought it'd be worth trying out. It supposedly gets you an error-diffusion look with the ordered algorithm, just based on choosing a different dither matrix. So I spent a few hours and threw together a tool to generate the blue noise dither matrix based on this void and cluster research paper.

Comparison of bayer and blue noise dither patterns

In some places the difference is obvious and in some places more subtle. Blue noise loses a little range over the bayer matrix, but I prefer it overall for its smoother gradients and more unique look. I haven't tried compressing this to see how it fares on YouTube but hopefully the less-regular pattern will help there too.
20  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 24, 2014, 04:36:33 AM
Two things, where abouts is the FOV? It looks a tad low in the video. Also, when you look down and you're not next to a door, will you still see your arm?

The vertical fov is 58.7, which IIRC is a horizontal fov of 90 at 16:9. As the fov goes higher, anything that connects the camera with the world (the reaching arm) looks worse and worse. 90 felt like a good compromise. Also, I'm trying to make the spaces on the ship feel tight and the fov has a huge effect on that.

The arm only appears when you're near interactive stuff - doors, hatches, ropes you can climb, items you can pick up. Otherwise it's not visible. Even when offscreen it's still casting a shadow at the moment, which looks pretty weird. Making it completely disappear without weird shadow discontinuities is gonna take a little work I think.
Pages: [1] 2 3 ... 14
Theme orange-lt created by panic