Thoughts on Consoles and Certification Processes

Last weekend I wrote an email to Kyle Orland of Ars Technica in response to a question about an independent game's certification troubles. That letter was quoted in this article, which was then summarized by gameindustry.biz, and is probably floating elsewhere around the internet too.

The original letter went through a few examples of specific issues of certification and how they could be handled better, to help substantiate why I think these processes are so broken. These are not the kinds of details you would expect to make it into a short article for a general audience, but having typed them up, I think some people out there might be interested (especially developers who have not done console games before but are thinking about it). So, below is my original letter (edited a little bit for clarity):

-----

Hi Kyle,

I have gone on record a number of times, saying that the XBLA certification process makes games worse rather than better. But that is a pretty old experience for me now (4 years ago), and they are unlikely to change any of that stuff until the new console comes out anyway. Keep in mind that the Xbox people as a whole do not think of XBLA as a high priority (you can get a glimpse of this from the E3 press conferences, etc).

But, I think the more important issue applies globally, to all of Microsoft, Sony and Nintendo (and not just to smaller downloadable games, but to every game regardless of size). The certification processes of all these platform holders were based on the idea that all these steps they test are absolutely necessary for software to run robustly, and that software robustness is super-important for the health of their platform and its perception by customers.

But, look at iOS. There is almost no certification process for iOS, so by the Microsoft/Sony/Nintendo theory, the apps should be crashing all the time, everyone should think of iOS as sucky, etc. But in fact this is not what is happening. There is no public outcry for more testing and robustness of iOS software.

Part of this may be that iOS software is so easily patched; so maybe a heavy cert process made sense back in the disc-only days, but as we go into the next console generation it becomes unnecessary. But something tells me that Microsoft/Sony/Nintendo are not really going to let up on cert, even though they say they will. It's just "not in their DNA" as they say. The proof of this is the bizarre over-complexification that already happens with console games today, and is baked into the current certifications, that any of them could easily fix, but none of them do, because they don't care.

For example: every single game is REQUIRED to say on startup, "sometimes this game saves, when you see this animated icon in the corner, DO NOT TURN OFF YOUR CONSOLE, etc". This is something that developers have to implement and that has to be tested, which costs significant time and money, but worse than all that, it impacts the user experience, because the startup of the game becomes just a little more bureaucratized, and also -- this is supposed to be a fun experience, so why are you issuing warnings and strict instructions? (Just one thing like this may not seem like too much, but combined with everything else, it is a lot; I am using it as just one specific example).

Why is this DO NOT TURN OFF YOUR CONSOLE warning there? It's because if the game is saving a save file, overwriting an old one, and you turn off in the middle, you might corrupt the saved game. Well, guess what... the solution to this is to IMPLEMENT A MORE ROBUST SAVE SYSTEM. You save the new file next to the old file, flush the I/O, and only delete the old file once the integrity of the new one has been verified (or just don't remove it, and keep two copies of the save at all times). On load you just make sure you load the intact save file if one is corrupted. This is not hard to implement; I did it in Braid. But if consoles cared about this kind of thing, it would be built into their basic save-file API, so that it would always work perfectly and no developers would ever have to think about it.

If they did this, there would be fewer things to certify, certification would cost a little less and take a bit less time. Let's say you save 3 days of development and testing per game (this is conservative; the real amount can be substantially higher when you factor in the discussions and coordination about how the save notice should look, etc). Now add up how many games have been released just on the Xbox 360, multiply that number by 3 days, and what you get is probably OVER A DECADE OF DEVELOPER TIME that was wasted. Just on this one little requirement. For something that should just be built into the system by one person in a couple of weeks. Okay, that was only the Xbox, so now add in all the PS3 and Wii games, and see what a huge waste of time that represents.

Like I said, just this one thing by itself would not be too bad, but it is only an example. Another example that all three certification processes have is the "title-safe region" restriction. This basically means that you are not allowed to draw text or gameplay-critical information near the edge of the screen (about 10% of screen width in a margin around the edge) because you don't know if the user's TV is displaying the whole picture (even modern HDTVs often cover the edge of the display with a bezel or else just crop it entirely, which is completely stupid).

