Andy Megowan - STORIES THAT WRITE THEMSELVES

As casual game developers, we have a contradiction in our business practices. We are competitors, each striving to coax consumers to spend their money on our games rather than on some other company’s games. Yet we are also collaborators, offering the games of our fellow developers alongside our own in exchange for a percentage. So how do we achieve any degree of differentiation in a market that requires us to collaborate with the competition? The solution is to distinguish between what we make and how we make it: We need to collaborate on process, and differentiate on content.

We all know that if there is not enough variety, our games are either too short or too repetitive. So what content do we add to a game that makes a meaningful difference to our audience? Both more content and diverse content have their own headaches. More content in a game provides differentiation, but it also leads to more work, longer startup times, more testing, and bigger downloads. And we want to diversify, but not too radically—because although variety may be the spice of life, you can’t make a whole meal out of spices. What we need, therefore, is a way to make games that can offer more content, use fewer resources, and do it without being repetitive.

Here are some processes that can help add richness, variety and “replayability” to your games. Most of these techniques have been around for a while in some form or another, and you can spot them in a few hit casual games. They are just the beginning of a long and exciting path towards games that are increasingly empowered to give our customers more of what they want without developer intervention. No matter how simple or elaborate a game is, you can use these tricks with minimal effort to enrich your games.

Fast Food
Visit any fast food chain and look at the menu, and you will see dozens of choices. Interestingly enough, there are more choices on the menu than there are ingredients in the kitchen. Combining some fraction of those ingredients with a minimum of effort and unskilled labor creates a wide variety of offerings.

This is the most common way to cram a lot of content into a small game. Break your content into several highly reusable chunks, and then store only the information on how to arrange those chunks. The game Tropix, for example, has several mini-games and environments that very cleverly combine and reuse a modest library of assets. PopCap’s Bookworm Adventures presents an epic tale and scores of characters by recombining body parts to create a formidable cast of enemies. And the classic retro RPG Aveyond takes place on large maps made of tiled, repeatable images.

This system has its limitations, of course. Like fast food, everything starts to look the same once you’ve seen all of the ingredients. And the environments remain identical from session to session and player to player. If the world remains the same, then the replay value has been lost; the interaction has been replaced with a sequence of steps that the player performs in order to recreate a familiar story.

Chinese Combination Plate
Let’s leave that fast food stand and visit a Chinese restaurant for lunch. You will see a long menu of lunch specials, but your options are limited. Each lunch special consists of an entrée, steamed or fried rice, and a fortune cookie. If they really pull out all the stops, then you also get your choice of a soup, a fountain beverage, and a fried wonton or eggroll.

Applying this same principle to your game design, you might build a sort of “Chinese Combination Plate Generator.” The developer creates a world with blanks where certain information is supposed to go. The game stores possible data to fill in those blanks, then randomly selects something different each time. For instance, the Virtual Villagers games each generate a cast of characters with randomly selected clothing, hairstyles, talents, likes and dislikes. Each time you play the game, you have a very different population.

Some games, like Tetris and Bejeweled, use this randomness as the core game to create a highly replayable experience. During each session, the player is confronted with a large quantity of randomly selected components, and must devise tactics specific to the situation.

Many popular games allow the player to get in on this action, too. WildTangent’s FATE and countless RPGs offer players the chance to customize a character by picking one item each from a list of genders, classes, faces, hairstyles, and so on.

Your audience will eventually catch on that while the ingredients are interchangeable, they have little to no effect on each other. Whether Sally has a red helmet or a blue bonnet, or whether the evil wizard’s name is Werdna or Mondain, the game plays the same. The choice of a particular ingredient has no influence on any other choice. Fortune cookie says: Tomorrow will be just like today.

The Iron Chef
Enough cheap food for now. Let’s see what happens when world-class talent takes a stab at preparing a meal. On the international hit show “Iron Chef,” two very accomplished chefs meet on a stage consisting of two fully staffed and fully equipped kitchens. The flamboyant host unveils a key food item and the clock starts ticking. Each chef has exactly one hour to prepare a sumptuous feast for the celebrity judges.

