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

Login with username, password and session length

Advanced search

1028266 Posts in 41277 Topics- by 32895 Members - Latest Member: Molinware

July 30, 2014, 05:18:31 PM
  Show Posts
Pages: [1] 2 3 ... 17
1  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.
2  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.
3  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.
4  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 22, 2014, 10:16:22 PM
Do you have any concerns that a lack of proper video quality on videos of the game will make it appear differently/uglier to people experiencing it for the first time on Youtube?

Yup! I'm experimenting now with ways to fix or at least improve the compression results. The main culprits are the contrast and the dithering - two cornerstones of the look I'm going for.  Grin
5  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 22, 2014, 09:47:24 PM
Will you be using any other colors for effect in game (emotional effect - not like tinted yellow because of a yellow light)

The whole game will be just 2 colors, but I may have selectable palettes or something for those 2.

Now, this might make me a bit unpopular in this thread... but to be honest, I'm not quite sure yet what to think of the 1-bit style. [...]

I think part of the problem is the small relative size of the gifs. Stretched to fullscreen you definitely wouldn't say the resolution is too high Smiley. Try watching the in-game hand footage (switch to 720p) at fullscreen to get a better idea.

In motion the 3D all looks perfectly correct, which is probably also breaking the "old" look, where you'd expect more projection or accuracy errors. So as you say, it's a filter applied to standard 3D rendering and that's not something I'm fighting against. My goal is to take something you'd see on a Mac Plus (not DOS) and move all the engine stuff to modern realtime tech while leaving the display tech at 1-bit.

Personally I think the 1-bit restriction, low resolution, inverse-lit wireframes, and exactly-one-pixel-wide lines give the game a very different feel to other b&w and wireframe-style games that have been released (Antichamber, Unfinished Swan, Within). But that's an opinion from the most biased person in this thread.

(Sup Andrew! Say hi to your bro for me.)
6  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 20, 2014, 11:40:45 AM
Don't know if it helps, but did you take a look at how they handled it in Trespasser? It's the only game I know with a similar arm controlling feature and although it was clunky at times, I really liked it back then. Smiley

I played a lot of Trespasser back in the day and I think their arm is why you don't see hand+environment interaction much in games these days. Smiley
It was a fun game but probably for the wrong reasons.

The arm is fully automatic in Obra Dinn, which means I have more control and can hopefully make it look less like a long thin noodle swinging around the screen.

I'll go back and watch some TP vids though to see if there's anything useful there. Thanks for the suggestion.
7  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 20, 2014, 11:13:47 AM
The way your arm stretches out to reach at items feels a little bit too straight, as if you're stretching your arm as far as the elbow can go.

Yeah you're right. It's still bent 10 degrees at its straightest but the elbow is aimed directly away from the camera so you can't really tell. This is one of the issues with trying to get the arm to look ok with the FOV but also be able to interact with the environment. Normally your view weapons/hands can be in their own little world and don't need to reach out and touch stuff so you can mess around with forced perspective more.

In this case I think the tube-like modeling on the arm wasn't doing any favors. I don't think I can ever completely get rid of the "long pole" effect of the FOV but I added some detail and it helps a little.

8  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 19, 2014, 09:04:23 PM
Hand Tweaks

Made a few updates already to improve things a bit:

  • Added an intermediate "curl" animation between touching and gripping. This makes the fingers curl around the handle a little more naturally.
  • Slow the player's movement down after they touch the handle. I don't know why I didn't think of this earlier. It always bothered me that you can zip around while the IK is gripping the door. Much better now.
  • When gripping the handle, set a max speed for the blends so the hand doesn't snap closed. When releasing the handle, it's still only distance-based to keep the fingers
    from passing through the handle.
  • Keep the elbow bent a few more degrees at its straightest configuration.


(with a touch of slo-mo)
9  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 19, 2014, 12:51:07 PM
Hah. I need to pay more attention to how many messages are on a page. That's not the first time I've posted at the bottom of a previous page.

It seems like the hand doesn't have a "grabbing animation", will that be fixed because it currently looks like the hand is sticking to the doorknob, instead of looking like the smooth arms movements?

The hand does blend from touching to gripping, but it's based on the palm's distance from the handle. I guess you'd call that blend a grab - the fingers close around the handle. When walking up to the door quickly, you won't see much of the touch frames and the gripping happens in just a few frames. I set it up like this to match how I grab a real door handle. I don't slowly grasp it; my fingers slip around it as soon as possible. In-game, it feels pretty good in practice.