Okay, so at first blush this seems to make sense, so to make sure players can see everything, we have to go through each screen and each mode in every game we ever release and certify that important things don't get drawn too far toward the edge. Well, as you can extrapolate from my previous example, this also has wasted DECADES OF DEVELOPER TIME (probably many decades, because dealing with title-safe probably takes a lot more time than save/load). And it is also something that these consoles could handle at the system level if they actually cared about the problem. Just put a screen calibration menu in the dashboard, and then initialize it properly so that players would almost never need to use it (when they are using HDMI output, initialize the settings using the display's EDID; if they are outputting a different way, just default to shrinking the display a little bit).

10% at the edges of the screen may not sound like much, but it is actually huge. Suppose a game is rendering at 1280x720... you are only really able to use the interior 1024x576, with everything outside that just being decoration. 1280x720 is 921600 pixels; 1024x576 is 589824 pixels, in other words, you only get to use 64% of the screen area for real! Everything outside that is only allowed to be decorative. You know how the 360's new Metro interface seems to use an absurdly small amount of real estate in the middle of the screen? That is due in large part to title-safe region. You know how games always seem to have their HUD elements placed too far inward when they could be nicer, further off to the sides? Same.

This would also have the benefit of saving work for most people who implement 2D games. In Braid we had to program a screen calibration menu. I notice there's one at the beginning of Dyad, and one at the beginning of PixelJunk Shooter. For God's sake why??

This makes all games worse all the time, and makes developers have to do a lot more work, but ultimately could be fixed very easily by any of the platform holders. They just don't care enough to do it. I think they will have a hard time getting rid of these rules because bureaucracy is in their DNA.

These are just two examples of many... I am going to stop ranting here, but this is just the tip of the iceberg. Most certification requirements are like this.

The edge that both Apple and Valve have going into the future is that they both genuinely care about the end-user experience and want to make it as good as possible. (Their end-user experience is already way better than any of the consoles and they are always working to improve it). Which coincidentally seems to be the place that these consoles are handicapped due to their corporate culture. Can anyone look at the current 360 or PS3 dashboards and legitimately say that those are products of an entity that deeply cares about user experience?

