GDC2013 - Game Design Challenge: Humanity's Last Game

I only caught the last two of six game design pitches.

• Jason Rohrer designed A Game For Someone.
• He was inspired by cathedrals that were built over the course of 500 years. They were not built for the builders; they were building these structures for the future. Likewise, Jason wanted to make a game to be played 2000 years from now.
• Digital technology would become outdated really fast, so only a board game would survive 2000 years.
• He designed a 2-player board game, but he had to make sure nobody now can play the game, not even himself. Instead, he built a simulator that would run his game and find strategic flaws, to which he would respond with design changes. He ran his game through the simulator thousands of times and now has a game nobody has ever played.
• He needed a material that would last 2000 years, so he built a board and pieces out of titanium metal. The board itself is a storage space for the pieces. The pieces can be inserted into the board like a screw.
• Instructions were written on acid-free paper, placed in a sturdy glass tube, and further encased in a titanium tube to make sure it would itself last 2000 years. The rules were written using symbols and images to be completely independent of language.
• Jason picked out a million random coordinates in the Nevada desert, drove to one of them, and buried the game. Then he walked away and deleted the coordinates from his GPS so that he himself cannot find it.
• All 1,017,000 coordinates were printed on hundreds of pieces of paper and distributed to attendees of this talk at GDC. Only one of the coordinates is the right one. If someone searched through the coordinates once per day, it would take approximately 2786 years to find this board game.
• Richard Lemarchand designed Ludo Sapiens: The Wise Game.
• According to the the doctrine of the 5 percenters, 5% of people know the hidden truth to humanity, that we're all the same because we're different. Every last person is deserving of respect.
• This game divides all players into three categories: 85% of them are Team Sleepy (unaware of the truth), 10% are Team Selfish (they know the truth, but exploit it), and 5% are Team Wise (uses the truth for good).
• It's a mobile app where players post deeds that they have done. Other players can browse deeds and judge them, which in turn places the deed-doer into one of the team. Judging will also move a player towards a team.
• After a while, players are sorted into one of the three teams, each with a different special power.
• The game is meant to affect the real world in legal, economic, political, and social manners.
• The 3rd place winner of the Game Design Challenge received a copy of Cards Against Humanties, 2nd place received possibly the first board game Senet, and the 1st place became the owner of one acre on the moon.

Shoplifter Shuffle Postmortem: Part 2

I am reposing this article that was submitted to my company blog here: http://blog.arkadium.com/shoplifter-shuffle-postmortem-part-2

We're back today to continue our series on our Shoplifter Shuffle Postmortem! If you haven’t already, check out our Part 1 of the series from yesterday, as we discussed our breakdown of what went well when creating our game. And now, for the not-so-perfect part, read on to discover some of the things we learned that didn’t go so well, and our final takeaways from our game development experience.

 

What Didn’t Go Well

1.       The musician wasn’t on-site

Gary, our musician, had all his recording equipment at his own home and he decided to work remotely. Since he wasn’t physically in the same room as the rest of the team, communication was infrequent and minor tweaks to sounds often took more time than it should.

For example, the first time he sent over the theme song, the volume was far too low and we couldn’t hear a single thing. We asked him to make it louder and the second file ended up being slightly louder, but also too low that the words sounded like muttering. We asked him to make it even louder and he took that to mean that we wanted our ears to be blown out. The third file was SO incredibly loud that we put it in the game and played it at 1% volume. We didn’t bother to ask for a fourth version.

Another problem was that Gary was pretty much working in a bubble, going off verbal descriptions of the game and written descriptions of how we wanted the in-game music to feel like. It would’ve taken us too much time to upload a build for his own eyes to see.

2.       Not testing the demo device earlier

From the very start, we knew we were going to demo the game using the artist’s laptop, since he had the biggest monitor. We built the aspect ratio of our game to match the laptop’s screen. What we didn’t take into account was that he was using a four-year-old machine.

When we finished development, we put the game on the artist’s computer and set it to fullscreen. Unfortunately, all the vector graphics had to scale up more than twice its original size. Tons of vector scaling plus a four-year-old processor meant an input lag that was about two seconds long. That may not seem like a lot, but one major element in our game is the ability to watch the shoplifter’s fingers and try to map it to an onscreen character. The two-second lag made it almost impossible to match key presses to character animations, since a character would often keep scurrying along after the player stopped pressing any keys.

We ended up having to optimize the code and convert a bunch of vector art to bitmaps, which only helped the problem a little. (C’mon, who optimizes during a game jam?) Thankfully, we lowered the computer’s resolution so that the game only scaled up by a factor of 1.2, which mostly got rid of the input lag problem.

3.       Not enough playtesting

Since the game is a battle of deduction and observation between two asymmetrical players, the balance between the shoplifter and the security guard had to be fine-tuned. If it was too easy or too hard for the shoplifter to blend in with the crowd, the game wouldn’t be fun for either player.

