You would think that dealing cards at random would be trivially easy to implement. You would also be wrong.

Truly Random

Always the eternal optimist (and devout follower of the YAGNI principle), I start by implementing dealing cards by simply picking randomly among the types of cards available. Something along these lines:

for (int i=0; i<HandSize; ++i)
    hand[i] = Random_GetInt(0, CardType::COUNT-1);

The best part of this approach is that it’s simple. The bad part is… everything else.

Maybe that works for your game, and if so, congratulations, you can stop now and move on with the rest of the game. Unfortunately, this doesn’t cut it for most card games. The player might get a hand all of the same card. Or maybe never get a card type that she really needs. Most of the time, an algorithm like this will frustrate players quite a bit and get in the way of the enjoyment of the game.

Deck of Cards

The next approach I usually try is to simply copy physical games and build an actual deck. Remember that we’re talking about internal structures, so this doesn’t mean that the concept of a deck is exposed to the player at all. As far as they know, they’re just getting cards at “random”.

In this case, you create an array of card types, shuffle it, and give cards from the top to the player.

const int cardsPerType = 3;
for (int i=0; i<CardType::COUNT; ++i)
    for (int j=0; j<cardsPerType; ++j)
        Deck_Add(deck, i);

Deck_Shuffle(deck);

for (int i=0; i<HandSize; ++i)
    hand[i] = deck[i];

This is quite an improvement over our first approach. To start with, we’re guaranteed never to get more than a certain amount of cards of each type in the deck. That will prevent ridiculous hands of all cards of the same type that make the game unplayable.

It also allows us to vary the amount of cards of each type in the deck. That way we can make some cards more rare than others, or even enforce unique cards by only adding one of each of those types.

You may argue that this approach is perfect since this is how “true” (meaning “physical) card games are designed most of the time. While that is true, physical card games often involve just randomly shuffling a deck because the alternative would be very time consuming (or might need a third-party who isn’t playing to set up the deck). Because of that, most games need to be able to deal with very uneven distribution of cards, which might be too limiting for your designs.

A lot of games games will benefit of having a more controlled deck, and since we’re running on a computer, we can afford to do a lot more than just shuffle cards together. We can take advantage of the digital medium and do things we couldn’t easily do with physical cards.

Aside: Shuffling a Deck

Shuffling a deck might seem like a trivial algorithm, but as usual the details can get a bit tricky.

If you wanted to get very physical, you could try to simulate real riffle shuffling of a deck: randomly split the deck into more-or-less equal parts, and interleave them with each other with some randomness. Then you’d have to run it several times and even so I think you’d get very suspect results.

A simplified algorithm is to randomly grab two cards in the deck and swap their positions. Is that good enough? How many times do you need to run that loop in order to get a proper (i.e. fully randomized) shuffle? I haven’t analyzed that algorithm, but I get the feeling it would have to be done many times in order to get something acceptable (especially considering the not-very-random nature of computer “random” number generators).

The best and simplest approach I have found to shuffle a deck is the following: assign a random number to each card in the deck, then sort the cards based on that random number. It’s easy to understand how a single sort will shuffle the deck properly and works the same for any number of cards (and runs in O(n log n) if we want to get pedantic about it).

Multiple Decks

One way to have more control over the deck composition is to have multiple decks. We don’t need to communicate to the player that there are in fact multiple decks, this is something that happens under the hood.

This is the approach we took in Subterfuge. Players are presented with a choice of 3 specialists every X hours. Initially those specialists were completely random, but the results were very underwhelming. The approach we ended up settling on involved classifying each specialist as being in the categories of attack, defense, or other. The game prepares 3 decks, one of each category with 3 of each of the specialists in each category. Additionally, we make sure that we never have 2 of the same specialist in a row.

When it comes time to generate 3 “random” specialists for the players to choose from, we pick the top one from each of the decks.

Blocks

In my current prototype, the player has a hand of 4-5 “cards”, and as soon as they use one, a new one is drawn and their hand refilled. Cards can be roughly classified in 6 different categories, and it’s important that the player gets access to one of those categories within a few turns.

I wanted to come up with an approach that guaranteed access to tiles of all categories, but without making the pattern too obvious. For example, I didn’t want to have the deck be one card of each category.

The solution I can up with was to break up the deck in blocks of 10 cards. Within each of those blocks, I can make some guarantees about its composition. This approach was inspired by the composition of boosters in collectable card games like Magic: The Gathering, or even in the way the deck is prepared in Pandemic.

The way I implemented it, each block of 10 cards will contain one card of each category, plus 4 other random cards (as long as they are not already in the block). Then all the cards in the block are shuffled and added to the deck. This results in apparently “random” draws without feeling predictable, and yet players are never left without a key resource they may need.

This kind of enforced structure can also add some depth to the game. Expert players might notice this pattern (or read this, which is a lot easier) and use it to their advantage when they’re trying to make decisions based on what cards might appear in future terms.

Any of you out there use a different method for creating random-but-not-quite-random draws in your games?

So I decided to write a “rulebook” for Lasting Legacy. I put rulebook in quotes because Lasting Legacy isn’t 100% a board game. There’s a light simulation component behind the scenes that is opaque to the player, but everything else can be treated like a board game. I figured it would be a good exercise for me, and maybe a good reference for early testers so they know what’s going on without a fancy tutorial.

I’m happy with the final result. It’s about three pages of generously-spaced rules without any images, which beats a lot of board games out there.

A word of caution: This is not trying to be a funny, engaging rulebook. It’s a dry, to the point, description of all the rules in the game, arranged in the best way to understand all the concepts in a single read. It’s also not a “How to play” document. I think that could be another interesting exercise for down the line, where I just focus on the bare minimum to get a player playing.

Lasting Legacy Rulebook

1. Overview

Goal

Gain the highest Legacy possible.

Setting

Guide a European family around the 19th century through several generations. Socialize and find suitable marriage partners to grow you family, so you can earn Gold, Prestige, and ultimately, Legacy.

2. Concepts

Note: Any numbers shown here are just the defaults. There are always effects in the game that can modify those numbers up or down.

Family members

People in the family tree are called family members. Family members under 14 years old are considered children. They’re represented with round frames and don’t have any special abilities. Once they become adults they can choose between one or more occupations, depending on their education level. Adult family members will have children based on their age and fertility.

The head of the family, indicated with a special frame, defines which family members can be used at any given time. Only the head of the family, their spouse, and people under them (children and heirs) are enabled. Other family members are disabled and can’t be used.

Occupations

Every adult member can have an occupation. The clothes and items people have represents their occupation. Occupations can be passive or active:

• Passive occupations have a permanent effect on the game. All the current effects are shown in the effect window.
• Active occupations provide you with a potential action you can perform by clicking on the occupation button.

Some occupations require a minimum education to appear as a choice. Occupations come in 4 rarities: common, uncommon, rare, and unique. Unique occupations will appear at most once per game. Occupations also could have one or more time periods during which they can appear: early, middle, or late in the game.

Personality

Every adult family member and friend has personality traits that consists of a series of likes and dislikes.

Friends

Your family friends are shown along the bottom of the screen, in oval frames. The smiley face shows their friendship level towards the family. Each year friendships drop a fixed amount. When the friendship level for a friend drops to 0, the face turns blue, and the following year that friend leaves.

Friends can join your family through marriage. The heart in the friend’s frame represents how much they love someone in your family. Love is determined by many factors, including personality match, sexual preference, age similarity, and friendship amount. If that love level is above a certain threshold, it means they’re in love with someone and they’re willing to marry that person (see section 3: Proposing and Accepting Proposals).

Gold

Gold is one of the primary resources in the game. It can be earned through actions and effects of people. Additionally, you may have a recurring Gold income (shown in the green arrow), and a recurring Gold payment (shown in the red arrow) that happen every year.

You can spend more Gold than you have, automatically taking a loan. Every year your Gold is negative, your family pays 10% of that negative amount in interest payments. 200 Gold is the debt limit. If you ever owe more that amount, the game ends in bankruptcy.

Prestige

Prestige is the other primary resource of the game. It represents your social standing, and the more Prestige you have, the more friend slots you have available. You always have at least one friend slot. For every 10 Prestige you accumulate, you gain an additional friend slot up to a maximum of 10. Beyond that, you can accumulate more Prestige but you won’t gain any more slots.

If at any point you gain a friend but you have no empty slots available, the friend with the lowest friendship leaves and the new one takes its place.

Prestige can also be spent to do actions that are usually associated with negative social implications. Friends can leave you if your Prestige falls and you lose a slot occupied by a friend.

Unlike Gold, Prestige can’t even go below zero. However, you can still use actions that would cause your Prestige to go to zero. If you do, the person who did the action will be disowned by the family and won’t be part of the active family anymore.

Health

People normally are healthy. Sometimes they will become sick due to a variety of reasons. From there, each year they can either become healthy, stay sick, or turn terminally ill. Once someone is terminally ill, unless something is done about it, they will die the following year.

Heir

A yellow line in the tree indicates the next heir to the head of the family, which is the preferred child of the current head of the family. Whenever a family member does an action that’s related to one of those traits, their parents will change their opinion of that person, either in a positive or negative way.

You can see the current opinion of someone by selecting them and looking at the smiley faces over each of their children. The more filled in that face is, the higher the parent’s opinion of that child is.

When the head of the family dies, the current heir becomes the new head of the family. The new head of the family also presents you with a new family goal due to their tastes and whims. This goal will let you gain Legacy by doing certain things during their time as head of the family.

Heirlooms

Heirlooms will give you Legacy based on different criteria. You start the game with one random family heirloom in your collection.

Events

Every 30 to 70 years, an event will happen which will affect how things normally work. You will be notified 10 years before the event becomes active.

Countries

The majority of the people you’ll encounter during a playthrough come from the country you are playing in. You might encounter a few friends that come from neighboring countries. If you manage to add those friends to your family, that country will be unlocked and available for a future playthrough.

Countries add variety in the form of starting conditions, tweaked rules, and some unique occupations to those countries among other things.

3. How to play

Each turn, take one of the following actions. Each action will move the year forward one year.

Socialize

Gain one friend. The new friend’s age and education level is influenced by the person who socialized.

Visit Friend

Restore one friend’s friendship level to the maximum.

Propose in marriage