A question a lot of developers have is: When the 720 / PS4 get launched, how many people are really going to care and buy games for those systems? Obviously some people will, but if it is less than bought games this generation -- which a lot of developers think is very possible -- then look for a "peak oil" kind of crash where a lot of too-big publishers and developers fight over a shrinking market. If the actual way the next-gen consoles work is much like now, they will be a functionally archaic in the marketplace (keep in mind that they have to compete with the iPad 4, 5, 6, 7, 8, and 9. Have you got any idea what the iPad 5 or 6 are going to look like, how powerful they are going to be, what other user experience benefits they are going to have? I sure don't.)

-----

A few days after having written this letter, I just have one more thought to add: I know that Microsoft thinks they are fixing these issues with their next console, and creating an environment more suitable to free-to-play games and downloadable things in general; I assume Sony is thinking similarly. I will be very surprised if either of them succeeds in fixing these problems. Large institutions always undercorrect; they always think they are being radical and risky when in fact they are doing something tame that is just a modified version of the status quo. When large institutions need to change course by 95% in order to do well, even if they know it's an emergency and are totally panicked, they can probably only manage about 35%. For recent illustrations of this, look at Nokia and RIM (or, uhh, look at the large governments of Earth in dealing with global warming).

So I would bet that Microsoft and Sony believe they are streamlining their online stuff, because they are implementing an expedited, simplified cert process for patches and content updates, or something, and that because of this they will be in a great position to compete with Facebook and Apple and Steam and whoever. Whatever they do is very likely not to be enough. Their competitors are not stopping either. (Steam, which was already pretty painless in terms of updating games, recently revamped their system; the new thing is way better than the old thing, which was already way better than what the consoles do.)

Fun With Subtitles

Lately I have been doing some difficult puzzle design. Today I woke up and wanted a break from that, so I decided to nail down one of the loose ends that hadn't been thought about yet: displaying subtitles during the in-game voice recordings (of which there are a lot).

Originally I wasn't sure whether I wanted to implement subtitles or not. It's important to me that the game have an overall aesthetic that contains no visual language. I was worried that if we were to draw subtitles for people who don't speak English, it might ruin this. But, a year ago, I was talking to a friend who has experience in film, and he convinced me that people just understand that subtitles are a different thing, that they are a layer on top of the game or movie or whatever.

So, I am implementing this, and maybe it's good, because if I had been hard-line about things, it would mean that most people in the world would not be able to understand the recordings. That's not terrible, because they are not necessary to complete the game, but as long as I don't feel like, ultimately, the subtitles are ruining things, it is probably better to have them.

(It's going to be an interesting time when I go try to implement the main menu without any written words...)

It's been a very productive day. I implemented the basic subtitling system in less than 3 hours (making a subtitle data file for one of the voice tracks, loading it, detecting in-game when a voice track is playing, finding the appropriate piece of subtitle for the current time, and drawing it on the screen). Here's the result:

The data file is a very simple format that I just made up. Taking my experience in making Braid multi-language, and looking at the kind of text we will be dealing with in The Witness, it was clear that I needed a format that was mostly about the text, with very minimal markup. Right now the main markup we need is just "which recording is the following text for" and "what time in the recording should the following lines be displayed". I can imagine that later on we will add some more features to it, but probably not many.

Since The Witness inherits code from Braid, we already have handling for other languages in our font rendering, so I pumped the text through Google Translate to test a couple of other languages:

If you are playing in English, subtitles are OFF BY DEFAULT. It amazes me how badly many games handle subtitles, most notably, that a great many games seem to have voice acting in English and then also default to subtitling in English. This is terrible because people read at a different speed than they listen, and they probably read faster. It ends up dividing peoples' attention in a weird way. I don't know why so many games do this except that they aren't paying enough attention to user experience. So to have a good experience you have to go turn subtitles off, but sometimes that doesn't even work! A couple of days ago, I was playing Xenoblade Chronicles, and when I turn off subtitles, only about half of the subtitles in the game go away. Apparently there are two different classes of subtitles and one of them you cannot even turn off! I think they never even tested it...

Island Update

Here's how the island looks now:

The current puzzle count is 415 (I think we have been over-counting a little recently; this is a more-accurate count).

In case you missed it, I did a live Q&A with Chris Hecker of Spy Party today on Kotaku.

In terms of world-building, lately Luis, Shannon, Eric and Orsi been doing a few things: (1) revisiting the most complicated areas in the game and making them playable with something resembling shipping art assets [until now they were playable only with placeholder pieces]; (2) starting to figure out what the game will look like, outdoor-wise; (3) stuff I can't spoil in a post like this.

On the tech side Ignacio is working on optimizing the game, as often. A big part of this has been working on the mesh LOD system, but he's also looking at performance issues related to specific subsystems like grass rendering. Salvador has done a bunch of work on asset streaming, which seems to be pretty solid so far. Andy made a number of improvements to the collision system and audio system, and has now started work on an OpenGL port of the rendering, which, when done, is a big foothold toward portability to other platforms besides Windows.

The audio guys, Andrew and Geoff, have done some really nice stuff in terms of sound. The audio aesthetic for the game is starting to come together. We have lots of rad footsteps and are doing some very interesting things in terms of environment sounds.

This is not a comprehensive account of everything everyone's been doing; it is just what leaps to mind!

Meeting Photos

Every week we have a meeting with the architects where we plan the structures and landscapes on the island. Most of the week, the architects are generally off thinking about this stuff while we are building the game. During the weekly meeting we get together, talk about what concepts the architects have come up with, figure out how those might integrate with the game, make decisions about which ones to pursue, and iterate in detail on concepts we have already decided to pursue.

A while back we took some photos of this meeting, so I figured it would be fun to post them.

Here we are looking at a number of different possibilities for one of the areas in the game. I had already done the gameplay design, so we had a working location that was built out of blocky programmer stuff (if you see blocky things in the island update screenshots, it was something like that). So we knew the general shape of what we were trying to build and how it had to behave; the architects started with that and made proposals about what the location might be like in terms of its basic construction.

We chose one of these ideas and iterated on it a while. Other concerns, having to do with the overall layout of elements on the island, then caused us to change the size and shape of this location; once we had done this, the original design was felt to be a bit weak at the new size and shape, so we went back and heavily modified the concept. Only this past week have we converged on the final design and gotten a good first approximation into the game in a playable way. It's pretty cool.

Because we're working on a lot of things at once, we usually talk about a few different locations that are at different stages of development. At this particular meeting we were also looking at some early concepts of the visual design and modeling of the area where you start the game:

The Depth Jam

Last week, I got together with three other designers for a four-day intensive design retreat known as the Depth Jam. The other attendees were: Chris Hecker of Spy Party, Marc ten Bosch of Miegakure, and Daniel Benmergui of Storyteller.

This event was an experiment. Chris and I had been discussing the idea for a while, but it took us a couple of years to get around to it. One of my personal goals in setting up this event was to find a new way to stimulate my professional development, because the old ways were not cutting it any more.

The Depth Jam was designed in reaction to shortcomings of other game-related events. In order to explain the design choices behind the Depth Jam, I will speak critically of these other events, in order to highlight the problems that the Depth Jam is meant to address. If you are a fan of these events, organize some of them, or otherwise identify closely with them, then this will be uncomfortable. The best I can do here is to assure you that this isn't attack-style negativity; it is criticism that comes from years of carefully considering these situations and thinking hard about how to make things better.

Conferences

When I first started working in video games I learned a lot from conferences and lectures. The few days I spent at the Computer Game Developers' Conference in 1996 were eye-opening, even though I wasn't comfortable enough as a game developer to know how to make effective use of that time. As years go by and we get better at what we do, a natural shift occurs: in the beginning, we are mostly deriving benefit from other attendees and presenters; later on, we are mostly providing benefit to other attendees, getting little out of it ourselves. I have been to the Game Developers Conference 17 times now. I find that I still do get something from attending, but it really takes a lot of work and there are very few people I can expect to learn from.

All the smart programmers I know complain about conferences and consider them basically useless (except for the smart programmers who are also on conference advisory boards). I certainly developed this kind of frustrated "there's nothing good here to see" attitude in the early 2000s, but to mitigate this situation I shifted into being much more of a conference presenter than an attendee. A lot of creative energy went into planning new conference sessions and making them good. This helped extend the useful life of conferences, because I was learning a great deal by running sessions. After about eight years, though, this ran its course and I had gotten the bulk of what I was going to get from this arrangement.

Game Jams

In a typical game jam, developers gather for 2-4 days to do a working sprint, the goal being to produce a finished game entirely during the event. I was lucky enough to be around for the Indie Game Jam, which probably started the game jam trend (though I was often too busy working on last-minute GDC lectures to make jam games, sadly!)

From the first Indie Game Jam. Pictured: Brian Jacobson, Sean Barrett, Ken Demarest, Charles Bloom, Jonathan Blow, Brian Sharp, Doug Church.

The Indie Game Jams were very different from the jams we see today. The IGJ was founded on the idea of exploring the design ramifications of a crazy technical question; we would provide attendees with some code to accomplish some technical feat, then they would see where that would lead in terms of design. For example, the question for the first IGJ was "Graphics hardware is pretty fast now; what will people design if we give them an engine that can draw 100,000 little sprite guys on the screen at once?" We were picky about who we invited: attendees had to be designer-programmers who were actually good at programming, because dealing with new technology on a short timeframe can be very challenging.

Also from the first Indie Game Jam. Pictured: Art Min, Charles Bloom, Robin Walker, Thatcher Ulrich, Brian Jacobson, Zack Booth Simpson, and ... I don't know, Justin Hall? Charles Bloom again?

In contrast, contemporary game jams are more open. The idea is that it's great to make a game, any game, and that even if you don't manage to finish, you were still part of a community. This community spirit is often upheld as the best part of a game jam.

I think these jams can be really nice for beginners, to show people that making a game is something within reach, and to help them meet other people interested in making games. For experienced developers, though, I think these jams are not so good, because the jams are part of an overall social context that supports stagnation.

Experienced developers would do well to continually hone their craft and push beyond their comfort zone, but jams celebrate low expectations and provide Warm Community Feelings that create a comfort coccoon. "You made a game that is not very interesting? You didn't finish a game at all? Well, you are still part of a community that likes you because you are participating in a game jam, and that is what is truly important."

I don't think there is anything inherently wrong with desiring a feeling of community, but we must take care to separate the notion of participating in the community from the notion of success. Participating in a game jam is not an indicator of success at game development -- nor is attending the Independent Game Summit or Indiecade. I think that nice feelings are nice, but you want to build an ecosystem where the nice feelings coincide with behavior that will make developers robust and powerful and interesting in the long term. You don't want nice feelings to act as a soporific. Activities that are good for beginners are often stagnant for intermediate developers.

What to do about this? I think if there were a category of game jams with higher expectations, so that advanced jams were differentiated from beginner jams, that would be a nice start. The IGJ model definitely asked more of participants, but I don't think the IGJ is the right thing going into the future, because even if you are playing with challenging technology, the time-limited format prevents you from going deep. IGJ was nice in 2002, but today it would just contribute further to the problem outlined in Chris Hecker's rant Please Finish Your Game. We see lots of wacky but shallow game designs all over the web, and it feels like a problem, or at least a vast sea of potential unreached.

As Chris says in his write-up about the Depth Jam, "game jams are shallow by design." Because they are shallow, I don't feel they are the right place for me to develop as a game design practitioner.

Retreat-Like Gatherings

There have been a few retreat-like gatherings for forward-thinking game designers: see for example Project Horseshoe and Phrontisterion. I have never been to these. I like the basic idea behind these kinds of events, but the execution seems to have endemic problems. I know people who have been to both of these events, but when I ask, they do not recommend attending the events. Certainly I have found Project Horseshoe's written reports unhelpful.

The obvious problem with these events is that they are mostly just a bunch of talking. When people get together for a bunch of talking, most of them just say a bunch of bullshit (here I mean bullshit in the Harry G. Frankfurt sense) that is unfocused and untethered to reality. If it is not of critical importance whether what people say is right, then most of it is not going to be right.

I really like the retreat model as a basic template. Over the past few years I've been to a number of retreats, mostly for things like meditation or silent existential contemplation. There's a lot good about going to a far-away place where you are not bothered by the concerns of everyday life. But looking at Phrontisterion and Horseshoe, the question arises: how does one design a retreat like this that is not just a bunch of talking?

I knew some of the answer, because I've seen success in dealing with a similar question in a neighboring realm:

Local Developer Meet-Ups

Many cities around the world have regular meet-ups; once a month or so, game developers get together at a bar or something, and just chat and be social. I generally don't go to these because bars are antagonistic to interesting conversations and because attendees tend toward the neophyte side, which means we have the same problem as at conferences: there's little benefit to be had for an experienced developer. But these events also have the Horseshoe problem, in that the conversation is not focused and doesn't really matter, so people just say a bunch of nonsense. If all you want is to get drunk and be social, these events are fine, but they don't do much for professional development.

Two years ago I started a series of monthly developer meetups in the San Francisco Bay Area; the idea was to keep discussion quality high by (a) holding the meetings in quiet places conducive to good discussion, like someone's house (b) inviting only active game designers [this was not a "game industry" meeting, it was a "thoughtful game designer" meeting], and (c) starting each meeting with one of the attendees presenting their own work. After the presentation, we discuss that work specifically for a while; then at some point, the discussion naturally dissolves into separate, more-general discussions.

(I have been to some developer meet-ups that also began with presentations, but which to me did not manage to establish a culture of quality. One example was the Austin IGDA meetings back in 2002-2003. I think there were many subtle things preventing quality from rising, mostly having to do with intention of the event: the goal of the meeting was to drive attendance, not to be deeply interesting; also, they were "game industry" meetings, with all the associated issues. Also, scale matters: the Austin IGDA meetings were bigger, and they occurred in offices or at places like Dave & Buster's, which did not encourage a personal connection to the presentation or the other attendees).

The meetings in the Bay Area were very successful at keeping discussion quality relatively high. The situation wasn't perfect, but it was much better than your typical bar meeting. (I would have attended these regularly even if I were not involved in organizing them). Other attendees really enjoyed the meetings as well. After about a year, though, I stopped arranging the meetings because we seemed to have exhausted the supply of people willing to present, and I didn't want to start having meetings that were not kicked off by solid presentations. Because everyone had a good time, there's a reasonable probability that in the future we will pick these up again. I think we might be able to improve the discussions further by reducing the presenter-vs-audience asymmetry somehow (see the Depth Jam section below).

Key to the success of these events was having specific, concrete issues to talk about: a specific game being presented, so that discussion could be anchored to the details of that specific game. It's also important that the game was being presented by its author; if the session is just someone talking about someone else's game that they liked or didn't like or just want to say something about, it is too easy for the discussion to be useless bullshit.

It seemed like this model could be applied to ground a retreat so that it would not just be a bunch of talking.

The Depth Jam idea

Now, we come to the actual Depth Jam. We settled on the basic idea very quickly: the jam would occur in a relaxing retreat-like environment. There would be a limited number of participants; four seemed like a good number. Each participant would have a good game that he has already been working on for a while, and which presents some deep and interesting problem he would like to solve; this problem serves as a focus for discussion. The fact that every particpant has a game under discussion means that every participant has "skin in the game", which keeps discussion tethered and unfrivolous.

I'd like to emphasize this last point because it can be subtle but it is crucial. Suppose some people are showing their games and being criticized and generally having a rough time due to all the stress that happens naturally when having one's creation dissected; and meanwhile, the people who are criticizing do not have any obligations, and they are just tossing in comments from the peanut gallery. This situation creates a weird imbalance. The comments and criticism will not be as thoughtful as they could be, yet they will be taken very hard by the people showing the games.

If everyone is having their creations dissected, there's only one class of attendee instead of two. It is easier to empathize and avoid unnecessary harshness. People are going to be more careful that their ideas and criticisms are thoughtful, because they are acutely aware of wanting careful input when it comes to their own game.

The Format

Our first proposal for the Depth Jam had us spending one entire day on each game, so that we could dive into each game at maximum depth without context-switching. However, as the idea churned, we decided it would be beneficial to allow some iteration. Why not split the day into two time slots, so that each game gets half a day and we cycle through the four games twice? This would allow time to modify the games based on the discussion, which would give the discussion even more teeth: now we're not just talking about a particular problem in a particular game (with some kind of tendency to wax philosophical), we're actually figuring out how the author will address the problem here at the retreat, with the results of that approach to be plainly visible in the next session.

In our pre-jam planning meeting, we decided to go even further this way, breaking each day into four slots, cycling through all the games four times (so that each game had a two-hour slot each day). This seemed to work pretty well and it allowed a lot of iteration, but it might have been excessive. Daniel thinks there was too much context-switching and he might have been able to think more effectively if given more stability. My impression is that the talking was great for the first couple of days and degraded in quality toward the end (but was still worthwhile even then). At least two attendees did not have a problem with this, though, and found that the final discussions were very valuable for them.

For the next jam I would propose a mixed format: we'd start with two 4-slot days, just like we did this time, followed by a day with no-talking, all-working-and-quiet-and-taking-a-walk, followed by a final 4-slot day. (Or, perhaps I would lengthen the retreat to 5 days and put the rest day in the middle.)

The nice thing about the 4-slot-per-day format, which would not have been true of the 2-slot-per-day format, is that it gives us the maximum amount of calendar time for ideas to stew between iterations. I have long been appricative of the role of calendar time in good design. Sometimes it doesn't matter how many hours you pack in trying to get things done; the good ideas will arrive unpredictably, and maybe you just need to allow time for this to happen. I was curious whether this principle would also be true on the timescale of a 4-day retreat. For me, at least, it was; I got my best idea in the shower on the morning of day 3, in response to discussions we'd had on day 2. During my session on day 3 we discussed and refined the idea, and on day 4 I showed an implementation of it.

Creature Comforts

We spent some money renting a nice beach house and ordering catered food; the cost for the event was around $5000. Chris goes into more detail about this in his write-up. You don't need to spend any money on an event like this, but if you can afford it I recommend spending some money to help create a nice environment that minimizes stress and factors away concerns like "what are we going to eat for dinner" and "who is going to do the dishes". The purpose is twofold: first, it helps you focus on the subject at hand; second, the minimization of external stresses helps you deal with the potential added stresses of working really hard and disagreeing with people all the time.

If you think that the Depth Jam will help you make more headway on even one deep problem than you would have otherwise, and thus make your game better, it's easy to think that the game will also sell a little better and that costs in the neighborhood of $1250 per attendee are easily justified.

Attitude

Discussions can easily turn into arguments, or at least energy-sucking disagreements. As peoples' energy gets drained, they become more irritable, so there's a feedback loop lurking here. A little bit of this happened at our Depth Jam, but we saw it happening and course-corrected, so that the final day's discussion was reasonable.

Prior to the jam, though, we had not thought much about this. I think it would be helpful in future for the attendees to go in knowing that irritability is likely to happen; the mere fact of this awareness probably helps the situation, and anyway, a little bit of psychologically-aware pacing at the beginning would have gone a long way.

Games and Attendees

It's very important the attendees be capable both of participating in good discussions and acting on the discussions to improve their games within a short timeframe. This latter requirement basically limits attendees to being competent designer/programmers. If someone can't program, it's hard to see how he can participate meaningfully in this style of depth jam, because it would be very hard to iterate. Possibly if someone is a level/world/puzzle designer who can build scenarios quickly in UDK or Unity or whatever, it can be made to work, but I still think that person would be feeling the limitations of being unable to make algorithmic changes.

I don't think that having teams of people would work, at least not for the format described here, because it would dilute the energy and bog down the iteration process. If you have one designer and one programmer trying to do the job that the other people are doing as single designer/programmers, your duo is probably going to have a hard time keeping up. If the jam is made up entirely of duos, it's going to make discussions a lot messier and lower-energy (twice as many people talking about the same number of games). At least one of us felt that four people was already too many for high-quality discussions, because you keep having interesting ideas but have to wait for other people to stop talking in order to say them, and by that time the discussion may have moved on to a different topic.

We have tossed around some ideas about how to scale the jam to larger groups, but haven't come up with anything that is fully convincing yet.

It's important that the games be high-quality efforts that pose problems that everyone will be interested in. We were fortunate to have four very interesting games: Miegakure, a puzzle-platformer in four dimensions; Storyteller, a game about building stories through character interactions; Spy Party, a heavily player-skill-oriented game about subtlety and deception in human behavior; and The Witness, a first-person puzzle game with a heavy emphasis on nonverbal communication.

If time permits I may do a detailed write-up of the issues we discussed for each game and the resolutions we reached (though care must be taken here, as we don't want to disclose aspects of these games that the designers would rather keep secret).

Conclusions

I am happy with the way this first Depth Jam went. I think we can certainly tweak the format to improve it, but already it is a useful tool in my further development as a game designer. I got much more out of this four-person, four-day event than I do from attending a conference. It seems appropriate to me to do a Depth Jam every six months. Provided we are organized enough to get the next one together, we'll adjust the format and see how it goes!

See also:

Chris Hecker's write-up
Daniel Benmergui's write-up
Miegakure web site

Island Update

Here's how things are looking now:

In a strange twist of fate, the corner of the island that I chose long ago to be closest to the camera is the place that has taken longest to develop. As you can see, we are continually modifying this area but it's still in a very rough state. Most other areas of the island are further along.

Lately I have been doing a little bit of playtesting and high-concept discussion (more on this later in the week). I've also been doing more work on the endgame. The modelers have been cranking away at making areas look better. I think we have another engine technology posting coming down the pipe.

Peter Thiel on Secrets

Peter Thiel is teaching a class at Stanford about how to start a technology company. One of the students is posting thorough class notes online.

In this instalment, Thiel takes the question of what kind of company to start and reframes it in terms of secrets.

Thiel's point of view reminds me of the way I think about games in general. Quite often I go out and give speeches about game design or business, and I say things that some think are overly idealistic, or oblivious to the necessities of recipients' situations, or just plain wrong. Certainly my advice usually runs counter to conventional wisdom. (Yet somehow, by following these principles, I seem to do okay.)

Thiel begins with the question: "What important truth do very few people agree with you on?" and goes on to define secrets, in this context, as "unpopular or unconventional truths". If everyone knew these things and believed them, they wouldn't be secrets.

I recommend this write-up to anyone who wants to think unconventionally about game design.

Island Update

We've done a first pass at changing the shape of the island terrain, and here's the result:

The changes are a little bit drastic in some spots, but overall not as drastic as I had expected. I had been worried about some issues in the natural flow of where players would naturally end up going, especially early in the game. It turns out we were able to solve these without changing too much. So between last island update and this one, for the most part, some areas were moved laterally or expanded, and some new elevation changes were introduced, but areas were not shuffled around; they are all more-or-less in the same place with relation to each other. So for the most part, things are converging, which is a good sign.

And, oh yeah, we are making that mountain a lot bigger. It is the messiest part of the island right now, and has been for a while. There are still a few things gameplay-wise to figure out here, then it will start to come together. My biggest questions in the area have to do with that white building near the bottom of the image; the puzzles inside that building will determine its overall structure, which will determine how it is worked into the surrounding terrain of the mountain. We have some proposals from the architects on what this building will look like, but it is waiting on me to finish the puzzle design.

Because we haven't done it in a while, here's the island from a different angle:

The current puzzle count for the whole game is 450.

Panel Art Update

It’s now been over 5 months since I joined The Witness team as an artist and I would like to share a bit of my experience on the project coming from a “big studio” as well as the most recent work I’ve done.

Just before I left my last job I was working as a Lead/Art Director on a marketing driven project focused on selling as many units as possible. On one side I had high level decisions being made by stockholders whose focus is on turning a profit while on the other side there was the development team who truly believed they would be able to make a good game.

Also I was surrounded by schedules, performance reviews, hierarchical titles, producers, human resources, bonus system and all the other corporate systems that eventually dilute the organic process of doing something creative. While I understand the logic behind it I  realized that is not the reason why I joined the video games industry and that something wasn’t right.

Now, after these few months, the answers for these questions became clear. Its all based on trust. In this project, all the decisions we arrive at are very organic. Jonathan has a very clear vision of what he wants and the fact that we can see it and believe in it makes it extremely logical and simple.

Our passion for what we do (and what we would probably be doing on our free time if we weren’t being paid for it) gets distilled directly into the game in a very rewarding process.How much and how we give it depends entirely on us and that creates a natural challenge and pressure that most AAA companies cannot provide.

This trust leads to respect and it creates a very unique work environment. This is something that I’ve never seen with all the project management, task scheduling and scrum meetings that try to fix an inherently broken game. I don’t think video games can be produced like an assembly line, at least not games that have something meaningful to say, and I’m glad that I found people that are doing it the right way.

All this may sound trivial but probably 90% of the game developers that I know will understand how big of an issue this is. I still believe big companies can change their ways and make the same profit if not more, but it has to start from the bottom, the people who are hard at work making the games.

As for the second part, I would like to share what we have been trying to do with the many island panels. As you might already know the player has to solve different puzzles using these panel interfaces scattered around the island.

I started my research by looking at what materials they could be made of, what technology they would use and how they would be assembled and how all this could relate with the different areas and narrative of the game.

This first set of images shows some proposals of how the panel screens could possibly look. I tried not to focus so much on the gameplay but more on ideas that could lead to further discussions among the team.

After some solid feedback and a couple of art meetings I was able to understand what was working or not and decided to do a new set of proposals. Also this time I tried to focus on the more technical aspect of getting these panels to work in the game and if the effort we would have to put into them would be worthwhile.

The same amount of work went into the structure of the panels and how they would be assembled. This time, working with the architects gave valuable input into understanding how they would actually be built in the environment and the amount of work required. On this image you can see a screen capture of several prototypes before being tested ingame.

These are usually modelled very fast with just base colors so I can do several iterations until I find something that I'm happy with.
And finally here is how some of them are looking in-game. They are still in concept but by placing them in the correct context makes it a lot easier to understand what is working or not.

Island Update

Here's how the island is looking right now:

But today we are going to have the first in a series of meetings wherein we think pretty hard about the topography of the island and what the flow of natural curious investigation will tend to be from various spots. Expect the island to look pretty different in the next update! (Or maybe it will turn out that things are mostly fine...)

Lately, I have been working on some of the more sophisticated puzzles in the game. These are things that were at least sort-of done already, but I wanted to revise the designs to improve them -- to ensure that the puzzles are as interesting as possible and built as closely as possible around the core themes of the areas that contain them. I am happy with the way these are coming along so far, but there is definitely still some work to do here.

The art team has been working further to nail down the style of the game, now focusing on cliffs and plants and other natural things, as well as control panels and other bits of machinery. We're also taking a few buildings that the architects have finished designing, and starting to build out the geometry as one really would for a video game. (The architects give us buildings modeled in SketchUp, and they tend to come into the game a bit messy, but also, not modeled the way an experienced video game modeler would do it).

On the programming side, we've got lots done lately. Andy has added a software occlusion culling system, which should help with frame rates in the game. He's also been playing with culling for water reflections. Salvador got animations working in the exporter and in the game, so now we can play animations on entities, which is very useful. (We worked on the game for years and built something fully playable without this ability!) I have been going back and doing the gameplay work for animated entities, as some things have to change in the gameplay logic. In all it is a very nice improvement. Salvador is now working on asset streaming, which will help the game start up faster and run better (and help it run at all on lower-end platforms like the iPad). Ignacio's been doing a whole lot of fixes to various systems and hammering away at the todo list. One of these things has been better control for the tone mapping process. We now get a graph of tone mapping curve:

And we also get the ability to export screenshots into Photoshop that have a color key on them; then the colors can be tweaked in Photoshop and re-imported into the game to alter tone mapper settings. This is in many cases more convenient than playing with those sliders.