We have developed many casual games here at iWin, but Family Feud Online Party, our first downloadable multiplayer game (and one of the first multiplayers in the casual games industry), was a production with unexpected twists and turns which forced us to re-tool and re-think how we build casual games. The result is a fun- and easy-to-play game that brings friend and foe together.
Family Feud (licensed by Fremantle Media) is a game in which players try to guess the most popular answers to questions asked of 100 people in a survey. What makes the game quirky is that the answers aren’t necessarily true—they are personal opinions. If thirty of the people surveyed believe that one of the seven dwarfs is named “Stinky,” then that’s a valid answer, worth 30 points.
There are four rounds, each with progressively fewer possible answers, and a final bonus round called “Fast Money” in which players try to earn 200 points by guessing the top survey answers to five rapidly fired questions.
Before starting development, we played every other interactive version of the game we could find to learn what had been done right and what had been done wrong. We played PlayStation, DVD, web browser, and phone versions, and watched dysfunctional families hopping around hugging each other on the TV episodes as well. It's a dirty job, but. . . .
We learned that, in order for an online version of Family Feud to be successful and fun, the game needed impeccable answer matching. After a player types in her guess, the computer has to match that guess to one of the answers from the survey. Even in the most polished versions we played, if the matching was off, it was a miserable experience. If a question asks “What do you do when you get mad?” and the player responds, “Get some fresh air,” then it should match the top answer: “Go for a walk.” Making that match is an easy job for a person sitting in the production box of a TV studio, but it’s a very hard task for a computer.
Our conclusion was that the matching system, however it worked, was the heartbeat of the game. It had to be intelligent, fair, and discerning—as “human” as the TV show judge. Even so, it disturbed us from the very beginning that no matter what we did, the matching would never be perfect.
We received the database of questions and answers early in the production. It consisted of the survey questions, the most popular answers from the survey, and the points associated with each answer. We immediately set about trying to figure out how to achieve the “human” matching that we wanted.
The first half of the solution was fuzzy logic. An advantage we had is that David Goodman, the software engineer assigned to the task, has a background in artificial intelligence. David designed the fuzzy logic, the database system and the editing tools for Family Feud.
Our fuzzy logic system had to match answers that were spelled wrong, answers with typos, words run together or split apart, as well as synonyms that cover all the different ways that humans can say the same thing. Thus, "spaghetti" had to match "spagetty," and "big car" had to match "large automobile." In that sense, the matching had to be very "loose.” At the same time, though, it couldn't match "shirts" to "skirts" or "shorts” since those might all be separate answers to a question. It had to be tight in places.
The fuzzy logic uses a set of rules to match different forms of a word. For instance, "Walk" matches "Walked" and "Walking." The logic matches words split or joined, like "police man" and "policeman." It matches common synonyms, so that "tiny" matches "little" and "wee." The synonym list includes a variety of items, from bodily functions and body parts to weapons, soft drinks and car models.
After much trial and error, the fuzzy logic evolved to the level of intelligence we needed, but its task was to match a player's guess with the answers and answer patterns. We still needed a way to supply that data to the logic.
To anticipate all the possible answers for each question, two full-time editors painstakingly added synonyms and alternative ways of expressing each answer. Over a six-month period, these editors used a special tool which allowed them to iteratively type in every possible answer the game should accept and then click a button to test them. The result is a report that lists answers that should have matched but didn't, uncovering both editorial and logical issues. We also had QA, executives, engineers, producers, and others using this tool in an attempt to thoroughly scrub the database.
The test report was sent to the editors, who used the editing tool to add or repair the answer patterns. The tool also spell-checked, looked for errors, and tested the length of answers and questions. Each set of questions and answers was edited for matching logic over more than seven iterations. The result is a hybrid of human and artificial intelligence that allows the game to answer that catchy phrase, "Survey says…!?"
Keeping it Clean
Another challenge in developing Family Feud was that players can type whatever they please, including words best left unsaid in public. Using naughty words to answer questions, though, is fun. What we decided to do was make all the displayed survey answers squeaky-clean, but allow the fuzzy logic to accept sailor-speak. For example, if the question is, “Name something associated with Marilyn Monroe” we would accept many words related to her superb anatomy even though the displayed answer is always “Nice figure.” In chat, there is also an optional filter that replaces bad words with comic symbols such as @#$%^&.
Game Show Host
Nick Rush (one of the creators of You Don't Know Jack) wrote the design document for the game. His experience helped give the game a “live” feel while at the same time constraining the amount of dialogue needed to keep the footprint down. We wanted the dialogue to feel natural, so all voiceovers are complete phrases, and not . . . assembled . . . from . . . partial recordings.
Terry McGovern, the voice of our host, was Flip Wilson’s sidekick for a season, and before that the lecherous brother of Richard Dreyfus in American Graffiti. He provided the energy as well as the “rarified” sarcastic comments and ad hoc silly lines that keep the game feeling fresh. The sound effects came from the actual TV show with some additional effects created by Greg Rahn at Soundmindz.
Art and Animation
We started with a very detailed storyboard that mapped out the flow of the game. In addition, we wanted to give each graphic its own personality, incorporating as many of the 12 principles of animation (exaggeration, anticipation, squash and stretch, etc.) as possible. To keep the animation lively, we made sure that nothing would ever go from point A to point B at the same rate or without first announcing its move.
The animations that required a mixture of frames and procedural movements were prototyped as QuickTime movies in Adobe After Effects and discussed before being programmed. To add freshness to the animation, we built in variables for the bouncing and settling of all the graphics so that the game never felt too mechanical, despite repeated motions.
Online Party, Baby!
Before bringing Family Feud online, we released it as a standalone product developed with our proprietary C++ game framework. The game was channeled through the usual casual games distribution channels and became a bestseller, so we knew we had something.
Since iWin began its existence as an online Java and Flash “skill-based” game company, we already had a mature and battle-tested game communication server and account management tools. We had community web pages such as player profiles and a friends list, and some robust e-commerce tools as well. We had already put a lot of thought and work into creating things like lobbies, avatars, awards, ratings, and high-score leader boards.
So we figured we’d just leverage our flashy C++ game with our back-end community magic and couldn’t fail, right? But we weren’t sure about two things: How do we write the code to make it happen and how do we actually make money off the sucker?
First we needed to figure out what language the online game should be written in. We investigated making the game into a rich Java or Flash applet, capable of running in a web page, but that would involve reworking all of the existing fuzzy logic, animation, and game-play pieces that we had already spent so much time tweaking.
Our download game engine provided great 2D graphics and rich audio, and it tapped directly into video memory, the stack, the file system, the mouse and keyboard, and other pieces of the local operating system. We didn’t want to lose any of that. And so we investigated just writing a game lobby, friends list, avatar creator, trophy room, user profile, stats info, and all of the account and credit card processing panels as additional C++ components. But that seemed like a lot of redundant and painful work since our proprietary game framework lacked common interface widgets such as tables, pull-down lists, and forms. Additionally, our existing web applications offered up flexible UI, simple and secure e-commerce capabilities, and backend systems integration. Writing those components using C++ would lock us pretty hard into inflexible design and functionality.
In bringing the venerable Family Feud license to a multiplayer experience, we decided we needed the best of both worlds. So we architected our proven C++ game engine to support an integrated web browser and Adobe Flash control. This wasn’t without challenges. Our engine wasn’t based on MFC or .NET, so we couldn’t just drop in a COM browser control. Instead, we had to use some fairly “hacky” code to have an off-screen, embedded IE browser write to our game window. We then overrode some functions so that we could create a custom protocol called link:// that allowed the web pages to pass data to the C++ application. (This article was a leaping off point: http://www.adp-gmbh.ch/win/misc/mshtml/index.html.)
How It Works
A player logs into the game using a C++ dialog box as part of the game framework. This allows the game to store the username and encrypted password. The data is then passed, via secure HTTP, to our web server where the account is validated and a player session is set up. Once a player is signed in, she can hit web pages to do things such as subscribe via credit card or PayPal, see her account status, edit her profile, or submit a new survey question. These web pages entirely take over the game screen and are designed to look like just another part of the game. The only hint that she is in a browser is a slight pause and a loading animation while the page streams down.
When a player is ready to play, she chooses her lobby and the game itself then connects, via Winsock, to one of our game servers. The client passes in the username and password to ensure security. Players can then proceed through the rounds of game-play, chatting, booting, ignoring others, and collecting new friends.
We knew we wanted to charge a recurring subscription for the game, but we had only vague theories concerning cost and length of subscription. Having the subscription and e-commerce routines happen in web pages allowed us to test a multitude of pricing models until we hit upon the one that has proven to be successful.
Shortly after launch, we noticed that subscribers would drop off more quickly than we had hoped. Accordingly, we decided to add an episodic feature through which players could log in every Tuesday and Friday and be guaranteed to see at least two or three games with brand new questions. This is the most labor-intensive, ongoing aspect of the game. New survey questions are written by our in-house writers, who also consider questions submitted to us by the community. We then run surveys during each game’s intermission. Once we receive enough answers, the responses are grouped and the logic is built out using the process outlined earlier. Then the new sets of questions are released on our staging server, tested more, and finally pushed live. The feature has proven to be enormously effective at getting people to return day after day and month after month.
QA and Customer Service
As you might imagine, a game of this complexity required a testing plan of similar complexity. Not only did we have the actual game to test, but we had web page components and multiplayer features. It takes time to set up multiple clients, have a player enter a room, answer questions, leave a room, etc. There were many scenarios to keep track of since players could join the game at any point, and no testing plan seemed to capture all of the possibilities. The lead Online Party developers were able to assist QA by creating bots which could answer questions, enter rooms, leave rooms or stay in a specific room, and do many of the things a real player would do. We had smart bots that knew all of the answers, dumb bots that sat there and chatted, as well as fickle bots with attention issues that entered and exited games repeatedly.
Since release, Customer Service has become the front line for bug reports. Customer complaints and issues are reviewed on a weekly and sometimes ad hoc basis to make sure there are no interruptions to the service and that the subscription process and auto-renewal system is functioning as expected. It's an ongoing process. Whenever we get asked if we closed all of the bugs, we still have to answer: “For now. But ask us again in ten minutes!”
Releases and Maintenance
When we launched the game it didn't have all of the features we would have liked to include. Also, we knew that testing with only a few hundred players couldn’t reveal all of the technical weaknesses in the game. Because much of the experience is web-based, updating all community pages was relatively easy (just update the web server and the new stuff is live). But updating the C++ client and associated art and audio assets was another story. The game shipped with a smart auto-updater that would automatically patch any files that had changed whenever a new release occurred.
Releasing updates to a live community is very scary, of course. We try to only post updates that are absolutely necessary and only after extensive testing, since all clients, for all iWin subscribers and all partners, will inherit the changes. Any mishap or breach in the testing process can be potentially devastating.
We hope that Family Feud Online Party will challenge the industry to push the envelope in interactivity and blur the differences between web, game, and television entertainment, putting the player at the center of the action. It certainly stretched all of us. We look forward to taking the Online Party model to the next level.
David Fox is currently the Vice President of Technology at iWin, Inc., developers of the best-selling casual games Jewel Quest and Mah Jong Quest, in addition to Family Feud Online Party. David has been a game designer and developer for over 13 years, with a focus on multiplayer casual games and storytelling. He is the author of several best-selling books about Internet technologies and culture, and his writing has appeared in publications such as Salon.com, Gamasutra, Gamelan, O'Reilley Network, Developer.com, and Game Programming Gems III.He can be reached at firstname.lastname@example.org.
Kevin Richardson is currently working as an independent game producer. While at iWin he produced the best-selling Family Feud Online Party, Feud I, Feud II, two Trivial Pursuit games, and an upcoming version of Hasbro’s word game Boggle. Previously, Kevin was an Executive Producer over the Reader Rabbit and Cluefinders franchises while at The Learning Company/Mattel Interactive and a producer at EA/pogo.com. Before leaping head-first into interactive, Kevin was in film and TV animation production and worked on Willow, The Brave Little Toaster, and other feature films. In addition, his writing on digital animation for film has been featured in the German trades. He can be reached at email@example.com.