Update!

I am working hard on puzzles right now. We've had figured out, for a while, the basic set of locations you can travel to on the island, and what the puzzles are in each. These locations were defined to varying degrees of specificity, though. Sometimes we know what the puzzles are, exactly (they are all designed and implemented) but aren't sure what the architecture is. Sometimes I have concrete ideas for some puzzles but only vague ideas for other puzzles, and it's a case of "I will fill these in later on, when I have time to think about it and come up with something good here; but it is pretty clear to me that there will be something good here, so I am not worrying too much about it."

Eventually, these things have to be figured out. Over the past month or so we've done some of that figuring. We nailed down the architecture for a couple of areas (including the all-important area where the player starts the game). We've done this in a way where the architecture and the puzzle ideas have synergy, which is always nice. In particular, there was one location that, from the beginning of development, was basically a big box with a window cut into it and some puzzles stuffed inside. For a long time (maybe 2 years!) I was never sure what to do with it, but eventually the architects suggested an idea for that location. I mocked it up and didn't like it. They suggested another one. This one sparked an idea for how to make the structural properties resonate with the puzzle theme, and when I built even just a rough-draft of the building, I found the result to be strong. Lately we've been finalizing that location too.

So anyway, there are all these spots on the island that represented vague ideas, with puzzles there that were just in rough form, or that weren't even implemented fully, but just served as reminders to do something there. I've been going through and filling in a bunch of those.

I have also been working with some other puzzles, which seemed "done enough to ship", and thinking hard about how to make them better. Braid benefited from a lot of this kind of attention -- a lot of games would have shipped with just early versions of the puzzles in that game, considering them to be just fine; but the more I worked with the puzzles in Braid, the more I found better, simpler, more-to-the-point versions of them. The same thing is happening here (though The Witness is a much bigger, more-complicated game, so sometimes it is challenging to get to that same kind of clarity.)

With regard to the visuals (modeling and texturing), things have been coming along nicely as well. Pretty soon a high-profile game magazine will publish some screenshots of one of the most-finished areas of the game, showing the look we are targeting and giving a strong hint of what the game will be like stylistically. When the magazine is out there we will link it here.

(This has not been a particularly coherent update; just wanted to let you all know what is up!)

Designing to Reveal the Nature of the Universe

This talk was presented by Jonathan Blow and Marc ten Bosch at Indiecade on October 7, 2011.


Any system of interactivity can of course be explored: If X happens, what are the consequences? What are all the ways in which pattern Y expresses itself, and to what do those expressions lead? By inspecting the structure of a system in this way, we can find the core ideas of the system, and see how those ideas illustrate fundamental truths of our universe. We present a game design aesthetic that values looking for systems that express these truths in the cleanest possible way. We explain how this is different from more-traditional combinatoric design techniques; we show examples from our games and describe a method for applying the aesthetic in general.

Here's a link to the Indiecade page, on which there's also a presentation by Richard LeMarchand, and more to come.

Thanks very much to Ida C. Benedetto for recording the talk!

Saying hi.

Hi everyone. We haven't posted anything in a while, but this is just because we have been working intensively on the game. These days we are doing a lot of working with the architects, integrating their designs with the gameplay. The result is coming out really well -- the architectural designs add tremendously to the feeling of being in a world, and they also give us opportunities to make the puzzles richer. So as we do this the game just keeps getting bigger and more sophisticated.

I'll post something more concrete before too long, but I wanted to at least say something, since it's been a while.

Team-wise, we have just hired two people (a 3D artist and a programmer), and we plan to hire another programmer as well, once his visa clears and he can get into the country. This is a pretty big staffing-up, percentage-wise, and will allow us to make things quite nice. The new folks will be starting over the next couple of months (they need to wind down the things they are working on currently!)

Island Snapshot

It's been a while since we did one of these:

The current puzzle count is 350.

Some parts of the island are pretty messed up in this screenshot. For the press tour, we made sure the whole game was more-or-less solid and playable. Just after that, though, we were free to tear things apart, move things around, change the sizes of areas, add new areas, and all that. We're still in the middle of that process and not everything has been made playable again.

A pleasant lightmapping update

It's been a little bit since the last post. We have been busy doing a lot of good things with the game. Here's one of them: Ignacio just got back from vacation and implemented a simple lightmap encoding idea that improves the color resolution of our lightmaps, removing banding, like so:

The difference is not too pronounced in this scene, but with smoother-colored textures it becomes a lot more obvious (and I do want to use more smoother-colored textures, art-direction-wise!)

The situation is, the lightmaps are HDR (for some definition of "high"), so we needed a way to encode those values reasonably into a bitmap. We were using RGBM where M is just an overall brightness factor; you read RGB from the texture then multiply by M to get the output color. We used to just encode this naively, but the problem is, when M is less than 1 then it actually kills precision in your RGB, so the solution is, well, don't ever let M go below 1; just clamp it. This is not rocket science and in fact is the kind of thing that is a little funny, as one starts wondering why we didn't think of that a long time ago, but hey, that's how it is sometimes. The results made me happy, though, so I am posting them.

The improved image quality may enable us to have higher dynamic range throughout the game (this is probably something we will evaluate later on), which would be very nice!

Previews of The Witness are now out there.

For the past couple of weeks I've been showing a preview version of The Witness to various folks in the press who were interested. Typically I just have them sit down and play for a couple of hours, from the beginning, with no guidance from me; afterward, we talk about what they just played.

Previews of the game are now being published, and readers of this blog have been asking for gameplay details for a while. So it seems like a good idea to list the previews here. I'll keep updating this post as I find more.

(Sometimes these previews, from the way they are worded, make it seem like I made the entire game with my own bare hands. That is not the case; it's just how this kind of article tends to sound. There are a number of people working on this game, who have creative input in various ways; see the About page for a partial list!)

Irradiance Caching – Part 1

This is the first article I wanted to publish when I started writing about the technology behind The Witness. I had just spent a week or so implementing irradiance caching with rotation and translation gradients. Extending the equations of the gradient estimation to the hemicube sample distribution had proven to be tricky and had taken me a considerable amount of effort. So, I thought it would be cool to document my derivation, so that others would not have to do the same. However, for that article to make sense I first had to provide some background, hence the previous two articles:

Unfortunately, by the time I was done with these, the work I had done on the gradients was not so fresh anymore, which is why it has taken me so long to complete this article.

Continue reading

Tree Update

I've been trying to refine the trees to look better, and I'm fairly happy with the results so far. All too often, game trees are using many tricks to make em look good. Because of that, the geometry often looks like a mess (unless it's really high poly). One thing I tried to do is make the basic geometry look fairly good, so that the lightmap would make the tree look nice without just revealing ugly basic geometry.

Here's some screenshots I just took. Here is a group of trees without a lightmap. As you can see, the underside looks pretty flat and boring, and it's hard to see which limbs are in front of others.

Here's the lightmap just by itself. While you can see a few lighting artifacts (like where the cross trees cross), overall the trees look pretty good even without diffuse textures.

And here's the final. As you can see, the underside has a lot more definition to it.

Once I get some LOD's I like, I'll write up another update.