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.

Apologies for the less than ideal sound and video quality. We’re working on fixing that for next time.

I managed to keep things shorter than last time, so this one is only 12 minutes. For those of you who prefer text updates, don’t worry, we’ll have one of those next week.

It’s a whopping 19 minutes long, so I may have overdone it a bit! I’ll try to keep it shorter for future updates.

Since this is the first time we’re doing this, any feedback is appreciated. Would you like to see more of these in the future? What should the focus be? Any technical issues I should improve?

Lasting Legacy is a fairly unique game, so it doesn’t quite fit in any predetermined genre. The closest category would be single-player, turn-based simulation, although the simulation part in Lasting Legacy is very light (unlike something like Sim City or The Sims), and in that respect it’s more like a board game. So it’s more accurate to say that Lasting Legacy is a blend of simulation games and board games.

Intrigued? You’re in the right place. Read on.

What Do You Do in Lasting Legacy?

The description of the game says that you manage a family for about 200 years and build a lasting legacy. Every action you perform moves the time forward one year, and actions are performed directly on individual people.

There are some common, general actions available:

• Socialize, which helps you find more friends.
• Visit a friend, to increase that friendship.
• Propose in marriage or accept a marriage proposal.
• Pick an occupation for someone who recently became an adult.

Those actions allow you to tend to the family and continue growing the family tree. The meat of the game comes from each person having an occupation, and that occupation provides either a special action, or an ongoing effect.

For example, having a Doctor in the family gives you an action to heal a sick person.

On the other hand, a Moneylender in the family gives you the ongoing effect of not having maximum debt anymore (time to run those credit cards!).

The ultimate goal of the game is to achieve the highest legacy possible each time you play. You gain legacy in one of two ways:

1. By acquiring heirlooms from deceased family members that give you legacy for different reasons (for example, number of people in your family with a particular occupation).
2. By meeting the whims of some important family members. For example, someone in the family might have a thing for big weddings, so you’ll gain legacy for every big wedding you have while they’re around.

Sounds simple enough, but in order to do those things, you’ll have to balance the maintenance of your family (social needs, marriages, children, sickness), acquiring gold and prestige, and, to top it all, dealing with the rising military tension in your country. War is inevitable, but you may be able to deflate military tension and push off the start of the war (which brings the end of the game).

Game Mechanics

Stepping back and looking at the game from a high-level point of view, there are two major mechanics that appear:

1. Tableau building. The family tree is your tableau, because it represents the powers and actions that are available to you. A lot of card games have a similar mechanic (Race for the Galaxy is one of the best and most famous ones), but in Lasting Legacy the tableau has a twist: It’s dynamic. People can only make a contribution while they’re alive, so your tableau will change as decades go by, and you’ll have to adapt your strategy and plan ahead to take full advantage of it.
2. Hand management. Your friends are a very similar resource to a hand of cards in most games. You may be able to bring them into play as part of your family, or maybe you can do their action once and discard them. This hand of cards is also very dynamic and it changes with the friendship levels and your family prestige.

Those two mechanics are very common in card and board games. That’s not surprising since Lasting Legacy has strong board game influences. However, Lasting Legacy is not a board game, and it would be very difficult to make a straight translation into a physical game. There’s a light simulation under the hood that makes people do things by themselves: have children, propose in marriage, pick occupations (unless you pick them for them), etc. Hopefully it’s a good blend borrowing the best of both the digital and the physical worlds.

Want to find out more about Lasting Legacy as we announce it? Make sure you sign up for our mailing list and/or join the Facebook page.

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.

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.

Are we slacking? Sipping piña coladas by the beach? Did we grow complacent with the successful launch of Casey’s Contraptions on the iPad?

The reason it’s taking so long is that we’re not putting out a rushed version of Casey’s Contraptions on the iPhone. Instead, we’re taking the time to re-work every screen to fit the smaller screen. Even if we could just cram everything into the screen, fingers don’t get any smaller on the iPhone, so the target areas need to be just as easy to touch.

This goes beyond just every UI screen. Quick, name a popular iPhone game that can’t be played with just your thumbs. I’m drawing a blank, and that’s for a good reason. The gold standard for iPhone games is whether it can be played with two thumbs. If it can’t, then it’s probably a bad design. So even though the levels are the same, we’re having to make major changes to how objects are manipulated.