The preparation of such a meal provides an excellent and useful development model for generating content. Each choice made throughout the process is affected by every previous decision, and it in turn influences every subsequent choice. It’s like taking the Combination Plate Generator and kicking it up a notch. In Blizzard’s mind-numbingly popular game World of Warcraft, the player selects a race from a list of eight to 10 possibilities. The choice of race immediately constrains the possible professions of the player. The player also picks a gender, and the race/gender combination leads to a unique list of customizable physical features. A male dwarf can pick a style of facial hair, but a female gnome can instead pick out a set of earrings. Some of these variations are purely visual, but that is meaningful content in a world with thousands of characters. Other pieces of information have consequences that follow you into the game and influence your character’s abilities and how it is treated by others.

Now We’re Really Cooking
This Iron Chef system leads to novel experiences from session to session and from person to person. Generated content has the potential to engage players’ attention, stimulate their brains, and allow unique stories to unfold. And when players can have different experiences from one another, it leads to discussion and the sharing of stories. We call that buzz—and buzz is very, very good.

Simple sequences like the stream of puzzle pieces in Tetris or the procedurally crafted worlds in FATE are just the beginning of self-creating stories. Here are some other possibilities:

For a game with characters that talk to one another, offer multiple versions of basic dialogue, and filter it based on the character’s chosen traits and any events that may have transpired.
For a click-management game like Diner Dash, how about this: procedurally generate a character with randomly selected strengths and weaknesses, then give her a store in a random location. The location determines prices, clientele, starting facilities, interior decoration, and the business goals that you must meet to succeed.
Joseph Campbell created a 12-step template for what he called the “Hero’s Journey”, the nearly universal pattern to all epic tales from Homer’s Odyssey to “Star Wars,” and Harry Potter. If you use Campbell’s template you already know what Components to make, and how to assemble them! Just come up with a set of variables and your design document is practically written already!
It would be especially cool and funny if someone were to use the Iron Chef system to simulate the preparation of actual meals in a game.

Imagine what might happen if procedural content generation were combined with player input analysis. Such a game could gather data about how Billy is playing, analyze it, and store it as parameters about the world. As more content is generated, these new parameters would be included, and different components would shift back and forth between valid and invalid possibilities. You would have a game that tunes itself to Billy’s needs, strengths, and weaknesses—a game with challenges, rewards, and stories dynamically generated especially for Billy.

What you would have, in other words, are stories that write themselves.

[SIDEBAR] How To Build Your Own Iron Chef

Here is a generalized data-driven system for dynamically generated content. Use it for major choices when assembling content like characters and to generate unique scenery as well. The payoff of implementing such a system is that your game will look and play slightly different every time, increasing the chances that someone will take at least one more look at your game.

Organizing Your Data
To prepare for this type of procedurally-generated content, you should organize your data along these guidelines:

Order of categories matters. You cannot select a pair of glasses until you know the nature of the face that they will rest on.
Include grouping categories that have no visible output beyond the generation of the data. As an example, let’s say that you have 50 body types, and that types 4, 8, 15, 16, 23 and 42 were all tall and narrow. You could create a category called “body type” that includes options like “tall and narrow,” “short and round,” and even “medium athletic.” To determine if a shirt is suitable for a given character, you need only say it’s valid for “tall and narrow” bodies instead of listing it as valid for body 4, body 8, and so on.
If you want some components to show up more often than others, add duplicate entries to your list of components. Instead of having a list of components {A, B, C}, you can make the list ten items long {A, A, A, A, A, B, B, B, C, C}. The result is that A will be chosen 50% of the time, B will be chosen 30% of the time, and C will be chosen 20% of the time. It involves duplication of the textual data where you store your lists of components, but text compresses extremely well.

How the System Works
The top-level design of this asset generation system is a Tree. The Tree consists of all possible permutations of the content that you are creating, with each node consisting of a Pointer to a possible Component. The system first generates this Tree, then selects a single path through that Tree, then prunes away all other branches so that all you have left is an in-order list of the components needed to build the new content.

Like most trees, each node has just one parent node and any number of child nodes. Unlike most trees, however, several nodes can all reference the same component. For instance, you could have a pair of boots that would be allowable on bipedal cats or swashbuckling pirates, which would be generated on two very different areas of the tree.

Along with the Tree are the Definite Stack and the Possible Stack. When testing the validity of a given component, the node will query the Generator for various pieces of information, and the Generator will attempt to find the answers on one of these two stacks and pass it back to the node. The Definite Stack is where you put all definite information about the world, such as “The environment is a desert” or “The character must wear a purple bandanna.” While the content is being generated, all possible permutations will also be checked for compatibility against the Definite Stack.