But maybe the way the arm points at the doorknob could be a bit more relaxed, it felt a bit stiff. But overall it looks really nice, and it would definitely work as is.

There are no indications that an item is usable, the only clue that you can interact with something is seeing the hand point at it. Since it's actually functional, I figure it's better to make the pointing part clearer and give up some of the naturalness. You're right that it's a bit stiff though so I may tweak that balance a little bit later.
10  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 19, 2014, 11:24:05 AM
Player's Hand

The player hand stuff is finally done for now. That wraps up the groundwork for all the major technical features in the game. From here it's hopefully just about filling in the content and dealing with the occasional technical hiccup.

At some point I noticed that the development of this feature followed the trajectory of an entire game. It started with an idea I was excited about, had a fairly rough implementation up and running quickly, then spent ages adding features, running into problems, and polishing the results. A sharp peak at the start, dropping into a long valley in the middle, and a slow climb back up to the end. Game development is a fractal.

The timelapse is over 30 minutes long so props to anyone that makes it through. Recording it kept me focused, but I don't think I'll do another timelapse like it any time soon. It's a lot of extra work to annotate and I personally prefer text and pics over video for explaining stuff. The way everything is a video tutorial these days drives me nuts.

If you check the final in-game footage, you can see how bad the dithering looks when compressed onto YouTube. I think this is a serious problem so I'll experiment with ways to get that looking better. Maybe less contrast in the two colors, a special non-dithering mode, or something else that compresses less terribly.
11  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 10, 2014, 07:24:01 PM
But can we see our feet? Durr...?

I've never seen feet that look good in first person and I don't feel up to tackling that myself -> No feet!

The hand/arm isn't just cosmetic so I feel the payoff is better anyways.
12  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 07, 2014, 08:25:33 PM
what happens when you go 1440p or 4k? Some of the classic retro "high resolution" pixel art effect will surely get lost?

As of right now, the resolution is fixed at 640x360. In fullscreen it's scaled to fill the monitor and you just get bigger pixels. The main thing that breaks down at that size is the dithering, which is why I'm focusing on reducing it at much as reasonably possible.
13  Feedback / DevLogs / Re: Return of the Obra Dinn on: July 07, 2014, 01:09:56 AM
How have you been planning the project from the highest level?

I started with a rough mental picture of how the entire game would play out. Visuals, mechanics, progression, events, story elements, etc. Then I just sit down and start picking out bits that I want to work on. I guess that's a big advantage of working alone. I can jump around between tasks to keep myself interested.

Do you have a master plan you set out with, or are features and solutions more ad hoc?

Yeah there's a master plan but big parts usually end up changing as I go along. Gameplay mechanics are the big question since I don't know if those will really work until they're implemented. For this game in particular, I have an idea about the core mechanics, and some confidence that they'll be ok but, there's always the chance they won't work and I'll need to come up with something else.

Do you use any bug tracking software or service?

Not yet. I just use git for version control. I'm not a huge git fan but SourceTree makes it bearable. For Papers Please I set up a FogBugz account for bug testing near the end. I may do that again or I may figure something else out. I don't remember being either impressed or disappointed with FogBugz.

Do you find yourself dividing time between work and personal life, or is your mind pretty much always on the project?

More and more these days I have to divide my time. Recently I've spent a lot of time on Papers Please - creating the Steam trading cards, dealing with support issues, and making a new build to fix some compatibility bugs. I also have a fairly packed personal life and working from home means that it's hard to find long uninterrupted stretches to work. A big part of how I work is based on speed though. If I spend too long on a project I'll lose interest and end up with an unfinished game. And even when I'm not physically working on the game, my mind is always thinking about it. Maybe that's why I get burned out so fast. I seriously cannot stop thinking about the game until I'm completely sick of it. That takes 6-9 months. The clock is ticking.

Hand Reaching

So despite having other stuff going on, I have been pecking away at the hand-reaching implementation. I thought it would be interesting to record a timelapse of the entire construction and coding of this feature. It's not done yet but it's close. Hopefully I can post that in a day or two. Here's a lame teaser:

A door. What wonders lie behind.

