GDC2013 - Mad As Hell: Hothead Developers Rant Back

• Karen Sideman, of GameLike, says she's not a psychopath but she plays one in game. We need healthier relationships with NPCs. She remembers playing Warcraft and commanding a two-headed ogre, one head that says, "I'm ready!" and the other saying, "But I'm not..." Characters in games were just game pieces before. Now there's a lot of narrative overlay there, but we're still manipulating the NPCs like game pieces. If we're doing this in any other context, we'd be labeled as psychopaths. Read The Psychopath Test: A Journey Through the Madness Industry by Jon Ronson.
• Anna Marsh, of Lady Shotgun, rants against crunch in the game industry. We don't have to work 18 hour days to make games. There's an unwritten rule that if you work in games, it becomes your life. But studies have shown that long hours are not productive if not even less productive. Management who relies on crunch is incompetent and we end up devouring ourselves. We need pre-production phase. We shouldn't just experience games; we need more experience outside of games. The raw material for our creativity is our experience and if we spend all our time immersed in games only, then our games are going to get more and more incestuous. Let's work efficiently and not obsessively. Rest makes better games.
• Mitu Khandaker, of The Tiniest Shark, rants about race. Only 20% of the world population is white, but this is not true of games. Racism is a systemic thing. It's wrong to think that white is default and color is the other. When Mitu's company announced the game Red Shirt, there was a brown girl on the cover and everyone assumed it was modeled after her as if characters in games are always autobiographical. It is not a "politically correct" thing; everything is already political so treat it as such. As creators of content, we are the ones who get to define what "normal" is.
• Kellee Santiago ranted about innovation in games. There's a myth that developers can become rich by releasing a hit game. This didn't happen for the developers who made Journey. There are new alternative funding possibilities like Kickstarter and Indiegogo, which are great because traditional publishers are not interested in innovation. Sometimes, a publisher would say they are interested in games like Journey, or Ico, or Flower, which sounds enticing to a developer. But then you realize they mean just that... they want Journey 2, Ico 2, and Flower 2, not another innovative game. There's a few indie developers who hit it rich like Minecraft, Dragonvale, and Clash of Clans. These developers have the power to change the industry. A similar thing has happened in the art world called the Renaissance, which wouldn't have happened without the patronage from rich people. The revolution has barely begun. We need to make innovative games and there are already many people who are out there making them, but we also need the press to cover the innovative games.
• Scott Jon Siegel won the "Duct Tape Award" for giving the best rant from last year. Last year, he promised to make more games and give less talks. Looking at his progress over the year, he ended up making no games and giving no talks. He was pressured too much to make a good game and the pressure caused him to completely fail. So he started making bad games. Games don't need to be good to have value, they just need to be. We are making games for ourselves too, as much as we are making them for the audience.
• Chris Hecker's gave a rant called "Fair Use" without speaking a single word. You can watch his rant here: http://www.youtube.com/watch?v=kXnoW2SvQrQ .
• Anna Anthropy recited a poem addressing gender issues in the game industry. You can read the transcription and watch a recording of it here: http://www.gamesindustry.biz/articles/2013-04-03-hothead-rants-pt-3-anna-anthropy .
• Naomi Clark ranted about cinema envy. She talked about the "New Hollywood" or "New Wave" period in film where people wanted to make more edgy, politically charged movies. Some films like The Spook Who Sat By the Door, which was about the civil rights struggle in the United States, got in trouble by the IRS and was removed from theaters. This is the kind of thing that us game developers should get in trouble for, not for being potty-mouthed teens obsessed with boobs. We need to approach political issues in games and one suggestion is to create games that come from anger. There are a few games that do this right now like Unmanned, Keep Me Occupied, and Half the Sky. But change doesn't come from a single game, it takes a movement. Apple is rejecting Sweatshop and Phone Story from the App Store, and this is the start of our movement.
• Margaret Robinson, of Hide & Seek, hates people. We are everywhere, we're an infection, we're a disease that creeps into every game. She hates Game Center, she hates X-Box Live, she hates Ascension noise. She also hates GDC and all the intelligent, expressive things that developers say. Now, she has to do the same thing. She reacts strongly to multiplayer games because they're so powerful and emotionally revealing. Her identity is revealed when playing games. She loves making games, but there's something weird in her head that stops her from accessing them.

GDC2013 - Three Folk Games to Inspire Radical New Video Games

Doug Wilson talked about three folk games that can inspire new video games.