This system assembles objects by creating all possible combinations, then selecting just one. The Possible Stack holds all of the previous choices made up to this point while the system generates a the set of options those choices allow. For instance, the game might ask, “If I were to select a gender of female and a race of Orcish, what professions are open to me?” The Possible Stack would then have “gender female” and “race Orcish” on it.

All of your components will be organized into Component Lists, with one list per type of Component. Think of it as having a barrel of noses, a barrel of ears, a barrel of hairstyles, and so on. Like the individual Components, the entire list will also have a validity check of its own. This allows us to quickly discard an entire list if we can determine it’s invalid without having to examine every member of the list.

A Component is the building block for this asset generation system. Each Component has three parts. The first part is the optional Pointer to Data—such as an image—that is unique to that Component. (Remember from before that some Components exist only to allow categorization and grouping of other items, so that’s why this data is optional.)

The second part is the Validity Criteria, a textual description of the circumstances under which the Component would be allowed. Note that all Validity Criteria are immediately trumped if the Definite Stack explicitly requires a component (“This monkey must have the purple mohawk”). If the Component does not meet the Validity Criteria, then the node reports back to its parent that it is not a valid choice.

The third and final part is the List of Child Components required to build this Component. For instance, if we were generating a house, the Child Components might be a front lawn, a front porch, a main body, and a roof. The node iterates through the Component List of front lawns. While a Child Component is being tested, it is added to the Possible Stack. If the Child Component reports itself as “valid,” it is added to the Valid Child List. Whether valid or not, the item is then popped off the Possible Stack and replaced by the next component on the Component List so that the “possible” state of the world is always accurate.

If a node passes the Validity Criteria and has real lists of Child Components, then the node reports back to its parent that it is valid, and control is returned to the parent node. A complete recursive pass through the generator in this fashion creates a tree of all possible assets.

Technical Design Considerations
This system builds a Tree of possibilities and then prunes the Tree down to a single path. In languages like C/C++, this large volume of allocations and de-allocations can fragment memory. The system can minimize the amount of memory used in these allocations by working with lists of Pointers. Instead of creating a Component, testing its validity, then tossing it out if it’s invalid or pruned, you create one of each Component, then add and remove Pointers to that Component during content generation.

Another easy step to reduce memory overhead is to change the order of operations a little bit. Instead of doing your pruning after the entire Tree is complete, you can actually make your random selection of Child Components from each Valid Child List and prune the others as your last step in reporting that a Component is valid. As a result, the Tree below your current location will always be a single, non-branching path of nodes.

There are also some other design challenges that should be mentioned:

While content can allow the player to devise new strategies, it won't generate new forms of game-play; you still have to dream that up yourself.
Variety and diversity of experience does not itself guarantee that people will want to replay your games.
We don't have purely procedural content yet. At some point, human beings must create the raw content that the slick algorithms then play with.
If you’re not careful, you can design systems that create so many possibilities for content that you don’t see them all during testing, and you can’t vouch for the quality of content that your testers never managed to see.

The good news is that both the Fast Food and Combination Plate systems can be coded using this Iron Chef methodology.

For the Fast Food technique of reusing components, the data on the composited asset for each category is limited to the category name and the Component chosen (for instance, “hair=male_blond_4”). To rebuild that asset at any time, feed this data to the generator’s Definite Stack, and you will get back the same asset every time.

The Chinese Combination Plate technique couldn’t be easier. Turn off validity-checking on the data. This makes all possible data for each category equally valid, so it will be randomly selected.

Andy Megowan (amegowan@iwin.com) has been designing and programming games for over two decades at several companies including Interplay, ION Storm, GameWorks, and Monolith. For the past five years he has worked at Sandlot Games, where he has worked in multiple capacities during the development of Slyder, Tradewinds, Westward, Super Granny, Cake Mania and many others. He recently joined iWin Games and has opened a new casual games studio in Seattle.

Josh Billeaudeau (jbilleaudeau@iwin.com) is a Production Engineer for iWin. An alumnus of digiPen, Josh worked as a Game Design Associate at Nintendo Software Technology on Mario vs. Donkey Kong 2: March of the Minis and other titles.

