RE: What’s Wrong with the IGF

We’d like to take this time to respond to the heated debate that followed from our “What’s Wrong with the IGF” post.

First, to anyone that took our blog post personally, please understand that this was not a personal attack.

We wanted to bring to light a fact that some judges don’t play games that they are assigned, and that that may be a problem in the future.

In light of the $95 entrance fee, we believe every developer deserves a fair shot at a nomination.

Judges not playing a game they are assigned to judge, for any number of minutes, is simply not acceptable.

Regardless, we had not intended this as a personal attack against Brandon Boyer or Simon Carless.

We understand that they do their best to make the IGF what it is.

As hard as they work, the system itself is flawed because it makes it easy to overlook games when the IGF was created to do the opposite: notice overlooked games.

However, we do not agree that calling would have solved anything. If we had decided to call, it would have been a word of honor against posting.

Furthermore, we mentioned the email because we are arguing for openness, not private correspondence.

Everyone should know about these issues and not be kept in the dark, so that we can have an honest debate over what could be done.

It is enlightening that some developers have already come out of the woodwork to voice similar complaints.

To that end, we’d like to wish everyone the best. Oh, and we’ll change the blog theme.

– the rotting cartridge

What’s Wrong with the IGF

UPDATE: We’ve posted a public statement about this post here.

Hello there.

Way back in December we posted an update saying that we would post “about our terrible IGF experience.” Granted, we may have exaggerated a few things back then. (read: a lot of things!) But with the IGF finals at GDC coming up, there is no better time than the present to relate our experience.

First, some backstory: We are an independent developer producing an iPhone game named Kale In Dinoland:

This year the IGF decided to use TestFlight for its iPhone games. We paid the $100 customary to the festival, as over 500 other developers did for their games. Going in, we didn’t expect to get nominated for anything. The game was content-complete but wasn’t done to the level of polish we wanted. Not to mention, there were still bugs. But this isn’t about the overall quality of our build, it’s about giving every game its fair shake.

Let me explain. When the IGF chose TestFlight for iOS distribution, they made a big mistake. We were given a list of all of our judges’ email addresses, revealing their identities. We aren’t going to release those names to respect the judges, but let’s just say we had a heavy-hitter.  For every judge, we could see how much they played; if they even started the game at all. How do we know this?

TestFlight records NSLogs (iPhone version of console logging) and custom “checkpoints,” uploading this data seamlessly for us to see. In addition, when a judge opened the TestFlight invitation email, downloaded and then installed the game on their iDevice, we can see all of that. I believe that the IGF organizers, who are usually lips-sealed on the judging process, did not know about this functionality. We can see exactly when a judge installed the game, when they started playing, how long they played, and how far they got. 

As you can imagine, this was an opportunity for us to see what really goes on behind closed doors at the IGF. How much do games really get played? Does hype count for everything? Is it true that to be a contender in the current IGF, your game has to already be widely known in indie circles? Does this mean that most of the judges won’t end up playing your game in these circumstances regardless of the quality of the title?

Here are the statistics:

Eight (8) judges were assigned to Kale In Dinoland. Of those judges, 1 didn’t install the game or respond to any of our invitations (which we had to send multiple times before judges joined). 3 judges didn’t play the game. Of the remaining 5 judges that played the game, 3 played it very close to the IGF deadline, which was December 5th. One judge, our outlier, played the game for 53.2 minutes. Excluding the outlier, on average each judge – including the 3 that didn’t play it – played the game for almost 5 minutes’ time. Back in that build, Kale’s intro cutscene took about a minute’s time. So we’re talking almost 4 minutes for each judge of actual game time.

Granted, they could have deduced the game was absolutely terrible and didn’t deserve their time. About this time, though, we were also running a beta that was being played by anonymous iOS gamers from the community. These helpful gamers were all interested in the game, having seen it on TouchArcade and IndieGames.com. What is the influence of prior marketing? The average play time for these external beta testers was 34 minutes, accounting for that one minute of cutscene time.