We needed extensive playtesting to reach this balance, but unfortunately we lacked both time and available testers. As a result, the game tends to become lopsided after a few rounds of practice: a well-played shoplifter can be almost undetectable, making the security guard’s job too difficult. While we had plans for a few subtle “tells” that could help the guard identify the shoplifter, we didn’t have time to implement them.

Our Final Takeaways

This year, we experimented with a minimalist version of the game jam: a lower-stress, less time-consuming experience that still produced a fun and innovative game. Even better, we all had a lot of fun making our game and are looking forward to doing it again! Remember that the game jam experience is all about you – the game developer – so you have the freedom to approach it in whatever way works best for you.

We’re planning to reassemble some of our team for a few other local game jams later this month, so look forward to more postmortems soon!

Shoplifter Shuffle Postmortem: Part 1

I am reposing this article that was submitted to my company blog here: http://blog.arkadium.com/shoplifter-shuffle-postmortem-part-1 .

Shoplifter Shuffle is a charming little game developed in 48 hours for the Global Game Jam. Two of us here at Arkadium contributed to the project – R&D developer David and game designer Brian– along with three other members from the gaming community.

If you haven’t checked out Shoplifter Shuffle, here’s the premise. It’s an asymmetrical, local 2-player game where one player secretly selects a character to be the shoplifter, trying to blend in with the AI-controlled crowd and get past security. The other player plays the security guard, looking for the shopper who’s acting out of the ordinary. The game doesn’t just take place inside the computer monitor, however. Since the two players are seated directly next to each other, the security player can closely watch the shoplifter’s fingers, while the shoplifter can do what he can to cover his hands or press decoy keys to throw off the security. The unique interactivity and fun presentation charmed the judges and our peers, and the game took home a nomination for the Most Innovative Award and won first place for the Audience’s Choice Award.

Some members of the team were experienced game jammers, but this year, they approached the game jam from a completely new perspective. We're here to give a short retrospective of the things that went well for us and a couple of things that didn't. For our Part 1 of the series, check out our breakdown of what went well:

What Went Well

1.       Using an additional time constraint

The Global Game Jam was 48 hours long, and anyone who’s ever had to make a game in 48 hours can tell you it’s not much time. In previous years at the Global Game Jam, we’d stay up all night working, sustaining ourselves with caffeinated beverages and scrambling until the very last minute.

This year, however, we were less inclined to pull all-nighters; four out of five of us are married and most of us had other obligations for the weekend. David (the programmer) had a sister visiting from overseas that same week, Brian (the designer) had to spend half his Saturday helping his brother move, and Gary (the musician) was repainting his house before his parents came back from vacation. Overall, we knew we didn't have 48 hours to spare.

So we said, “Let’s do it in 8.” That sounds crazy, but for us it was a breakthrough. It’s far too easy to let your scope get out of hand, even with the prior knowledge that you only have two days to work on it. The additional, self-imposed time constraint forced us to keep our scope as limited as possible and throw away any ideas that were even moderately big.

Reducing your scope not only decreases development time, but it has a useful secondary effect: it keeps your game simple. I can’t stress how important that is in a game jam environment where people’s interaction with your game is about 5 minutes long. A simple, concise game tends to “demo well” and leave a more lasting impression.

And yes, we did make our game in 8 hours. Well… we did spend 2-3 additional hours playtesting and fixing bugs, but that doesn't count, does it?

In the end, our schedule broke down this way:

On Friday night, right after the theme was revealed, our team went to dinner for some brainstorming. By the time we finished eating, we had found a concept we all liked, and we agreed to run with it. Rather than begin development that night, we decided to go home and start fresh the next day.

On Saturday, we met in the afternoon at David’s house and did pretty much all the art, programming, sound, and design work in one sitting (besides a short break for dinner). Most of us wanted to head home by midnight, and we cut a few features to make sure the game was code-complete by that point.

On Sunday, we met in the morning and did some polish, bug-fixing, and final balancing before the presentations started.

2.       Avoiding the obvious

In addition to the stricter time constraint, we had a second self-imposed rule going into the game jam, which was to not make the obvious. We didn’t want to present our awesome game only to find out that three other teams had the same idea. But how do we determine what is obvious and what isn’t? One simple trick is to take the first three ideas that come to mind and throw them away.

This year’s theme was the sound of a heartbeat. To us, the obvious three ideas were:

- A game about an actual heart, pumping blood or doing whatever hearts do.

-  A game where your character’s ability is directly mapped to their heart rate, e.g. they can jump higher or hit harder if they have a lot of adrenaline.

- An audio-based game where the sound of heartbeats gives you clues on your objective.

Not to say that these options were bad; in fact, Inde’, Pulse of the Samurai, and Silent Hunter followed these three ideas respectively and all won or got nominated for awards. But our team wanted to ensure we were completely original in both theme and mechanics.