In other words, good things take time.

Which reminds me of this wonderful quote from the Mythical Man Month:

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. Menu of Restaurant Antoine, New Orleans

All The Little Details

It’s more than just doing a good job though. There’s often a surprisingly large amount of work involved implementing small parts of a game. Things that, when you do them right, go completely unnoticed, but when you don’t, are jarring and irritating. Games are full of examples of things like that, from AI to menu screens.

In this case, I’ve spent a whole day and a half getting the behavior of the toolbox area working correctly on the iPhone. On the iPad, the toolbox area is the bottom wooden box that holds the items you can use in the game.

On the iPhone, since we’re dealing with a different screen aspect ratio, we decided to spend all our screen real estate on the game area, and keep the toolbox hidden. (And yes, since you asked, you can zoom and pan on the game area). Whenever you want to use the toolbox, you press the button and it slides out. Easy isn’t it? How could that possibly take a day and a half?

That’s one of those cases where the devil is in the details.

• Apart from pushing the button, the player can also tap it and slide in and out. When that happens, we need to detect what you mean with that gesture and finish opening/closing the toolbox after you release the touch.
• Whenever the player grabs an item out of the toolbox, we need to close the toolbox so it’s not in the way.
• Whenever the player grabs an item in game and drag it near the toolbox, it needs to open so you can drop it there.
• But dragging an item towards the edge of the screen indicates that you want to move it outsize the zoomed area, so we don’t always want to open the toolbox. Only when the player drags it near the button that opens the toolbox.
• But perhaps it wasn’t possible to scroll down any further (either because we’re zoomed out all the way, or we’ve moved the camera as far down as it goes), in which case dragging any object anywhere near the bottom of the screen indicates we should open the toolbox.
• Of course, it’s possible that the player just grabbed an object out of the toolbox, the toolbox closed automatically, and he didn’t move the touch near the bottom of the screen. In that case, we want to be aware of that and not open the toolbox.
• Dragging an item towards the toolbox, and then away from it should close it since it means the player changed his mind and doesn’t want to get rid of it yet.

Take all those cases, and make them work with and without zoom. And there are even a few more weird combinations we need to deal with, but you get the idea. If that sounds like crazy, well, it is kind of crazy. Fortunately it was something I was able to implement writing unit tests, so it’s pretty easy to modify and update as we need to change things.

For the curious, this is what just a couple of the unit tests look like:

struct F
{
	F()
	{
		camera.pixelSpaceWidth = GameParams::WorldWidthInPixels;
		camera.centerSS = Vec2(0.5f*GameParams::WorldWidthInPixels, 0.5f*GameParams::WorldHeightInPixels);
	}

	Camera camera;
	ActionQueue actionQueue;
};

TEST_FIXTURE(F, ItemOnBottomRightCornerDoesNotOpenToolbox)
{
	camera.zoomFactor = 2.0f;
	camera.centerSS = ScreenCenter;
	CameraUtils::Update(0.02f, camera, true, Vec2(ScreenCenter.x + 0.5f*ScreenCenter.x, ScreenCenter.y - 0.5f*ScreenCenter.y), false, actionQueue);
	CHECK(camera.triggeredToolboxOpen == false);
	CHECK_EQUAL(0, actionQueue.count);
}

TEST_FIXTURE(F, ItemOnBottomLeftCornerOpensToolbox)
{
	camera.centerSS = ScreenCenter;
	CameraUtils::Update(0.02f, camera, true, Vec2(10, 10), false, actionQueue);
	CHECK(camera.triggeredToolboxOpen == true);
	CHECK_EQUAL(1, actionQueue.count);
	CHECK_EQUAL(ActionType::OpenToolbox, actionQueue.actions[0].type);
}

TEST_FIXTURE(F, ItemOnBottomRightCornerOpensToolboxIfCantScroll)
{
	camera.centerSS = ScreenCenter;
	CameraUtils::Update(0.02f, camera, true, Vec2(GameParams::WorldWidthInPixels, 0), false, actionQueue);
	CHECK(camera.triggeredToolboxOpen == true);
	CHECK_EQUAL(1, actionQueue.count);
	CHECK_EQUAL(ActionType::OpenToolbox, actionQueue.actions[0].type);
}