Men in the family can propose in marriage to friends. When you click on the propose in marriage button, only the friends who are willing to accept will be highlighted. Click on one of them to marry them.

Women will sometimes have a dowry made out of Gold and/or Prestige associated with them. When you marry a woman with a dowry, those resources are added to the family resources. On the other hand, women from the family will sometimes have to offer a dowry in order to marry a man. In that case, those resources will be taken away from the family resources.

Accept marriage proposal

People in the family can receive marriage proposals from friends (indicated by the hearts above their heads). These proposals are only available for one year. If you accept it, they’ll be married right away. Otherwise, the friend will feel rejected and their friendship will drop more than usual.

Choose an occupation

When a family member becomes an adult, they can choose an occupation (indicated by the question marks above their heads and their lack of occupation item and clothes).

If you don’t choose an occupation, they will pick one of the available ones after 5 years.

Use occupation action

You can click on the occupation action of any active family member to perform that action. Occupation actions are unique to each occupation. Sick people can’t do any occupation actions.

You can also use the occupation action of a friend. That’s like asking them for a huge favor, so they’ll do the action, but then leave.

Restore heirloom

Whenever someone in your family over the age of 50 dies, they will leave a family heirloom in the attic. Each heirloom in the attic has a cost associated with restoring it. You need to restore an heirloom to add it to your heirloom collection so it generates Legacy.

Pass

When there’s nothing else better to do, you can pass the turn and earn 5 Gold.

4. End of game

The game will end when one of these conditions is true:

• You run out of time and the war starts. The year display will always tell you how many years you have remaining.
• You reach your Gold debt limit.
• The head of the family dies without an heir.

The amount of Legacy you have at the end of the game is your final score.

My early-in-development creative process.

I don’t usually bother fleshing individual ideas out in design documents because it usually takes just as long for me to implement those things and see them in the game instead. And who would want to read about an idea when you can see how it works in the game directly?

During this phase I need to generate lots of different ideas because only some of them are going to stick. The more varied the better, so I like to approach my idea generation from different angles. The two most common approaches are starting from the theme, and starting from the mechanics

For example, in Lasting Legacy, we quickly came up with occupations like Family Doctor or Ball Organizer from the theme, and figured out what useful things they could do in the game (heal people, and attract new friends respectively).

We also came up with several occupations starting from a mechanics point of view. For example, we knew we wanted someone to increase the income of other people, so we came up with the Savvy Businessman occupation.

This time around I also used a third approach to generate ideas: Isomorphism.

Isomorphism is a word that comes from the greek composed of “isos” (same) and “morphe” (shape) and it means that two concepts are equal. This concept is very useful in mathematics. Imagine you have a very tough problem that you don’t know how to solve. Instead of having to go through the very difficult task of trying to solve that problem, you could instead show that it maps exactly (is isomorphic) to another problem you have already solved.

How does that help us with game design? If we can determine that our game, or at least parts of our game, map to parts of other games, we can look to see if the mechanics of those games can apply to ours.

I didn’t set out to design the Lasting Legacy this way, but it turns out there is a close correspondence between a lot of concepts in Lasting Legacy and Magic: The Gathering. That’s really good news because not only is Magic a great game, but it has been in active development for 25 years and it has explored a lot of different mechanics. So being able to draw parallels and tap into those ideas is a great resource and a very different angle of attack to a tough problem.

The mapping between Magic and Lasting Legacy goes something like this:

• Hand of cards = Friends
• Permanents = Active family tree
• Graveyard = Dead and inactive family members
• Library = Upcoming friends

I want to highlight that we’re talking about looking at concepts from another game, mapping them to our game, and then applying them, not using them straight. Those concepts couldn’t be used as it is, or wouldn’t make any sense, without the mapping from game to game. For example, in Magic: The Gathering, the player has a hand of cards but Lasting Legacy doesn’t, so the idea of discarding a card to achieve something doesn’t apply. Once we establish the mapping between the hand of cards and available friends, we could use the idea of dismissing a friend for similar purposes.

These are are some of the mechanics that we were able to map and apply to Lasting Legacy.

Bringing cards back from graveyard. Reanimating creatures has been a staple of black decks in Magic from the beginning. Thematically we could revive a dead family member, but that doesn’t fit very well with the more realistic approach of Lasting Legacy. Instead, we created a Genealogy Researcher, who can become the same occupation as a dead family ancestor.

Looking at cards from the top of the deck. Deck searching and manipulation is a very common blue Mechanic in Magic, but Lasting Legacy doesn’t really have the concept of a deck of cards, so we can’t do a lot of that. We can, however, look at the “top” X friends that would come up and pick one, which is exactly what the Dashing Socialite does. It’s a very useful occupation because it gives you a degree of filtering of your friends and reduces randomness.

Enter the battlefield effects. In Magic, many creatures have an effect that is triggered whenever they “enter the battlefield” (meaning, enter in play). This is a very useful tool, and we adopted it in Lasting Legacy. It gives you another reason to bring someone into the family, even if it’s not for their occupation or even to extend the main family branch. For example, the Charismatic Musician increases your prestige whenever he enters the family.

Blinking. Several cards in Magic allow players to “blink” permanents. That means those permanents go away and immediately enter into play again. That’s very useful to protect those permanents or re-triggering their enter the battlefield effects. We haven’t added this to Lasting Legacy yet, but it’s definitely towards the top of the lit of possibilities, especially if we end up with many other occupations that have effects when they join the family. This mechanic might make for an interesting subtheme for an expansion down the line.

There are many more mechanics that could be mapped to Lasting Legacy, but these are some of the most interesting ones we’ve done so far. If we end up making expansions, I’m sure we’ll revisit this topic as a source of new ideas and mechanics.

By now you’ve probably heard of Lasting Legacy: you’re managing a family around the 19th century through several generations, socializing, choosing good marrying prospects, and helping family members pick an occupation. Ah, occupations…

Occupations

Occupations and the life and blood of the game. It’s what gives the player lots of new actions and effects that can be combined in lots of different ways to achieve lots of powerful effects. The only downside of occupations is that… there are a lot of them! Right now we have about 50 and that’s just some really basic stuff. I expect the game will ship with about 100 occupations, and possibly more once we add country-specific ones.

50 doesn’t sound too bad you say. Sure, but each occupation has a lot of data that goes along with it: a name, whether it has an action or not, text for the action,text for the log, costs, whether it’s inherited… Hang on, let me tell you exactly what an occupation has:

struct OccupationInfo
{
     Occupation::Enum occupation;
     Rarity::Enum rarity;
     const char* maleName;
     const char* femaleName;
     const char* description;
     const char* logEntry;
     IconSpriteId::Enum spriteId;
     uint32_t periodFlags;
     int goldIncome;
     bool incomeMultiplied;
     int prestigeIncome;
     int legacyIncome;
     bool action;
     int goldCost;
     int prestigeCost;
     bool educationRequired;
     int targetCount;
     bool pickable;
     bool destructive;
     bool inherited;
     Occupation::Enum childrenOccupation;
     int personLike;
     uint32_t tags;
     AccessoryType::Enum maleAccessories[MaxAccessories];
     AccessoryType::Enum femaleAccessories[MaxAccessories];
     int maleAccessoriesCount;
     int femaleAccessoriesCount;
};

How do we set all that data for 50 different occupations? Back when I was working for big game companies I’m sure that someone’s job would have been to create a GUI tool to let designers enter those values. Then someone else would create a fancy XML format that could be exported from the tool. Then, if we were lucky, someone else would take that XML and crunch it during the asset conversion process into something binary that could be read directly into memory. Probably someone else would work on tech that would let you hot load new data while the game was running. Sweet!

Except that now I’m a lowly indie developer and I don’t have time for any of that stuff that doesn’t actually make the game better. Fortunately, I also don’t have a team of 50 designers to deal with, so my solution is this:

{
	OccupationInfo& info = OccupationInfos[Occupation::Banker];
	info = OccupationInfo(Occupation::Banker, "Town Banker", IconSpriteId::Banker);
	strcpy(info.description, "Gain 100 gold. Income decreases by 1.");
	info.logEntry = "%s %s gained %d gold.";
	info.tags = OccupationTags::Gold;
}
{
	OccupationInfo& info = OccupationInfos[Occupation::Poisoner];
	info = OccupationInfo(Occupation::Poisoner, "Cunning Poisoner", IconSpriteId::Poisoner);
	strcpy(info.description, "Kill another family member.");
	info.logEntry = "%s %s poisoned %s %s.";
	info.cost = 500;
	info.tags = OccupationTags::Danger;
	info.rarity = Rarity::Uncommon;
}
{
	OccupationInfo& info = OccupationInfos[Occupation::Tutor];
	info = OccupationInfo(Occupation::Tutor, "Private Tutor", IconSpriteId::Tutor);
	strcpy(info.description, "Another adult family member leaves their occupation and becomes educated.");
	info.logEntry = "%s %s sent %s %s to school.";
	info.educationRequired = true;
	info.tags = OccupationTags::Social;
}

“Oh the horror! Hardcoded data!” shriek all new CS students as they recoil from the screen.

But it really isn’t that bad. Actually, it’s pretty great: I don’t have any exporting/importing to do, I don’t have to load anything at runtime, and the compiler does a lot of checking for me. True, I can’t change it on the fly, but I don’t really need to when rebuilding the whole game takes about a second.

Unfortunately the problem is that we have 50 of those initialization blocks. Hopefully a lot more by the time we ship. They’re perfectly fine to work on each of them in isolation, but I’m not able to get a big picture. Have I created a similar one to this new one I’m thinking about? How much do other similar occupations cost? Can I get all the Social occupations together so I can compare them? How many rare occupations do we have in the late period? I can’t answer those questions very well by looking at that code. I needed something else.

Global View

Using some kind of text file wouldn’t help any. It would be a matter of changing that into an ini or an XML file, which would be much more painful without any of the benefits.

I started setting up a Google Spreadsheet, which is something we did for the specialists in Subterfuge. Spreadsheets have some nice capabilities like doing data validation on cells (for example, to enter enums), or letting you sort records based on some criteria. In Subterfuge the spreadsheet method worked reasonably well because we didn’t have as many specialists and each of them had less data, so the spreadsheet was pretty manageable. Here we just had too much data for each occupation and the spreadsheet was getting unwieldy.

