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

Login with username, password and session length

 
Advanced search

1057162 Posts in 42941 Topics- by 34886 Members - Latest Member: chriswhat

October 25, 2014, 03:56:02 AM
  Show Posts
Pages: [1] 2 3 ... 15
1  Feedback / DevLogs / Re: Return of the Obra Dinn [Playable Build] on: October 23, 2014, 06:25:02 AM
[...]About "Memento Mortis": the right form is "Memento Mortem".[...]

I'm gonna lock 10 Latin scholars in a room and ask them to settle this with hand-to-hand combat. Last one standing decides the translation and gets a free copy of the game.

(I'll probably use "Memento Mortem" unless someone really objects)
2  Feedback / DevLogs / Re: Return of the Obra Dinn [Playable Build] on: October 23, 2014, 02:55:46 AM
The most frequent piece of feedback that I've gotten so far is that the death moments are too long on second viewing. So even though my original plan was to keep it like that, this is something worth changing. I'll figure out some way to manually speed up the watch if you've already seen the moment before.

The sky, the water around the boat, and the top deck are all completely unfinished. One of the reasons I wanted to get this build out is so I can stop being secret about the core mechanic and start posting more progress posts about how I fill these things out.

Some other feedback:

  • Needs a mouse-invert option (will do)
  • Needs adjustable mouse sensitivity (will do)
  • Hard on the eyes - add less contrasting color options (will do)
  • Make a Linux version (will do eventually)
  • A way to take pictures or remember faces would be nice (probably not, but thinking...)


Response dump:

[...] It's kinda like ordering someone to remember their own death [...]

I think that may be close to the sense I want. It's funny that Latin is so strict about this kind of thing. Really though, as a phrase, "MEMINI MORTES" may be correct but it doesn't look cool at all. So my inclination would be to change what I want in order to get a cool-looking phrase. Can you give me more descriptions about what "Memento Mors", "Memento Mortis", "Memento Mori", etc mean when translated? Through PM is fine if you'd rather not post it here. In any case, thanks for the help!


[...]I felt myself longing for the player character to cast a shadow[...]

I experimented with a player-cast shadow. It has the same problem as the hand-held lamp did: too much changing stuff as you move around. There's a lot of careful tuning to make this 1-bit low res thing work and I've found that leaving the world view mostly static helps a lot.

Quote
The default controls are nice but I found myself wanting to use the mouse buttons to interact with things.  RMB for right hand, left click to pull up stop watch seems intuitive to me but maybe you have other plans moving forward.

I'm not locking the mouse right now (Unity issue), so mouse clicks risk losing focus. I'll get it sorted and you'll be able to hit space or and mouse button to use. There'll be just one use function though, no LMB/RMB separation.

Quote
[...]The interface for filling in the crew muster is cumbersome[...]

I think the only thing I'll do here is let you page through the book with the left/right arrow keys. Thanks for the detailed comments!


[...]Even if I was a bit disappointed that so far I can't interact with anything but doors on the Obra Dinn. I constantly tried to open cupboards and drawers and stuff but to no avail. Would be great I we could interact more with the ship.[...]

This is intentional (same with the clearly door-breaking axe just lying there at the start). Little bit more about that below.

Quote
So far the gameplay feels a bit like 6 degrees of sabotage (great game btw) but with a time travel twist.
Question is, I am (the player) just a agent that has to find the truth of what happened and who has to deduce who killed whom and how? Or will I have any influence of how the story unfolds? I am in any danger?

That's pretty much spot on. I really liked the simple identification mechanics in 6 Degrees of Sabotage. My original plan for Obra Dinn was a lot more involved but would've been impossible production-wise. When I stepped back and considered the situation of boarding a ship full of dead people, the idea that your task would be based strictly on identification made sense. So to answer the question, yes, your tasks is only to deduce the identities and fates of everyone on board. I'm going to try to be very explicit that this is not a horror game, so you're never in any danger. You'll also have no control over the past and no way to affect past events. That limits a lot of what I can do with the game, but the simplicity of it really intrigues me.

Quote
I also wondered how my time travel opened the locked door, I have not interacted with the door in any way. So why is it open when I come back? Would have been more logical if I went back in time, walked through the open door and waited for the clock to run out. Kind of Silent Hill style.

Currently, the doors open because I'm gating the player. I've considered an in-world explanation for this. My original vision was to find keys in the past and transfer them to the current time (say, by putting them in the dying guy's pocket). But at some point I realized that's a cure worse than the disease and decided to just open the door in the present if it was open in the past. I have some ideas about how to make this work more naturally though so stay tuned.


Could you make a dedicated animated GIF recorder that ships along with the game? Since you literally only have 1-bit visuals it might be pretty efficient?

That's a cool idea but without YouTube's social ecosystem I'm hesitant to put effort into a custom solution like this. The screenshot key was a last minute addition to the dev build and ended being a great move though so maybe a little 5 second giffer could be worth it.


[...]interesting game play, it took me 3 tries wandering around trying to pick up the bloody ax to fine the case and get with the program ...

It's painful, but this was exactly my plan. I want the player to get the whole "interact with everything!" impulse out of the way right at the start so the rest of the game goes much more smoothly. That first skeleton could've had a knife and you probably wouldn't have expected to use it to open the door. But I thought putting door-breaking axe is the perfect way to get this pill down quickly. All the drawers and cupboards in those two side rooms are for a similar purpose. The basic idea is that literally everything could be picked up or opened but you should pay attention to the hand when looking for actual interactive stuff. This isn't an "open all the drawers to find the items" or "improvise with this weapon lying here" kind of game and I wanted to establish that quickly since I think it could hang over the player for a long time otherwise.


[...]I'm not sure how close the human models are to your final intent or how much you still plan to experiment with them[...]

I played around with lower poly, more stylized characters a while ago but the visceral connection to the violence just wasn't there. I think I'll probably stick with the current style for the rest of the game.


Two things about the potential crew fates: I'm not a native speaker so maybe that's the reason, but "killed by gravity" comes across as an oddly stilted phrasing to me. And the presence of Europe on the "Alive in..." list seems a bit weird when five separate European countries are also on it.

The fate sentence construction is pretty strict, which results in stuff like this. I may or may not try to fix that up. I'm also considering the possibility of specificity in the fates. So, for example, you can determine that he made it to Europe fairly easily - and fill that in - or you can dig much deeper and find some small clue to see that he actually went to Spain. So while "Europe" is correct, "Spain" is correcter. Just an early idea though. The rest of the story, including the fates, is completely up in the air right now.

Quote
And at the risk of being "that guy" - will there be some type of in-universe explanation for what the watch actually does (or what the character does that's represented by the watch), or will it be a suspension-of-disbelief thing? As it stands the emotional disconnect between being just some officially appointed investigator and being able to "see" past events involving dead people feels a bit strong to me.

There is an in-world explanation for why you have the watch, but lemme just say that you won't find out for a while.


This game has some of the best stair walking I've seen in a game

Thanks :D. I lucked out on this. There's no special handling of the stairs beyond "speed up the headbob when moving up/down on y". The collision is a big ramp with sliding disabled and it plays different footstep sounds.


[...]One bug I encountered was in the frozen death scene levels, the narrow patio outside of the captains quarters isn't solid and you fall through to the bottom of the world.[...]

Whoa I've never seen this. Which part of the balcony was it?
3  Feedback / DevLogs / Re: Return of the Obra Dinn [Playable Build] on: October 22, 2014, 09:14:40 AM
Sorry, I already played this game:
http://www.ign.com/articles/2014/10/02/the-vanishing-of-ethan-carter-review?watch
And it's much more enjoyable.

I just found out that Ethan Carter has a similar mechanic. Apparently Cryostatis too. I guess this ground is fairly well tread.

Anyone that's played Ethan Carter, how similar is it to this Obra Dinn build? EC looks really good but I probably won't play it for a bit to avoid any kind of influence.
4  Feedback / DevLogs / Re: Return of the Obra Dinn [Playable Build] on: October 22, 2014, 05:30:18 AM
...are you aware of this dithering algorithm?
http://pippin.gimp.org/a_dither/

I haven't seen that one yet. Looks pretty good, gonna try it out for the characters. Thanks!
5  Feedback / DevLogs / Re: Return of the Obra Dinn [Playable Build] on: October 22, 2014, 03:50:16 AM
Hey guys, thanks for all the great feedback so far.

The intro sequence and the intrusive text popups at the start are all temp things just to get the player going in this early build. I got a little worried at the last second that nothing is clear and added the "find the muster roll" and "determine everyone's fate" cards. In the full game there'll be more chances to nudge things without straight-up telling the player like this. 

There's always a problem with early builds that it's easy to think you're seeing a bug or getting stuck because it's unfinished. Those explicit cards are supposed to clear some of that up for now.


...are you going to keep size modes in final release ? or are you just testing which one people going to like, imo looks best on small framed.

I'll probably keep all the sizing modes and maybe add some more. Which one looks best depends on personal preference and monitor size.


notes as i go, feel free to ignore:..

Good stuff! I had to look up Ghost Trick. Smiley

Music is the one thing I had to basically punt on for this demo. I like the moment composition, but not the instrumentation. And the theme song is still in progress. I've had trouble getting a good orchestral sound; mainly because I know nothing about orchestral instrumentation.

You're right about the pacing too. I'm going to try enforcing the watch's rules to slow things down in an understandable way. So, for example, you can't cancel a moment trip to quickly move between the past and the current time - you have to wait.


... Some initial feedback: perhaps there should be a way to end the "time rewind" early (unless there already is and I missed it)?
... Also, invert mouse for the final version! ...

There's no way to end the moments early. Initially that was just a UI thing but now I prefer that you're stuck and at the watch's mercy. I'll definitely have an invert mouse option in the settings.


First of all I'd like to say the the game is bea ut if ul

Nice! I threw the screenshot key in there at the last possible second and I'm really glad I did.


Quote
...Due to the mysterious atmosphere and setting of the game I found the "determine the fate of passengers" slide
a little redundant....

Yeah, that's just a makin-it-totally-clear-for-this-early-build thing. It'll be more natural in later builds.


This is unbelievably awesome. I wasn't expecting the quality of the models. The way the hand goes out and grabs doors feels so immersive, I don't know why I've never seen other games do it before.

Thanks! The door grabbing mechanic was a lot of work but I think it was worth it. You may notice that the book grab is different but the box handle uses the same grabs as the door handle. Saving myself some work there.


...The only thing that bothered me was the quotation marks on the text are wrong...

I'm not even lying when I say this also bothered me, but not enough to fix yet. I need to check if the font has opening quotes and which UTF code they are. It'll get fixed is what I'm saying.


... the Latin is wrong, it's usually memento mori. However, I believe memento mortis is actually also right, since memini takes the genitive, and mortis is the gen. of mors

I know zero actual Latin but I'm familiar with how all over the place translations can be. Wikipedia has or also memento mortis, “remember death” on their memento mori page but that's obviously too easy. Someone on twitter suggested first "Memento Mors", then either "Memento Mori" or "Memento Mortem" based on this page here.

If anybody knows for sure (if that's possible), please let me know. Otherwise I'm gonna change it to "Memento Mortem" since I think that captures the sense of "remember this even where someone died" that I'm going for.


...I spotted rendering errors with the doors, depending of the camera position they would disappear, here some screenshots to give you an idea of what happened...

Thanks for the pics. Unity has a lot of really nice, easy to use systems built right in. One of those is occlusion culling, which can be generated at the click of a button. Unfortunately, trying a myriad of values for blocker and hole sizes gives me various dropouts on the ship. I need the culling for performance and the current settings have the least crazy dropouts. That spot you've found there is the only one I know about. I'll keep tweaking the values until it works.
6  Feedback / DevLogs / Re: Return of the Obra Dinn on: October 21, 2014, 10:56:34 PM
First Playable Development Build





Play through the first 15 minutes or so of the game. It's still very rough and very untested. For such a low-res game, performance is not great on a 2011 Macbook Air running BootCamp. Hopefully it runs ok on most machines. The core mechanic is only lightly touched on, but you should be able to mentally extrapolate out what's here to a full game. Give it a try and let me know what you think or if you have any problems.


IGF

My original goal was to submit to the IGF this year. That deadline was pretty useful in getting me through these past few weeks of crunch, but in the end I've decided not to submit the game as it is. Maybe next year.


Devlog

I have a bunch of technical details and modeling videos I'll try to post up here in the next few days.
7  Feedback / DevLogs / Re: Return of the Obra Dinn on: October 18, 2014, 07:20:03 AM
Slight change of plans. A first playable build is coming in the next few days but I won't be submitting to the IGF this year. The build is a nice vertical slice but I think just not enough to stand up to serious judgement yet.

8  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 29, 2014, 06:54:31 AM
"Gameplay"

Imagine a zippo-like *chlink* sound when opening/closing.



9  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 29, 2014, 06:46:50 AM
I'm a visual artist and big fan of those early mac dithered pictures.[...]

Whoa big post! Thank you for the suggestions. You're right about the problem with blinking pixels at such large sizes. The frame-to-frame coherence is pretty bad when the pixels are bigger, especially with sharply contrasting shades. There's also the problem that the whole dithering mechanism falls apart if things are so big that your eye can't combine neighboring pixels into the desired shade. So my solution is almost the opposite of yours - to reduce dithering as much as possible. Shape-wise, things are pretty clear with just the lines:


Lines only.


This is easy on the eyes at any size, especially in motion. Dithering improves the look but makes it harder to read, so the goal is finding the right balance. Your sample image looks cool at small sizes but in fullscreen I need to move back from the monitor to parse it. Adding another shade as you've done would let me dither less, which would be nice. But I prefer the challenge of making this work with just 1 bit.

Your other suggestions are spot on and mostly in effect: Simple geometry, Textures tuned for the dithering, and lower contrast colors.


Ridiculously excited about this one. I'll throw my vote against the blur, though, too- seems to just undercut the Apple II-ness of the concept, without adding much. [...]

Thanks! The fullscreen blur is really subtle in practice. It's a half pixel gaussian blur and just adds a slight softening or "oldening" effect. Most monitors/video cards do their own bilinear filtering when upscaling to fullscreen anyways, and this is just a little stronger than that. You'll be able to toggle it for the first demo and I think you'll be surprised how much more comfortable it is in fullscreen with the softening.
10  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 25, 2014, 09:48:12 AM
I mentioned it on twitter, but this fullscreen problem surprised me. Up until recently, I've only been playing the game seriously in the Unity editor's reasonably small play window. It's always looked good to me there. Also in all the screenshots and gifs posted in the devlog.

The problem comes when taking those nice crisp 640x360 black and white pixels and filling your entire view with them. The original Mac Plus monitor was 9". You can't just stretch that to 27" and expect it to be comfortable. Especially (I found) for a 3D game.

Anyways, I most likely won't have a ton of options in the menu for this. I'm not a fan of lots of options in general; makes it harder to develop and maintain. Instead, I'll probably just have two options for fullscreen: normal or "softened".

None of this matters for windowed mode btw. Unfiltered black and white works great as long as the physical size isn't too big.

How about not running fullscreen?  Float the game viewport at a size that feels good in the center of the screen, surrounded by black?  The original 128K mac screen was only 9 inches diagonal, at 72 DPI, which is a good pixel density to read shapes.

Good point. A forced window on a black field would be my first choice. Unfortunately, I learned on Papers Please that players have zero tolerance for black bars. None. I got tons of support requests about this (Papers Please has small but permanent black bars in all resolutions).

Although I may add an option for this too, since I think it will unquestionably look the best.
11  Feedback / DevLogs / Re: Return of the Obra Dinn on: September 25, 2014, 08:14:57 AM
  • Some good news: My next big post here will likely include a playable build.
  • Bad news: That won't be for another month. [...]

Lies.

Fullscreen Looks Terrible

I've been worried about this:

  • 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.

Couldn't ignore it so I went ahead and tried a few things. These pics are all crops of the full 1920x1080 frame. Click on any one for a full-size version. Scale it up to as close to fullscreen as you can to get the right effect.


Base 640x360 stretched to 1920x1080


When viewed small, everything looks great - still or in motion. Stretched to fullscreen on a huge monitor, the pixels end up so chunky that my eye can't resolve the lines and shapes easily. It's even worse in motion.


Double Resolution

The obvious solution is to just increase the resolution:


Rendered at 1280x720, stretched to 1920x1080


That helps with the chunky pixels but it loses some of the low-res style that I like. The 1-pixel wide lines are now half as thick which feels too thin. The biggest problem though is that it exposes my payless modeling and texturing, especially on the characters. I chose this 1-bit low-res style partially so that I wouldn't have to kill myself on high-res asset creation. So either I up-res all my models and rethink the asset creation or find another solution to this fullscreen problem.


Cathode Ray Tube

Ok, next try. Who doesn't like a good CRT shader?:


Base 640x360 rendered through a CRT shader at 1920x1080


Pretty good. The shader itself is not that great but I'll assume it's good enough for this test. The CRT details, border, and geometry are all full resolution 1920x1080. The blurriness helps join the pixels together so they feel cohesive again at fullscreen. The downfall is that you're looking at a low-res CRT. I personally love this effect in most cases but it just doesn't feel right here. Part of that has to do with the audio, which is realistic and high-fidelity; mixing that with an old shitty monitor feels off. The whole CRT effect is also too distracting IMO. It's hard to describe, but this feels like going too far stylistically by clashing "old computer" with "old ship".


Squares->Diamonds

Right. Now for something weirder. Diamond-shaped pixels:


Base 905x905 rendered at 45 degrees, then rotated back at 1920x1080


Not sure what I was thinking here. This is pleasantly unique and doesn't look half-bad. Vertical and horizontal lines get a nice stippling effect. Overall though, it still feels too rough and also a little gimmicky. Not that the entire 1-bit thing isn't one massive gimmick; this is just one gimmick too far.


Scale2x

Running out of steam. I went back to some Papers Please experiments and dug up scale2x:


Base 640x360 stretched to 1920x1080 using scale2x


Hey not bad. Not great, but I like the mottled look. The scale2x algorithm connects pixels really well so the lines and shapes are much easier to read. I also tried scale4x (just run scale2x twice), but it creates lots of small artifacts that look terrible. I was pretty happy with this and probably could've left it there but decided to go back and borrow some blur from the CRT technique.


Scale2x + Blur


With a touch of blur:


Base 640x360 scaled2x'd to 1280x720, guassian blurred 1 pixel, then stretched to 1920x1080


Ship it. This ends up as a kind of CRT-lite. None of the skeuomorphic business with pixel grids and screen curves but it does feel "old" without being explicitly "computer old".


Done For Now

Not saying I won't go back and waste more time on this later. Hopefully I can be happy with this for now. There's a ton of other stuff I need to do and not much time to do it.
12  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.
13  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:
Maya
Photoshop
PRO
  • 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
CON
  • 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:

Code:
<image id="Sailor01" source="Naked" publish="true">
<layer image="PantsPantaloonsDark"/>
<layer image="ShirtLong"/>
<layer image="Sailor01Custom"/>
</image>
<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:

Code:
<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):

Code:
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.
14  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.
15  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.
16  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.

Thanks!

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.
17  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.


Advantages

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.)


Variations


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.


Timelapse

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


18  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.

Quote
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.
19  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!

Quote
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.
20  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.
Pages: [1] 2 3 ... 15
Theme orange-lt created by panic