So, a large group of anonymous gamers who were not required to play the game averaged about 30 minutes more play time than the the 7 judges who were required to play the game, 3 of whom did not even play the game. Is 4 minutes enough time for someone to give a fair assessment of a 2-hour-long game? How many more games were given similar treatment? Had we not taken initiative and sent multiple emails urging judges to download the game via TestFlight, how many judges would have ended up playing the game? Here’s the last email I sent out, urging the judges to accept the TF invite:

The build has been up for a while now (I sent emails via TF), but only 1 judge has installed, and 4 other judges still haven’t even signed up for TestFlight.

The sad truth is, the heads of the IGF know about all of this. They made the mistake of using TestFlight and allowing us, the developers, to see backstage. Shortly after posting the update that included negative remarks about the IGF – on this relatively unknown blog – we were mysteriously followed on Twitter by @brandonnn and received an email from none other than Simon Carless.

Hey folks,

It’s just been brought to my attention that you believe that you’ve had some issues with your IGF experience and are preparing to blog about it. My name’s Simon Carless and I head up the GDC events, including the IGF – and I’m CC-ing Brandon Boyer, the IGF chairman here.

Before you go ahead and do that, could we have a phonecall discussing your perception of what happened during judging and your impressions of what didn’t run correctly from your perspective? We _do_ actually care about individual entrants such as yourselves, and it upsets us when people don’t feel like we’re doing a good job. So let’s talk about it directly!

Myself and Brandon are available at a few times on Monday – I’m in U.S. pacific time and he’s on U.S. central time. Do you have time for a call?

Thanks,

Simon Carless

EVP, UBM TechWeb Game Network

We considered calling. At the very least, we decided not to post what we would have, and gave it some second thought. Let’s be honest: It is obvious that Brandon Boyer and friends care about the IGF as the prime outlet for indie games. We don’t doubt that. But this isn’t about handling the situation silently. If we had called and talked about our concerns, the heads of the IGF don’t have to be held accountable for a broken judging system. It’s about transparency, which is something the IGF completely lacks.

So there it is, our story about the IGF. We hope that, as a community, we can change the IGF for the better by exposing flaws in the judging system and holding those in power accountable. But until then, please hold off on marking the IGF as the be-all end-all of indie games. Instead, join protests like the IGF Pirate Kart. And if you’re still not convinced there’s something wrong with the IGF judging system, hear it from a judge herself.

The Rotting Cartridge Developer Interview: Design

In an effort to appear less secretive and more identifiable, we’ve recorded interviews with each of the members of The Rotting Cartridge, so that the public can put faces to the magic. The first interview focuses (by his request) on J, the founder of TRC and really the creative genius behind the whole thing:

Stay tuned for a final trailer and release date on our first game/port, Kale In Dinoland, coming in February.

Bastion, and why I can’t look past its ending

I bought and played Bastion the night it came out, having followed Supergiant Games ever since January, when I found a link to a game that – upon first glance – looked similar to an isometric RPG game I was set on creating. But Bastion was its own thing, which I soon found out during the developer videos at Giantbomb.

The reason I was so interested? Sure, the art was amazing – at that point I wasn’t aware the sound was as well – but the narrator. Here was a developer set on doing something new, set on bringing a baby into this world.

I guess with every new sequel to a sequel, I get queasy. There just aren’t that many original designs floating around right now – seems like everyone is dead-set on repackaging the same bullshit we’ve already seen with a different colored ribbon. People have compared Bastion to an old SNES game. I don’t see it. But what I do see is this freshness, and perhaps that’s what people really mean now when they call it an SNES game: an original game. For god’s sake, an original game!

Everyone I told about Bastion during this time wasn’t thrilled. They didn’t see the potential the game had, being caught up with the nth installment of whatever RPG series and reluctant to try an XBLA title. But this isn’t about how I was right and they were wrong. This is about why I, fundamentally, can’t look past Bastion’s ending.

(SPOILER ALERT)