Miguel mentioned SQLite, but I wasn’t too keen on linking with some extra library and loading that data at runtime. It also sounded like total overkill to have a full relational database for what amounts to a single table. Then I realized how wrong I totally was.

People have written GUI tools for SQLite that let you create, edit, and browse databases very easily. For example, we’re using DB Browser for SQLite and I think there are better ones out there (although maybe not free ones). Our main table looks something like this:

And the data itself like this:

It looks like a spreadsheet until you realize that you can very easily search any field and you can even create “views” with more complex queries ahead of time. So now I can quickly see how many rare occupations we have in the late period with a single click. Very sweet! It definitely gives me that global view I was hoping for.

How about loading this data from the database at runtime? I doubt it would be a big deal, but it’s still something I’m not crazy about. Fortunately, it’s super easy to extract the data from SQLite. We have this in our make file:

@sqlite3 -header -csv $(DB_SRC) 'SELECT * FROM Occupations' > $(DB_CSV)

And that spits out a nice comma-separated file with all the data. Still, loading csv files at runtime isn’t much of an improvement, so we do a bit more processing. Initially I started converting the csv file into an ini file (since we already have an ini-reader library), but then I realized there was no point in doing that. Unlike Subterfuge, I’ll never want to have different versions of the game data around and load them based on different rules versions. We just want one true version. What’s the easiest way to put that data in the game? C code!

So with a simple Python script, I convert that csv file into a C file that looks an awful lot like the one we started with, except that this time it’s completely derived from the contents of the database. One of the great benefits of this is that we can let the compiler do a lot of the checking instead of having to do it in the script or (gasp) at runtime. For example, some occupations force their children to have a particular occupation (King -> Prince). I don’t even have any code that checks that the occupation you enter there is valid. We just generate code like this:

info.childrenOccupation = Occupation::XXXXX;

If XXXXX doesn’t happen to be a valid Occupation enum, you get a build error until you fix it. And again, since the whole turnaround time between editing the database and building the game can be a second or two, it’s really no big deal at all.

Constants

I left one small detail: Constants. Look at some of the first code I put up early on:

strcpy(info.description, "Gain 100 gold. Income decreases by 1.");

What’s wrong with that? Yup, you got it. Somewhere else in the code, I have some constants like this:

const int BankerReward = 100;
const int BankerIncomePenalty = 1;

Now every time I change how much money the Banker gives, I need to change the string and the constant (let’s not even talk about localized strings yet).

So instead now I use global string replacement while we’re generating the C code. The string on the database is this:

Gain [[BankerReward]] gold. Income decreases by [[BankerIncomePenalty]].

Whenever we load the csv file, we look for any substrings with the pattern [[…]] and we try to match them from a header file with constants that we’ve loaded. If we find them, we replace them with their values, and if we don’t, we spit out an error and stop because clearly someone wanted to have a string replaced there and probably mistyped it.

Does all of that sound complicated? Not really. When I said earlier that the Python script was simple, I wasn’t kidding. This is the bulk of it, including the constant replacement (just a couple helper functions are missing):

def main():
	dir = os.path.dirname(os.path.realpath(__file__))
	baseDir = dir + "/../LastingLegacy/AssetsRaw/"
	reader = csv.DictReader(open(baseDir + 'db/occupations.csv', 'rU'))

	sourceCodeDir = baseDir + "../src/"
	globalVariables = readGlobalVars(sourceCodeDir)
	pattern = re.compile(r'\b(' + '|'.join(globalVariables.keys()) + r')\b')

	Rarities = {'C': 'Rarity::Common' , 'U': 'Rarity::Uncommon', 'R': 'Rarity::Rare', 'Q': 'Rarity::Unique'}
	Periods = {'E': 'Period::Early' , 'M': 'Period::Middle', 'L': 'Period::Late'}

	defFile = open(sourceCodeDir + "Occupations.inc", 'w')
	for entry in reader:
		type = entry['id']
		defFile.write('{\nOccupationInfo& info = OccupationInfos[Occupation::' + type + '];\n')
		defFile.write('info.occupation = Occupation::' + type + ';\n')
		defFile.write('info.spriteId = IconSpriteId::' + type + ';\n')
		defFile.write('info.maleName = "' + entry['maleName'] + '";\n')
		if entry['femaleName']:
			defFile.write('info.femaleName = "' + entry['femaleName'] + '";\n')
		else:
			defFile.write('info.femaleName = info.maleName;\n')
		
		description = multipleReplace(entry['description'], globalVariables)
		defFile.write('info.description = "' + description +'";\n')
		
		defFile.write('info.logEntry = "' + entry['logEntry'] + '";\n')
		WriteOptionalBool(defFile, entry, 'educationRequired', type)
		WriteOptionalKey(defFile, entry, 'goldCost', type)
		WriteOptionalKey(defFile, entry, 'prestigeCost', type)
		WriteOptionalKey(defFile, entry, 'goldIncome', type)
		WriteOptionalKey(defFile, entry, 'prestigeIncome', type)
		WriteOptionalKey(defFile, entry, 'legacyIncome', type)
		WriteOptionalBool(defFile, entry, 'incomeMultiplied', type)
		WriteOptionalBool(defFile, entry, 'action', type)
		WriteEnum(defFile, entry, 'rarity', Rarities, type)
		WritePeriodFlags(defFile, entry, 'periods', Periods, type)
		WriteOptionalKey(defFile, entry, 'targetCount', type)
		WriteOptionalBool(defFile, entry, 'destructive', type)
		WriteOptionalBool(defFile, entry, 'pickable', type)
		WriteOptionalBool(defFile, entry, 'inherited', type)
		if entry['childrenOccupation']:
			defFile.write("info.childrenOccupation = Occupation::" + entry['childrenOccupation'] + ";\n")
		WriteOptionalKey(defFile, entry, 'personLike', type)
		WriteOptionalTags(defFile, entry, 'tags', type)
		WriteOptionalAccessories(defFile, entry, 'maleAccessories', type)
		WriteOptionalAccessories(defFile, entry, 'femaleAccessories', type)

		defFile.write('}\n')

	defFile.close()	

Here’s the full script in case anyone is interested in the details.

Boom! Done!

Ship it.

Once you have defined that feel, you can run every single design decision by it. Every game feature should support those feelings in some way, if not, they’re a good candidate to cut. And if some contradict them directly, you can veto them right away and not go down that path any further.

For Lasting Legacy, we have two main feelings we want to evoke in players:

1. Experiencing the drama of complex family stories.

A playthrough of Lasting Legacy lasts about 20-30 minutes and the game is intended to be played over many times (more details on this for a later post). Each of those playthroughs is completely different, and the player experiences an entirely different story of a family through the generations. The combination of the player’s actions and the behaviors of the game characters should create funny, memorable, and sometimes bizarre situations.

For example, this is a recount of something that happened in just one of the generations of one of my recent plays of the game:

The Novak family was pennyless and without any income. Mr. and Ms. Novak spent all their effort into trying to gain prestige and money to secure a place in society. They had two children, Jakab and Andrea. Jakab, unfortunately, ended up being the Town Gossipmonger and never held any real jobs. Andrea managed to become a Baker, but the income was meager.

Things started looking up when Andrea, caught the eye of Mr. Kende, a handsome, rich friend of the family. They were quickly married and the family felt the relief as they had access to Mr. Kende’s fortune. The parents approved very strongly of this union and made sure that Andrea would become the heir of the family.

Years passed, and even though the disappointing Jakab was married and provided numerous grandchildren to Mr. Novak, Andrea and Mr. Kende didn’t have any children of their own yet. This was a grave cause of concern for her parents, who even encouraged them to see an herbalist to increase their fertility. A few more years passed and at this point it was clear that there would be no children out of that marriage. Something had to be done or the dynasty would end right there.

Jakab started spreading rumors about how Mr. Kende had come by his fortune through shady means, hoping to hurt his reputation and have his parents choose him as the new heir. His attempt failed, ended up being further distanced from his parents, and Andrea was still the sole heir.

Mr. and Ms. Novak died after some time, and Andrea and Mr. Kende, still childless, became the new head of the family. It looked like the dynasty would end here, but that’s when they became acquainted with Ms. Bognar, the orphanage director. She was able to facilitate the adoption of Henrietta, an adorable 6 year-old girl who would become the hope of the family’s future for years to come.

We want to be able to let players share their most memorable stories, but we haven’t fleshed out exactly how we’re going to do that. As you can see from the previous paragraphs, it’s not a trivial matter. One possibility is to export some kind of autogenerated scrapbook that players can annotate if they want to, but there are many other ways we can go wit this (Any great ideas? Let us know in the comments).

2. Feeling smart for discovering combinations of occupations that create really powerful outcomes.

The explicit goal of Lasting Legacy is to score as many points as possible (i.e. build the largest legacy). In order to do that, players will acquire gold, prestige, and eventually turn it into legacy through different means. To get really high scores, players will have to carefully combine the actions and abilities from the different members of their family and their friends. The more outrageous the combination, the bigger the score.

This is an example of the kind of thinking that goes behind finding combinations of powers:

The current head of the family likes prestige and will give 1 legacy for every 10 prestige the family earns. You have a Philantropic Benefactor in your family that gives you 5 prestige for every 50 gold you “donate”, but gold is running low. However, you also have access to a Ruthless Negotiator, who reduces all action costs by half, so each Philanthropic Benefactor activation gives you 5 prestige for 25 gold. This works for a few years, but you’re almost out of money.

Then you notice that one of your friends is a Radical Anarchist, whose power is to get rid of all debt but he goes to jail. So you bring him to the family, rack up the debt to the maximum with the Philanthropic Benefactor, and finally send off the Radical Anarchist to erase all the debt. As a result, you gained a large amount of legacy, greatly increased your prestige, and didn’t spend much gold in the process.

This is very similar to the kind of combination of powers you find in games like Magic: The Gathering (a huge influence on me in general), and also reminiscent of the specialists powers in Subterfuge.

Those two goals are orthogonal. I could see some players enjoying one but not caring about the other, so we’re making the game that can be enjoyable even if you just care about one of those aspects. We’re making sure that both kinds of players can enjoy the game to the fullest. Someone who mostly cares about the stories, can just focus on growing the family and dealing with the emerging drama. On the other hand, someone who cares about maximizing their score also need to maintain the family going because it means playing longer and scoring more points, but they can ignore the in-game meaning of the actions they’re taking and just visualize it in terms of how big of a legacy they’re creating.