• Doug is best known for Dark Room Sex Game, B.U.T.T.O.N., and Johann Sebastian Joust.
• Folk games are traditional, ethnic, or indigenous sports and games. They include physical games like Tag, Jump Rope, Ninja, and many card games. They often use simple and common equipment like balls and ropes, are spread by word of mouth, and commonly have "house rules."The folk games that Doug is interested in are the physical and silly ones.
• Why look at folk games? They require a different way of thinking. Also, paper prototypes can't simulate physicality and game feel, but folk games can prototype motion control.
• Folk Game #1 - Standoff
• This game requires three or more players and is similar to Rock-Paper-Scissors.
• Each player has three choices -- shoot someone else, shoot themselves, or shoot the air. If you're shot at, you're eliminated. If you shoot yourself and nobody is shooting you, you're eliminated. But if you're shooting yourself and someone else shoots you, you're safe and you reflect the shot back at your attacker. Shooting the air is the conservative option but is also defenseless.
• You can play the game with a house rule of using two hands. Two beats one (two guns at you goes through your shield).
• Another house rule is having three lives represented by standing, kneeling, sitting, and finally laying down when you're dead.
• Takeaways from Standoff
• Game gestures should feel good in and of themselves. It feels good to make a gun with your fingers.
• It doesn't matter that the narrative doesn't make sense. The logic of shooting yourself to reflect a bullet doesn't make much sense, but it makes the game silly and approachable for people to play. The "wrong think" has weird warped logic, but it feels authentic. Many motion control games take themselves too seriously and therefore feel awkward when the controls don't quite work. Good examples of silly motion games are Cash 'n Guns and WarioWare: Smooth Moves.
• House rules are an integral part of the game. Games should be easy to modify and add rules, so that people feel ownership. With Johann Sebastian Joust, people modified the game to put the Move controller behind their backs instead of holding it with their hands.
• Folk Game #2 - Listelanse (Sneaky Lance)
• This is a two-player game where both players are blindfolded and holding big wooden spoons. Both players move slowly towards each other and try to hit the other player with the spoon.
• Loud music is played to add tension and also make players not being able to hear themselves. The crowd can shout commands and hints at the players.
• The game is very silly and performative. You feel like a badass because you're blindfolded, but you look like a fool to everyone else.
• Takeaways from Listelanse
• Moving in slow motion feels really good and was a big inspiration for Johann Sebastian Joust. Build the game around an existing activity, gesture, or motion that's already fun. Spectatorship, performance, and physicality should also be a source of inspiration.
• Physical gaming and rich multimedia make an excellent pair. The lights and sounds that are employed add tension, and also set the tone of how to act. Johann Sebastian Joust plays Bach's music, which makes players feel like baroque gentlemen. Lemon Joust was a similar game that was independently designed, but in many ways, Johann Sebastian Joust was more effective with its usage of Playstation Move's light and the music.
• Folk Game #3 - Danish Clapping Game
• This is a game for 2-6 people where each player clap their hands on their knees and then perform one of three actions (move their arms left, right, or up in the air). If players happen to mirror another, then their next action must be to clap each others' hands, changing the rhythm of the game.
• One house rule that Doug plays with is when players mirror each other by raising their hands in the air, their next action is to jump up in the air, high five the mirrored player, and yell "Yay!"
• When playing with more than 2 players, they have to pay attention to both their left and right sides.
• Takeaways from Danish Clapping Game
• Mimicking is fun. Doug designed a game based on mimicking called Monkey See, Monkey Mime. This goes back to a previous takeaway: build around and existing motion that's already fun.
• Comedy and physicality is fun. Doug thinks of motion control as slapstick comedy. Physical games foregrounds what happens in front of a screen.
• Design for spectators, not just for players. Kinect Party is a good example.
• General takeaways
• Folk games are not always just a direct inspiration. For example, playing Standoff with iPhones is not fun.
• Fingle is a good example of people congregating around one device. 
• Space Alert  is another good example of a board game taking some folk game inspiration.
• Resources
• Junkyard Sports by Bernie DeKoven.
• The Well-Played Game: A Playful Path to Wholeness by Bernie DeKoven
• The New Games Book by Andrew Fluegelman
• Come Out and Play Festival
• You Are Go! festival by Invisible Playground
• Recollect camp games you've played as a kid or games you've played in college for inspiration. Always talk to friends about the games they've played.

GDC2013 - Prototyping: A Developer's Best Friend

Simon Darveau of Spearhead Games talked about the value of prototyping.

• The most important lesson is to "follow the game's will."
• Simon worked on Petz Sports and the Assassin's Creed series. Petz Sports was designed entirely on paper first. 90% of the stuff did not end up working in the digital version.
• He believes that a revolution is coming. There are four steps in creating a game... 1) identify the high level goal, 2) build core mechanics and experience, 3) defining the most amazing content, and 4) producing the game. Simon is best at the third step.
• 12 advices for prototyping

1. A game has its own will. Follow the fun and it's not always where you thought it would end up.
2. Think inside the box. Start with familiar mechanics and add a twist. Don't rely on mechanics that haven't been proven yet.
3. Escape from prisons of paper. Don't use a game design document because it's the wrong medium to express interaction. It's not only boring to write, but it's too abstract. Destroy any paper process and get the team talking and working together by day one. It promotes ownership and faster development.
4. Prototype in the same game engine you are using. Don't play with another beast and realize that it cannot be ported back into your engine. Also, don't make several different parts outside of each other and then stick them back together because there are lots of integration issues.
5. Iteration time is of the essence. Don't make one map of your three-week schedule; make 3 maps per day. it will force you to simplify what you are trying to do.
6. Try everything, generate chaos.
7. Merge game and level design. If you're a game designer, you should not push any feature without proving it out yourself first.
8. You don't know what your searching for until you found it. Prototyping is not a validation tool, it's an experimentation tool.
9. Refine your diamonds. After you find the mechanic, iterate and polish it so you can communicate your ideas to others.
10. Make your prototype open source. Playtest it a lot with everyone and get as much feedback as possible.
11. Be humble and confident. Don't be afraid to fail and be ready to fail all the time.
12. You need ninjas, not warriors. Warriors see their games as products and will just do what they're told. Ninjas are the true developers, not afraid to ask questions and explore.

• There's no official prototype validation process. Just play internally with the team and the gems will rise to the top.
• Prototyping is not shooting in a random direction. You must know where you're going.
• Don't use paper documents. It frees you up to discuss changes as a team.
• Convince management that prototyping is worth it. The best way to do this is just make the prototype and show them the value of it.

GDC2013 - Introducting Machinations: A New Way to Design Game Mechanics

Ernest Adams and Joris Dormans introduced their tool to design game feedback diagrams.