The idea is that the game won't have a HUD or item highlighting. Any interaction with the environment will happen using the player's hand. Most of the time the hand isn't visible, but if you get near something interactive, you'll reach for it. Get within range and you'll grip it or hover it. Click the mouse button and you'll open/pickup/etc whatever it is there. So all the interaction is context sensitive.

There's some pretty big limitations to this approach that I'm hoping I can plan around.
14  Feedback / DevLogs / Re: Warboat (Local Multiplayer Boat Battle) on: June 30, 2014, 03:27:57 AM
This looks like a lot of fun. I especially like the clear and direct mapping of the controls onto the character. Should be very easy to pick up and play - great for a 4-player local shooter.

One small suggestion is to add a trail effect to the cannons so their origin & path are a little clearer.

Warboat is the best possible name.
15  Feedback / DevLogs / Re: Return of the Obra Dinn on: June 25, 2014, 08:19:12 AM
Reading about all your experiences with Maya makes me wonder why didn't you just use Blender (which you seemed to like).
I love the art style, but I'm even more interested in the story and gameplay hook, which you mentioned but didn't want to talk about yet.
Your devlogs are a great inspiration! Thanks for sharing your process.

For this project I want to try paid software for everything in the critical path. Especially with the new reasonably-priced Maya LT. I've used and enjoyed Blender, but it still had issues related to being free software.

Story, Gameplay, & Spoilers

I'll wait a big longer before going into the story & gameplay. And it's a good thing I haven't said anything about it yet. My core mechanic ideas have already changed quite a bit since starting. I haven't prototyped anything gameplay-related yet either so it could all change some more. What I've got in mind now seems ok enough so the next steps will be to prototype it. If things work out, I can start fleshing out the narrative using that mechanic.

Actually, revealing the core mechanic will ruin a large surprise near the start of the game. Part of me wants to keep everything secret until I release. But there's not much point in running a devlog like that so the core mechanic will become public when I start prototyping it. The full story will likely stay mysterious until the final release though. Similar to the Papers Please dev process I guess.

Technical Features

I mentioned in the OP that I want to experiment with some technical features. At this point, there are 3 of these:

  • 1-bit rendering
  • Walking simulation
  • Hand-reaching environment interaction

The rendering is mostly taken care of. I'll be tweaking things for a while but the basics are done. The hand-reaching (not around) I'll describe in detail a little later. I worked on the walking today.

Walking Simulation

Sound will be a big part of creating the atmosphere and filling in the holes left by the visuals. One of the things I want to get right is the footsteps across the wooden ship. The game won't have a run button (the ship is too small for it), so the player will be plodding along everywhere. I thought it would be fun to make a simple little simulator to drive the footfalls, scuffs, and head bobs. Something to tie them all together in a logical way. Here's what I came up with:

Walking sim foot discs

There are two discs, one for the left foot and one for the right foot. The circumference of each disc matches the player's stride of 0.5 meters. As the player character covers ground in the game, the discs "roll" along the ground.

In the gif, each disc has a red arc that represents when the foot is on the ground. The bottom of the discs are resting on the ground, so when the red is down, the foot is down. As the black hole passes over the bottom, the foot is in the air. The "foot" of each stride is connected by the line. The dot follows whichever foot is higher. The left foot always leads (for now) and the right foot follows behind. When the player stops walking, the discs return to their natural orientation with the hole at the top.

So with this simple sim, I can attach some events:

  • Red arc first touches ground point -> Foot fall
  • Red arc just leaves ground point -> Foot rise (scuff)
  • Center dot -> head bob
  • Disc speed -> effect volume

The only input to the simulator is the delta of the player's position. There are two neat tricks that make this work well:

1. The radius of the discs starts out small and gets larger quickly as you walk. This isn't visible in the gif, but the idea is that you take a few small steps as you get up to speed. So the initial stride may be 0.3 meters before you're at top speed of 0.5 meters/step. This is simple to model by just changing the disc radius.

2. The y coordinate of the player position delta is scaled by 3. This makes the sim think you're covering much more ground when going up or down slopes and stairs. The result is that the player takes quicker steps in these cases. You can see it in the gif as the screen gets darker when I go down some stairs. It also adds little extra quick steps as you go over small bumps, which is a nice effect.

It's only been tested with temp sounds right now; I'm curious to see if it holds up with proper foley sounds. I expected to spend a few days on this but ended up happy enough at the end of one day that I'll move on to the next tasks.
Pages: [1] 2 3 ... 17
Theme orange-lt created by panic