We hope that once players have played through the game many times and they become really good at it, that they ignore the explicit game goals and make their own constraints. The game becomes more of a toy at that point (unconstrained play) which is an aspect I love in games (we did that with Casey’s Contraptions as well). For example, the player may want to decide to play through a family in extreme poverty that never earns any gold, or a family that is all made out of criminals and low-life characters, or maybe just try to breed the most extreme physical characteristics possible. We hope there’s a lot of room for exploration and enjoyment beyond just getting high scores.

We don’t talk much about the role of luck in video games, probably because it’s hidden away under the black box of the computer simulation, but just like with board games, it can have have a large impact in the type of experience the video game provides.

Thinking about luck in these terms was crucial for the game I’m working on (still unannounced!). We made some crucial decisions thinking about how luck was part of the game and kind what kind of experience it created for the player. I’m hoping this post helps people with similar design challenges.

This post should apply to any kind of game in general (board or video games). Next time, I’ll be focusing especially on luck in video games using this as a launching point for a deeper look. Also, I’m limiting the definition of luck to random effects built into the game system itself, and not due just to player interaction.

No-Luck Games

In games with no luck, players rely completely on their skill to win. In that way, they’re closer to sports. Games become an intense, straight competition, pitting players’ brains against each other. Right there it shows how luck (or in this case, the absence of luck) creates a very specific feel to a game.

Good examples of games without any luck are classics such as Chess or Go. There are also plenty of modern board games with no luck, like Puerto Rico, Caylus (they both have a minimal amount of luck in the initial tile order), or Hive.

It’s interesting that a lot of abstract games tend to have no luck, and the more thematic a game gets, the more they seem to rely on luck.

Are You Feeling Lucky?

Having some amount of luck in a game can be very beneficial for most kinds of board games. It accomplishes many things:

1. Keeps things varied from game to game
2. Keeps players feeling they have a chance to win even if they’re not currently ahead
3. Removes pressure from winning players (“If someone beats me, it’s because they had a lucky streak”)
4. Makes players who didn’t win feel they stand a chance next time they play (“next time I’ll catch a break and I can win!”)

Points 2, 3, and 4 all encourage more people to play the game and feel they’re competitive at it, even if they didn’t win (and even if they’re not really competitive). One of the best examples of this is poker: Everybody feels they can do great at poker, if only they get good cards. In reality, this is not true in the long term, but poker introduces plenty of luck that it really is true in the short term.

A consequence of all those points is that having some amount of luck allows players of different skills to participate in the same game and enjoy it equally. For games that rely on having multiple people looking to play it, it can be a big factor.

Types of luck

For games that choose to add some luck element, there’s a whole range of amounts and types of lucks they can use for different effects. Unfortunately, it’s also possible to mix the wrong type of luck with a given game feature and create a frustrating experience instead of an enjoyable one.

• Post-action luck. This is luck introduced after the player has made a decision and executed an action. It can be in the form of flipping a coin to see if you unlock a chest, or rolling a dice to see if your armies invade a territory.
• Pre-action luck. Pre-action luck consists of the random events that happen before the player performs an action. The player is able to take them into account and make a decision based on them.
• Hidden information. Hidden information is the third kind of luck. I was a bit hesitant to include it as its own category first, but it seemed different enough from the other two to warrant being listed on its own. Hidden information refers to things that are known only to some players and will affect other players or the game scoring.

Post-action luck

OK, I’m going to say it: I’m not a fan of post-action luck. The player has already made its action and the outcome is random (even if it’s based on a probability curve the player is aware of, like rolling 3 six-sided dice). Since it doesn’t add to the choices the player has, it’s mostly uninteresting. This is the kind of luck that can add a bit of spice to an otherwise boring game, it doesn’t do much to make the game more interesting.

When used incorrectly, this kind of luck is extremely frustrating. The player can feel they chose the “best” action, but they rolled double 1s and their move backfired on them. Sure, there was some tension knowing that could happen, but was it really fun? Maybe the first time or two, but probably not long term.

While I typically really don’t like this kind of luck in my games, there are some situations in which even I will add it can add some interest to the game.

The first case is when the player can choose to perform one action or another, being aware of the different probability curves for both actions. For example, you can roll a single die and deal that damage to an enemy, or you can roll two dice, but if you roll two 1s, your character gets hit instead. In a situation like that, even though it’s still post-action luck, the player was presented with a meaningful decision ahead of time and had to weight the risks and rewards of both options.

The second case where post-action luck can work is when the action is repeated many times over the course of a game. That way, the outcome of each individual action in themselves is not game-breaking, and all the actions will eventually add up to the average over the course of the game. Luck in this case introduces a bit of noise and slight excitement without affecting things much.

This is a good situation to combine with the ability for players to slowly change their probability curves over the course of the game. That way, they can increase their chances of success for an action as the game progresses, presenting the player with a way to feel more powerful. This is often used in RPGs and video games.

Having some kind of post-action luck that affects the outcome of an action can also give players hope that they can do something, even if those chances are small. Otherwise, without any luck involved, they would see the situation is hopeless and lose interest in the game. At the same time, having that luck element makes predicting every possible outcome nearly impossible, so it encourages players to make a decision without spending a long time figuring out an ideal outcome.

Finally, another situation where post-action luck isn’t always a bad thing is in very short games. I love King of Tokyo even though it’s a complete dice fest with lots of post-action luck. Even if you get some really bad dice rolls, a game maybe only lasts 10-15 minutes, so it didn’t feel like a complete waste of time. On the other hand, losing a 4-hour game to a dice roll can be extremely infuriating.

The dark side of post-action luck is the human addition to random rewards, which is the reason why gambling or slot machines are so popular. Games can exploit that human quirk to their advantage and hook players in a game that would otherwise not be very interesting or fun.

A very meta post-action luck is buying “booster packs” of collectable card games (like Magic The Gathering). Purchasing the cards is the action, and the luck happens when you open it and see which random cards were in the pack. As most ex-Magic The Gathering players can attest, this can be extremely addictive.

Pre-action luck

This type of luck can add just as much randomness as post-action luck, but creates a very different feel for the game. Since the random event happens before the player action, even if you didn’t get the ideal outcome you were hoping for, you can choose to do the best action given your situation.

To illustrate the difference, consider power-ups in a first-person shooter. You open the door to one room and there’s a mysterious gift package power-up. You have no idea what it is, you pick it up and… it turns out it was health. Maybe that’s great because you were low in health. Or maybe you were maxed out and it was useless. That’s post-action luck.

Alternatively, imagine you open that door and you see 3 power-ups side by side. You see what they’re going to give you (health, ammo, or a new weapon). As soon as you take one, the others go away. Maybe neither one of them is exactly the ideal, but you can make a decision and pick the best one for your situation. That’s pre-action luck.

In board games, Stefan Feld is the master of pre-action luck. A lot of his games involve some kind of luck mechanism that limits your actions. For example, in The Castles of Burgundy or Bora Bora, you roll dice, and the numbers on those dice determine which actions you can take.

Without going that far, just about any games that involves drawing cards from a deck and having a “hand” of cards uses pre-action luck. The cards you’re dealt are the pre-action luck, and then you have to do the best you can with those cards.

An extreme type of pre-action luck is initial game layout. That happens only a single time during the game, and before players make any actions, so it has the potential to affect the full course of the game. Even players who are adamantly opposed to luck in games, are often willing to accept game setup randomness because it can be fully taken into account during the game without any surprises.

Pre-action luck isn’t as common in games as post-action luck, but it could be used just about anywhere that post-action luck is used. Consider the classic situation of a character attack some monsters and rolling a set of dice that determine whether he hits and how much damage it does. We could change that into pre-action luck by having players roll the dice (either all at once or separately), and having the dice restrict the options of what they can do. For example, low rolls on one dice could indicate that they can only do an attack close to the ground, while high rolls means they can attack flying enemies. Then the player can choose which of those actions to take, or maybe he can instead take a defensive stance or run away.

The main downside of pre-action luck is that it can extend every player action. The more it’s used, and the more possible choices it presents to the player, the longer the game might take, so it’s best to save it for times where the decisions really matter. If not, either post-action luck or no luck at all, might be better choices.

Hidden information

The most common example in board games is hidden end of game bonuses. For example, in Shipyard players get a set of goals that will score them points at the end of the game. There are two reasons for these goals: By giving each player different goals, it encourages players to focus on different aspects of the game instead of fighting over the same set of “optimal” actions. It also encourages players to pay attention to what other players are doing, and potentially try to anticipate or even block other players from getting too far ahead in their goals.

An even more interesting case is the game Troyes (one of my favorites!). Not only does each player get a set of end-of-game goals to get extra points, but all players, not just the player holding them, will be scored based on those goals. That makes paying attention to other players and trying to guess what they’re doing even more important.

At the extreme end of hidden information there are games like Discworld: Ankh-Morpork, in which each player gets a hidden winning condition. Players go about doing their actions until someone announces at the beginning of their turn that they have won the game, and they reveal their hidden victory condition card.

The higher the importance of the hidden information, the more casual and random the game becomes (and so, the shorter the game should be ideally).

I started writing this thinking it would be a quick entry about luck in games, but now it’s grown into something pretty large, and I didn’t even get a chance to touch on luck in video games. I’ll look into that next time.

Related reading These are a couple of great writeups/presentations on the same topic:

• Types of Luck by Antti Karjalainen
• Luck, Skill, and Hidden Information by Robert Gutschera

Brewing

A new game for me starts as an idea somewhere, sometime, that got jotted down into my “game ideas” personal wiki page. I have that page accessible 24 hours a day on my computer, iPhone, or iPad. Only while I’m running/cycling or in the shower am I away from that page (and unfortunately, that’s the time when most ideas seem to spark). I make a point of not censoring any ideas: If I thought that something would be neat (not just gameplay, but a setting, a visual, a mechanic, or anything), I jot it down.

Over time, I accumulate quite a few ideas. Every so often I review them and I might expand on some and flesh out sub-ideas. Or they might spark different ideas of their own and I jot them down too. I never delete any of them, because I’m consciously trying to not censor anything yet. This is purely brainstorming mode. I’ve even sent emails to friends about possible game ideas straight out of this list, crappy ideas and all.