HOME \| LECTURES & ARTICLES \| GAME DESIGN \| STORIES THAT WRITE THEMSELVES Stories That Write Themselves Letting your games build their own worlds Andy Megowan Casual Connect Magazine, Summer 2007 As casual game developers, we have a contradiction in our business practices. We are competitors, each striving to coax consumers to spend their money on our games rather than on some other company’s games. Yet we are also collaborators, offering the games of our fellow developers alongside our own in exchange for a percentage. So how do we achieve any degree of differentiation in a market that requires us to collaborate with the competition? The solution is to distinguish between what we make and how we make it: We need to collaborate on process, and differentiate on content. We all know that if there is not enough variety, our games are either too short or too repetitive. So what content do we add to a game that makes a meaningful difference to our audience? Both more content and diverse content have their own headaches. More content in a game provides differentiation, but it also leads to more work, longer startup times, more testing, and bigger downloads. And we want to diversify, but not too radically—because although variety may be the spice of life, you can’t make a whole meal out of spices. What we need, therefore, is a way to make games that can offer more content, use fewer resources, and do it without being repetitive. Here are some processes that can help add richness, variety and “replayability” to your games. Most of these techniques have been around for a while in some form or another, and you can spot them in a few hit casual games. They are just the beginning of a long and exciting path towards games that are increasingly empowered to give our customers more of what they want without developer intervention. No matter how simple or elaborate a game is, you can use these tricks with minimal effort to enrich your games. Fast Food Visit any fast food chain and look at the menu, and you will see dozens of choices. Interestingly enough, there are more choices on the menu than there are ingredients in the kitchen. Combining some fraction of those ingredients with a minimum of effort and unskilled labor creates a wide variety of offerings. This is the most common way to cram a lot of content into a small game. Break your content into several highly reusable chunks, and then store only the information on how to arrange those chunks. The game Tropix, for example, has several mini-games and environments that very cleverly combine and reuse a modest library of assets. PopCap’s Bookworm Adventures presents an epic tale and scores of characters by recombining body parts to create a formidable cast of enemies. And the classic retro RPG Aveyond takes place on large maps made of tiled, repeatable images. This system has its limitations, of course. Like fast food, everything starts to look the same once you’ve seen all of the ingredients. And the environments remain identical from session to session and player to player. If the world remains the same, then the replay value has been lost; the interaction has been replaced with a sequence of steps that the player performs in order to recreate a familiar story. Chinese Combination Plate Let’s leave that fast food stand and visit a Chinese restaurant for lunch. You will see a long menu of lunch specials, but your options are limited. Each lunch special consists of an entrée, steamed or fried rice, and a fortune cookie. If they really pull out all the stops, then you also get your choice of a soup, a fountain beverage, and a fried wonton or eggroll. Applying this same principle to your game design, you might build a sort of “Chinese Combination Plate Generator.” The developer creates a world with blanks where certain information is supposed to go. The game stores possible data to fill in those blanks, then randomly selects something different each time. For instance, the Virtual Villagers games each generate a cast of characters with randomly selected clothing, hairstyles, talents, likes and dislikes. Each time you play the game, you have a very different population. Some games, like Tetris and Bejeweled, use this randomness as the core game to create a highly replayable experience. During each session, the player is confronted with a large quantity of randomly selected components, and must devise tactics specific to the situation. Many popular games allow the player to get in on this action, too. WildTangent’s FATE and countless RPGs offer players the chance to customize a character by picking one item each from a list of genders, classes, faces, hairstyles, and so on. Your audience will eventually catch on that while the ingredients are interchangeable, they have little to no effect on each other. Whether Sally has a red helmet or a blue bonnet, or whether the evil wizard’s name is Werdna or Mondain, the game plays the same. The choice of a particular ingredient has no influence on any other choice. Fortune cookie says: Tomorrow will be just like today. The Iron Chef Enough cheap food for now. Let’s see what happens when world-class talent takes a stab at preparing a meal. On the international hit show “Iron Chef,” two very accomplished chefs meet on a stage consisting of two fully staffed and fully equipped kitchens. The flamboyant host unveils a key food item and the clock starts ticking. Each chef has exactly one hour to prepare a sumptuous feast for the celebrity judges. The preparation of such a meal provides an excellent and useful development model for generating content. Each choice made throughout the process is affected by every previous decision, and it in turn influences every subsequent choice. It’s like taking the Combination Plate Generator and kicking it up a notch. In Blizzard’s mind-numbingly popular game World of Warcraft, the player selects a race from a list of eight to 10 possibilities. The choice of race immediately constrains the possible professions of the player. The player also picks a gender, and the race/gender combination leads to a unique list of customizable physical features. A male dwarf can pick a style of facial hair, but a female gnome can instead pick out a set of earrings. Some of these variations are purely visual, but that is meaningful content in a world with thousands of characters. Other pieces of information have consequences that follow you into the game and influence your character’s abilities and how it is treated by others. Now We’re Really Cooking This Iron Chef system leads to novel experiences from session to session and from person to person. Generated content has the potential to engage players’ attention, stimulate their brains, and allow unique stories to unfold. And when players can have different experiences from one another, it leads to discussion and the sharing of stories. We call that buzz—and buzz is very, very good. Simple sequences like the stream of puzzle pieces in Tetris or the procedurally crafted worlds in FATE are just the beginning of self-creating stories. Here are some other possibilities: For a game with characters that talk to one another, offer multiple versions of basic dialogue, and filter it based on the character’s chosen traits and any events that may have transpired. For a click-management game like Diner Dash, how about this: procedurally generate a character with randomly selected strengths and weaknesses, then give her a store in a random location. The location determines prices, clientele, starting facilities, interior decoration, and the business goals that you must meet to succeed. Joseph Campbell created a 12-step template for what he called the “Hero’s Journey”, the nearly universal pattern to all epic tales from Homer’s Odyssey to “Star Wars,” and Harry Potter. If you use Campbell’s template you already know what Components to make, and how to assemble them! Just come up with a set of variables and your design document is practically written already! It would be especially cool and funny if someone were to use the Iron Chef system to simulate the preparation of actual meals in a game. Imagine what might happen if procedural content generation were combined with player input analysis. Such a game could gather data about how Billy is playing, analyze it, and store it as parameters about the world. As more content is generated, these new parameters would be included, and different components would shift back and forth between valid and invalid possibilities. You would have a game that tunes itself to Billy’s needs, strengths, and weaknesses—a game with challenges, rewards, and stories dynamically generated especially for Billy. What you would have, in other words, are stories that write themselves. [SIDEBAR] How To Build Your Own Iron Chef Here is a generalized data-driven system for dynamically generated content. Use it for major choices when assembling content like characters and to generate unique scenery as well. The payoff of implementing such a system is that your game will look and play slightly different every time, increasing the chances that someone will take at least one more look at your game. Organizing Your Data To prepare for this type of procedurally-generated content, you should organize your data along these guidelines: Order of categories matters. You cannot select a pair of glasses until you know the nature of the face that they will rest on. Include grouping categories that have no visible output beyond the generation of the data. As an example, let’s say that you have 50 body types, and that types 4, 8, 15, 16, 23 and 42 were all tall and narrow. You could create a category called “body type” that includes options like “tall and narrow,” “short and round,” and even “medium athletic.” To determine if a shirt is suitable for a given character, you need only say it’s valid for “tall and narrow” bodies instead of listing it as valid for body 4, body 8, and so on. If you want some components to show up more often than others, add duplicate entries to your list of components. Instead of having a list of components {A, B, C}, you can make the list ten items long {A, A, A, A, A, B, B, B, C, C}. The result is that A will be chosen 50% of the time, B will be chosen 30% of the time, and C will be chosen 20% of the time. It involves duplication of the textual data where you store your lists of components, but text compresses extremely well. How the System Works The top-level design of this asset generation system is a Tree. The Tree consists of all possible permutations of the content that you are creating, with each node consisting of a Pointer to a possible Component. The system first generates this Tree, then selects a single path through that Tree, then prunes away all other branches so that all you have left is an in-order list of the components needed to build the new content. Like most trees, each node has just one parent node and any number of child nodes. Unlike most trees, however, several nodes can all reference the same component. For instance, you could have a pair of boots that would be allowable on bipedal cats or swashbuckling pirates, which would be generated on two very different areas of the tree. Along with the Tree are the Definite Stack and the Possible Stack. When testing the validity of a given component, the node will query the Generator for various pieces of information, and the Generator will attempt to find the answers on one of these two stacks and pass it back to the node. The Definite Stack is where you put all definite information about the world, such as “The environment is a desert” or “The character must wear a purple bandanna.” While the content is being generated, all possible permutations will also be checked for compatibility against the Definite Stack. This system assembles objects by creating all possible combinations, then selecting just one. The Possible Stack holds all of the previous choices made up to this point while the system generates a the set of options those choices allow. For instance, the game might ask, “If I were to select a gender of female and a race of Orcish, what professions are open to me?” The Possible Stack would then have “gender female” and “race Orcish” on it. All of your components will be organized into Component Lists, with one list per type of Component. Think of it as having a barrel of noses, a barrel of ears, a barrel of hairstyles, and so on. Like the individual Components, the entire list will also have a validity check of its own. This allows us to quickly discard an entire list if we can determine it’s invalid without having to examine every member of the list. A Component is the building block for this asset generation system. Each Component has three parts. The first part is the optional Pointer to Data—such as an image—that is unique to that Component. (Remember from before that some Components exist only to allow categorization and grouping of other items, so that’s why this data is optional.) The second part is the Validity Criteria, a textual description of the circumstances under which the Component would be allowed. Note that all Validity Criteria are immediately trumped if the Definite Stack explicitly requires a component (“This monkey must have the purple mohawk”). If the Component does not meet the Validity Criteria, then the node reports back to its parent that it is not a valid choice. The third and final part is the List of Child Components required to build this Component. For instance, if we were generating a house, the Child Components might be a front lawn, a front porch, a main body, and a roof. The node iterates through the Component List of front lawns. While a Child Component is being tested, it is added to the Possible Stack. If the Child Component reports itself as “valid,” it is added to the Valid Child List. Whether valid or not, the item is then popped off the Possible Stack and replaced by the next component on the Component List so that the “possible” state of the world is always accurate. If a node passes the Validity Criteria and has real lists of Child Components, then the node reports back to its parent that it is valid, and control is returned to the parent node. A complete recursive pass through the generator in this fashion creates a tree of all possible assets. Technical Design Considerations This system builds a Tree of possibilities and then prunes the Tree down to a single path. In languages like C/C++, this large volume of allocations and de-allocations can fragment memory. The system can minimize the amount of memory used in these allocations by working with lists of Pointers. Instead of creating a Component, testing its validity, then tossing it out if it’s invalid or pruned, you create one of each Component, then add and remove Pointers to that Component during content generation. Another easy step to reduce memory overhead is to change the order of operations a little bit. Instead of doing your pruning after the entire Tree is complete, you can actually make your random selection of Child Components from each Valid Child List and prune the others as your last step in reporting that a Component is valid. As a result, the Tree below your current location will always be a single, non-branching path of nodes. There are also some other design challenges that should be mentioned: While content can allow the player to devise new strategies, it won't generate new forms of game-play; you still have to dream that up yourself. Variety and diversity of experience does not itself guarantee that people will want to replay your games. We don't have purely procedural content yet. At some point, human beings must create the raw content that the slick algorithms then play with. If you’re not careful, you can design systems that create so many possibilities for content that you don’t see them all during testing, and you can’t vouch for the quality of content that your testers never managed to see. The good news is that both the Fast Food and Combination Plate systems can be coded using this Iron Chef methodology. For the Fast Food technique of reusing components, the data on the composited asset for each category is limited to the category name and the Component chosen (for instance, “hair=male_blond_4”). To rebuild that asset at any time, feed this data to the generator’s Definite Stack, and you will get back the same asset every time. The Chinese Combination Plate technique couldn’t be easier. Turn off validity-checking on the data. This makes all possible data for each category equally valid, so it will be randomly selected. *Andy Megowan* (amegowan@iwin.com) has been designing and programming games for over two decades at several companies including Interplay, ION Storm, GameWorks, and Monolith. For the past five years he has worked at Sandlot Games, where he has worked in multiple capacities during the development of Slyder, Tradewinds, Westward, Super Granny, Cake Mania and many others. He recently joined iWin Games and has opened a new casual games studio in Seattle. *Josh Billeaudeau* (jbilleaudeau@iwin.com) is a Production Engineer for iWin. An alumnus of digiPen, Josh worked as a Game Design Associate at Nintendo Software Technology on Mario vs. Donkey Kong 2: March of the Minis and other titles.