• There are many types of game mechanics - physics (running, jumping, ballistics, vehicle), economy (collecting, resource management), progression, tactical maneuvering, social, etc.
• Internal economies appear in most genres. There are many prototyping methods (paper, spreadsheets, software,), but machinations offer a fast, cheap, flexible, and easily playtestable solution. The only thing that machinations have trouble prototyping are physics.
• The motivation for the framework is to visualize overall structure of game mechanics and economy systems. There are various attempts to systemize game design, but they often try to do too much. Machinations focuses on economic functions and entity flows.
• Machination diagrams include four main components -- nodes (entities and economic functions), resources (that move between nodes), resource connections, and state connections.
• The tool offers templated design patterns such as the dynamic engine. In a dynamic engine, a source produces an adjustable flow of resources, players can invest resources to improve the flow, there's a trade-off between short-term and long-term investment, and players upgrade until a certain point and then the game switches over to another system.
• Another design pattern is the multiple feedback system, in which a single mechanism feeds into multiple ones, each with a different profile. This increases difficulty and learning curve.
• You can create diagrams to map economies of space exploration games or even first-person shooters.
• Machinations is no silver bullet. It's a prototyping tool designed to explore game economies. It is better to focus on general structure of the entire game or a detailed structure of individual mechanisms.
• Future features include multipage diagrams, hierarchical design,, user-defined nodes, standalone app that doesn't run on Flash, and actual integration into game engine architecture.
• Machinations allows developers to prototype internal economies, facilitate understanding of complex dynamics and emergent systems, and allows methodological approach to game design.
• Start using Machinations at: http://www.jorisdormans.nl/machinations/

GDC2013 - Microtalks

In this panel, a handful of game developers each had five minutes to talk about a topic of their own choosing.

• Leigh Alexander (Gamasutra, Sexy Videogameland) is a writer who rarely writes game reviews because she believes it's the job of the press to go beyond product reviews.
• She also wants more diversity and initiatives in the triple A space. She hates that marketing is gutting things done by teams.
• "I've heard this game couldn't have a black hero because it wasn't going to sell. You have to basically do what the market leaders do or else no one will buy your game." 
• Marketing sometimes makes stupid decisions like selling Dead Island with a statue of a bloody female torso or promoting bullying with the latest Hitman. We need marketing to sell joy, not sex. Don't just make decisions based on numbers, but support the industry. 
• "We have a serious image crisis right now. Marketing can sell crap, but it's failing to sell truth and joy. We need a fresh perspective. If you work in marketing and you just want to make numbers, please work in another industry. It'll be better for everyone."
• Tom Bissell (Gears of War Judgment writer) talked about storytelling in games.
• Tom wrote some novels before becoming a games writer. Games are low on the list of mediums for writers.
• "Big action video games are not and never will be, a writer's medium. The writer doesn't steer the story, the gameplay determines the story, the player steers the story. The writer contextualizes gameplay and grounds the player's experience in the story."
• In game development, script sequences came from developers. The script had no context, and dialogue moments were written without even knowing where the content would fit within the game.
•  "The problem was we were writing dialogue that took place in environments we hadn't seen, after gunfights we hadn't fought, and assigning them to place during moments we didn't really understand. Nothing in our script felt grounded. As an experience, it felt false. We realized the only way it would work was to allow the player's experience to be our story."
• The developers had a second run where they embraced the player's run as the story. The story has to be what the player does and the writer is a journalist reporting live from the battlegrounds.
• "One of the many reasons video game scripts often feel divorced from what is actually happening on screen is people have this very ingrained belief that game and story are two different things. Our experience on Gears taught me that story and game need to be the same thing. The story has to be what the player does. A writer who is not having a constant conversation with the experience of the player has been put in an impossible situation."
• Kim Swift of Airtight Games talked about how to "not be a douchy boss."
• Listen to your team and trust teammates to help you fill in your knowledge gap.
• Be transparent, disperse information, and don't leave anyone in the dark. Everyone is an adult and can make decisions for themselves, so give them all the information and trust them to make the right decisions. Communication is a give and take.
• Tell them they're awesome and give people credit. Give constructive criticism by giving references and collaborating on solutions. Be pleasant about feedback.
• Empathize and be open to criticism yourself. By being empathetic, it makes you more approachable.
• George Fan from Popcap Games talked about how to choose a theme for your game.
• When choosing a theme for your mechanic, there are four main questions you have to ask yourself.
• Is your theme something you're into? You'd be much more engaged in your game if you actually like the theme.
• Does your theme support the mechanics? In Plants vs. Zombie, for example, plants were chosen because they are stationary and zombies because they wanted a single-screen experience and zombies are slow walkers.
• Does your theme communicate the goal? You need to support immersion and give motivation. 
• Does you theme have both familiarity and novelty? Lightsabers were popular because they were both familiar (swords) and novel (they glow).
• Carla Fisher presented a gamer's guide to parenting.
• Kids are like a game of all genres and requires extensive QA. She suggests to guide children's behavior using lessons she learned from games.
• "Potty training with Plants vs. Zombies." There was an achievement that you received by collecting a lot of sunlight. It incentivized players to play slowly rather than aggressively. Potty training is a similar task.
• "Baking with Left 4 Dead." Left 4 Dead is a game all about teamwork and fosters communication. When baking with your child, give easy tasks to them like mixing flour while you handing the more difficult ones.
• Ben Cervany talked about using the city as a foundation for a game.
• The city is already our biggest game. It presents complex dynamic models like flocking cars and crowd behaviors.
• Employ the latest technologies (fluid media, printed objects, head-mounted augmented reality, media capture, gesture tracking) to create new immersive contexts for expression and bring games to places.
• Some game concepts that incorporate the city - dynamic summoning of infrastructure, play flows across context and devices, party up with players in real space and real time, game time while in transit, putting sensors and outputs in our space, urban planning as a MMOG.
• The city hosts a myriad of fluid games, so start building tools to play the city together.
• Mare Sheppard, president of Metanet Software, talks about their one-hit wonder.
• The company released N and N+, two distilled platformer games all about the feel.
• The game series is functional but it's not beautiful. The team wanted to make the perfect final version, but they were always moving forward and not looking back, so they didn't return to the series. No projects that came afterwards felt as good as N and they were struggling to find a better game. They were stagnating instead of progressing.
• They announce N++, the third game in the series. They want to finish off the game so that they can finally move forward. They need to close the chapter on N. Nobody ever talks about the psychological and emotional side of game development.
• "Everyone is stressed and has problems, even if they're not talking about them. It's part of the creative process, the learning process. Everything about making games is hard, and not just the technical part. I know we aren't the only ones struggling. We felt for years that it was our private hell. It doesn't have to be that way. Maybe we need to talk about the psychological and emotional side making games as well. That's incredibly difficult to do, because it means we have to accept ourselves even at our lowest and most vulnerable points."
• Anna Anthropy talked about gender diversity at tech conferences.
• She asks men in the industry to boycott panels without a single woman.
• "If you're a man and you're being asked to speak at a panel where no women have been asked to speak, refuse vocally. Say, 'I'm not comfortable speaking on a panel where no women are allowed to speak.' GDC has a bit of problem with women. The game industry as a whole has a problem with women."
• "I feel like many of you sitting here want diversity at this conference. You see the value that more perspectives, different perspectives, could bring to inception. It's not enough to have the want, you have to act. Some of you might shrug at the mention of affirmative action. I say affirmative action is action."
• Manveer Heir, designer at Bioware Montreal, talked about his experience playing Minority Media's Papo & Yo, which touched him emotionally and moved him to tears.
• Papo & Yo is a metaphor for alcoholism and domestic abuse. The monster in the game helps you. You can also feed him fruit, but it makes him go berserk and attack you.
• "By the end of Papo & Yo, I was sobbing profusely. I was a grown man breaking down in his living room. I've never experienced that gravity of emotion through media."
• The game made Manveer remember his strained relationship with his younger brother, who was bipolar and committed suicide in 2011. The game reminded him to let go and forgive. Game making should be about putting your own experiences in the games that you work on. Personal experiences and showcasing your vulnerability to the world are more likely to capture universal truths. Emotional resonance is what we look for.
• "Papa & Yo reminded me of something I already knew: the need to let go of my anger, the need to forgive and look towards the future, the need to grow as a person. What's interesting about Papo & Yo is it captures a universal truth... My only current interest in making games are those that have emotional resonance. Games that move players to reflect, consider, and emote in way they do not normally. I hope more of you will consider putting this emotional content in your game. There are those of us that crave this emotional content."