During this time I’ll rearrange the list. I’ll move more likely ideas up, or ones that I’m more excited about. That has the effect of a kind of bubble sort, so the better ideas somehow rise to the top (except for the brilliant ones hidden in the depths somewhere).

This list is particularly useful when I’m in the middle of a project and I have what seem brilliant game ideas. Do I put the project aside to do this great idea instead? No. Instead, I add it to the list with all the others. If I’m really excited about it, I’ll flesh it out as much as I can, but it needs to wait its turn. As you can imagine, after a few days, the idea doesn’t seem so shiny anymore, so it was a good thing it didn’t derail the current project.

Struggling

Eventually the time comes when I need to pick a new project, and this is where the fun and the pain start.

You would think a good approach might be to read the list and start evaluating ideas. In a way, that’s what I do, but before I evaluate ideas, I need to some frame of reference to decide what’s a worthwhile idea and what isn’t.

In the past my criteria for considering a project involved the intersection of three requirements:

• The game must be interesting for me to work on. I want to learn something new and be excited about what I do. Not interested in cloning something or making a derivative game.
• A game I can realistically implement with the resources at my disposal. I’m not an artist, so that usually means not having a content-heavy game, and relying on code as much as possible (like the procedural geometry in Flower Garden–no artist modeled those flowers by hand).
• A game that has potential to sell well on the target platforms.

Unfortunately, meeting all those three requirements at the same time isn’t easy, especially given the astounding number of games already on iOS.

Before I go any further, I need to step back and ask myself a very important question: Why do I want to make this next game? This is a question we indies have the luxury of asking (and answering). I think most big (and small) studios are too busy staying afloat to be able to ask anything like that (besides, the answer is almost always “make more money” for them).

It turns out the indie life is treating me very well, so making lots money isn’t one of the main reasons to make this next game. That means I can safely remove that requirement from my previous list, which grants me a lot more freedom.

I’m probably going to spend the next 6 to 10 months working on this project, so it needs to be worthwhile. Does it need to be innovative and break new ground in a way no one has seen before? Does it need to make hard-core FPS players cry to be worth considering? Does it need to be radical, pixelated, mash up 5 different genres, an win the IGF and respect of my peers?

It turns out none of those are the reasons that drive me to make games. In the end, when I look deep down, the reason I want to make games is for the pleasure of taking a vision from the initial idea to something people can play. It’s the creativity involved that drives me. I imagine it’s the same reason people are driven to write or paint. If along the way, some of those games manage to be innovative, make money, or win an IGF award, that’d be fantastic, but in any case, the development process is its own reward.

Given all those factors, I can go down the list of games and evaluate each one. Does it have potential to meet those requirements and be a satisfying project? This might not come as a surprise for those of you involved in creative activities, but this is hands-down, the most difficult time of development for me. As long as I don’t have a project picked, my mind is constantly going over this. Anything I read, see, or hear is filtered and analyzed thinking of how it would fit in a game. During this time I’m often moody, volatile, and prone to depression if this goes on for too long.

Even though it seems I’ll never going to be able to come up with an idea worth doing, eventually something comes along, and the next phase starts.

Prototyping

I’ve already talked about prototyping at length before. I take the idea I’m considering and I try to answer the key questions in the shortest possible time. This is the time to shoot down any bad ideas, or prove why they’re not feasible or just boring.

The prototyping phase is a big high for me. It often involves manic activity and I can get a prototype done in a day or two from the initial excitement on the idea. The bad part is that most prototypes prove not to be that great, and they go back to the drawer of game ideas, and I’m left scrambling for another idea.

Struggle. Prototype. Discard. Repeat.

I usually repeat this cycle multiple times. Each time around I get more anxious, and the lows and highs are a bit more extreme.

Fortunately, at least so far, eventually I find a prototype that seems worth doing. Something I can see spending the next X months of my life doing. I usually run it by a few friends whose opinion I value highly, and if they’re excited about it too, then it becomes an internal green light and I move on to the implementation phase.

Tips

Apart from asking yourself why your making a game, here are a couple of things worth keeping in mind when picking a new project. They’re not new things and I’ve heard them before in one form or another, but they’re worth reiterating:

• Don’t compete with big companies. They can throw a lot more resources, and, most importantly, lots of marketing behind their titles. Don’t try to take Zynga head on. Do your own thing.
• Don’t chase trends. Take risks. Be different. You’re indie and have low overheard. Take advantage of that and do things the big boys would never dare risk $50 million on.
• Keep the scope of the project small and focused. It will be bigger than you envision anyway. By being small, you can come up with new ideas faster than big companies.

How about you? What’s your process for deciding to work on something? Do you struggle until you pick the project? Do you stick with an idea, or do you change and restart?

I was having a discussion today about free games with other developers and I thought I would post here some random thoughts and open it up for discussion.

Free-to-play (or freemium–even if they aren’t exactly the same, I’m bundling them all under the same category for this discussion), have have a fairly bad reputation, and they’ve been under fire recently from developers. It’s true that a lot of those games have been rather poor from a game design point of view, while raking in loads of money from players who are apparently happy to play them.

It’s important to separate the financial model (free with other ways for players to spend money in-game), and the quality of those early games or the intentions behind them. I am convinced that free games is the future of mass-market games (it’s already pretty much the present, so that’s not much of a stretch).

There’s no doubt that the financial model of game affects its design. Compare arcade games, retail console games, and subscription-based games just as an example. Free-to-play has a huge impact on the design as well.

Free-to-play games are in their infancy. Not only are they a relatively recent happening, but they were also wildly successful, which encouraged a lot of copying and not much innovation. So they’re stuck in a type of design that results in a local maximum of profit, while providing a not very satisfying experience for a lot of players. As game developers, we need to find out how to make great games while using the free-to-play model.

I’ve been going around this quite a bit recently, because I’m in the stages of deciding what my next game is going to be. The reality of the App Store are pushing me towards free-to-play, but I’m not interested in making a Farm/Store/Pet game.

These are my random thoughts on what we can charge for in a free game and how it affects game design:

• Reduce delays. This is very effective, but feels cheap and somewhat manipulative (yes, this is coming from the guy who did Flower Garden… but that was before IAPs and the whole point of the game was the nurturing/waiting part). It also falls in the category of the question I often ask myself: If I remove this from the game, will it be better or worse? The answer is (almost) always “better” by removing those delays.
• In-game currency. This is seems like a better approach as long as there’s no competitive multiplayer. However, it does wreck havoc with the game balance. Either it becomes too easy and not fun for those who paid, or boring and grindy for those who didn’t. Still, especially on mobile, it’s not a totally bad way to go. You’re letting people make a choice how they want their experience.
• Extra content. That seems to be the traditional, developer-approved way to go. PC and console games have been doing that with DLCs for a long time. The main problem is that not many players want that content, the amount of content you can sell is limited, and it often requires a lot of extra effort to generate.
• Extra choices. This includes different characters, clothes, weapons, etc. I see this as the sweet spot between the last two options. What you buy doesn’t completely throw off the game curve, but it’s also not just new levels or missions. Combine that with letting players earn credits to get those choices (by grinding if they want to, but it’s all optional) and it seems like a good way to go. You can also go the way of League of Legends (which I have yet to play!) and you can rotate in that extra content for limited amounts of time, so players get a taste and they have the option of buying them permanently.
• Cheats. By cheats I mean more lives, rewind/replay, invulnerability, etc. It feels like a throwback to the arcade days. Some players will be put off by it (either by the fact it exists, or by the fact that they finished the game too quickly with the help of those cheats), but it can work in the right game. You’d probably want to do something about high scores, like putting players who used those cheats in a different leaderboard.

What are your thoughts on this? What are some other ways that players can pay for in free games and still allows us to make a great game?

Casey’s Contraptions is an iOS game created by the two of us, Noel Llopis and Miguel à ngel Friginal. Noel, an industry veteran for over a decade, turned indie over four years ago and found success with microtransaction-based Flower Garden on iOS. Miguel worked as a graphic designer in the advertising industry for years before becoming a web developer. Casey’s Contraptions is his first published video game, although his first paper role-playing game came out almost 20 years ago. We met through Twitter several years ago, and then finally in person at a 360iDev conference. Even thought we didn’t plan it that way, we ended up working together during a game jam, and that set us in the path to collaborate in a future project.

We knew we wanted to target iOS for our next project because we love the platform from a user and a developer point of view, and because it’s a platform where it’s possible for indies to succeed financially. Beyond that, starting a new game is never easy. Even though we have page after page of possible ideas, settling on a specific game idea is always very hard. We wanted something that met three requirements: The game had to be creative in nature as opposed to using destruction as the main gameplay element, it had to be something we were excited about, and it had to be something with the potential to sell reasonably well on the Apple App Store. Easier said than done!

We prototyped game idea after game idea, and even though a lot of them were not bad, none were a complete standout. Eventually, after seven or eight different prototypes, we settled on the concept of creating physics-based, Rube Goldberg-like contraptions to solve different puzzles. At its core, the game has similar mechanics to some classic games like The Incredible Machine, but with an emphasis on exploration of creative solutions rather than finding the one right answer to each puzzle, designed around sharing, and built from the ground up for a touch interface on iOS.

We structured this project as a pure 50-50 partnership, and without any external funding or publishers. Miguel quit his full time job (as a web programmer no less!) to do the art for Casey’s Contraptions, and Noel took care of the programming. Design was a fully collaborative activity, where we both contributed equal amounts to everything from the rules, the feel of the game, or level creation. Everything else we split up based on our strengths and expertise: web site, server back end, PR, etc.

This is not a true postmortem, but more of a post-launch analysis. Games today, and especially iOS and Facebook games, are becoming more of a service rather than a product. Development and launch are only the beginning of the story. If all goes well, we’ll have a lot more to say about Casey’s Contraptions in a few months.

What went right

Strong theme and style

Casey’s Contraptions started life without Casey! The initial prototype focused only on the creation of contraptions and the physics simulation behind it. It showed a lot of potential, but it was missing something to make it stand out. It needed more personality.

After some brainstorming, we quickly zeroed-in the idea of a smart 8 year old building the contraptions. Not only did that add the much-needed personality to the game, but it also focused the rest of the development. Instead of doing a physics game with generic pulleys and levers and other industrial-looking items, we naturally went with toys and household items Casey could have access to: His sister’s doll, paper planes, or his RC truck.