When you get to the end of Bastion, the game freezes and you are offered – in a menu screen – two options, either to try and save Zulf or leave him behind. The reason I am so opposed to this is before the menu pops up, the game design is spot-on. Near perfect. Every part of the game felt enjoyable to me. But this – MENU – pops up, I’m thinking, “What is this? No “good-or-evil” menus popped up in the entire game!” All of a sudden I was shocked.

It may have been Supergiant’s tight development schedule. But I view the menu as a blunder, a smear on the perfect canvas.

Bastion is a game devoted to dynamically engaging the player through gameplay. The narration represents the epitome of this fact: he reacts to you, he talks to you, and you trust him. The entire game leading up to the ending moment was filled with direct engagement. You were told your decisions in the game, on the playing field, had meaning. And I was foolish enough to believe they would follow through on this design theme. I was wrong.

What should have happened? There should have been no pop-up. The player should have been able to either realize there was a choice, and choose, or not realize there was a choice. And that potential: for people to not realize there was a choice, and blindly trudge forward leaving Zulf behind only to later find out they could have saved him – is a moment I wished occurred in Bastion, one that I can’t look past.

Design Theatre: Shadow of the Colossus Part 2

This is part two of an x-part series summarizing the design of one of the greatest games of all time, SOTC. Part 1 can be found here.

Welcome back to Design Theatre! Today, we’ll take a look at how Shadow of the Colossus (SOTC) was designed in its first major sections of gameplay.

There are sixteen bosses in Shadow of the Colossus, each with a unique twist on the “stab its vitals” formula. The first boss, a giant wandering colossus with a club, is by far the easiest, only requiring the player to climb up its leg and stab its head to defeat it. However, at this early point in the game, the player doesn’t yet know they have to do this, and since the player has likely never faced something this large in a game before, they panic. The battle serves as a tutorial, teaching the player the fundamentals of how to defeat a colossus, without giving them all the answers. For example, it is hard to imagine that the latter bosses of the game require the player to utilize their environment in creative ways to defeat them, yet the goal – climb the colossus and stab it with your sword – remains the same. From this section we learn:

#5. In the beginning of a game, introduce a short-term goal that shouldn’t change for the duration of the game.

Design Theatre: Shadow of the Colossus Part 1

There’s plenty of great games that, for one reason or another, passed me by during the course of my existence. Shadow of the Colossus? One of those games. And now since SOTC comes up in almost every discussion on “video games as art” or as film or as an example of good design, I’m pressed to sit down and finally play it.

First of all, if you haven’t played it yet, WHAT ARE YOU WAITING FOR GET A COPY AND A PS2 AND PLAY IT ALREADY!! ^__^ No, seriously. You’re missing out. Now then..

Shadow of the Colossus starts with a very long cutscene that plays like a film, despite its graphical rust. We see a man on a horse climbing a precarious ledge, and then follow him to a huge bridge over a canyon. This opens up a few questions: Who is this man (boy?) on the horse, where is he going, and most importantly, where did he come from? As far as I’ve played, not all of these questions are answered, though we do learn where he is going. This leads to the first lesson of Design Theatre:

#1. Open with questions.

In case you’re designing a game with its own story and world, take a lesson from SOTC and open with questions, easing the player into their place in the world, while simultaneously immersing them in it. Half-life 1 and 2 do this: the player starts on a tram car, with someone talking, and while this dialogue alludes to events in the game world, it opens up many more questions than it answers. The original Halo also does this, with Captain Keyes and the AI Cortana exchanging dialogue without speaking to the player directly. In fact, even Braid does this, opening with the protagonist silhouetted against a burning city: why is it burning? Where am I? The answer to Braid’s question is answered at the end of the game, which nicely transitions back to the burning city after the epilogue, concluding the narrative and making the game seem complete.

Going back to SOTC, the opening cutscene then fades out perfectly into the title screen – it does not upset the mood of the game by fading to a black screen with a spinning logo, as was – and sadly still is – a cliche of console and pc games. Portal 2’s story was fantastic, but the proliferation of loading screens was downright ridiculous. When designing a game with loading screens, please don’t upset the carefully-crafted mood of the game each time a load screen pops up, or the bulk of the game’s content will be lost in the moments after the load screen as the player tries to recollect their composure. So I’m making this the second lesson of Design Theatre:

#2. Never let load screens upset the mood of the game: hide load times whenever you can.

This is an oft-overlooked lesson. Say what you will about Apple, but if they ever made a game, be sure that minimal load screens would be a top priority. Why? Because Apple cares not just the product, but the presentation of the product, and treats both equally. For those who played the original Mass Effect, the infamous elevator scenes – where the player had to ride extremely slow elevators that masked level loads – are NOT what I mean when I say “hide” a load screen, since some players knew they were waiting for a level to load. SOTC hides its loading from the player extremely effectively, as there are little to no load screens during the course of the game. (You might have not noticed the game loaded anything at all!)

When our hero finally steps off his horse, we see him carry a girl (who looks his age) to what is presumably an altar, and sets her there. What is interesting about this scene is that you may not have noticed the girl at all until this moment, which serves to renew interest in the story after a quite lengthy opening sequence. It is implied through an anonymous talking mask that she is dead, and our hero has ventured into the land of the colossi, (that was apparently so dangerous a giant bridge was built over it) apparent immortals whose physical incarnations can only be killed by a mortal with an ancient sword, which our hero conveniently yields. Here, our questions start to be answered, but more questions are raised.

The scene is actually a cleverly-disguised tutorial section, which explains to the player the goal of the game (kill all 16 colossi to bring a dead girl back to life), foreshadows the shadow spirit’s role in the story, provides narrative incentive to play the game (“But read this, the price you pay may be heavy indeed.” What price? Death?), and tells the player that the sword is important to gameplay (“Raise thy sword by the light”). This leads to the third rule of design theatre, which is relevant to story-based games:

#3. Intertwine the tutorial into the story. The meaning of important plot objects should parallel their meaning during gameplay.

For example, the opening cutscene shows the player that they are alone with their horse, who enables them to travel long distances together – exactly what the horse is used for during the course of the game. The idols need to be destroyed — the colossi need to be destroyed. The sword allows our hero to hold some power — only the sword can kill the colossi.

Once the player moves on to the first area, we must leave Agro (the horse) behind, and climb our first wall. When I first got to this section my friend and I couldn’t figure out where to climb up, but once we discovered that the moss can be climbed, every other climbing area was relatively easy. What we didn’t know at this point was that the visual distinction of climbable surfaces (furry materials) shows the player how to defeat the first colossi, without telling them directly: climb up the fur on his feet. Notice that the designers could have shown us the first colossi and then told us during the course of battle that “fur can be climbed,” or even show us (by panning the camera or something), but instead make us show ourselves before the first battle even begins. This is our fourth lesson:

#4. When introducing a new gameplay mechanic, let the player show themselves how it functions.

The ability to let the player show themselves how or why something is separates games from film and books. It seems natural that the progression of entertainment goes something like so:

• Books tell the reader; they speak directly to the reader, but they can only produce imperfect images because every human interprets words differently. English teachers tell you it is better to show than to tell in stories, which comes naturally to films.
• Films show the viewer (if they are good films!); they show the viewer exactly what they mean, but the visual conception of the world is usually concrete. Great films usually go against the viewer’s visual conception of the world that the protagonist lives in – in Taxi Driver, (spoiler alert) this is when De Niro shaves his head into a mohawk, tries to kill a politician in an army jacket and then goes on a violent rampage. In The Shawshank Redemption, this is when Andy reveals that he’s been carving an escape passage behind his pin-up posters.
• Games let the player show themselves; the player, through experimentation and logical thought, can deduce the meaning and function of elements in the world. In level 1-1 of Super Mario Bros., you know to jump on Goombas to defeat them, use Mushrooms to grow and hit ? blocks to uncover power-ups and coins. None of this is told to the player from a third party – the player discovers the world for themselves.

This marks the end of Part 1 — but don’t worry! ^__^ Part 2 is on the way! Whereas Part 1 focused heavily on story and the first steps of a game, Part 2 will focus on the colossi battles and their presentation.