GDC2013 - Developing a Windows Store Game with DirectX and C++

• Phillip Napieralski give a quick tutorial for developing a Windows Store game with DirectX and C++.
• He showed off the Taptiles hub interface, which was built with XAML. The game is built under the hood with DirectX but uses XAML for the main menu interface.
• Fruit Ninja, on the other hand, uses DirectX for its main menu UI.
• XAML is a markup language that interacts nicely with DirectX in various scenarios.
• Direct3D Visual Studio template is a code example.
• It has two main classes (CubeRender and Direct3DApp).
• The ^ operator is a 'handle." It's a WinRT pointer that is reference counted.
• There are five classes to override and implement (Initialize, SetWindow, Load, Run, Uninitialize).
• There are also two lifetime management events (Suspend and Resume).
• You have five seconds to load or the OS thinks your app has crashed. He recommends to have a secondary splash screen in Run() for the loading sequence, rather than loading assets in Load().
• He showed off the Marble Maze game example with additional features (store simulator, cheats, notifications with friends, share charms, and animated live tile).
• Take full advantage of Win8 features.
• Tiles - should have dynamic content like leaderboards, send updates to users, and can use Microsoft servers instead of from inside the app. Tiles are just an XML document and there are lots of templates to start with.
• Toast notifications - immediate notifications defined in XML, needs a push server
• Appbar - triggered by gesture (swipe from the edge), Windows + z keyboard combination, or right click.
• Charms - make game social with ease, define a source and a target for the charm
• Persistance - process lifetime management
• Saving data - space available for roaming data, easily switch LocalSettings to RoamingSettings
• Monetization - can include in-app purchases or set time periods for trials
• Get Windows8 and Visual Studio 2012 (Express version is free).

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.

GDC2013 - Job Graph: Task Graphing in Mortal Kombat

• Gavin Freyberg, Director of Technology at NetherRealm Studios, talked about their proprietary multithreading engine.
• All gaming hardware has multiple processors. The future is even wider and all games will need to run multithreading processes.
• Task graphing defines game system flow in terms of tasks and dependencies between them.
• Task and Job mean the same thing. Their job graph defines fixed function graphs, can have set of connection points between graphs, link graphs at runtime to form a meta-graph, keeps graphs independent unless dependencies state otherwise, and support child graphs.
• Characteristics of job graph - object-oriented approach to asynchronous behavior, data-driven, runs on SPU, scheduling burden is spread across threads, graphs have single entry and exit points, has basic priority schemes, predication of jobs possible, dependencies are left empty, context data are embedded in instance, use lock-free code
• It's important to create a visualizer of threads. The job graph visualizer is a standalone app that visualizes graph run. Its limitations are that it cannot have cycles in meta-graph, all depdency satisfiers must be known and well-controlled, and the perfect scheduling of jobs is NP-hard.
• The job graph components...
• The core system - fully data-driven, act on user-defined context data, dependencies are the glue that hold everything together
• Graph leader - describes an instance (data offset, data counts), encapsulates runtime state (return state, internal branching state, external wait state, dependencies, predicate state, context data)
• Token stream - describe execution of graph, are tokens for passing controls and job execution
• Dependencies - atomic counter and a list
• Work pool - contains multiple list of pending work, contains lock-free allocator for queues job data structures
• Loop - conditionally acquire exclusive resources (pop work or release if exhausted), exclusive resource doesn't go to work pool until something needs it
• Runtime system - owns the work pool, contains collection of instance lists, has special 2-pass instance launch process
• Migrating code to the job graph was easy. It involves breaking code into jobs based on dependencies, using exclusive resources as a porting aid, increasing priority of the critical path, and setting up relationships outside of the meta-graph.
• Results of job graph - explicit dependencies, low system overhead, supports runtime, allows conditional graph flows, can easily solve problems like 1 frame lag
• The main problem with using job graph was its overhead. It uses up 3% of CPU spread across all execution units.
• Mortal Kombat used a lot of middleware like Scaleform, fmod, and Havok. Middlewares were all encapsulated as a job in the graph.