We interpreted the heartbeat theme to mean tension and nervousness, which led us to discuss Edgar Allan Poe’s The Tell-Tale Heart and Chris Hecker’s Spy Party. We were drawn to the idea of one player keeping his identity secret, and having the secret be communicated by a heartbeat.

Jumping off from that point, we decided to make a multiplayer game about deduction, body language, and the tension players feel when they’re sitting shoulder-to-shoulder and competing – especially when one is keeping a secret from the other.

We used the heartbeat sound as a way to increase tension at a critical moment in the game. When the security guard is “looking at” the shoplifter (i.e., putting the cursor over the shoplifter’s character), the shoplifter hears a pounding heartbeat through the headphones. This the shoplifter’s moment to panic and think, “Oh no, they've found me!” and it makes for a more cathartic experience when the tension is resolved.

3.       Playing to the team’s strengths

We had an incredible 2D artist, whose specialty was drawing cute animated characters with tons of personality, and a musician with a quirky sense of humor. So straight off the bat, we knew that making something quirky and weird would be our best bet.

While choosing the theme for our game mechanic, we started off with a generic sniper idea similar to Spy Party, which later turned into a border patrol officer overseeing people crossing a bridge. These antagonistic and perhaps controversial themes didn't really fit our team’s strengths, however. We suggested a lighter paparazzi theme, where a photographer is trying to find a secretive celebrity among a crowd of AI characters. This worked better, though there are already similar paparazzi games out there. Finally, we settled on security guards (or “loss prevention officers”) trying to catch a shoplifter in a department store.

While this theme was unusual, it was also relatable to anyone playing the game – we’ve all had our receipts checked by these loss prevention officers before. Our artist really made the game come to life with his art, creating eight distinctive characters and adding all these little touches (like the NTSC scan lines on the security feed) that maintained a consistent visual style. Our musician also ended up writing a theme song to go along our intro screen, which turned out to be a hit among players.

Shoplifter Shuffle,
Stay out of trouble,Blend with the crowd,And stay in a huddle!

But of course every time you’re trying something new, not all things work out well. Check back tomorrow to see our breakdown of what didn’t go well, and our final takeaways from creating our game and working within a game jam!

NYU 9th Floor Talks: Creating an ARG

Frank Lantz, director of the NYU Game Center, gave a talk about Chain Factor, an alternate reality game that his company, Area/Code, developed for CBS.

Presentation

