Post-GDC update

We brought The Witness to the Game Developers Conference and had the game playable privately in a hotel room to select members of the press.

We had to do a lot of work to get the game back into playable condition; a lot of things had been broken since the press tour last August / September. (When you are making sweeping changes to a big and complicated game world, it is pretty easy for things to get bent out of shape). So the GDC served as a good internal deadline to have the game banged back into shape.

I didn't expect a lot of press coverage to come out of this, because at the GDC there's just a lot of stuff going on, a lot of things for people to pay attention to and write about. So I had been doing this mostly as an opportunity to keep the press up-to-date with the game, see how it is evolving graphically, etc. But, to my surprise, we got a lot of coverage. Here are links to what people are saying about the game lately:

First, a video interview on Gamespot (excerpted; we probably talked for 45 minutes or an hour).

Kirk Hamilton at Kotaku finds a musical treatment for The Witness' game design philosophy.

Ben Kuchera at the Penny Arcade Report, with a piece about online distribution channels, and another biz-focused one.

Ben Gilbert at Joystiq, with a design-oriented posting and also a more biz-like one.

Alex Rubens from G4 with an overall preview of the game.

Daniel Starkey of Destructoid, with a preview as well.

As you can see from the write-ups, people seemed to really dig the game. So that is all good.

Keep in mind that, because I am known for my previous game and and the reporters are there talking directly to me, the tone that tends to get adopted in these write-ups makes it sound as though I were making the game myself. That's not the case; there's a good-sized team of very talented people building the game! (This reminds me that we need to update the About page to list everyone who is currently working on the project.)

Playtest; Island Update

Here's how the island looks today:

The current puzzle count is 440.

As expected in the previous update, over the past week or so I went back and worked on the endgame again. I built an original version of the endgame last summer; I had one friend playtest it, and it worked out pretty well, though I felt it wasn't quite epic enough. I didn't know what more to do with it at the time, so I just let it sit, and went to thinking about other parts of the game.

Lately I had more ideas for the endgame, so I went into personal crunch mode and rebuilt into something more epic. This was one of the most productive periods of my working life (maybe the most productive) and I think this area, all taken together, may be the most interesting thing I have ever designed. However, it may be a little too difficult for the player, at the moment! Today I playtested this endgame and one other area of the game, with a game designer friend of mine, and it took nine and a half hours to play through these two areas (6 hours for the endgame, 3.5 hours for the other area). I think this is a little long, so I am going to be tuning these areas and cleaning them up a little bit. This weekend hopefully I can get in some playtest time with Jeff and Casey of Jeff and Casey Time, so if that happens we will see how it goes.