TEST_FIXTURE(F, ItemOnBottomLeftCornerWithZoomOpensToolbox)
{
	camera.zoomFactor = 2.0f;
	camera.centerSS = ScreenCenter;
	CameraUtils::Update(0.02f, camera, true, Vec2(ScreenCenter.x - 0.5f*ScreenCenter.x, ScreenCenter.y - 0.5f*ScreenCenter.y), false, actionQueue);
	CHECK(camera.triggeredToolboxOpen == true);
	CHECK_EQUAL(1, actionQueue.count);
	CHECK_EQUAL(ActionType::OpenToolbox, actionQueue.actions[0].type);
}

When it’s all working, if we did our job correctly, all that players will think about is using their toolbox items and none of those weird cases will cross their mind. Things will just work as expected.

One More Thing

Here’s another example of another task with “hidden” work to behave as expected. When moving object in place in Casey’s Contraptions, and releasing the touch, how many times did the item move slightly because your finger grazed the screen as you released it? I hope the answer is never (or not very often). That’s not coincidence. We have some logic in place to detect those really annoying, but very common touch movements as people lift their fingers from the screen. Without it in place, it was pretty frustrating placing pieces accurately. With it, nobody notices because it works as expected.

So next time you find yourself using a smooth user interface, take a second to consider all the work that went into making it as transparent as possible and thank those poor developers.

Next week we’ll have a post showing some of the specific changes we had to make for the iPhone and comparing screenshots side by side (let’s see if I can get Miguel to write that one).

We’re convinced that the update will be well worth the wait. To tie you over, I leave you with a video from our friends at Bolt Creative.

At one point I was half-seriously toying with the idea of creating a Twitter account that would show our latest commits to Subversion. Apart from the 140 character limit, that falls in the TMI category.

So instead, I thought it might be interesting to give a weekly update with what Miguel and I have been up to each week. Hopefully it will give you a glimpse at what’s going on behind the scenes. Any feedback in what you want to see more or less of is totally welcome.

Week Of Oct 29

Both Miguel and I felt this was a very slow week. I’m not sure exactly why, but I suspect post-IGF submission syndrome. We’re feeling the mini-crunch we did leading up to it, and now we have lots of not-so-fun tasks to do on our planes. Still, I think we’ve been slowly picking up speed. Next week should be a fully productive one.

Sound Effects

We added audio for in-game sound effects. Up until now we only had background music and no sound effects at all. Yes, that means we submitted to the IGF without sounds. Yikes! We had to cut corners somewhere. Fortunately, since the IGF takes updates, the next update will include some initial sound effects.

We’re using OpenAL for audio playback, and I was pleasantly surprised to see how simple and efficient it is. What a great change from using AVAudioPlayer!

We’re currently trying to define the style of the sound effects. It’s a strange mix of slightly cartoony, but not too much. Hopefully we’ll zero in on that next week.

Sharing Of Levels

Sharing of levels. We can finally share levels through email. It makes sending levels to each other much easier, and it should come in handy for the next round of testing. Of course, we still can’t reference an attached file from an email using the Apple API, so we’re having to submit levels and a screenshot to the server and store it there.

Sandbox editor

There’s more to creating a level than just placing objects. To create a playable level we need a title, a specific background, some goals, and a set of available items in the toolbox. Since we want people to share fully-featured levels, we’re building this UI right into the game, and it’s what we’re going to use to create all the levels ourselves. We can’t wait to see what people create, but, I have to admit, it’s somewhat of a pain to implement :-). We still have a few days of work in this one.

Right now it’s all using UIKit on top of OpenGL. I’m still waiting for a great, cross-platform GUI library + tools that gives us the basic features from UIKit + Interface Builder but it’s fully cross-platform.

Also, while Miguel isn’t looking, I’ll share with you what we have so far for the level editor sidebar.

In case you missed it, Casey has a Twitter account. And apparently he likes Angry Birds quite a bit! :-)

Also, don’t forget to join the Casey’s Contraptions Facebook page.