GDC2013 - Applied Value of Player Psychology: Putting Motivational Principles to Work

• Scott Rigby (Immersyve) and Troy Skinner (WB Games) talked about the implications of truly pursuing applied psychology.
• We must truly understand player psychology in a quantifiable and systematic way, or we can wake up in our bed and believe whatever we want to believe.
• "Big data" trap. Terabytes of data * 0 clue = No clue. Need to understand what's going on to get meaning out of your data. Big data does not open the psychological black box alone.
• Be as passionate about testing your theories of fun and engagement as you are about having them.
• Their recommendation is to be discriminating and a bit skeptical.
• Clearly measure each part of your model of fun and engagement, like social scientists who define and measure love.
• Validate your model. Just because it looks convincing doesn't mean it's accurate.
• Share results with stakeholders.
• Self-determination theory is the leading psychological theory of motivation and emotion world-wide. It has empirical validation and over a thousand published studies.
• Scott Rigby creates the Player Experience of Need Satisfaction (PENS) model where he focused on fundamental needs instead of the players' wants. It has three core components.
• Competence/Mastery - player should feel effective and growth, they need informational feedback, competence feedback can be delivered in granular/sustained/cumulative/instantaneous amounts
• Relatedness - feel like you matter to the game world (you are saving someone, or you are the healer that your team relies on)
• Autonomy - agentic motivation, offer lots of meaningful choices
• Competence is a turnstile issue. Developers often anchor competence satisfaction in the wrong place.
• In the console market, there are Tier 1 games (huge mega-hit games) and Tier 2 games (profitable games). But there is a huge gap between Tier 1 and Tier 2 games (about a $50 million difference).
• Case Study: Mass Effect 1 and 2.
• Mass Effect 1 was rated 89% on Metacritic, the ad spend was solid, and had 5.1 million people hyped about the game. The game was a Tier 2 game.
• The team wanted to push the sequel to Tier 1, so they focused on quality, marketing, and PR execution.
• Mass Effect 2 was rated 96% on Metacritic, four times the amount of ad spend, and 7.2 million hype. The game was still a Tier 2 game.
• Developers should figure out why games make money and what players are doing, then support the studies with design. Where should the money go towards?
• In the console market, there are two types of gamers.
• The game connoisseur plays everything on all platforms and all genres. They identifier themselves as a "gamer" and has the t-shirts and merchandise to prove it. They care about their game performance and will participate on forums and read guides to improve their competence. They are always reading and following the latest gaming news and will evangelize their favorite games to their friends and family. Their driver to purchase is innovation and depth. We are familiar with this market because the game connoisseur is us! But we only make up 15% of the market size.
• The bro gamer makes up 65% of the market size. They are more casual and they play only the best and most popular games. They want to be entertained; they're not looking to be the best. They play games with their friends and want to avoid embarrassment. They only care about what to play, not how to play, and they want to be quickly competent in the games.
• These are the 10 rules to follow when trying to make a successful game.

1. The majority of console players prioritize entertainment over challenge. Thus, the simple console market model is...
• First, the connoisseur is attracted to a game because of innovation.
• The connoisseur will recommend the game to his bro gamer friends.
• The bro gamer tries the game and feels good at it.
• The bro gamer buys the game and spreads to other bro gamers.
2. Need to capture both segments to make a hit game. Both audiences have the same needs (competence), but with different approaches.
• Batman: Arkham Asylum is a very good case study. The connoisseur felt attracted to it because it was the first awesome superhero game, there was depth in the combat system (needed both offense and defense to win), and the skill required is visible. The bro gamer also liked it because the combat used simple 2-button controls, defense was simple to understand (there were visual signals of incoming attacks), and there were direct boss battle instructions.
• If players die 3-4 times in a linear game, they'll quit. Don't let that step happen. Help players after failures. It'll appeal to both audiences because the connoisseur won't feel like you're talking down to them and the bro gamers will get the help they need to proceed.
3. Complexity in controls is your enemy. This is not where you want to add depth. The more effective players there are, the more unit sales you'll have.
4. Don't gate mastery. Clinical practice like learning a musical instrument is hard and boring, so don't make that a gating factor. Give people an easy way to do want they want, like exploding people with your first in Mortal Kombat. Another solution for growth is adding RPG mechanics.
5. Reward effort more than skill. The more feedback density you use, the more motivated the player will be.
6. Exploit inexpensive ways to give players feedback. Blowing someone's head is awesome, but it's expensive to make and it's hard to top yourself. There's no room to grow, because how can you reward the player above that? Instead, UI is much more cheap and captivating. Having upgrades, ranks, and grades open up lots of room for player growth. Call of Duty's secret sauce is its XP system because it gives lots of things to achieve and tons of player feedback.
7. Find a way to consistently tell the player they are progressing.
8. When players die, don't teabag them. Don't make them less powerful when they're already down, but give them some comeback mechanics.
9. When players struggle, teach them to be successful.
10. Making all players competent is the price of entry for hit games. Connoisseurs are already hyper-educated, so making them more educated doesn't incentivize them to purchase.

• World of Warcraft players, when left to their own devices, will make custom UI that gives themselves more feedback.
• You can predict sales by looking at the hours of sustained plays.
• Immersion comes from competence, not graphics or audio.

GDC2013 - Strange Love: The Relationship Between Game Theory and Game Design