(It's interesting; I haven't done a playtest of The Witness for a while, but I was still thinking of it as a 10-15 hour game, and that's what I tell people when they ask. But if these two areas by themselves, even after being cleaned up, are 6-7 hours of playtime, that means the whole game is ... ... much longer. Sometime in a month or two, I'll do some playtests with people who have never seen the game before, and we'll see how long it really is.)

Meanwhile, on the art side, we've been working on the style of the game; expect a future blog post as we come to conclusions on that.

Tech-wise, Andy has been working on performance stuff. First he made raycasting much faster; til now the game had been relatively lazy about spatial organization. Andy implemented a quadtree for finding entities in the world and enabled k-d tree generation and serialization for casting rays against individual meshes. (We had k-d tree code already as part of a library but weren't using it.) Salvador is working on in-game animation playback, as well as exporting; until now we have been making do without animations, but once this is in the game it will help us with a number of issues.

Dear Esther is out.

[This message is crossposted from the Indie Fund blog.]

Our gift to you, on this very special Valentine's Day, is the worldwide release of the long-awaited game Dear Esther.

If you haven't heard of Dear Esther, watch this:

(Or hey, watch the trailer even if you are quite familiar with the game; the trailer is beautiful and worthy of multiple viewings.)

We expect public reception of this game to run wide: some will love it, and others will be very concerned about whether this thing can be called a game and what that means. So far, this has certainly been the case in pre-release reviews.

Game Informer scored the game an 8/10, saying: "You should consider checking out Dear Esther the same way you’d appraise a film. If you’re interested in absorbing an intellectual story and gorgeous visuals without having to exert a drop of effort, take a chance on this curious experiment."

VideoGamer.com scored the game a 9: "Discovery is such an important part of Dear Esther, especially when everything is so phenomenally pretty."

Meanwhile, Destructoid gave the game a lowly 4.5/10: "It’s as if it wants to be a part of this wonderful medium of ours without asking itself why, which is exactly why you should seek it out and learn from its failures as a game enthusiast, critic, or developer."

We like that there's such a big difference of opinion because it means the game is breaking new ground. It's playing in territory that is not safe; there is no established understanding there.

Dear Esther is a game that no publisher would have funded. Dan, Rob, Jessica and the other associates of thechineseroom have done an excellent job putting together a beautiful game. We are happy to be backing it; we hope you enjoy playing it.

If you'd like more information about Dear Esther, here's an interview with Dan, and here's a link the game's page on Steam.

Update: Dear Esther has been wildly successful, selling 16,000 copies in under 24 hours. As an investment, it reached profitability in 5.5 hours. More details are available at a new post on the Indie Fund blog.

Island Snapshot

Here's how the island looks right now. It is a bit crazy and messy, especially the stuff nearest the camera:

This is because this corner of the world is one of the last areas that we haven't really figured out, in terms of what goes where. There is sort of just some random stuff dumped there right now. That will change pretty soon.

Expect the next few island snapshots to show a lot of big changes. We've reached the point where the basic gameplay is settled, I'm refining many of the specific puzzles, and we've got at least rough drafts of many of the architectural layouts. That means we can start planning the island a bit better. Over the next month or so, we're going to be changing the shape of the island to something a little more geologically plausible, something that carries more information. It's going to be interesting to do this without disrupting the gameplay layout of the island too much.

The current puzzle count is 427. In January I scrapped and re-designed an area and its 60-or-so puzzles. The previous area was inside dark caves, which is a bit cliche, and the gameplay hook that motivated my setting that area in caves, which I had hoped would be cool, didn't work very well. In addition, I felt that the puzzles themselves, while fitting into the rest of the game, were the weakest part of the game. I'd been feeling this way for a long time, but I didn't have a good solution for it til late December. I moved the location and redesigned the puzzles. Now the theme of the location is totally different, has a gameplay hook that works way better than the cave thing, and is very cool. The puzzles situated in this area are also much stronger than before, because I found a way to change the rules of those puzzles to make them much tighter. They'd felt wishy-washy before (people would play through that area and, after finishing, lack clarity on what the puzzles were saying. That's no good.)

We certainly could have shipped the game with the old area in the caves with the old puzzles, and probably shipped the game at least a month sooner, but an important skill in building a beautiful game is knowing when something just isn't good enough.

Next I am going back to the endgame, which I did my first pass at last summer sometime; I've got a gameplay hook to add which I think will bring it over the top and make it extra-good. I'll be working on that over the next few weeks while also working with the landscape architects on the island revision.

Also, we've got a new programmer starting soon (this week or next!) Combined with our other new addition, who's been here a few weeks (Andrew Smith, ex-Zipper and -Oddworld; hi Andy!) we will have quite a bit of tech manpower to bring to bear on finishing this game.

The trailer for Dear Esther is out now.

If you're interested in arty games that push the boundaries of what games are doing, you may be interested in Dear Esther, which will be released on Valentine's Day of this year (much sooner than The Witness will be!)

The trailer has just been released:

See more about Dear Esther at the official site.

This will be the second Indie Fund game to release. Just a few days ago we announced that Q.U.B.E., the first funded game, is already a financial success. It appears obvious that Dear Esther will be as well.

Engine Tech: Concurrent world editing

Summary

A small team with limited manpower, we wanted a low-effort way to use our existing version control system (svn) to facilitate concurrent world editing for our open-world 3D game (i.e. we desire that multiple users can edit the world at the same time and merge their changes).  We developed a system wherein the data for each entity is stored as an individual text file.  This sounds crazy, but it works well: the use of individual files gives us robustness in the face of merge conflicts, and despite the large number of files, the game starts up quickly.  Entities are identified using integer serial numbers.  We have a scheme for allocating ranges of these numbers to individual users so there is no overlap (though this scheme could certainly be better).  The system seems now to be robust enough to last us through shipping the game, with seven people and one automated build process concurrently editing the world across 18 different computers.

We don't know whether this method would work for AAA-sized teams, though it seems that it might with some straightforward extensions.  But for us the method works surprisingly well, given how low-tech it is.

Continue reading

Architecture in The Witness

This summer, we began working in earnest with architects, to bring further sophistication to the design of locations in The Witness.  Before this time, we had a game that was fully playable, but buildings and the areas around them tended to be placeholders, developed only enough to make the basic gameplay possible.  We began working with two architecture firms, FOURM design (for buildings and such), and David Fletcher Studio (for landscape architecture).  Both firms are located in the Bay Area, so it's easy for us to meet regularly.

When we sat down to start working with the architects, one of the first things we did was put together a history of the island where The Witness takes place: how long has the island been there?  What groups of people lived there, and what kind of structures did they build?  How did later civilizations use the structures built by earlier groups?

Quickly we developed a running theme of sites that are old and have over time been used in two or three different ways.  When entering a new location, you probably first notice the most basic elements of its structure: where you can walk to easily, versus where you can't; what puzzles or goals are calling for your attention, and what walls or doors might be preventing you from getting to them.  If this is all you care about, you can then play through the area in a very utilitarian fashion.  But if you have an eye for detail, you may notice the elements of modern construction shoring up the design of an older structure with a different purpose.  The design of the new structure tells you something about what the newer guys were doing there, and how it differs from what the older guys were doing there.  And if you look really closely, you can see traces of the original footprint of the site (perhaps these are very subtle, some bricks just rising above the dirt in a few places), and infer the purpose of this very old site too.

If you see the different civilizations that came to this island as embodying different philosophies; and you see the structures they built as representative of the way these philosophies led them to interact with the world; and you see further that when they replaced a site, it represents the rejection of some older worldview that they consider no longer useful, then perhaps you start to get some idea of the amount of backstory that can be encoded into the world, nonverbally.

All of this backstory is also directly relevant to the main story -- who you are, why you are on this island, how you may get back home.  So, to put it another way, the game is constructed so that the more you pay attention to tiny details during your travels, the more insight you will have to the central story, even though it may not be obvious at any given time what a particular detail has to do with that story.

Having smart architecture, it seems, really helps this process work, brings it alive.  If you build a game where people are supposed to pay attention to details, but the details are wrong or naive or just don't have much thought put into them, then at some level the game just won't work.  Even if you don't know the first thing about architecture, you have been in enough buildings in your life that the deeper parts of your brain have distilled plenty of patterns about those buildings.  Your brain knows the difference between a real building and a nonsense building that wouldn't occur in the real world.  It can feel the difference in veracity between carefully-thought-out structural details -- on the one hand -- versus stuff that was just placed by a level designer to look cool.  When I showed a recent build to a friend, who had already played an earlier build of the game, he said the new structures made the game feel deeper, more serious.

I was a little surprised by this statement but should not have been, since really, that is what we are aiming for.  Thoughtful design of these structures and landscapes gives the game further gravitas.

The most-recent issue of Game Informer printed an article that showed some of the first screenshots of the newly-architected areas appearing in the game engine.  It is an interesting article; pick up the issue if you haven't!  They also put up a companion article online (but which not as extensive) here:

(Summary article at Game Informer)

The area featured in this article is the one that we have taken furthest so far in terms of modeling and texturing.  Here are some other shots of it:

The Keep, before and after


The Keep, close-up 1


The Keep, close-up 2


The Keep, close-up 3


We've done basic planning for some of the other areas, so I thought it would be nice to show some screenshots of work in progress.  For each of these, there's a 'before' version (when we had a fully-playable game, but basic placeholder structures) and after (once we have incorporated the architects' designs, revised the site plans and in some cases even the puzzles, etc):

 

The Compound, before and after


Glass Factory, before and after


Peninsula, before and after


Vault, before and after


Don't regard these "after" images as representative of what the game will look like!  They are still works in progress, and the final game will look substantially better: scenes like these will feel richer due to the placement of detail objects, further care put into the texture mapping and lighting, refinement of the still-rough-drafty terrain features around these structures, and many other bits of subtle game development magic.  But I wanted to show these now since they provide a good taste of the game's flavor, and they show how much structural intelligence is brought to the table by working with the architects.  Yes, we could have started with the placeholder structures and made them more elaborate and better-looking, in a general video-game-level-design way, but that's different from having well-thought-out ideas subtly embodied in the structures of the areas, which is what we are going for.

My Screenshots folder

From time to time I take screenshots, to send in email to other team members, or for the architects' reference, etc.  Today I glanced at my desktop and noticed it looked pretty cool.  So here it is (with some shots, that seemed a bit too spoilery, redacted):

 

New game: Q.U.B.E. will be released on December 16th.

In addition to working on The Witness, I am a partner in the Indie Fund, a group of successful indies who finance imaginative indie games under developer-friendly terms. Our fund has been around for almost 2 years now, and I am happy to announce that our first funded game is about to be released. It's a first-person puzzle game called Q.U.B.E., made by some guys in England called Toxic Games. They are just out of school, this is their first game, and they managed to make it without a programmer!

 

Q.U.B.E. will be available on Steam.

(Web site for the game)

(Indie Fund announcement page)