The choice of toys as game items not only influenced the level design, but also the goal of the levels. At the beginning we were thinking of doing levels to accomplish tasks Casey would have to deal with in real life, such as putting toys away or popping a balloon. After a while, the idea of “playtime†levels came up, where the setting and the goal were completely imaginary (rescue explorers from a jungle in their hot air balloon) just as Casey would have imagined during his playtime sessions.

The character of Casey also helped anchor the art direction. We were aiming for something that would appeal to a very wide range of people, from the very young to adult casual gamers. Although Miguel looked into everything from a most modern Cartoon Network style to manga, to crazier Warner Bros., we ended up settling with a mix of Calvin & Hobbes and something out of a 50s Hanna-Barbera show, with strong outlines and solid colors, to make people of all ages feel comfortable with the visuals. We were able to carry this distinct style to all the items, locations, and user interface in the game, which gave it a very consistent and unique look.

Social features

Creating something is fun, but creating something and being able to share it with people is twice as much fun. We wanted to make Casey’s Contraptions a very social experience from the start. Not something that you played through and put away, but something you could share with friends along the way.

Since Casey’s Contraptions uses a full physics simulation at its core, it’s possible to come up with very unique, chaotic, and often unexpected solutions to most puzzles. Weeks after launch, we’re still amazed at how some people are solving some levels, coming up with item combinations we never thought about during development. Since these solutions are very unique and fun to watch, they were a perfect candidate to share with friends.

With that in mind, we designed the game with sharing from the start. After you complete each level, you can share your solution with all your friends just with the tap of a button (and, in the latest update, the default is to autosubmit a solution if you improved your score). Your friends’ solutions are equally accessible, as cropped thumbnails in the level completion screen, and tapping on any of them will bring up a full-screen view that you can even replay and watch the full solution.