• Games were about human social interaction. In the modern era, games met computers and became more about the player's relationship to the machine. Recently, however, especially in NYC, people have become more interested in social interactions again and public space games have been on the rise. Some examples include Rockband, Payphone Warriors, physical space games, and real-world games.
• Area/Code was about real-world games, big games, and cross-media games. They focused on location-aware technology and games that connect or overlap with the real world. They transform public space and social media into new gameplay.
• "Area" stood for location-based media such as graffiti and billboards, while "Code" meant technology. The company had about 6-8 people doing work-for-hire.
• CBS approached Area/Code about making an alternate reality game (ARG) for their television show, Numb3rs. At that time, ARGs were really popular with the success of A.I's The Beast., ilovebees, Year Zero, and Perplexity.
• 42 Entertainment pioneered ARGS. The David Fincher movie called The Game also popularized the genre. ARGs are about reality hacking, making simulation seep into reality so that the players don't know what's real and what's part of the game.
• CBS actually didn't know what an ARG was. They would sometimes confuse it with MMO, LARP, Geocaching, and VR.
• Area/Code tackled ARGs and tried to solve traditional problems with the genre. Almost all ARGs are entirely unplayable, requiring advanced literacy of the genre and requiring players to be involved from the start. There was also no replayability given that they were focused on narrative, which plays out only once. Most people who say they love ARGs have actually never played them.
• They identified four core values of ARGS which are collaborative problem solving, participatory storytelling, puzzles, and a narrative and performative arc.
• The things that they didn't want to include were fake websites and blogs, improvisational writing and performances, and multimedia.
• The problems they wanted to solve were a difficult player experience, brick walls caused by puzzles, confusion, ambiguity, obfuscation, lack of feedback and rewards, lack of progress, the requirement of specialized literacy, multimedia, and the traditional flow of story to puzzle to story.
• Their gameplay goals included making it procedural, rule-based, emergent, fluid, accessible, suspenseful, dramatic, mysterious, challenging, intriguing, thought-provoking, and casual.
• They wanted to make an ARG around a casual puzzle game. Numb3rs also wanted to make an episode centered around an ARG. Area/Code helped the producers of the show write the episode. The episode, Primacy, was about an evil ARG game designer named Spectre who was making a game called Chain Factor.
• Area/Code wanted to make the game as a narrative artifact. They were inspired by several works including...
• Oulipo, an experimental narrative collective from the 1980s who did procedural generated literature. They wanted to make sure that the story was the puzzle.
• Maze, a choose-your-own-adventure book with illustrations of mazes. The book release was tied to a real-life prize for the first person to find the shortest path through the maze. The voice of the narrator was great and jester-like, and it served as an unreliable game master.
• Masquerade, another book that was tied to a real-life treasure hunt. There were clues on every page that led to the location of a golden rabbit.
• Pale Fire, a novel where the theme of the story was expressed through its structure. The writer himself is a fictional character in the novel.
• Planet Puzzle League, a casual puzzle game based on Panel de Pon. It exhibits both lightness and depth.
• Chain Factor's pre-production was suppose to be 30 days. Kevin Cancienne, the lead programmer, was suppose to develop a new prototype everyday for 30 days, to which he said it was "bullshit." The team built one prototype, which ended up being Chain Factor, and then stopped. It was already really fun.
• The prototype was very configurable, which allowed the team to discover the best version of the game and find the fun. The paper prototype before the digital prototype took about 10 minutes.
• The core mechanic of the game involved dropping numbered discs into a grid. When a number on a disc matches the number of adjacent discs in that row or column, that disc disappears.
• On the Chain Factor website, there's a quote of the day and a FAQ, both sometimes with deep philosophical text. While playing the game, there would be random error messages that tell the backstory of the two developers, Spectre and Frank.
• Power mode has locked boosts that can be unlocked by entering multiple keycodes. These codes were hidden all over the place outside of the game, including in the Primacy episode, posters and billboards in the real world, fake banner ads on websites, forums posts, and television spots. When you find and enter a secret code, you'd get an e-mail from Spectre.
• The error messages that told the backstory were based on score, so people had to actually get good at the game to get the clues.
• The backstory revolves around Spectre creating a global mathematical scheme. Millions of players thought they were just playing a simple puzzle game, but were actually solving and cracking a large-scale math problem. Spectre is trying to pull off a giant bank heist by crowd-sourcing math problems.
• The gameflow was story, clues in the real world, unlock powers, obtain a higher score, and get more of the story.
• The fans created an elaborate wiki that reassembled the game's structure. 
• The core puzzle game was really good. Margaret Robinson of Lookspring wrote an article about how much she loved the game and she eventually married Kevin Cancienne.
• Casual players were playing so much of the game that they were actually unlocking the error messages. They gradually became more involved with the ARG mystery.
• Later, it turned out that Spectre's plan wasn't to steal money from Wall Street. He studied economy and was an anarchist. He believed the world was in dystopia and wanted to destroy the world economy.
• This story was inspired by Ant Colony Optimization and the works of Luis von Ahn, who created Captchas and the ESP game, both games that solve real-world problems.
• The theme of the story was reflected in the structure of the game. Both the story and the mechanics were about distributed computing.
• Erik Wolpaw has stated that there are two kinds of stories, the story story and the game story. If he ever made a game, he would reduce the delta between the two types of stories to zero, which he did when he made Portal.
• The climax of Chain Factor was a "shootout" between Spectre and the hired programmer, Frank. Frank grew suspicious of Spectre's plans and built a backdoor in the code to foil his plans. While Spectre's mode was the Power Mode, Frank's mode was the Survival Mode. Whichever mode acquired the more accumulated points gave that person the power to carry out their plans.
• In the end, it was a race between the casual players who were mostly playing Power Mode and the ARG players who were trying to sway the victory towards Frank. However, some ARG players also wanted to see what would happen if Spectre won. Finally, Spectre wins in the end. The ending is a note from Spectre planting a time bomb of economic destruction and promoting distribution over accumulation. Of course, Area/Code couldn't actually crash the economic market so in the story, Spectre was merely planting the seeds of his plan. A month later, the market literally crashes and it was a great coincidence that pushed the story of Chain Factor.
• The game played on the moral status of game choices. However, ARG players knew that it was a fictional narrative and they wanted to see how the story would play out.
• The core puzzle game was a success. The puzzle game was an excuse for the team to make a simple abstract puzzle game instead of the large, real-world, cross-media games that they were used to.
• Using the game as a narrative artifact led to its oblique and eccentric personality. The team needed to make a game about math and numbers to tie in with the television show, and it turned out quirkier than it would've without the story. It's good to embrace constraints because it helps guide you to solve problems.
• Combining opposites (an abstract puzzle game with an ARG) also led to the game's success.
• The core puzzle game was strong enough to live on its own and the mechanics were repurposed for the iOS game, Drop7.

Question and Answer