• This talk was given by Frank Lantz.
• Game theory is a mathematical study that applies to many fields including philosophy, military, economy, and strategy. Game designers don't use proper game theory much at all.
• Game theory is the mathematical analysis of situations where multiple parties are making choices. Take for example a costume party where everyone is trying to come up with an awesome unique costume. This decision will depend on other people's decisions and can be modeled mathematically.
• The key terms of game theory are players (the parties involved), strategies (the choices), and payoffs (the results). With all situations, you can make a payoff matrix.
• The origins of game theory come from John von Neumann, who was a great mathematician. He also liked to party and play Poker. He wrote a book called the "Theory of Parlour Games" which started game theory.
• Roulette is a game that can be calculated with possibilities; chess is a game of calculated decision trees. Poker, however, was completely different. Poker was about bluffing and bidding, about making choices based on opponent's choices.
• "Chess is not a game, it's a computational puzzle. Real games, like life, are about bluffing..."
• Game example #1 - Cutting the Cake
• In this game, one player cuts the cake and the other player gets first pick of the piece she'll take.
• For the second player, there is a dominated strategy, the choice that is obvious and best. She'll always pick the bigger piece.
• For the first player, the decision is minimax. He'll go for the choice with the minimal losses (cut the cake as evenly as possible).
• The process of looking through the opponent's eyes is the core of game theory.
• In a zero-sum game, all the choices add up to zero. One wins and the other loses.
• Game example #2 - Matching pennies
• ​In this game, two players choose a side on a penny respectively. If both pennies match, the first player takes the pennies. If both pennies are different, the second player wins and takes them.
• Often the best strategy here is to add some randomness to throw off the opponent.
• What if the game was non-zero sum? Consider "matching pennies with Bill Gates." The same rules apply as before, except if both pennies match on heads, Bill gives you a million dollars. The obvious choice for you is to play heads, but Bill will always play tails. There is a dominant strategy, but it's good to throw in the other choice to throw off your opponent. This is likewise in baseball, where throwing your best pitch will make you become predictable, so it's good to throw in a bad pitch every now and then.
• Game example #3 - Chicken
• In this game, both players drive cars towards a cliff. The first player to swerve is the loser. However, if neither players swerve, then the outcome is very negative for both, resulting in death. This is a non-zero sum game.
• Scientists have found that this payoff matrix applies to animal fights in nature.
• John Maynard Smith's theory of Hawks vs. Doves maps out this behavior. He looked at game theory in relationship to biology and found that animals follow an evolutionary stable strategy. If there are too many doves, then it pays off to be the hawk with the aggressive strength. If there are too many hawks, then they end up fighting each other all the time and it pays off to be a dove. Ultimately, the two species strike an evolutionary balance.
• In the game of Chicken, eliminating choices will force a decision for the other player. If for example, one player removed his steering wheel altogether, he can't swerve because he has no means to, which means the other player is forced to swerve. Sometimes, the irrational beats rationality.
• Game example #4 - Prisoner's Dilemna
• In this game, two criminals are apprehended and placed in different cells. They are asked to betray their partner (defect) or stay silent (cooperate). If both cooperate, they get one year in prison, but if they defect against each other, they'll both get 3 years in prison. If they choose different options, the defector will get off jail scotfree while the other will get 10 years in prison.
• This is a real dilemna because the decision is difficult. There is no dominant strategy.
• The best optimal decision is to defect. It yields the better deals and avoids the nasty 10 year sentence. If the two prisoners are smart game theorists, they will choose this strategy and get 3 year sentences. However, another pair of prisoners can come into this situation, and they're dumb and uninformed. They'll both choose to cooperate, resulting in a much better payoff. The "optimal" solution lead to suboptimal results, but the dumb solution lead to higher payoffs. What?
• The RAND cooperation was a group of military game theorists. Von Neumann and RAND both thought the optimal solution during the Cold War was to pre-emptively bomb Russia first. But it turns out that the irrational decision (not to bomb) saved the world.
• Game theory put us in the brink of nuclear war, but the paradox of irrationality also came from RAND. There's a chance that game theory and Poker, a game that was meant for degenerate gamblers, saved the world.
• Robert Axelrod asks the question, "How do we get to cooperative payoffs?" He created a computer program that simulated the iterated prisoner's dilemna and asked for open submissions for bots to face each other in this simultation. The most successful bot was Anatol Rapoport's Tit for Tot strategy, which always cooperated but will attack if attacked the turn before. This strategy continued to win in future decades even when everyone knew it was the strategy to beat. Tit for Tot is also discovered and observed in biology.
• William Press and Freeman Dyson later categorized Tit for Tot as a subset of zero-deterministic strategies.
• Game example #5 - Ultimatum game
• In this game, one player must divide $100 and offer the deal to another player. The other player can accept the deal or reject it, in which case neither player gets any money.
• Thomas Schelling wrote about game theory. It's not just about conflict and competition, but about coordination, competition, and negotiation.
• What are the applications of game theory to game design?

1. ​​Legacy. Game theory came from real world games like Poker. In addition, many historical game theorists have designed games. John Nash, who developed the Nash's equilibrium, designed a game about networks and relationships.
2. Formal Analysis. Game theory provides a great basis for game balance, yomi, and game economies.
3. Inspiration. Game theory decisions are simple, but not trivial. You can see examples of it in board games, reality game shows, and many social games. Frank Lantz's games (Parking Wars, Spore Islands, Power Plant, The Friend Game) are all also related to decisions players make in regards to each other.
4. Reconciliation. Recently, we've seen games like Journey, Proteus, Dear Esther, The Graveyard, and Heavy Rain. These are games that removes min-maxing and focus heavily on emotional experience.

• ​The key takeaway is that "the rational is not incompatible with the sublime." Explanations do not exhaust a topic. Knowing that a person is made up of atoms doesn't diminish the person in any way.
• Game theory is not just about rationality. Humanities and sciences have separated, but can we bring them both together without diminishing either of them?
• Math, strategy, and rules can co-exist with stories, emotions, and love. Game design is where math and beauty meet.
• ​It's okay if game theory has no practical use. We're not necessarily looking for utility, we're looking for truth.

GDC2013 - Live Streaming Video: Social Power to Games