In addition to sharing solutions, we also included a level editor to allow players to create their own contraptions from scratch. This was the same level editor we used to create all the levels in the game. Nothing like eating your own dog food to make something solid and usable. Initially, players were able to share these levels through email, and, in the first update, we also added the ability to share them publicly through a web site (http://shared.caseyscontraptions.com), effectively giving players access to hundreds of new levels.

As it’s the case with most games that include level editors, we were aware that only a small minority of players would take the time to create their own contraptions. But it’s also those players that are really devoted to the game, and take it upon themselves to spread the word about your game and champion it to all their friends.

Iterative development

For Casey’s Contraptions we used a very stripped down and relaxed form of iterative development. We had short iterations and in each iteration we aimed to fully implement what we considered the most important features at the time. We didn’t do any real estimating of tasks (other than, “yeah, we think we can do that in about two weeks†), and we didn’t set a hard-limit on the iteration (they varied naturally between one and a half and three weeks). The most important concept is that at the beginning of each iteration we would make decisions about what to work on next, and those decisions were made with all the knowledge leading up to that point.

For example, we didn’t start the project by coming up with the full list of items we were going to have in the game. Instead, we had a list on the wiki of possible items (to which we would add more whenever we thought of a new one during development), and we only decided which new items to add to the game at the beginning of each iteration. That allowed us to make good decisions based on what we had learned so far: “Most objects we have so far fall down. We need more items that add forces upwards†, or “The magnet is fun, but we need more metal items to make it more useful†.

This mentality applied to everything: From level creation, to menus, features, etc. Looking back, we can say there’s no way we would have made the same decisions early in the project than we did as we went along.

Strong launch

In less than 24 hours after launch, Casey’s Contraptions worked its way up to the top 10 paid apps in the US and in over 20 different countries. A day later, it reached the #2 overall spot in the US and had great initial weekend sales.

This strong launch wasn’t just pure luck. It was something we planned months in advance and worked hard to achieve (although we did need a dash of good luck). We wanted to build awareness and buzz around the game, but given the short development cycle for iOS games, we would have to do it in a shortened scale.

We started out by announcing the game more than six months before release (25% of the way into development). During the following months, we continued talking about the game on Twitter and our blogs, often showing work in progress or outtakes. The next big milestone was showing the game around at GDC. Not only did we get a lot of other developers to play it and give us invaluable feedback on it, but we also met with some of the game press, and that resulted in some very nice previews afterwards.

The final push came as soon as we submitted the game to Apple for review. We decided to set a fixed release date three weeks after the submission, which would give us enough time to do all the PR work: creating a video, putting together a media packet, contacting media outlets, etc. In the weeks leading up to the launch, we also stepped up our blogging of different interesting aspects of the game.

As a result of everything we had done up to that point, we were very lucky that Casey’s Contraptions attracted Apple’s attention, and they featured it prominently on launch day as iPad Game of the Week worldwide. We had given the press enough time with the game, so a lot of very positive game reviews came in right around launch day, helping get the word out for the game.

Even though we had been originally thinking of pricing the game at $4.99, we decided to shoot for volume instead and priced it at $2.99. That turned out to be the right decision and immediately put us on the top 10. Sales on iOS charts follow a sharp, exponential drop off, so being in the top 5 represents a huge increase in sales over just a few positions down the chart.

Looking at the App Store today, it’s apparent that it’s becoming harder for small, quick games to be really successful and top the charts. With over half a million different apps on the App Store, and hundreds of games released every day, you really need to stand out from the rest to be noticed. Most of the games that manage to do that are ones that required significant time and effort investment and have good production values. The App Store gold rush is over.

Enough development time

From start until launch, Casey’s Contraptions was in development for 8 months. That seems like a long time by iOS standards, although more and more successful iOS games are starting to take that long.

Our initial plan was to ship the game by Christmas. It wasn’t based on any rigorous estimating, just an off-the-cuff estimate. It just “felt†like we could be done by then. Obviously we were wrong.

Taking the amount of time that we did was a very positive thing. We didn’t really waste much time, it’s just that the game needed that amount of time to mature and get to where it is today. If we had chosen to ship it earlier, the final product would have suffered significantly.

One of the hardest things in a game like Casey’s Contraptions is making interesting levels. Having this amount of development time, with a working game editor since the very beginning, allowed us to make a lot of levels along the way. Looking back at a lot of the early levels we made, they were laughably hard and not that interesting. After several months, were able to develop a sense about what made good levels and what the appropriate difficulty was.

Having enough time allowed us to make fairly fundamental changes to the game design when something wasn’t working. For instance, initially each level had three different goals you could achieve. Depending on the number of goals you accomplished, you earned a bronze, silver, or gold medal. It quickly became apparent that players were extremely confused by the three goals and weren’t able to keep them straight.

We changed levels to have a single goal, but since we still wanted to have some replayability beyond “solving†a level, we added optional stars you could collect by touching them with any item in the game. The first star would be very easy to get, the second one a bit harder, and the third one would require some serious thinking. That was a huge improvement, but then we discovered that most players expected to get all three stars in their first playthrough, and would stubbornly keep playing the same level until they got them all or quit in frustration. That prompted us to change the stars yet again. This time the difficulty of getting them was tied to the overall level difficulty, so players could easily get all three stars in the early levels. We’re very happy with the final design, and we would not have gotten there if the project had been rushed.

We also gave ourselves sufficient time at the end for polish and style. Polish isn’t going to make the game design any better, but it’s going to contribute a huge amount to first impressions. Every animation, sound, and particle effect becomes really important in those crucial first few seconds with the game. On a mobile platform, polish becomes even more crucial. If your game doesn’t immediately engage the player, there are lots of other things they can shift their attention to.

What went wrong

No simultaneous iPhone launch.

The initial prototype of Casey’s Contraptions was running on an iPhone. While it showed a lot of promise and it was fun to assemble contraptions even that early on, it was clearly begging for more screen space.

The iPad was the obvious platform of choice. Its large screen can display very nicely detailed graphics, and allows for very natural, direct manipulation of items. It was a perfect fit for Casey’s Contraptions.

Even so, while there are a lot of iPads out there (14 million), the iPhone and iPod Touch are the undisputed kings of the App Store (about 185 million devices). Especially for a game that relies on the social component, getting a critical mass of users playing at the same time, sharing solutions, and sending levels is very important. We definitely stormed up the iPad charts, but that still left the majority of iOS users not being able to purchase our game.

Why didn’t we wait until we had the iPhone version to launch? No particularly good reason other than we were itching to get the game out. We also had no idea what kind of impact a strong launch would have on our servers, so the idea of an iPad-first launch seemed like the way to go. In hindsight, we would have been better off waiting to launch both versions at the same time (or almost the same time, maybe a week or two apart at most).

To make up for this, we’re planning on making the iPhone release a second launch of sorts: We’ll make the iPhone version coincide with a new game update that includes a lot of new content (for free for people who already bought it), and we’ll try to repeat the same strong launch we had on the iPad. The idea is to get everybody who’s already bought the game playing again, along with all the new iPhone players and create that critical mass.

Butting heads too much

We make the perfect two person team: We have complementary specialties, but we also have a lot of overlapping skills. We also seem to always approach things from opposite ends: Aesthetics vs. usability, performance vs. gameplay, simplicity vs. interest, uniqueness vs. familiarity, or tea vs. coffee. That is actually a really good thing and the success of Casey’s Contraptions was in no small part due to our combination of personalities and skills.

There is, however, such a thing as too much of a good thing. We are both very stubborn and it will take a lot to convince us to see things in a different way. There were some times during development that we spent more time debating one point than actually implementing it.

The fact that we’re working remotely didn’t really affect most of our day to day development, but it definitely made hashing out these situations significantly harder, dragging them out for far longer than they should have. This was also the first time we were working together on a significant project, so it made resolving those situations more difficult. Now that we’ve gone through this first project, we’ll hopefully be better equipped to handle similar situations in the future.

Unnecessary rework

Rework is a necessary part of a creative process. You’re unlikely to get everything right in the first draft of a text or a music composition. That’s even more so the case for game development because there are so many parts interacting with each other. Not only is it hard to predict the exact final outcome, but even if you could, you often don’t know exactly what you want until you’ve seen one version of it.

Just about every screen and every item in the game went through several revisions of art, behavior, sounds, or layout. There’s no doubt that every revision made them better. However, we had a few parts of the game that we had to revise a few too many times. This was mostly in some of the UI screens, like the now infamous “level completed†screen, or the look and positioning of the in-game menu, which we must have gone through at least 6 or 7 complete redesigns.

We believe that design doesn’t just flow one way. If you want the best final product, you can’t just decide on the functionality of some user interface (or any part of the game for that matter), implement it, and then give it a pretty face with some graphics. Both the implementation and the graphic design will actually feed back into the functionality of the UI. Once you go around this cycle a few times, you can zero in on a very strong design, both from a functional and a design point of view.

The problem comes when you go around that loop too many times, or when the loop doesn’t converge into a particular design, but keeps shifting around. That was often caused because we were fuzzy on some of the details, or when we were forgetting about some particular feature that had to be reworked into the design. Some other times feedback from our testers made us realize that a screen wasn’t clear enough as we had designed it and caused us to rework it. As tempting as it was to push through and call it good enough since it was already completely done, it was always the right decision to go back and re-work things as needed.

For example, at the beginning of each level Casey explains what goal you need to achieve. This screen seemed straightforward enough, except that the version we had early on was blocking the view of the level while it was up. Our testers complained it was hard to remember what you had to do without seeing the items it was referring to at the same time, so the final design shows Casey’s dialog along the bottom of the screen, and the goal items are even circled with a marker.

We can alleviate this problem by iterating on particular pieces of UI or the game in smaller cycles, without taking each one to completion. Instead of starting by completely implementing a screen, or completely creating a perfect mock up with all the graphic elements, we need to start by laying out a screen with simple boxes and buttons and implement the basic functionality. Then we can make a first pass at a real layout and some graphical element, implement some of the new functionality and animations suggested by that, and continue iterating until it’s done. We got much better about this in the last third of development, and it’s something we want to carry forward to future projects.

Not enough unit-testing

Noel is a big fan of unit testing and test-driven development (TDD). Those are some techniques we used in past projects to very good effect and something we definitely wanted to carry into Casey’s Contraptions as well.

The goal was never to have 100% unit-test coverage or write every single line of code through TDD, but to write only the tests that would benefit the project. That usually meant some code that a lot of other code relied on (the game item management), or something complicated (toolbox interaction), or something prone to breaking (rope manipulation).

In the end, we slipped to the side of not having as many unit tests as we would have liked. Some things like object attachments kept repeatedly giving me headaches during development because of the complicated, untested code. By the time we noticed those problems and wanted to start adding tests, it was too late because some of that code relied on non-unit test friendly APIs like UIKit or Box2d.

We should have taken the time when those problems started appearing to start writing some tests and slowly refactor the code as we fixed the bugs and added new features. Instead, since we seemed to be constantly “just a few months away from shipping†, we decided to skip that and definitely paid the price later on. We even shipped with a few off edge cases that we knew were buggy but we didn’t dare fix weeks before submission.

We’re already working on updates and and an iPhone version of Casey’s Contraptions, so we’ll continue dealing with that code for quite a while to come. We’ll slowly introduce unit tests in areas of the code that we need to revisit during this time.

Fixed price model

The pricing model is something we went back and forth about several times during development. In spite the long-term success of Flower Garden and other free games with microtransactions on the App Store, we chose to go with a fixed-price model for Casey’s Contraptions.

We thought our audience would appreciate a traditional fixed-price model better than a microtransaction-based one. We also figured it was a model that was working well for other similar iPad games such as Angry Birds or Cut The Rope, so it made sense to follow their lead on that.

Unfortunately it seems that might have been the wrong decision from a financial point of view. After a really strong initial launch, Casey’s Contraptions dropped down the charts very rapidly after just a few weeks. Since revenue follows a very sharp exponential drop off, even being in the top 100 iPad games means very little revenue per day, and points to a very thin “tail†to the sales curve.

In spite of the bad reputation microtransaction games have in traditional game development circles, they’re a lot harder to develop than single-purchase, fixed-price games. Not only do you need to implement very robust server features, but you need to finely balance the in-game economy, the pace of rewards, and the cost of new purchases. Our optimistic estimate was that it would add at least a full month to the development time (and given how our estimates were, it probably meant two months for real).

A possible alternative would be to have a traditionally-priced game, but offer new levels or locations as extra purchases. This would have been a lot simpler to implement, but it probably wouldn’t have made much difference in revenue. Usually, only about between 2% and 5% of the players buy any extra content, so for microtransactions to really pay off, they need to be unlimited (in-game currency, fertilizer, etc), or have a very large user base. With a small, fixed amount of possible things to buy, we would need to rely on having lots of players to make much of a difference.

We’re hoping releasing the iPhone version will generate lots of renewed interest in Casey’s Contraptions, spur lots of sales on both platforms, and hopefully increase the long-term chart staying power. If that’s not the case, we can always consider the possibility of experimenting by changing the pricing model in the future.

Conclusion

We’re extremely happy with the development of Casey’s Contraptions and with the initial launch. We managed to create a unique game around creativity that was very well received critically and from a sales point of view.

The first free update should be available by the time you read this. It adds the ability to share contraptions with everybody through the web site, as well as browing public contraptions, which should increase the popularity of that feature quite a bit. It also adds some of the most-requested features, such as multiple player profiles for all the parents playing Casey’s Contraptions with their children out there.

Unlike a traditional retail game though, the story is far from over. What we do in the next few months will have a very significant impact on the long-term success of the game.

Facts

• Web site: http://www.caseyscontraptions.com
• Release date: May 19, 2011 (iPad). Summer 2011 (iPhone)
• Development time: 8 months
• Team size: 2 (full time)
• Development cost: Cost of living for 8 months + a tad over $1000
• Open source code: Box2d, UnitTest++
• Primary tools: Xcode, svn, Versions, Trac, TexturePacker, Adobe Illustrator, Audacity
• Lines of code: 46,518
• Raw asset size: 510 MB
• Total app size: 12.2 MB
• Subversion commits: 2442
• Trac tickets closed: 683
• Gallons of tea brewed: 77
• Shots of espresso consumed: around 1500

This article was initially published on Gamasutra in June 22, 2011. I reprinted it here for completeness, to keep it with all the other Casey’s Contraptions articles.

For the rest of you still twiddling your thumbs, eagerly awaiting for midnight, here’s some insight on what went on in the level creation for Casey’s Contraptions.

Built-in editor

From the beginning of the project, the idea was to have a level editor built in to the game. The level editor was the very first thing I implemented in the game. Before there were menus, or levels, or anything else, the game was a level editor without any goals.

That’s what Miguel and I used to create all the levels we shipped with. Nothing like eating your own dog food to make something solid and usable. This is the final level editor that players can use to create their own contraptions from scratch and send them to friends.

The only difference is that user-created levels only have the goal of getting the 3 stars in the level, whereas game levels have a separate goal. This was mostly because of the UI work required to allow the user to set different goals affecting multiple objects. It would have been way too complicated, although we’re not ruling out the possibility of extending it in the future. Miguel and I had to edit level files by hand to add the extra goal information.

Levels. Evolved.

One thing that worked really well in Casey’s Contraptions is that we had a working level editor from day one. The first prototype was a tiny level editor! Of course, we’ve been refining it since then, but the core was there.

After a month or two of development, we implement some goals and the ability to play through the levels created. That means we’ve been able to make, play, and test levels for 6 months before shipping.

It was having that amount of time to create levels that allowed the level creation to mature and let us discover what went into a fun level, to refine the difficulty, and create much more interesting levels in the end. Some of that was influenced by what mechanics were fun and which ones weren’t (placing something in a pixel-perfect position).

The different game items also had a huge influence over the level design. Clearly their functionality is going to affect level design hugely, but the surprise was that the character of the items also influenced level design quite a bit.

For example, early on, most of the levels were about solving everyday tasks Casey had to deal with: put toys away, knock down a ball from the roof, pop a balloon, etc. But as soon as we started adding some of the more colorful items, like the doll, the piggy bank, or the RC truck, our levels shifted into being mini-stories: The doll is jumping from a building and you need to catch her, the piggie is being taken away on the truck, etc. That’s when we realized that we could make really fun levels based on playtime stories, not just real situations. Probably about a third of the shipping levels are playtime levels.

Creation process

Initially, we just created levels without thinking too much about it. Used whatever items we wanted and created something that seemed fun. We were learning a lot by doing that: Playing with item interactions, seeing what was possible and what wasn’t, which items we were gravitating towards and which ones were no fun to play with. We weren’t doing it consciously, but what we really doing was exploring the possibilities of the “level space”.

As you can imagine, most of what we created early on went out of the window pretty quickly. Most of the levels were insanely difficult, and a lot of them were simply no fun at all. We were also creating the levels to challenge each other to solve them, and while that was really fun, a lot of those levels were devilishly difficult. We’ve been dialing back the difficulty level ever since then.

The actual process for creating a level wasn’t very involved. Either one of us would go ahead and create a first pass at a level. Sometimes I would sit down and consciously decide to create a new level (especially if it was a level designed to teach about a new item), but more often than not, an idea would come up while doing something unrelated in the game.

Once we had this first pass, we would send it over to the other person and have them either poke holes on the design (if the level can be solved trivially by just dropping a ball somewhere for example), or tweak it to tighten it and make it more fun. Later on, we would revisit levels based on tester feedback or us becoming more experienced.

I estimate that the average time to create a level, from the first item added to the time it was added to the game, was about half an hour. Some of them were much faster, and some much slower though. And for yet some others, we struggled with them for a whole day and finally dropped the idea completely.

What makes a good level

As we quickly learned, making a cool-looking contraption and removing a few pieces does not a good level make.

The best levels always have multiple solutions. Otherwise, it becomes a game of “guess what the designer had in mind”. There are plenty of games like that out there (and I hate them all when I feel that it turns into that). So even if we started with a complete contraption, we would always make sure there were at least two different ways of accomplishing the goals.

The other thing to avoid in a level is the possibility of trivial solutions. If a level can be accomplished by placing a single item that drops and causes the goal to complete, that’s not very fun. It was a tough balance between leaving enough freedom to create your own solutions, but making it so there were no really “cheap” and boring ones.

The stars were tricky. Each level has thee stars you can get, but they’re completely optional. Initially I wanted our levels to be easy to solve, but each star was progressively more difficult to get. Getting the third star required some serious thinking. My reasoning was that people would solve the levels first, get comfortable with the game, and then come back and get three stars in everything. Boy, was I wrong! It was clear right away that most people wanted (no, expected!) to get all three stars in their first pass through the game. So we changed most of the levels so getting the stars is not hugely difficult, especially in the early levels.

Letting the testers loose on the game was an extremely valuable experience. Not only did they catch a fair share of bugs, but they also had a fresh perspective on the game. It was amazing seeing them solve levels in totally different ways than we had anticipated. It was extremely rewarding to see people come up with solutions and even interactions I had never considered even though I had written all the code.

Here’s a good example (Spoiler alert. Skip ahead to the next section if you don’t want to learn multiple solution to one level).

Here’s one level I designed called “Angry Doll” (any references to popular iOS games must be purely coincidence, by the way :-)

This was a level intended to highlight the use of the slingshot, but you already had the doll and one slingshot in place (and the doll misses the pig with its initial flying kick). One possible solution I had in mind was to use the remaining balls and slingshots to alter the course of the doll and knock the pig down.

There are a few different ways you can do that, which made it an interesting level. However, I was totally unprepared for some of the solutions the testers came up with.

This solution uses multiple slingshots on the doll, which changes its course and adds a lot more force to it. It flies straight for the pig and smashes it on impact. Not just that, but for extra style points, the tennis balls go flying out on a totally chaotic pattern, and they get all the stars!!

This other solution might be my favorite. It completely bypasses even the intermediate goal (alter the doll’s trajectory) and instead attaches a slingshot directly on the piggie bank and smashes it against the wall (getting a star along the way). Genius!

Item sequence

There was one additional constraint to making levels that we didn’t start dealing with until fairly late in the project: Item sequence. Initially, only a few, simple items are available to solve the goals in each level. As you play your way through the game, we introduce new items slowly, making sure their properties are well understood before introducing a new one.

The first time you complete a level with a new item, you’re “awarded” that item, and you can start using it in your own contraptions in the level editor. You can even see the stickers of the items you’ve earned so far on the cover of the “My Contraptions” book (I was playing Psychonauts at the time, so I suspect that might have influenced that design decision a bit).

Having a set item sequence meant we had to be very careful which items were available in which level. We kept a spreadsheet with all the levels, and which items were introduced when. Every new item we introduce follows the following steps:

• When an item first appears, it’s already placed in the level. That means the player gets to see how that item behaves.
• The next level, we give that item to the player so he or she can place it in the level to solve the contraption.
• Another level or two making use of that item. That reinforces the behavior of the item and makes the player comfortable with it before moving on.

We were shooting for fewer levels, but it’s not hard to see why we ended up with 72 levels in the first version of the game.

To be really sure we were respecting the right item sequence, we even wrote a script that parsed all the level files in order and spit out where each item was used. It even made sure that every item followed the rules above (first placed in the world, then available to place by the player). This will continue being extremely useful as we add more items and levels in future updates.

Make your own

There you go. That should give you an idea of what was involved in creating the levels for Casey’s Contraptions. In the near future we’re planning on holding contraption-creation contests and we hope to highlight some player-created contraptions. Go ahead and buy the game and start practicing to make your own contraptions. Remember: The crazier the better!

What can we tell by looking at those games? I see two clear categories: Games with a strong, established IP (Street Fighter, Sonic), or independent games with a huge amount of polish and style.

It’s All About Polish

The love and care developers put into those games shows the moment you start them up. Look at the textures in Tiny Wings, the sound effects in Angry Birds, the feedback animations in Words With Friends, or all the little details in Cut The Rope. All the tiny particle effects, transitions, sounds, and general squish and responsiveness. Every single one of those games is oozing with its own style and contributes to a very enjoyable first (and repeat) experience.

And that is the main point of this post: To make a successful game on the App Store, the main thing you need is love. You can skimp on features, on content, on marketing, on a web site, or even on gameplay balance. All those are things that you can add or improve after shipping, but polish and style are responsible for that crucial first impression. Miss the chance to hit the player with all you’ve got the first time they play your game, and that might be a lost sale (and a lost advocate of your game since word of mouth is such a strong force on the App Store).

Not convinced about the difference polish and style makes?

This game is essentially Tiny Wings with just a little bit of polish (and it does have *some* polish).

And this is Tiny Wings.

I rest my case.

Ship As Soon As Possible?

Traditional game development (especially for consoles) usually goes along these lines: Plan everything, create a game with everything that you want/can fit, ship it once it’s done, and hope not to touch it again. On the other hand, in this day of web/Facebook/mobile development the favored approach is to release a product as soon as possible, and then iterate from there.

My preference in the last few years has been more along the shipping as soon as possible lines (even if I haven’t always been successful at it). But then I paused and really thought about why and what I would accomplish by shipping early. These are the main reasons I could think about:

• Getting to market first. This is a big one in the web world (and maybe even in the hardware world). Even if your product is imperfect, or its UI is less than ideal, getting that initial critical mass of users could be what tips the balance in your favor.
• Canceling the project early. Maybe it takes as long as the first version of a product to realize there isn’t demand for it. So it was better to have spent 6 months instead of 3 years before canceling the project.
• Focussing your efforts. An impending ship date will make wonders to keep people on track and focused on what’s important to ship a game.
• Become profitable as soon as possible. Even if you make the same amount of money and spend the same amount of time working on a project, if you start bringing in money at the 6 month mark rather than at the 3 year mark, you’ll be profitable earlier. And as any RTS fan will tell you, getting extra resources early in the game can put you at a huge advantage.
• Changing the product based on early user feedback. Otherwise you might spend years working on a product that people don’t really want, or they would prefer something slightly different.

How do those reasons apply to iOS games?

• As an iOS game, your biggest moment is launch. That’s when you can get most momentum and get the word of mouth ball rolling. First impressions matter a lot and a lot of people will make snap decisions about your game in the first few seconds. If it’s not looking its best, it doesn’t matter if it came earlier than another game. Besides, games, for the most part, aren’t providing as much of a service as they’re a form of entertainment. Barring brand new genres or whole new platforms, getting to market first doesn’t mean much. And even if you’re making a brand new genre, chances are it’s unique so the clones won’t start showing up until after you launch and becomes popular (unless you announce way in advance).
• Stopping development on an unsuccessful game earlier rather than later is always a good thing.
• Likewise, having a milestone around the corner does wonders for focussing your efforts. That was one of the big benefits we got from submitting Casey’s Contraptions to the IGF.
• The last one is tricky. It might seem like a benefit for iOS games as well, but I’m going to argue it isn’t. Don’t get me wrong, I think that testing and user feedback is very valuable. But games ultimately are a form of art[1] and you are the creator. In the end, you need to decide what your game and your vision are like. Feedback will help with usability and balancing issues, but not with what the game is fundamentally. Stick to your vision.

My Approach

Looking at those lists, it makes it clear to me that iOS game development is not all about getting a product out of the door as soon as possible. There’s no need to create a finished product for your first release. Instead, save every feature and content you can for free updates or even future in-app purchases.

I’m convinced that polish and style are one of the most important things an iOS game can have. It’s not the first time I say that. So get the product out as soon as you can, but do not, under any circumstances, cut any polish from your game. Plan on spending a good month or longer after your game is “done” polishing it. That time will definitely be well spent and will increase the value of your game more than any other month you spent developing it.

What I’m suggesting here is actually quite different from what Chris Hecker talked about at last year’s GDC. Even though we’re both saying “take your time and do your game right”, he’s emphasizing the completeness of the game (in the sense of exploring all its potential), while I’m emphasizing the presentation. I think the main reason our messages are so different is the platform we’re developing for. On a platform like iOS, I really think you can explore the full potential of a game after it ships without any real drawbacks.

Right now we’re in the polish phase in Casey’s Contraptions. The game has been “done” for a while, in the sense that we have all the items, lots of levels, you can play through all the puzzles, make your own contraptions, etc. Even though it already has a lot of style and polish, it definitely needs that extra layer of shine to make it really stand out and bring it to the quality of those games in the top 10 list. We can only hope that Casey’s Contraptions joins them after we launch!

Interested in keeping up with Casey’s Contraptions as we’re gearing up for launch? Join the Facebook page.

[1] Feel free to substitute whatever word you want there that isn’t offensive to you: entertainment, interactive media, etc. Games are something *you* create from your imagination, so art seems like the best term to me.

I want to have great experiences, not just long ones, and I’m willing to pay for them. Just like other media, each game has an ideal length to develop its ideas fully, and we shouldn’t fall to pressures to make then any longer than they should be. I don’t want endless grinding or backtracing through the level to meet a minimum time quota. Just like every book doesn’t have to be The Lord Of The Rings, there is room for both epic sagas like Dragon Age and Fallout and short experiences like Limbo or Braid. Maybe there’s even room for the equivalent of Italo Calvino’s shortest short story, The Dinosaur.

I would go as far to say that games should err on the side of being too short rather than too long. There’s a saying in Spanish that goes “Lo bueno, si breve, dos veces bueno”, which roughly translates into “Good things, if short, twice as good”. I’d rather be left wanting more than not being able to finish something. As a busy gamer, I don’t get to finish many games these days, and the ones that I do really stand out from the others and hold a special spot in my heart.

Besides, a lot of other games can’t even be measured in length. How long is Starcraft? Team Fortress? Civilization? Tilt To Live? They are as long or as short as you want. Should we be docking them for being too short? Should we force all games to have infinite replay value? No, the important thing is that they’re great experiences.

Forget length. Give me awesome.

Other Indie Voices On Game Length

• Alex Amsel of Tuna
• Alex Okafor of One Man Left
• Brett Douville of Bethesda Softworks
• Chris DeLeon of HobbyGameDev
• Chris Hecker of Spy Party
• Cliff Harris of Positech Games
• Dave Gilbert of Wadjet Eye Games
• Eitan Glinert of Fire Hose Games
• Greg Wohlwend of Intution Games
• Gavin Bowman of Retro Dreamer
• Jamie Fristrom of Torpex Games
• Jeffrey Rosen of Wolfire
• Jonathan Blow of Number None
• Markus Nigrin of The Pocket Cyclone
• Martin Pichlmair of Broken Rules
• Matt Gilgenbach of 24 Caret Games
• Peter Jones of Retro Affect
• Rob Jagnow of Lazy 8 Studios
• Ron Carmel of 2DBoy
• Scott Macmillan of Macguffin Games
• Steve Swink of Enemy Airship

Twitter tag: #gamelength