• CBS approached Area/Code about making an ARG, but didn't exactly understand what an ARG was. It was the summer of ARGs and they were going with what was popular at the time.
• Numb3rs fans didn't really play Chain Factor, and vice-versa.
• The narrative was all laid out in a spreadsheet.
• The game ran for four months.
• Players self-organized their community.
• How did the team design around the ads and how long it would take for players to solve the puzzles in the ads? The team assumed that once the ads were found, then the puzzles were solved, which proved to be true while the game was running. One of the animated ads was suppose to be shown at a mall. Unfortunately, the mall didn't run the ad so Area/Code faked a video of the ad and posted it on the forums.
• Drop7 does not share any code or assets from Chain Factor, only the game mechanics. Game design cannot be copyrighted.
• CBS wanted to find a company to help them do non-traditional advertisement. Area/Code couldn't guarantee that they'll bring more viewers to Numb3rs, but they did guarantee that they'll do something quirky and interesting that would engage a lot of people.
• ilovebees was a good inspiration for Chain Factor because of the phone booth mechanics.
• Chain Factor did not integrate any live events because they wanted accessibility for everyone. They also already do so many live events in the other games that they were aiming to do something different.

NYU 9th Floor Talks: The Cutting Edge of Game Research

Ken Perlin, a Computer Science professor at NYU, presented some of his cutting edge research in procedural animation and education games.

Presentation