• Integrating live streaming into games, you can incorporate spectator interactions to influence outcomes. For example in sports games, there can be a "home advantage" where the player with more audience support gets a boost in gameplay.
• Millions of people can upload, save, and share their gameplay stories.
• In the future, the number of people watching live games will overshadow the number of players.
• Live stream events are reaching TV broadcast-sized audiences. A network like VH1 lives off an audience of 20,000 and many popular streamed channels can get those numbers.
• In the future, distribution will be everywhere from X-Box Live to Smart TVs to phones.
• Popular streams include Dota 2, League of Legends, The Sims, FIFA, Mario games, and Magic the Gathering. Retro games are also huge.
• To create a good streaming game, you need...

1. ​​Awareness of spectators
2. Consistency of experience
3. Leaderboards
4. World info (viewers know the state of the game at all times)
5. Developer and publisher commitment
6. Show official inside-the-game or behind-the-studio videos

• ​​People need live real-time connections to their games. Riot built their business model around this and is incredibly successful.
• Stream 101 - relax, production values are not important, stream often, have a voice, showcase your people and their personalities
• Conclusion - game discovery is now video-based instead of text-based, the streaming community is growing fast, make the game "watchable", both fans and companies should stream

GDC2013 - Usability Is Not Random

• This talk was given by Mike Acton, director at Insomniac Games. The goal was to develop a mental model for recognizing and breaking down usability issues. It is not a numbers or deep talk.
• Usability should be applied to tools UI. Actually, usability should be applied to game, API design, and everywhere...
• The main lessons of this talk are...

1. ​Only way is to watch it live
2. Choice is bad
3. Choice is good
4. 20 questions is all you need
5. Learning curve is bad
6. Learning curve is good
7. When in doubt, be like Maya

• ​The five functions of usability are...

1. ​Context
2. Information density
3. Message creation
4. Message translation
5. Message response

