Saturday, June 9, 2012

Topics to Make Your Developer Blog Interesting

At the game company that I work for, we've discussed internally about starting a new blog to build our studio brand and more importantly, attract new hires. We've had two brainstorms about topics that we think the blog should cover and as with all brainstorms, many out-of-the-box ideas came from it. Thinking about this more, I think it's not really a big secret about what makes a good developer blog.

To start, who is the target audience of this new blog? I think it can be broken down into three categories. The first are people who have talent but aren't currently in the games industry. To attract this group as hires, we just have to show them why games are the industry to be in. Thankfully, we have so many employees who are passionate about games. We live and breathe games. We should write about why games are important to us. We should show the awesome games we're working on, the amazing art we produce at the company, the fun game challenges we do, and cool tech demos of our game engines.

The second category are people who are in the games industry, but don't have that superstar talent yet. Attracting this group to our blog is easy. We have to educate them. Personally, I only ever spend time reading another company's blog if it's informational or educational. I'm a busy man so I'd only dedicate my time to reading and following a blog if I feel like I can walk away learning something new or thinking about something in a new way.

Fortunately, we have a lot of great talent in our company. Game designers should write about game design theory, dissect a game that they're currently playing, or walk through the reasons they've made a certain decision in our games. Artists should write about art techniques, or about the many iterations of art designs that a single game went through and the reasons why those changes were made. Programmers should write about programming problems they've encountered and the clever solutions they find, or introduce new tools that they started using. Analytics and revenue teams should write about how data drives game design or what kind of UI has been proven to monetize. Producers can write about their experiences with scrum or tips for managing a team.

There is such a breadth and depth of knowledge to be shared. While I understand that many things of the company are disclosed for contractual reasons, close-to-full transparency and sharing of knowledge is the best thing your blog can have. Ronimo, the developers of the fantastic Awesomenauts, has a great developer blog written by the lead programmer that is very transparent about their programming problems, art iterations, and even unreleased game concepts. I'm subscribed to over 600 blogs and this is easily one of my top five blogs to follow.

Finally, the third category are people who have the talent and are in the games industry, but they're just with another company. To attract this group, we have to show them what we offer as a company that others don't. Most certainly, the best thing about the company is that we empower employees to have creative freedom and give them many avenues to express themselves and have their voices heard.

We run a weekly brainstorm meeting where we tackle design challenges a project is facing. Every employee can attend the meeting and throw out ideas, no matter how crazy or farfetched they are. As we always say, there are no bad ideas in the brainstorm. We have an idea submission process where any employee can submit a snippet of a game idea and then a dedicated team develops a prototype of the idea in two weeks. If the idea is great, it might even turn into a full-production game for the world to play. We also run annual game jams where the entire company steps out of their everyday roles and get inspired to make off-the-wall games. Not many game companies give their employees the channels to have their creativity expressed, so that is definitely a strength of ours that we can expose.

Thursday, June 7, 2012

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.

Wednesday, June 6, 2012

Trials of Designing Procedurally Generated Adventure Games

Clara Fern├índez-Vara, a Postdoctoral Researcher at the Singapore-MIT GAMBIT Game Lab, gave a presentation about her procedurally generated adventure games. Her work concentrates on adventure games and narrative in simulated environments.

Presentation
  • Procedural content generation has existed in video games since early maze games and rogue-likes. Even the shuffling of cards from a card game can be considered procedural generation.
  • Will Wright's presentation of Spore at GDC focused on letting the users do the work of creating content. Procedural generation is focused on letting the computers do the work.
  • Clara's primary genre of focus are adventure games. Her influences include Heavy Rain, Machinarium, and Phoenix Wright.
  • Her goal is to look for innovation in adventure games. She wanted to create a system based on psyche and recreate the logic of dreams. Dreams happen to be unstable and random, so it fits perfectly with the somewhat random results of procedural generation.
  • The initial system that she designed involves creating a puzzle structure -> populating it with puzzles -> creating object combinations out of a list of NPCs, properties, and items -> and selecting and placing the objects in a specific order.
  • The puzzle generation system she used was inspired by GRIOT. She created Symon in 2010, in which the player is trapped in the dreams of a paralyzed patient.
  • The designer's role in a procedurally generated game is to figure out the puzzles and objects that provide insight into the narrative. She focuses on adventure games as simulation, thus it's important that generated puzzles have to create narrative. In Symon, for example, there's a puzzle involving a carnivorous plant, which signifies gardening. Symon doesn't like gardening, but he's been doing it for the last couple of years for his wife. The plant blocks Symon from progressing, but he can choose to kill it or give it something so that it leaves him alone.
  • The development of Symon had several problems. The design was dependent on the code, so whenever the designer wanted to make a change, she needed the programmer to implement it. Secondly, the process and iteration was slow due to the programmer being a bottleneck. Finally, there was only one type of puzzle with one variation (fetch quests).
  • Many players don't expect to replay adventure games, so a lot of the procedurally generated nature was ignored by the audience. There was a big challenge to write walkthroughs as every player experienced a different game with different characters and puzzles. However, once the game was played through a few times, it was very easy to figure out the system and the game got boring.
  • Many tools were built to help the designers such as a tool to create puzzle patterns, a puzzle map, and a database editor.
  • Generating puzzles procedurally doesn't mean it's playable. There's a lot to add to make it an actually meaningful experience such as giving hints to the player when they're stuck.
  • Clara worked on Stranded in Singapore in 2011. It took place in the real world instead of in a dream. With this game, she had more control over the design and was able to add more puzzle patterns, although the generation algorithm still needed work.
  • Randomness can be an enemy of believability. For example, there was a puzzle in the game that involved finding ice cream and two slices of bread, combining them into a literal ice-cream sandwich. This is an actual food found in Singapore that the designers wanted to include in the game as a means to expose Singapore's culture. However, many players thought it was a random result of the procedural generation and didn't believe it actually exists.
  • Stranded in Singapore had a problem reconciling fiction with the mechanics. In Symon, the procedural generation made sense in the dream world since dreams are random and wacky, but it was odd in Stranded in Singapore.
  • Stranded in Singapore was focused on food, bargaining, and commercial transactions.
  • Lessons of designing procedurally generated adventure games are to focus on simulation, design relationships that generate narrative, and ensure that the game premise and fiction complement each other.
Question and Answer
  • The environments of Symon were generated based on the characters that were randomly selected to be in the game session.
  • The variation of objects is the biggest factor to give more narrative range and better replayability.
  • Clara's games are designed to not let the player get stuck. In order to do so, the games allow an undo or reset ability.
  • Her games are basically parodies of adventure games.
  • To generate the game session, the game has to generate the puzzles in backwards order.