• Ken is the founding director of NYU's Media Research Lab and the Director of the Games for Learning Institute. He is a mathematician who has won an Academy Award for his noise and procedural texturing techniques that have been used in film and television.
• Ken started his career in computer graphics. Being in the industry for so long, he has experienced the power of Moore's law, seeing computers get twice as faster every two years.
• He has developed several hundred Java applets. Some of his work can be found on his NYU homepage (http://mrl.nyu.edu/~perlin/).
• When researching something, you have to boil it down to the simple possible version.
• One of Ken's biggest research interests has been conveying emotions through artificial characters.
• In Polly's World (http://mrl.nyu.edu/~perlin/experiments/polly/track.html), Ken tries to convey emotions with the least possible number of vertices and polygons. The procedurally animated character is made up of only 6 vertices, but displays a wide range of emotions through its movements. Our brain maps simple animations to emotions.
• Why do we care about animated characters? Ken researches the human body as an instrument to understand psychological emotions.
• In Responsive Face (http://mrl.nyu.edu/~perlin/experiments/facedemo/), Ken researches what's the simplest emotive face possible. At the very least, an emotive face requires movements of the eyebrows, lid, gaze, head, and mouth. A person has n-points in the face like a keyboard has a number of notes and facial expressions are like chords.
• Micro noise movements and procedural variations makes the emotions more realistic. Without these micro movements, the face is just a lifeless still picture.
• Autistic children have trouble looking at other human's faces and thus grow up not knowing how to read emotions. However, they don't have that problem with artificial, computer-generated faces. Many autistic children used Responsive Face to learn human emotions.
• Plan 9 From Outer Space, often regarded as the worst movie ever made, is almost unwatchable because the acting is so bad. The actors' faces are so emotionless that it's impossible to identify with the characters.
• In an attempt to create an "interactive Pride and Prejudice," Ken developed an applet with five birds with disembodied feet. The birds showcase procedural walking animation, which is tons better than canned animations.
• We should think of avatars the same way a director thinks about actors in a live play. We shouldn't communicate actions to the avatar (ie. "jump here", "punch that", "open this door"), but communicate emotions (ie. "you love her"). Likewise, actors shouldn't indicate (ie. "I am feeling happy!", "I feel very sad."), but actually emote.
• With Fish Tales (http://cims.nyu.edu/~perlin/fishtales2/), players can record a one-minute story using Bob the fish and two bouncing balls.
• In Candy Circle (http://mrl.nyu.edu/~perlin/candycircle/), players make procedural music using a spinning wheel filled with candy. It researches the rule of the fifths; when the further away the chords are, the more dissonant the sounds are.
• Ken also experimented with spiral escalators (http://mrl.nyu.edu/~perlin/escalator/). Spiral staircases always go right going upwards because they were designed solely for battle. Since most knights were right-handed, it would give the advantage to the person who's above.
• The barrier of entry to making games is so high. Ken would like to have more people coming into the arts that are enabled by programming.
• There are "fake languages" such as Code Do It and Scratch that enable people to jump into programming. Ken is researching how to make programming more integral to education.
• Ken's New Line Fractals (http://mrl.nyu.edu/~perlin/newlinefractal/) show mathematical visual examples of fractals. Students can move vertices around to experiment with creating their own fractals.
• Using a real-time interpretive version of Java, Ken created Flower, in which students can directly edit the code and immediately affect the flower. In Musical Rubber Ducky, students can affect the ducky but also the music too using live code. Can we invite them to the narrative as well?
• Ken developed a Pride and Prejudice reader. Before the invention of books, literature used to be written on scrolls. Someone later introduced the concept of pages, a fixed length record that changes per edition. But writers wrote and thought in terms of sentences and paragraphs, not in pages.
• In this interactive map of Pride and Prejudice, you can see the entire book's topology. You can easily identify the key chapters of the book using filters and highlights.
• Asteroid is a game that topologically and mathematically exists on a torus or a doughnut.
• The second book to use the interactive map is Winnie the Pooh. This version also includes a procedurally animated bear that users can play around with using live coding. The code editor includes tools that enable learning programming easier. When you insert a 2D array, a map will appear that lets you set dots and automatically generate the points in the array for you.
• Everyone should be able to program. It should be as accessible as painting, filming, and writing. People need immediate feedback to instigate learning.
• Ken is really interested in how to power up this maker culture.

Question and Answer

• Learning tools should be like Google Docs in that they are collaborative, shared documents. People should have conversations with each other about creation. Learning is a performative activity.
• Just like how jazz is to music composition and improvisation is to acting, we need live perfomative structures for coding to learn programming.
• What's the difference between games and simulation? Games have goals.
• We need to increase programming literacy and convey programming as a liberal art. Kids need to look at code in their early stages.
• Ken remembers reading a children's book when he was a child and at the end were the advanced notes for the teacher to read. Although Ken couldn't read the notes as a child, he understood that that's what he was learning and that he'll eventually be able to read the advanced text. Kids shouldn't be using a fake language, but rather be looking at what the grown ups are using. They should be exposed to C++ or Java-like languages.
• Kids are learning reading through other subjects such a history and science. We should teach coding gradually in the same way.
• Many people are reluctant to learn coding, but that's okay. We should focus on teaching the kids. We don't currently live in a society that requires that level of technical knowledge, but this might change ten years in the future.
• Excel is a programming environment that many people use, despite not being programmers. Max/MSP is a programming language that non-programmers such as visual and sound artists use. Both of these programs are always running live and give immediate feedback. There's no intermediate building or compiling stage.
• People don't necessarily need to learn C++ or Java the same way that not all writers have to linguists. Guitarists don't need to learn how to make guitars.
• Programmers have a sense of being macho. Music, on the other hand, is more inclusive. We need a real-time sharing structure and a more inclusive environment for non-programmers.
• Will books become non-linear in the future? This may very well happen, but it won't replace the books as we know them. Different media can coexist the same way that different instruments can coexist. It's not all about hacking and recombinations. Technology is the wrong word to describe media; these are instruments.
• Will the secondary functions of the interactive reader overshadow the literary work itself? The work lives on if they're great. Beethoven lived on when the Beatles came around and the Beatles didn't go away when Lady Gaga came around.

NYU 9th Floor Talks: Bennett Foddy on Creative Practice

Bennett Foddy, creator of QWOP and GIRP, gave a talk at NYU Game Center about his creative practices.

Presentation

• Bennett breaks down his creative practices into five principles.
• Principle #1 - Put down the controller and think outside the computer.
• Figure out ways of input before you start developing your games with the computer.
• His latest game, Get On Top, is played with two giant trampolines with Playstation move controllers strapped underneath them. Jump on the trampolines to make your character jump.
• It's a wrestling game where you have to get your character on top of the opponent's,
• He was inspired by Japanese arcade games that utilizes large elaborate peripheral controllers.
• There was a fan critique of Armored Core's control scheme, which almost demands players to have 15 fingers and constant active input of the face buttons. One fan joked that the best way to play the game is to turn the controller around.
  
• Although this was just a joke, Bennett thinks it's pretty cool and sees it as an opportunity. Why not make a game that requires you to play like this? The control scheme is complicated and clumsy, but there can be an interesting game that can come out of it.
• The NES controller is very simple and recognizable. It only has a directional pad and two buttons, essentially giving players the total of 3 verbs. But designers should start thinking of their game design in terms of verbs first, and then map the controller to their actions.
• Principle #2 - Integrate
• In Fable 2's seduction minigame, a radial HUD with icons appear. The player's attention moves towards the icons and bars, and the characters and world are faded to the background. The HUD becomes the focus and distracts from the world.
• Health bars are a non-integrated system. They are out of field and floating in the air, and breaks the players' immersion. Fighting games are a genre in which fans and developers alike claim that health bars are completely essential. But even fighting games can deal with health bars. For example, Bushido Blade is about fast-action and one-hit kills.
• Bennett's own fighting game for Indiecade, Fistmonger, has no floating health bars. Both fighters are standing on top of a cliff and the point of the game is to knock the other off. Instead of health bars, every time a fighter is hit, the clifftop degrades, making it easier for the fighter to fall off.
• In Tim Roger's Ziggurat for the iOS, your shots will explode and you can cause chain explosions. This combo system is invisible to the player and never shown onscreen.
• CLOP's difficult ramp is an actual ramp.
• The 2nd room of VVVVVV has a difficulty spike in the form of a floor of spikes.
• QWOP and Super Hexagon have integrated rules. You immediately know what to do when starting the game. Non-integrated rules need to be explained.
• Principle #3 - Build for immediacy
• Don't include a tutorial in your game. Tutorials rob players of any sense of discovery and exploration. It's like a person who always finishes sentences for you.
• Good examples of non-tutorial games are Limbo and Bennett's own cricket game, Little Master.
• Bennett attaches a MIDI mixing controller to his games and connects every relevant variable to a slider. He can tweak fast and test all variables in real-time.
• No tutorial leads to discovery which leads to elation and satisfaction.
• Princple #4 - Play with the player
• The developer's role is traditionally like a mentor or a tour guide. Bennett likes to have a warped perspective of this relationship.
• The developer should be standing in for Player 2, trying to defy, confuse, and embarrass the other player.
• In Secret of Monkey Island, there is a fishing minigame where a bird comes in at the end and steals your fish. Inspired by this, at the end of GIRP, when you reach for the gift box at the top of a cliff, a bird might swoop in and steal it.
• In CLOP, many players might exploit the game by only using the horse's front legs to drag the rest of the body forward. The game can catch players doing this and unlock the "Lame Horse" mode where the hind legs become paralyzed.
• By reacting to the way the players play the game, you can play together.
• Watch players play through a designer's eye.
• During playtesting, don't fix your game based on one playtester failing. If the player is lost in the maze, it doesn't mean you should remove the maze.
• Proteus has no tutorial.
• In Eradica, if you put the disc upside-down, the intro screen would be shown upside-down as a prank.
• Playful tricks have a personal contract between player and developer. It makes the player more aware of the game maker.
• Principle #5 - Push, don't press
• This principle is derived from a Jonathan Blow quote.
• Pushing is understanding the promise of game design.
• Don't do the obvious because it's not surprising to the player. You have to push yourself to find more.
• Push the mechanics to their limits and exhaust their functions, but don't force the mechanics to be more interesting than they may turn out to be (pressing).
• Bennett's Sun God is a game where two characters are tethered by a rope. It's a player game that can also be played by one player (just like a xylophone). The characters leave cherry blossom trails.
• Bennett was happy with how the game ended up looking, but not so satisfied with its gameplay. He might have pushed too hard. He forced the tether mechanic to work, instead of scrapping the idea when he realized it wasn't working.
• "The most creative are no different in IQ with their peers, but are able to get themselves to a specified mood to be most creative. They get themselves into a state of play and exhibit childlike behavior." -- John Cleese
• Alfred Hitchcock would sometimes tell completely irrelevant stories during stressful times on set. While odd to many of his colleagues, he did this deliberately to ease his cast and crew and get them into a mental state of play.
• It's easy to tell forged signatures from real ones. Forged signatures starts and stops, while real signatures flow naturally. This is similar to calligraphy vs. sculpting from stone marble.
• SVN makes your creative thinking too safe. Game design decisions feel like they don't matter anymore because you can always just rollback to an earlier version. Game jams and prototypes solve this problem because they keep games small and light.
• Long full production of games is a drudgery that takes away from the fun of the prototype.

Question and Answer

• What's a light physical game? Catch.
• Jesse Schell has said to make a fun toy first.
• There are different types of frustration and Bennett thinks that in-game frustration is good.
• Bennett's games require a bit of literacy of technology. But relying too much on literacy and conventions would limit your game design.
• Bennett wants to make a game where you play as a bird and is pushed out of a nest. You have to learn to fly immediately. This is an appropriate metaphor for how he wants players to play his games.
• Hokra is a game that Bennett thinks is easy to get into a state of flow because it has an easy learning curve.
• Bennett's has had several collaborations in the past including the boxing game with Tom Rogers and Get on Top with Douglas Wilson.
• Designers should learn to code.
• Don't be too systemic and delete changes. Knowing that you can possibly lose everything liberates you to make big changes and take risks.

Searching for Fun: Procedural Content Generation as Search and as a Necessity

Julian Togelius, an associate professor at the IT University of Copenhagen, spoke about the necessity of procedural content generation in game development. His main research interests include game AI, adaptive games, player modeling, and procedural content generation.


Presentation

• Procedural content generation (PCG) is the process to create content with zero or limited human intervention. PCG is done algorithmically. It does not necessarily mean NPC behaviors or game mechanics, but content, which includes levels, maps, terrains, dungeons, puzzles, quests, rules, characters, parameters, and rewards.
• PCG is necessary. Developers don't have the time or money to generate all content, especially in this age with high development costs. Players burn through content way faster than developers can design and implement them.
• Elder Scrolls: Skyrim is a huge success, partly due to some of its PCG nature. It pushes its budget just a bit more.
• Games with PCG include Elite which is a huge game that fits in Commodore 64's memory, Rogue, Diablo, Dwarf Fortress, Far Cry 2, Speed Tree, Civilization IV, and Borderlands.
• However, PCG sucks. It's unreliable, uncontrollable, lacks macrostructure, can produce boring and generic results, is poor with animations, and can't represent style.
• The future of PCG is search, the need to check generated results. Populate with multiple generations and pick the best choices. This is an evolutionary computation. Keep a population of candidates, remove the bad based on a fitness algorithm, and keep repeating until the remaining candidates are good enough.
• Evolutionary computation allows exploration of larger design space and better control. Most importantly, it avoids catastrophic failure where fitness equals zero.
• Julian developed a PCG system that created Starcraft maps. For the fitness functions, he looked for terrains that would create interesting game events such as choke points, paths from one station to another, enough resources in each area, and blockages. However, the generated maps were poorly received by playtesters because Julian believed that asymmetrical maps were more interesting, but hardcore Starcraft players would only play in symmetrical maps.
• When representing a dungeon, you can create a PCG function based on a grid. Getting more abstract, you can simply create the system based on position and direction of walls. Getting yet more abstract, you can generate based on patterns of walls and floor. Even more abstract, you can define just the number of rooms and doors.
• Cameron Brown's Ludi and Yavaloth are procedurally generated board games, not that its in-game mechanics are procedurally generated but the game design was all generated by a computer. The title Yavaloth itself was also procedurally generated.
• Julian created Infinite Super Mario Bros, a PCG take on Super Mario World. The levels were procedurally generated and during playtesting, testers were asked to rate the levels based on fun, frustration, and anxiety. Using this data, the system created better levels in an exhaustive search for optimal parameters.
• Galactic Arms Race is a PCG game where weapons would constantly evolve based on the collective player-base.
• Infinite Tower Defense is a PCG tower defense game where enemies learn player patterns and develop new tactics. Meanwhile, the player gets PCG weapons based on their most commonly used weapons.

Question and Answer

• Improviso is a puppet theater game about acting. It is a multiplayer game which pairs players anonymously online to dramatize a story together. Meanwhile, an AI system collects data from thousands of players and once trained, it can autonomously play the role of one of the characters in the play.
• Can you represent the game rules as a vector such that it simulates a new player who doesn't know how to play and then builds levels that fits the simulated player? For example, in the original Super Mario Bros., the levels slowly teach the player new mechanics as he progresses through. This can be computationally expensive.
• The most memorable PCG stories are the failures. Nobody remembers the successes.
• Can the game "yes, and" the player? For example, the game builds itself around what the player is expecting to do. The game sends a slow walking enemy towards the player, expecting the player to jump. Whatever the player presses to jump, that becomes the jump button for the rest of the game.
• Julian developed a game where you drive around a car in a field of colored blocks. The player can set up specific causes and consequences. For example, whenever the car hits a red block, create two green blocks. While the player is setting up these rules, the game itself is trying to figure out what the goal of the game is and it builds additional rules to reinforce that. In this way, it is yes-anding the player, but it became clear that things get really chaotic very fast. Yes-anding only works when both sides are in agreement with each other.

Beyond the Television Screen

I just wanted to share a story of a neat game I played a year and a half ago.

On September 23, 2006, my friends and I attended a gaming event called the Manhattan Story Mashup held by Nokia, the mobile phone company. Over 250 participants showed up, each given a Nokia N80 cellphone a few days in advance. The cellphones came with a pre-installed game that was to be used at the event. The setup of the game is quite complicated so let me try to explain.

People would write short stories and submit them to the website. The nouns from the stories were selected to be "target words" for the players at the event. Each player would receive a random target word on their cellphone at regular intervals. They would then need to run around New York City, using the same cellphone to take pictures that would accurately convey the target word to another person. The pictures in turn are sent to two other random players and the two players must race against each other to guess the word that the picture represented in multiple choice fashion. Guessing the correct word would earn the player points, and likewise, the player who took the picture would receive points for being a good photographer. Were you able to catch all that? No? Well, I made a diagram to help you better understand.
At the very start of the game, my friend Gary and I headed downtown from Columbus Circle to Times Square. We both knew that Times Square would be the perfect place for picture taking, since the area is littered with commercial images and hundreds of people in motion. Our strategy paid off since we found a nice spot in front of the police station, where we took thirty to forty pictures that other people were able to match with the correct target words. By the end of the game, we finished with 412 points (which coincidentally, is my favorite 3-digit number), placing us in first place in the competition.

Many of the participants, including Gary and me, were really doubtful of the game before it began. It sounded like a cheap marketing gimmick and required too much investment. But we grew to love it as we played and coming out as the champions wasn't too bad either. The Story Mashup was a fun experiment to turn a video game into a social event, to take it beyond the television screen. With the Nintendo DS having Wifi and iPhones becoming a viable gaming platform, I would love to see a game of this caliber developed for those systems. This is all just wishful thinking...