• Usability is the "total time required to solve the specified problem at the desired level of quality." There are many sophisticated measuring tools, but the most important one is to watch your testers live and ask good questions.
• Context is "all agreed upon information." Agreeing on what we're trying to accomplish will add more context and usability. Take Google for example. When doing a search, you have to visually parse the results to find what you're looking for. Clicking the "Image" tab gives the search more context of what you're searching for. More constraints makes it potentially more usable.
• The upper limit of usability is determined by the amount of agreed upon informaton we start with. In this case, choice is bad. Google, with no context, gives us too many results that it becomes less usable. If you're specifically looking for computational knowledge, searching on Wolfram Alpha (more context) will directly give you the result you're looking for.
• There are 2 kinds of contexts: the hunt (where you know what the end result is) and play (where you don't know what the end result is). When you're "playing," you have an idea of what you want, but you don't necessarily have a specific thing you're looking for. In this case, choice is good. Common instances of play can be found with Amazon and Netflix, which present lots of relevant, comparable options quickly to the user, increasing its usability.
• Information density is "the amount of problems that can be solved with any particular message." It is the data that is associated with each step in the process. Every problem is just a game of 20 questions, narrowing down the list of possibilities and page results. For example, looking at Google again, at the start of a search, there are infinite possibilities to what you're searching for. The moment you type the letter "a", it reduces the possibilities to about 6,500. You add a second letter and it reduces that number of possibilities dramatically again.
• Message creation is "the amount of time required to react correctly." The things to measure here are parsing time, thinking time, and error rate. Common problems to message creation are the need to do calculations in your head, the need to choose between unknown options, and having options that are too granular or useless. Learning curve is bad, so reduce the time it takes to learn what to do.
• But initial difficulty isn't always bad. There are plenty of software, games, and activities that have high initial difficulty (programming languages, 3D modeling software, real-time strategy games, fighting games, learning a musical instrument). History has shown that dedication to a difficult task produces better mastery of the task. In this case, learning curve is good. People get better with practice.
• Message translation is "the latency to transform a message to a useful result." This is basically the time it takes between a user interaction and the result being shown, whether that is building lightmaps or compiling a program. Follow the 5 second rule. One iteration takes 5 seconds, so one minute wasted is a loss of 12 iterations. Make things more usable by reducing the time needed to work out what the right thing to do is.
• Message response is "the throughput of the message." It is the time until the next message can begin.
• When in doubt, be like Maya or a UI that users are already familiar with. The more different your tool is, the bigger the bridge your users have to cross in order to use it.
• Usability is a triage. You simply can't do everything because you don't have infinite resources or time. Don't try to maximize usability in everything.
• References

1. ​"Mathematical Theory of Communication" - Claude Shannon
2. "Design of Everyday THings" - Donald Norman
3. "Man Who Lied to His Laptop: What We Can Learn About Ourselves from Our Machines" - Clifford Nass, Corina Yen

GDC2013 - WiiU Application Development with HTML5 and Javascript

• Nintendo announces the Nintendo Web Framework (NWF), a framework that allows you to create applications for the WiiU with HTML5 and Javascript.
• The WiiU offers dual screens (your tv and the gamepad), an internet browser, touchscreen, gyroscope, accelerometer, and support for Wii remote controllers.
• WiiU also launched with web service apps such as Hulu Plus, Amazon, and Youtube.
• Wii Street U is a new app by Google created using the NWF.
• The NWF offers a great way to prototype traditional native games.
• "Gunman Clive" is a 2D platformer game that was released on 3DS and in one month, outsold both its iOS and Android versions. There is marketing value in Nintendo hardware and people demand better controls that the WiiU can offer.
• NWF runs on a Windows PC and is based on the Webkit framework. With Javascript extensions, it allows use of the touchscreen, gyroscope, accelerometer, and any of the WiiU-supported controls. It also supports save data, file I/O, software keyboards, video playback, and access to the Miiverse.
• You can use standard HTML5 libraries like jQuery in your applications. The NWF Dashboard interfaces between your code and the WiiU hardwre. It will convert your gamepad touch inputs to mouse clicks. The Dashboard also comes with a web debugger/inspector.
• NWF uses a fast Javascript virtual machine, GPA accelerated graphics, and a great bitmap/sprite renderer. The hardware can run GUI Mark 3 (a benchmarking program) at 60 FPS even when you increase the number of sprites drawn by 10.
• The logo of NWF contains an image of a bamboo because the codename of the project was Bamboo. A bamboo's roots sprout from the ground very quickly, but it has a solid framework to support its fast growth. Likewise, NWF is a solid framework that supports quick development growth.
• NWF is free to use after getting a WiiU devkit and they have a special introductory program for new developers.
• Their business policy
• No concept approval
• Price and release date are independently set by developers
• Distribution will be following industry standard models
• ​In the future, NWF will also support Unity. Unity for WiiU will be distributed for free to all WiiU developers.

​​The Future of Mobile Gaming: A Conversation with Nickelodeon and EA

Nate Altschul from Nickelodeon talked about a bunch of HTML5 game engines and what he recommends.

• Why use HTML5? It has high reach, ease of development, avoids 30% tax, it's a Flash replacement on mobile browsers, and it offers quick iteration.
• There are a few problems with HTML5 right now though. The tech is a moving target (DOM -> Canvas -> WebGL), it's fragmented, there's few "real" games, there are no big success stories yet, and many tech challenges (audio, animations, etc.)
• There are many HTML5 game engines available today. In fact, there are more HTML5 engines than there are "real" games. When choosing an engine, you should evaluate its traction (how is its growth?), your team size, its toolchain (what IDE, visual editors, debugging tools does it use?), its features (canvas, WebAudio, physics), its reach, the languages you can code in, and its price.
• There are many deal breakers that make some HTML5 engines useless. These include no links or examples of real games developed using the engine, no multiplatform targeting, no WebAudio support, no canvas, no lazy loading, no Flash animation integration, closed source, unresponsive development team, large unoptimized sprite sheets, no language support other than Javascript, no screen scaling without affecting aspect ratio, bloated keyframe animations, no cutscenes, no object pooling, inefficient memory management, missing abstractions from browser quirks, no multiple renderers, no localization, and no embeddable entry point JS file.
• Javascript sucks for development. It has no strong typing, can't cross-compile to native code, it doesn't scale well for big complex teams, it has no compile-time error checking, no code auto-completion, no code navigation, no abstraction layer for browser differences, difficult debugging tools, and it's just plain ugly.
• Here are some HTML5 game engines that are actually recommendable because they have minimal deal breakers.
• PlayN - cross-platform engine, uses Java, optimized for Android browsers, free and open-source, uses Eclipse IDE. Gotchas - buggy Flash and iOS backend, installation and setup is a challenge, no more support from Google, GWT overhead, has about twice as many lines of code. Recommended for Java developers targeting Android.
• CreateJS - deep Adobe CS integration, supports Javascript/TypeScript/Haxe, free, uses MIT license, done by Grant Skinner (Flash expert), toolchain (Adobe Flash CS6, Zoe Spritesheet Exporter, EasleJS). Gotchas - big spritesheets, not multiplatform, no SWF export, relies on Flash's DisplayList metaphor which adds overhead. Recommended for Flash developers.
• ImpactJS - features Canvas/WebAudio/Physics, easy to put into native wrappers, uses Javascript, $100, lots of indie games but no professional games yet, has Weltmeister (visual editor), supports Ejecta (iOS wrapper). Gotchas - large animation files, limited screensize support, not open sourced. Recommended for indie developers who want to make side-scrolling platformers.
• Construct 2 - best visual editor, $390, lots of indie games, requires no programming knowledge. Gotchas - lack of fine control, hard to optimize, large animation files. Recommended for beginners with no programming experience.
• Cocos2D HTML5 - familiar API to Cocos2D, high reach (HTML5, iOS, Android), uses Javascript/Haxe, free, supported by Zynga, toolchain inludes CocosBuilder/PhysicsEditor and other Cocos2D pipeline tools. Gotchas - still early, very small community (but will grow very fast), large animation files. Recommended for Cocos2D developers.
• Spaceport.io - supports vector graphics, features over-the-air updates, reach (native iOS and Android), supports Actionscript 3, a few real games developed using this engine, toolchain (Adobe Flash CS6, FlashBuilder, FlashDevelop), very similar to Adobe AIR. Gotchas - only native support, no HTML5 browser support. Recommended for Flash and Air developers.
• Haxe - cross-platform SDK, reach includes HTML5/Flash/iOS/Android/Win8, free, language is ECMAScript (similar to AS3), the only engine that's truly multiplatform, toolchain includes IntelliJ/FlashDevelop/FDT/SublimeText, integrates Adobe CS6, uses Stencyl visual editor, can create cutscenes using Flash-like timelines, backed by Blackberry.
• Honorable mentions (good engines, but has a few deal breakers) - Tresensa, Ludei CAAT, CocoonJS, Playcraft, Turbulenz, PixilJS, LimeJS.

Aron Sagon from EA also gave a talk about games as service. I'm not really sure what the point of his talk was... outside of complaining how difficult it is to make them.

• Aron is a chief engineer who worked on Pogo, Sims 3, Star Wars: The Old Republic, and most recently, Simpsons: Tapped Out.
• He compares the old business model (sell shiny disks) to the new model (sell a service). The service model can be broken down into three steps: identify the user, collect money, and then deliver the experience.
• In the service model, you have to keep track of the users and what they've bought, then make sure you deliver the service to them. In the traditional model, you didn't have to track users. Once they've bought your product, your relationship with the customer is pretty much over.
• It's very, very hard to track your users. Users don't want to register new accounts and even if they do, they are unlikely to remember their account info. Even with iTunes, Apple does not provide information about who is purchasing or using your app. There is a lot of extra overhead to put in analytic and tracking data into your games.
• Building service games is very difficult. Before, you would develop the game and then ship it. Now, you often ship the game and then develop it. Development timelines can be as long as 5 years. And because of the massive volume of players, small mistakes can become big deals.
• Making a pretty game is important, making a fun game is important... but there is much, much more that goes into game development. You need to integrate monetization, virality, engineer databases, etc.

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!