Robot Invader | Mechanical agents of destruction. Also video games.

Wind-up Knight 2

Posted on December 10, 2013 by Chris

We’ve been pretty quiet lately. It’s been almost a year since our last game, Rise of the Blobs, and other than a few blog posts here and there (and an award or two) we’ve kept a pretty low profile. But don’t take that to mean that we’ve been lounging around; the truth is that we’ve been working so hard that we haven’t had time to come up for air.

Today I am excited to be able to finally tell you about one of the things we’ve been working on: Wind-up Knight 2. Wind-up Knight was Robot Invader’s first game, and since its release in late 2011 nearly 10 million people have played it. Fans have contacted us from around the globe (the US represents only 1/4th of our user base!) to ask for new levels and expansions. But we’ve done better than that: Wind-up Knight 2 is an entirely new game. We’ve put so much insane stuff into it that even our most veteran players, the folks who beat Turnover’s Fair Play without rotating their phone, will be surprised.

WUK2-2

We have a lot more to tell you about Wind-up Knight 2, but we’ll save it for the coming weeks. Wind-up Knight 2 will be gracing phone and tablet screens around the globe early next year. Keep up to date with our progress by following us on Twitter or Facebook.

WUK2-3

Posted in Android, iOS, mobile games, Uncategorized, wind-up knight | 5 Comments

Porting Wind-up Knight to OUYA

Posted on July 3, 2013 by Chris

Wind-up Knight has just shipped for OUYA. It runs great on the console and is really fun to play with a controller. If you have an OUYA, go check it out! If you don’t have one, $99 is totally worth the price of admission for a cheap, hackable, indie-focused Android game console.

Despite the title of this article, Wind-up Knight isn’t really a port. The binary we ship is almost identical to the one we distribute on Google Play. It’s trivially easy to take an existing Android game and boot it up on an OUYA, especially if you already have support for controllers. That said, getting Wind-up Knight ready to ship for the platform took a bit longer than I anticipated, so I thought I’d document some of the work required.

Controller Support

Wind-up Knight has had support for physical controllers since its initial launch. It supports the Xperia Play and is playable with Bluetooth HID controllers like the Nyko PlayPad Pro or MOGA. This support is based entirely on standard Android APIs, so even controllers that we never had access to during development, like the Japanese SMACON, work great. As an aside, the absolute best device to use for controller development is the NVIDIA Shield.

Because we already had support for controllers, Wind-up Knight was playable on our OUYA immediately. We just pushed our existing executable (the one distributed on Google Play) to the device with adb install and it ran almost perfectly. Though OUYA provides a library to help with controller support, there’s no need to use it: the OUYA controller reports as a standard HID controller, and can be supported with existing Android KeyEvent and MotionEvent APIs. We ended up only using the OUYA SDK to do OUYA-specific things, which is pretty much just the billing API for in-app purchases.

Though Wind-up Knight was playable right off the bat, it wasn’t ready to ship. There were a number of controller-related issues to solve. First of all, two of the buttons on the controller were swapped, and the DPAD wasn’t working. After a lot of research, we tracked this down to a bug in Unity.

In order to support older devices, Unity’s Android controller implementation uses low-level Linux APIs to read button states. However, the mapping of buttons to Unity inputs is not guaranteed by these APIs. You can specify a Unity button called “joystick 1 button 1,” but there’s no guarantee that this button will be the same one that generates the Android key event for KEYCODE_BUTTON_X, which is what we would expect. You might have two controllers with identical button layouts that report identical key codes, and Unity may still map them to different buttons in its Input system.

To work around this we need to ensure that Unity is looking at the key code rather than actual hardware information. We do this by overriding Activity.dispatchKeyEvent() in our Java layer. This function is called as keys are delivered to the application, and provides a spot where we can transform (or even consume) key events before they reach Unity. In this function I look for KEYCODE_BUTTON_* and DPAD_* events and transform them into new events that map to keyboard buttons (e.g. WASD). This forces all controllers into a standard key mapping, which we can easily manage with Unity’s Input API. Synthesizing KeyEvents also clears the hardware reference information that comes with controller key presses, thus preventing Unity from using unreliable lower-level APIs to read the hardware.

With this change our controller mapping for all controllers, including the OUYA’s, is the same. Fortunately, the mapping of MotionEvents to analog sticks appears to be reliable across all controllers, so using standard Unity Input APIs for analog axes works fine.

Apparently there is some Unity plug-in specifically for OUYA controller support, but I don’t really see the point; I want a solution that works for all controllers and isn’t device specific. Our approach didn’t require any changes to our Unity game at all–it’s confined to Java land.

User Interface

Once our controller support was sorted, the next step was to make all of our UI controller-capable. This is actually a lot more work than I expected. Though we use standard Android APIs for most of the menus in Wind-up Knight (I wrote about that system a few years ago), I still needed to go through all of them and ensure that buttons could be selected, that focus moves through multiple buttons in predictable ways, and that screens without obvious buttons (such as the Armory) had special case code to allow complete manipulation without a touch screen. Furthermore, in the bits of UI that are done within Unity (such as the level select screen), I needed to add code to support focusing in on things that one would normally just touch. I budgeted a week to do this work and it ended up taking me two; even with a relatively UI-light game like Wind-up Knight, going from a touch interface to a controller interface is a lot of work.

OUYA’s controller also supports a mouse pointer, and I assumed that I’d be able to fall back on that if absolutely necessary, but that plan didn’t work out. The pointer doesn’t actually simulate touch events at the Activity level, so while it can be used to click on buttons in normal Android UI, Unity doesn’t see it at all. I suspect this is implementation is the standard Android pointer implementation, and not something that OUYA invented, but either way it is unfortunately restricted.

Also important to shipping on OUYA was removal of most things that link to web pages. For example, we have links to Facebook, Twitter, and Google+ on the Wind-up Knight main menu. This makes sense on a phone or tablet, but not on a TV game console: the user probably isn’t interested in tweeting from his OUYA. Those buttons had to go, as did links to things that require Google Play (such as the Google Play game services button and links to Tapjoy offers).

Our first submission to OUYA was rejected because we had neglected to move some UI elements away from the side of the screen. The size of the visible area of the screen varies greatly from TV to TV, and to ensure nothing is cut off it is important to leave a 10% buffer of open space on all sides of the display. Fortunately it was pretty simple to pull all of the UI in (I just inserted a FrameLayout with a 10% margin into the root of my Android UI when running on OUYA), so this didn’t keep us down for long. But it’s definitely something to consider when developing for TVs.

Finally, the in-game HUD was hidden for the OUYA version. Normally the HUD indicates buttons where the player will place their fingers, and is completely unnecessary when playing with a controller on a TV. On the OUYA version of Wind-up Knight, we only show the buttons during tutorial sequences, and even then we show controller button images rather than the icons that are displayed on phones and tablets.

One last gripe about UI: the OUYA buttons themselves are annoyingly named “O U Y A” rather than the standard “A B X Y” format specified by Google. We had to create special graphics to indicate the correct buttons, which widened the size of our otherwise small OUYA-specific footprint.

Other Things

The other bits required to finish off the OUYA version of Wind-up Knight, such as integration of the OUYA billing system and minor additions to the Android manifest, were extremely simple and straightforward.

One strange aspect of OUYA development is that the launcher requires an internet connection to correctly show development builds. If your internet goes down, you’ll get an error (and a nice exception in logcat) when trying to launch your game. We worked around this by using the adb shell am start command to launch our development builds from the command line.

Wrap-up

Bringing an existing Android game to OUYA requires almost no OUYA-specific work. There is work to support controllers, and significant work to convert touch-based UI to a controller UI, but none of this work is specific to the OUYA itself. Considering the plethora of other controller-based devices running on mobile hardware that have been announced this year, adding support for controllers and TVs to our games seems to make a lot of sense. For Wind-up Knight, we were able to make our game run great for OUYA with changes that are applicable to all kinds of other potential future devices.

For now, the OUYA is really the only device in its class, and Wind-up Knight is really awesome on it. Our hope is that it is the canary in the coal mine, and that it will usher in a new class of microconsoles that are easy to develop for and ripe for independent games. I’m really happy to be able to support this effort so easily with Wind-up Knight.

Posted in Android, game engineering, wind-up knight | 2 Comments

Free-to-Play is A-OK

Posted on March 20, 2013 by Chris

Let’s talk about free-to-play games.

I mean, really talk about them. Pick them apart. Analyze them. Maybe even learn a few things.

Because sometimes I feel like talking to game developers about the topic of free-to-play games is like talking to a brick wall. “I don’t play free-to-play games,” one developer, who’s work I really respect, told me smugly when he learned that our games cost nothing to try. His game, an XBLA title, costs nothing to try either.

I don’t think we even agree on what “free-to-play” means. I think it means “a game that you can play for free that also has things you can choose to buy in it.” But when I floated that definition on Twitter, a number of people disagreed.

f2p1

f2p2

f2p3

(thanks to Teut and Raph for humoring me on this point.)

I’ve noticed that developers tend to get themselves worked up over a specific free-to-play implementation and then, rather than take that particular design to task, turn around and blast all “free-to-play” games. You hate Farmville because you see it as a Skinner box thinly disguised as a game, created for the express purpose of extracting money from its player’s wallets. Fine. But what does Farmville have to do with Temple Run 2? Or Real Racing 3? Or The Walking Dead? These are all free games with in-app purchases built into them, but they have very little in common. Too often the conversation ends before it starts with arrogant platitudes like “I don’t play free-to-play games.”

Welcome to the Dark Side

Thankfully some developers are willing to dive deeper. Charles Randall’s post on this subject is incisive because he captures the essence of what bothers many game developers about free-to-play games.

Charles manages to side-step a big red herring: the mechanics commonly used in free-to-play games. It’s not energy systems or grinding or unlocking content or wizard hats or consumables or in-game currency that bothers him. After all, every one of those mechanics can be found in traditional paid games, and thus can be justified absent monetization.

Rather, it’s the idea that a game that asks for purchases in the midst of play just might be designed to manipulate you into paying. Charles sums up this general uncomfortableness well:

Beyond these issues, there are the questions that F2P games raise in my mind while I play. How can I know that I am not being manipulated? If I am playing the game, but it gets grindy, and there are purchases which will alleviate the grind, what were the reasons for the grind in the first place? Did the designer believe that the grind was the optimal path for the game to be engaging, or was the designer making conscious decisions based on conversion metrics?

The problem, according to this point of view, is that even if a particular game element (say, grinding) has real game design utility, the very existence of in-app purchases causes players like Charles to wonder if the element was inserted just to make money. The design has been tainted, or “corrupted,” as Charles would say, by the need to monetize. This is, I think, a very common view amongst traditional developers.

I also think it’s a pretty weak argument, for several reasons.

First, the basic premise of the “f2p corrupts game design” argument is that paid games are different. It assumes that traditional games do not include elements that have no purpose other than increasing the developer’s bottom line. This is, of course, completely false. Why do so many console games feature women in skimpy armor? Why would a developer ever bother making a game featuring somebody else’s intellectual property? Why does Alan Wake have ads for Verizon, why does Peter Parker’s camera say CyberShot on it, and why does the loading screen of Wipeout 2 feature the Red Bull logo? Heck, why do we need better graphics in our game devices? Developers may not think about it this way, but traditional games are designed from the ground up to be financially successful.

Game design: corrupted!

Of course, there are some games made without any concern for future profit. I’m a big fan of Tale of Tale’s work, for example. But this is probably not what developers have in mind when they are thinking about the general merits of paid games compared to free games. The truth is that all commercially produced games are influenced by the need to be profitable. Whether it manifests as a character design (would God of War have been successful without Kratos?), superfluous sex appeal, reliance on a licensed character, or graphics tech to meet customer expectations, it’s always there.

And because it’s always there, it’s better thought of as a design restriction than as a problem. If your publisher tells you that market research has shown that the your new PS4 game must include elves, gangbangers, and a nail gun, you do your best to figure out how to make the best game you can within those restrictions. And guess what, that’s what goes into making a free-to-play game too. If your market research shows that paid apps on the iTunes App Store and Google Play are dead (they are, but let’s debate that point in a future post), your challenge is to make the best game you can within the format that the market accepts. Your monetization scheme, much like your control scheme, is a design restriction that you must work within. That there are restrictions that relate to your bottom like is a fact of life for all game developers, regardless of platform or price tag.

Importantly, this doesn’t mean that you must trade fiscal viability for quality. Many games do make that trade–I’ve worked on enough licensed character games to know exactly what that entails–but it’s not a requirement. Many developers are able to create financially successful games that are also quite good. The fact that money must somehow be made, and that the need to make money will inevitably influence design, is nothing new. It’s just one more design restriction within which a designer must operate. A mark of a good designer is one that can make a fun game given numerous restrictions.

Let’s take this a step further. It’s better to think of free-to-play mechanics as a design restriction because it results in a specific player behavior: strategizing. The folks playing free-to-play games are not the Pavlovian dogs we sometimes portray them as, listlessly clicking their way through CSR Racing and happily plunking down cash for the privilege of clicking faster. Playing a f2p game seriously is all about figuring out how to get as far as possible by spending as little as possible. It becomes a hardcore min/max strategy game, and figuring out the strategy is really fun. Games like The Sims boil down to a mundane operation loop within a progression arc that the player is attempting to optimize; it is figuring out the parameters of that optimization that provides most of the enjoyment. The same is true for free-to-play games: adding purchases into the mix gives the player an axis to strategize upon, and when it works it’s really fun.

Of course it doesn’t always work, and not all free-to-play games are fun. But the point is that the monetization aspect of these games is absolutely a participant in the greater game design balance. In fact, in my experience it’s by far the most difficult part of a free-to-play game to design. The restrictions imposed by f2p are dramatic.

Winner Take All

Speaking of balance, Charles goes to some length to make his complaint specific to games that have purchases that “affect the balance of the game.” That is, games that allow the player to somehow get ahead by buying stuff. I appreciate the point; Charles is actually drilling down into the things he doesn’t like rather than writing everything under the f2p banner off. But his complaint hinges on a couple of assumptions that seem pretty rickety from where I sit.

She probably bought upgrades for those arms.

First, Charles notes that pay-to-progress is “corrupting” in games that feature competition between players because the competition is no longer honest. I don’t disagree in principle, but this is hardly specific to free-to-play games. By that logic, performance-heavy multiplayer games like Far Cry 3 must also be a “corrupted” design because the player who can afford the fastest PC and the best network connection has the edge. It also assumes that purchases that power the player up will always result in winning, while most multiplayer games I know maintain a delicate balance between skills and stats. Not to mention the existence of intelligent match-making systems designed to pit players with similar stats against each other to maintain fun.

Second, this argument seems to have no bearing on games where the purchases are not directly related to “triumph over a player” that is playing for free. I can pay to buy a crystal in Triple Town so that I can improve my town, but no other player is affected by that action. Even in multiplayer games, there are many examples of purchases that are about convenience for the player rather than competition with another. I have a friend who regularly buys World of Warcraft gold from China because he just doesn’t have much time to play and wants to go on raids as a leveled up character. This hardly ruins the game for other players.

In fact, I think we can expand upon this idea to find the fundamental disconnect in Charles’ argument. At the core of this discomfort that he describes is the assumption that the goal of a game is to win. Paying to win just feels, well, like a bit of a cop-out.

The thing is, the majority of successful free-to-play games cannot be won. They are endless. Winning isn’t the point. In fact, the audience for these kinds of games isn’t playing to win at all. They are playing to have a good time. They are playing for enjoyment of the moment. They went to the movies instead of purchasing the Blu-ray; buying some popcorn while they’re there isn’t weird, doesn’t mean they’ve been taken advantage of, and doesn’t turn the theater into a casino.

I am the Audience

I think that some traditional game developers and hardcore gamers haven’t figured out that there’s a new audience for games yet. An audience that doesn’t share their tastes and has a wholly different idea of what games are worth. An audience that the traditional game industry has repeatedly failed to reach for thirty years. An audience that likes to be able to try things out for free and then make their own judgements about whether or not potential purchases are worth it.

I also think that many traditional developers shy away from having to participate so directly in marketing. That’s what a lot of free-to-play design is: marketing to try to get the player to want to spend money. In the traditional game space, marketing is always handled by somebody else, usually off at a publisher somewhere, often demonized by the team. So it’s natural that traditional devs are wary of stepping into this role, especially when it effectively becomes a part of the core game design. But of course, marketing is a fundamental component of all successful games.

What most of us think about when we think of marketing.

The point isn’t to paper over the offensive things that some free-to-play games do. I just don’t think that free-to-play game design is intrinsically evil, or corrupting, or actually all that much different from all the other stuff that already goes on in the game industry. There are plenty of paid games that I find offensive as well, but I also know that they are not representative of their price point or platform. Packaging up a bunch of games and categorically declaring them to be the online equivalent of casinos because they can be played for free is, in mind, a gross generalization. Worse than that, it’s a meme that blinds people to the actual merits–and problems–with this type of game. It’s a stereotype, a way for people to stop thinking about things they are not initially comfortable with, a way to casually dismiss them with “I don’t play free-to-play games.”

How’s this for an alternative theory: traditional game developers look at some popular f2p games and find them lacking. The graphics are bad. The game play is simplistic or almost non-existent. It’s a knock-off of a better game from fifteen years ago. And then they see that some of these games are making insane profits. Inconceivable profits. And to the seasoned developer, who has excellent taste and experience in video games, the only possible explanation is trickery. The players must be getting duped. It’s the only way to square the apparent popularity with apparent lack of compelling content.

But really, it’s just a matter of taste. Traditional game developers who dismiss f2p are like hardcore wine connoisseurs complaining about the popularity of Trader Joe’s Two Buck Chuck. By writing off the entire category these developers miss the nuance. They miss the opportunity to learn about a different kind of game design. They miss the opportunity to speak to an audience that does not care for traditional video games. Worst of all, they miss out on some great f2p games that have top notch production values because they’ve decided that the problem is the price point.

I have eight different consoles connected to my TV. I own (and have played to completion) hundreds of console games. But I’ve also spent more on free-to-play games than console games so far this year. Which box am I supposed to fit in? Am I a wine connoisseur or a two-buck-chucker? I don’t even drink!

Posted in game industry, mobile games | 6 Comments

Rise of the Blobs

Posted on January 17, 2013 by Chris

Robot Invader is staffed exclusively by veterans of the console game industry. Our team of five has shipped over 50 console games between us, and we worked together on many of those titles earlier in our careers. When we developed Wind-up Knight in 2011, we were working within a genre that all of us had prior experience with, and as a result it was a straightforward (though not necessarily easy) game to build. Wind-up Knight now has close to seven million total downloads, and player reviews on both Google Play and the iTunes App Store are glowing. We’re very pleased with its success. But for our second game, we decided to create something completely different.

Robot Invader’s second game is called Rise of the Blobs. It’s a fast-paced arcade puzzle game, and it’s probably not what you expect. We’ve played a lot of puzzle games on our mobile devices, and gotten completely hooked on a few. But Rise of the Blobs is something else. It’s easy to play but crazy challenging in the end game. It’s got loads of depth and strategy, and we’ve added alternative game modes that change the nature of the puzzle significantly. This is not a genre that we’ve worked in before; it’s a design that we unearthed rather than one we conceived. Rise of the Blobs is the product of almost a year of iteration and development, which more than twice as long as the time we spent on Wind-up Knight. It’s a puzzle game unlike any that we’ve ever seen.

You can read more about Rise of the Blobs, and it’s available now for free on iOS and Android. Here’s a teaser video to give you a little taste of what it’s like.

Please give it a shot. We’re very excited to finally have it available to the public.

Posted in Android, iOS, mobile games, rise of the blobs, Robot Invader | 8 Comments

The Future of App Stores (and the history of video)

Posted on August 15, 2012 by Chris

I grew up watching movies. Mostly on video tapes, which came in hard plastic cases from a place called Flicks & Pics a few blocks from my house. Flicks & Pics was something of an institution in my neighborhood; it was a mom-and-pop rental joint with about twenty thousand VHS tapes in stock, organized by genres like “Action,” “Noir,” “Cult,” “Classics,” and even “Stinkers.” On Tuesdays you could rent any movie in the store for a dollar, and the owners refused to charge for movies that starred Brooke Shields. I watched Akira, The Maltese Falcon, Strangers on a Train, and Blood Simple on Flicks & Pics tapes. A Taxing Woman, Beverly Hills Cop, Drunken Master 2, City Lights–the list goes on. You selected a video by finding its box on the shelf and taking the tag hanging under it to the register; if no tags were present, all copies were already rented. This system meant that even minor films for which only one copy existed still got the same amount of shelf space as the latest summer blockbuster. Some films even bore small stickers with comments from employees, inviting you to take a chance on a feature you might have never otherwise considered. It was always easy to find something new at Flicks & Pics.

Then, sometime in the early 1990s, Blockbuster arrived in town. I visited it shortly after it opened and was impressed by its large size and volume of titles. But upon closer inspection I noticed something strange: Blockbuster always had twenty or thirty copies of the latest hit, but every other film in the store seemed to be some Grade Z schlock that I’d never heard of before. The oldest films in the store were made around 1982; not only did they not carry High and Low, they didn’t even have a foreign section! Instead they focused on a narrow selection of big budget flicks and padded the rest of the store out with soft porn and “films” like Ninja III: The Domination. “Who rents this crap?” I wondered.

I later learned that Blockbuster’s business model operated on deals with the movie companies. In exchange for discounts for the big-budget, heavily marketed films, Blockbuster agreed to supplement its stock with direct-to-video movies that had been produced with almost no budget. The theory, I guess, is that the big titles would draw people into the store and eventually they’d rent some of the schlock. Since the schlock was so cheap to produce, Blockbuster’s guaranteed purchase of a certain amount of it was a good deal for the movie companies. And for Blockbuster it allowed them to fill their catalog at low cost while ensuring that they always had films less than a year old in stock (this is called, apparently, “depth of copy”).

Blockbuster (and its twin, Hollywood Video) rolled into towns across America and pretty much put an end to local mom-and-pop video stores. Several in my town gave up the ghost after the big B arrived. But Flicks & Pics survived. Small as it was, it catered to a crowd that was looking for films they couldn’t find at Blockbuster. What gave that neighborhood video store staying power was the way it was curated; the selection of films, complete with staff recommendations, made it a goldmine for people who were ready for something a little more challenging than Red Shoe Diaries. Flicks & Pics had “breadth of copy;” while not every film was good, there was always something new to find and the chances of renting a real train wreck were pretty low. When the store finally went out of business in 2007 (long after the local Blockbuster had become an empty, derelict building), it was because the VHS format was no longer viable. Advancements in technology dealt the blow that the big chain stores could not. When the store closed there was a sort of community vigil in the parking lot.

The lesson here is applicable, I think, to modern app stores. We have a problem very similar to that faced by video stores in the 1990s: the volume of apps is now so immense that an unfiltered catalog is impenetrable. iTunes and Google Play both do their best to surface the content of their catalog to users, but they don’t have the virtual shelf space to promote every high-quality app. They probably don’t even have a good way to identify high-quality apps (especially since the Apple review board apparently spends in inordinate amount of time trying to ensure that no screenshots containing male genitals are approved). Users have become wary of spending money on apps they haven’t tried because the crap apps are right there in the database along with the good ones.

The volume of apps has made visibility the #1 problem for developers to solve. The rise of free-to-play isn’t just about new monetization schemes–it’s a way to lower the user’s perceived risk and thus get more people to give the game a chance. All the social media integration in games lately serves as another way to get noticed outside of the stores themselves. These sorts of alternate approaches are increasingly necessary because even with promotion by Apple and Google, high quality paid games aren’t being purchased anymore. You might have built the Citizen Kane of mobile apps, but it’s unlikely to gain traction while wedged between You Got Served and Battlefield Earth on the shelf. We need a filter. A way to more effectively separate the wheat from the chaff.

Blockbuster’s filter was pretty simple: let the market(ing) decide. The chain would observe which films did well at the box office and then ensure that they had enough to satisfy the high customer demand for those films immediately upon the video release. Depth of copy: they focused on having a large number of a few recent hits because that’s what customers generally wanted. And of course, customer demand was driven by marketing campaigns paid for by the production companies. Money goes into marketing, marketing drives demand, demand drives investment by places like Blockbuster. And for everything else, Grade Z apparently sufficed.

The App Store today is admittedly kinder than Blockbuster’s model. Apple and Google make valiant attempts to promote content that they think is high quality, and this helps offset the necessity for heavy marketing. It’s still possible for an app or game without mega marketing dollars behind it to become a hit. But as the volume of apps increases, and as users become increasingly risk averse, mega marketing is becoming more important. Promotion by Apple and Google is unreliable; developers with the cash are investing heavily in marketing to avoid being drowned in the stream of new releases. As in every other medium, marketing works. Marketing, or including an already well-marketed brand, seems to be the only way to make a paid game viable on the App Store today.

But the problem with the marketing-driven model is that it favors the developers who have giant money bags to throw at marketing. If a huge marketing spend is required for success, only companies that are already rich will be successful. The app stores have been a democratizing force, especially in the game industry, because suddenly small developers and independents have found themselves on equal footing with the big guys. If Google Play and the App Store stay the way they are now, I think that the large companies will smother everybody else.

But what if we had something a little bit more like the model employed by Flicks & Pics? A breadth of copy model, where the entire catalog–not just the boxes in the window–is selected with a certain audience in mind. Valve’s Steam seems to prove that this model can work and be highly profitable, but there is a big difference between what Valve does with its store and what Google and Apple do with theirs. The audience for games on Steam is extremely well defined: they are PC gamers who like Valve games. From that you can extrapolate which types of products are likely to do well and which are likely to fail and thus apply a content filter fairly easily. Apple and Google, on the other hand, must address everybody who has a phone. Which is to say pretty much everybody in the world. That’s a lot harder filter to design.

Apple and Google do promote apps that they select based on some secret criteria. But hand-picking content isn’t going to cut it in the long run because the process just doesn’t scale. Back when people browsed the web with Netscape, Yahoo was little more than a directory of web pages. A phone book of links, organized by hand into categories and sub-categories that could be easily clicked through. Yahoo’s viability fell through the floor when Google came out because its hand-built index only represented a small portion of the web. Google, on the other hand, could search for anything. You know what happened to those two companies after that.

We need a an app store that operates like Flicks & Pics did, a breadth-of-copy approach that is designed to introduce new content to specific types of users. But gone are the days when this is a task that can be performed by hand. We need a system that suggests different apps to different users, one that considers quality metrics other than raw downloads. A way to ensure that users can find apps that marketing has got them excited about, and a way to expose those same users to apps that have no marketing. A system that exposes unknown gems to enough people that they have a chance to become a hit. If Steam is a store for PC-gamers-who-like-Valve-games, we also need a store for young-adults-who-like-mysteries and middle-aged-parents-who-enjoy-travel and children-who-like-outer-space, etc, etc, etc. Simple categories don’t cut it. Top 10 lists don’t cut it. There’s so much content on the app stores now that we need smarter systems to browse it.

Perhaps Apple’s purchase of Chomp will eventually cause the App Store to evolve into something smarter, something more dynamic, something less controlled by marketing alone. I sure hope so.

Posted in Android, iOS, mobile games | 7 Comments

Playing the Story

Posted on February 15, 2012 by Chris

Last week David Jaffe, the outspoken designer of tons of games including God of War and Twisted Metal, gave a speech at DICE about how games and stories are incompatible. The coverage of the talk makes it seem pretty cut and dry: David Jaffe hates stories in games and thinks they are a waste of time. IGN reported that Jaffe “made a compelling argument against stories in games.” Even the transcript of the talk bears the headline David Jaffe explains why games shouldn’t have stories.

Any argument against stories in games is guaranteed to spark controversy, which Jaffe’s talk did. There are so many examples of excellent games with great stories that it is easy to attack Jaffe for saying the two cannot be combined. And hey, it’s an argument that has been waged across the internet tundra for years already, so it’s bound to drive hits.

But despite all the press, that’s not really what Jaffe is saying. Rather than condemning stories in games, Jaffe is issuing a warning to game developers who dream of emulating their favorite films not to forget which medium they work in.

What Jaffe is actually talking about, I think, is a very specific group of games that are not just laden with cinematic story telling, they actually appear to be more interested in the story than the game itself. He is complaining about developers who have been “seduced by the language of film” to such an extent that it impairs the core gameplay of their games. I bet Jaffe isn’t a big fan of Heavy Rain or Metal Gear Solid 4. The danger that he alludes to is the siren song of being a movie director, of having the chance to sit in the big story telling chair and then crashing into the rocks when we focus so much on narrative that we neglect the part where the player actually does stuff.

Boil this down and it’s not an argument against stories in games, it’s an argument that gameplay must take precedence over all other elements.

That’s an argument that nobody disputes. Well, I take that back. There are probably some “serious games” folks and some Facebook developers who place value in games that have no play. But generally, the idea that gameplay is the core foundation of the medium is, I think, common sense. The problem is that Jaffe seems to be casting narrative as antithetical to gameplay, and this is what causes people to bristle. But really, the core message here isn’t “get rid of stories,” it’s “don’t trade gameplay for story,” and “don’t trade gameplay for the chance to act like a sexy Hollywood director.” I think you could probably just generalize that and say “don’t trade gameplay for _____.” Nobody is going to argue with you on that one.

The details, however, are full of little horned men with pitchforks. What is “gameplay” anyway? Are we talking about the mechanical mapping of button presses to simulated actions? Are we talking about the formulation of tactics before the actions themselves are executed? Is it the rules of the game, or the space for player expression within the rules? Is the gameplay in Monopoly the act of selecting which properties to buy and develop or the art of wheeling and dealing? Or maybe the rolling of the dice and placement of the figure?

Where is the line between the game system and its contextual content? If the gameplay of Clue is to collect enough information to reliably name the killer, why is the same operation not called gameplay in Heavy Rain? Rock Band would certainly not be fun without its mechanical timing and rhythm challenge, but the mechanics alone wouldn’t be compelling without its excellent music catalog either. There’s a novelization of ICO by an author that I like, Miyuki Miyabe, but ICO isn’t a story I want to read–it’s one I want to play.

Maybe these definitions are hard because we’re trying to pin a single word on a medium that is full of different kinds of interactivity and expression.

I had something of an epiphany a while back when, after years of studying Japanese, I finally figured out what the word omoshiroi (面白い) meant. My dictionaries all defined this word as “funny or interesting,” and this definition always bothered me. “Funny” and “interesting” are two completely different states of mind! I think Backus–Naur Form notation of language grammar is pretty interesting, but nobody in their right mind thinks BNFs are funny. I had a hard time using this word until it finally hit me that omoshiroi actually means “not boring.” Anything that isn’t boring can be omoshiroi. In fact, the word is defined not by a specific form of entertainment, but simply by its negation of banality.

You know what? “Gameplay” is the same. It’s the stuff that the player does while playing the game that is not boring. I think where we get bogged down is in the idea that “gameplay” must mean “mechanics” or “rules” or “strategy” or any other single thing. Gameplay is that which engages the player. It might be timing our jumps correctly, or lining up a perfect combo, or deciphering who killed Colonel Mustard in the conservatory with the lead pipe. Gameplay is figuring out who or what Pyramid Head represents in Silent Hill 2. It is managing relationships in Fallout 3, aiming fowl in Angry Birds, and sword fighting with insults in The Secret of Monkey Island. Gameplay is pounding your finger into your controller and screaming at the top of your lungs to make Old Snake crawl through an irradiated tunnel to avert nuclear war. It’s the meat of what games are, and it’s made out of all of the bits games have at their disposal, including narrative. If it’s good, gamers are engaged and entertained and not bored. And if it’s bad, playing is a waste of time.

Jaffe is right: don’t trade gameplay for anything. But don’t let that stop you from making gameplay out of stories.

Posted in game design, game industry | 8 Comments

OS Native UI in Wind-up Knight

Posted on January 4, 2012 by Chris

A while ago I posted the following tweet to my twitter account:

Fun fact: #windupknight on Android includes 7575 lines of Java. iOS version has 7005 lines of Objective-C. Both have 12000 lines of C#.

This generated a lot of responses, mostly asking about what the Java and Objective-C code is for. Today I’ll explain how I structured the OS-native code for Wind-up Knight, and what I learned in the process.

We absolutely love Unity to death, but one thing it’s terrible at is 2D UI. Specifically, 2D UI that is based on atlas textures and that can automatically resize itself to different screen sizes and aspect ratios is a gaping hole in Unity’s otherwise formidable mobile game engine feature set. All the 2D stuff we do in Wind-up Knight is code I wrote from scratch (or borrowed from the net); there are basically no tools for 2D-on-mobile and so you have to make your own. Font rendering is particularly problematic. Unity takes the old-school game engine approach of rendering all fonts with font textures, so if you want to support arbitrary UTF8 text, you’re in for a hard time (or some ugly fonts).

Early in the project I decided to rely on native OS APIs to do 2D UI rendering in order to get around this weakness in Unity. It’s pretty easy to knock up some simple views and render them on top of Unity in both iOS and Android; in fact, both systems use view hierarchies that are so similar that I was able to copy and paste some code between platforms (and languages) with only minor syntactical changes. My plan was to draw anything requiring text with the native OS API, and to draw everything else with Unity. This would also make certain complex-but-common UI controls (like scrolling lists) easier to implement, as both operating systems provide them right out of the box. We knew that we wanted to localize the game into Japanese (and maybe Korean and Chinese as well), so having a robust way to render UTF8 text was key.

To get native code support to work you need to follow a few steps. On Android, I created a project outside of the Unity folder and then wrote a shell script that would package the generated .class files up as a jar and move it, along with the other project resources, into Unity’s Plugins/Android folder. The workflow was to edit Java outside of Unity, compile it, build the Jar, and then rebuild the binary from Unity.

On iOS, the process is reversed: Unity outputs an Xcode project, so you put your native code files in the Plugins folder (or elsewhere; there’s some trial and error, and maybe a few shell scripts involved) and execute a Unity build first. Then you can work on the generated project in Xcode to add Objective-C code, and finally compile the final binary from Xcode like any other project.

In theory, using native code for UI drawing this is a great idea. Unity can bind itself to native code (via the [DllImport(“__Internal”)] declaration on iOS and via JNI on Android) and call down into it pretty easily. On the native side you have tools and debuggers made for designing interfaces, and you can leverage all that stuff this way. Plus both systems have a solution for different size screens and things like that.

In practice, it turned out to be a poor decision. First, we ended up having quite a lot of non-trivial UI (even though Wind-up Knight is a pretty simple game, interface-wise), which required me to write those 7000 lines of native code twice in two different languages (and if we ever want to port the game elsewhere, I’ll have to write it again).

Second, the tools provided by Apple and Google are not artist-friendly tools. They both require intimate knowledge of how the UI subsystems that run the OS work under the hood. Therefore, the only person who can author UI with this setup is the engineer (that’s moi). Unfortunately, engineers are rarely artists; though I worked from mockups generated by people who understand art and did my best to replicate them, the UI in Wind-up Knight is missing much of the polish that we put into the rest of the game. Our artists, Mike and Casey, didn’t have access to the UI authoring environment and couldn’t get in there to work their magic.

Third, as the game got larger our Unity rebuilds got slower and slower. This is especially problematic for Android because we need to do a Unity rebuild to test every change. With 52 levels it takes Unity a few minutes to build and package our game as an apk, so even a one-line Java change requires a lot of waiting to verify. It would be nice if Unity had an incremental build system for this kind of stuff.

Fourth, and perhaps most importantly, maintaining a few thousand lines of code in two different languages is costly and error-prone. Porting Wind-up Knight from Android to iOS was trivial at first, but as our UI grew more complex the amount of work it required to mirror in Objective-C became significant. In the end, between the two platforms, I wrote more UI code than game code (!!), and though that code was not complex, it was quite time consuming. And the result was a serviceable but far from fantastic UI.

One thing about this plan that did go well was our plans for localization. Thanks to OS native text rendering, implementing Japanese text was pretty trivial. There are still some issues (word wrapping rules for Japanese suck on both platforms), but for the most part it worked exactly the way I had planned it. Japan is our #2 market worldwide, and at this moment it’s #1 for iOS; I suspect that success has a lot to do with our Japanese localization.

Future Robot Invader games will definitely leverage platform APIs, but probably not for UI. There are other things we do in Java and Objective-C, such as in-app billing integration, GameCenter calls, and Android Notifications. Those kinds of things are quick and easy to do in the OS-native programming environment, and really don’t belong in Unity code anyway. But for the next project, my plan is to spend some significant time building a proper UI system within Unity (or perhaps buying one of the available 3rd party libraries).

Posted in Android, game engineering, iOS, mobile games, wind-up knight | 11 Comments

Locomotion Smoke and Mirrors

Posted on December 18, 2011 by Chris

If we’ve done our jobs right, Wind-up Knight is a fairly simple game. There are only four inputs, and only two are ever needed simultaneously. Sir Sprint, our heroic spring-loaded knight, runs forward automatically, removing the need for a classic directional pad or analog stick. The challenge is derived from careful level design rather than a complex interface, and though the game is not easy, it’s straightforward.

Achieving a control scheme that is simple to understand and simple to operate, even for a straightforward game like Wind-up Knight, is actually a pretty complicated problem. The term I use for this kind of code is player handling, referring both to the steering of the player’s avatar, and to the manipulation of the player himself. You see, games that control well often do it by lying to the player, by fudging the simulation, by breaking the rules.

Good player handling code is often smoke and mirrors; the player presses buttons and sees a reasonable result, but in between those two operations a whole lot of code is working to ensure that the result is the best of many potential results. For example, my friend Greggman discovered that Mario 3’s jumping rules change depending on whether or not a level has slopes in it. Halo’s targeting reticle famously slows as it passes over an enemy to make it easier to target with an analog stick without using an auto-aim system. When Spider-Man swings, he certainly does not orient about the spot where his web connects to a building (at least, he didn’t in the swinging system I wrote).

Good player handling code doesn’t just translate the player’s inputs into action, it tries to discern the player’s intent. Once the intended action has been identified, if the rules of the game allow it, good player handling code makes the action happen–even if it means breaking the rules of the simulation a little. The goal of good handling code isn’t to maintain a “correct” simulation, it’s to provide a fun game. It sucks to miss a jump by three centimeters. It sucks to take the full force of a hit from a blow that visually missed. It sucks to swing into a brick wall at 80 miles per hour instead of continuing down the street. To the extent that the code can understand the player’s intent, it should act on that intent rather than on the raw input. Do what I mean, not what I say.

Wind-up Knight appears to be a pretty simple game, but we actually pull a few tricks under the hood to make the game control the way you expect it to (rather than the way it would if left to a pure physics simulation).

Jumping

Sir Sprint does a lot of jumping, mostly from off of solid surfaces. But he can also jump right after running off a ledge–for a very short amount of time, we’ll allow a press to the jump button to result in a regular jump, even though there’s nothing under his feet. This is particularly helpful to players on phones that occasionally slow down; they shouldn’t have to die because the frame rate fluctuates right at the point of a jump.

We also allow wall jumping to occur while Sprint is in mid-air. If you jump at a wall and hit jump again before he lands on the surface, Sprint will automatically flip, snap to the wall, and jump off it again. This makes the wall jump feel a little more sticky, and it means you have a larger margin of error when timing a wall jump; even if you press the button slightly too early he’ll probably still make it.

Rolling

If you are rolling under a low ceiling and release the roll button, the knight will continue to roll until he reaches an area where he can stand. In that case, if you hit attack or shield while rolling, the move will be queued up and executed automatically as soon as the knight stands up. This lets you make moves immediately after exiting the roll state even if you press the button slightly too early.

The low-hanging ceilings, by the way, often extend invisibly on either side so that you don’t automatically stand up into some spikes.

Collision Detection

We have a fairly complicated “hit type” system to allow the rejection of legitimate collisions based on arbitrary game rules. For example, if an enemy hits the player as the player is in the middle of swinging his sword, we ignore the hit to the player and instead reverse it to kill the enemy. There are no double K.O.s in Wind-up Knight; when it happens, the player always wins.

We also ignore hits from falling things to Sir Sprint’s body region if his shield is up. If the shield is up, all falling things are considered impotent. This way, if Sprint runs into an object that has just fallen in front of him (missing his shield but not his torso), he won’t die.

Camera

The camera in Wind-up Knight is the second most complicated system in the game (the first being Sir Sprint’s locomotion code). It watches where Sprint is going and tries to prepare itself ahead of time for dramatic changes in motion so that it never snaps or cuts jarringly.

The most interesting case is the way that the camera watches for upcoming walls. If Sprint hits a wall he turns and runs back the way he came, which requires the camera to do a fairly dramatic sweep in the opposite direction. To smooth that transition out, the camera searches for walls ahead of Sir Sprint and then moves to align itself to them. However, not all walls will cause Sprint to change direction; low obstacles, for example, are probably going to get jumped over.

It took me quite a while to find a heuristic that could reliably detect upcoming walls but reject lower platforms. In the end I went with a system that shoots three rays out from Sir Sprint’s position, and only accepts an upcoming wall if all three intersect the same plane. You might not even notice that the camera speeds up and slows down in order to deal with dramatic orientation changes, but without that code the game would feel a lot less smooth.

Sometimes heuristics are not enough to get the correct effect, and you have to fudge it even further. We place secret camera “hint” objects in pits and shafts that Sprint is meant to slide down so that the camera can move to ensure the upcoming floor is always visible even before Sprint begins to fall down the shaft.

Though helping the player complete an action that they intended to complete is almost always the right thing to do, it is possible to go overboard with this kind of system. Games like Prince of Persia (the next-gen cel-shaded version, not the wonderful original) go so far in assisting the player that it’s almost impossible to actually fail. If the assistance is so obvious that the player notices it, the game feels suddenly like a false challenge, as if it is on rails. For Wind-up Knight, we chose a few areas to smooth out to ensure the best play experience, but the rest we left up to the physics simulation and the player’s actual prowess.

It may be smoke and mirrors, but good player handling systems are almost always focused on translating player intent, rather than player action, into game play. Hopefully the work we put into this area on Wind-up Knight makes it a better game, even if most players never know it’s there.

Posted in game design, game engineering, wind-up knight | 26 Comments

Wind-up Knight for iOS Released

Posted on December 15, 2011 by Chris

Human language is incapable of expressing the degree of excitement we feel as we announce that Wind-up Knight is now available on iPad and iPhone via the App Store. We even made a cool trailer to commemorate the moment:

We worked hard to bring this game to iOS, and we certainly hope you enjoy it. We added Game Center Achievements and a lot of polish, not to mention level tweaks, performance optimizations, and dramatically improved button placement and sizing specifically for your iDevice. Wind-up Knight is a Universal app and will run on everything down to the iPhone 3GS; the iPad 2 version is pretty much the best experience possible (iPhone 4S is a close second).

We’ve also simplified our pricing for this version. It’s a $0.99 app (at the current special holiday rate) but comes with Books I through IV unlocked from the get-go. No special offers, no paywalls, and now Notes are used exclusively for items in the Store.

Here’s the link. Stop reading this and go try it out now! Prepare to get schooled by some high-end 3D platforming iFun.

Posted in iOS, mobile games, wind-up knight | 9 Comments

Pay by Numbers

Posted on October 31, 2011 by Chris

Why tear out my heart for all the world to see?
Why not paint by numbers
Catchy melody
Burn it up the charts with sweet simplicity
Then do it again
— Self, Paint by Numbers

If you ask experts in the field of mobile game monetization how to make a hit, they’ll give you consistent advice. You should be “free to play” or “freemium,” which means you offer the game at no cost but then ask the user to pay for various things later. They will encourage you to schedule payment prompts at particular intervals, and to offer items that can be bought with cash. It’s probably a good idea to have some sort of energy mechanic that forces players to take a break and wait for energy to “refill” every once in a while. Of course, if they are impatient they can just pay for more energy and continue immediately. You probably want to have some items that are cheap, and some other items that are super expensive, because a small percentage of users will go crazy over your game and end up buying these extremely expensive things. In fact, these “whales,” the users that buy the $60 floppy hat and the $100 crested armor, will be your primary source of revenue. Make sure most of your items are consumable, so the player will have to buy them over and over again. You should give out free, randomized items every once and a while, just to keep the player interested. And if they haven’t played for a few days, why not pop up a notification reminding them that they just earned free gold without even doing anything?

This is what the experts will tell you, and they are clearly right: these types of systems allow you to give a game away for free and still make quite a profit on it. The top grossing games on iOS and Android are, almost without exception, games that employ these schemes.

There’s nothing wrong with any of these ideas. Indeed, most of them predate the current boom of mobile phone games. Once upon a time we called them DLC, or shareware, or subscription fees, or “insert credit to continue.” MMOs have been operating on these systems for more than a decade. You can find some of them in Animal Crossing. Some developers have jumped on these systems as intrinsically evil, designed only to exploit the player, and an assault on game design, but this argument has a big problem: it ignores players who genuinely love these games. Look, Britney Spears might be a singer who’s career is entirely constructed by a corporation for the purposes of selling CDs, but it’s also true that some people genuinely enjoy the songs she sings. You can’t argue that those people are “wrong” for liking Britney Spears, just as you can’t really argue that people who enjoy Farmville are “wrong.” Though some implementations may seem more questionable than others, the schemes for monetizing free games are not intrinsically bad.

In developing Wind-up Knight we spoke to a large number of well-meaining experts, all of which told us the same thing. And we thought about their advice pretty hard. Well, actually, we thought about it really hard. We thought and debated and made plans and then threw them away for the entire course of development. In the end, we ignored almost all of the advice we were given.

It’s not that we think monetization systems are all evil. The problem with the type of advice we were getting is that it assumes that your game design is inconsequential, the “touchy feely bits” between prompts for more free gold. It doesn’t really matter what the player does, just as long as they can do it within the monetization structure that seems to work. Maybe that’s why so many of the top grossing games on iOS and Android feel so empty and soulless–there’s really nothing to do other than walk the monetization state machine in a loop.

Wind-up Knight’s design isn’t something that we sat down and wrote up. If anything, it’s a design that we unearthed, something that already existed and was just waiting to be discovered. Something that we moulded and polished into a full game, but certainly not something that came from a big Word document describing a bunch of play mechanics. It is the product of iteration, a lot of iteration: about 40% of our development period was spent testing ideas and tweaking the results. The game we ended up making is almost nothing like our original concepts.

The thing is, the game we discovered isn’t a game that works with an energy system. Consumables don’t work well in the design. There’s really no justification for an artificial delay in the game loop. The items we have are not worth $60. Almost all of the advice we received about “how to make a game that makes money” was at best inapplicable and at worst outright contrary to our core design.

Wind-up Knight is a hard, skill-based game. The design requires a level of rule transparency and respect for the player that some other games don’t need to concern themselves with. When you die in our game, it must always be because you messed up in an obvious way; unfair deaths would change our rewarding challenge into a recipe for frustration. This respect for the player must also extend to every other element of the game, and that includes item sales and monetization. We felt that to compromise the core design to bolt on some sort of scheme would pretty much ruin the entire game. It would cheapen the experience, and remove the value of a difficult achievement.

We went around and around on our monetization plans. Finding a middle ground that allowed us to make some money without damaging the game design or pulling a fast one on the user took a long, long time.

Here’s the system we came up with in the end.

You can play Wind-up Knight, from start to finish, completely for free.

However, to do so you have to be good. Very good. You must get high ranks on just about every level. But if you are awesome, the game is free.

Playing well will get you Notes, our in-game currency. Notes are paid out at the end of each level depending on your ability to collect all of the items in the level.
Levels are separated into Books, four in all, each with 13 levels apiece. The first Book is free, and subsequent books can be unlocked for free with Notes earned from play.

If you are unable to play well enough to unlock a Book for free, you can unlock it by buying a few Notes or spending $1.99.
If you just want to check out the content and don’t care about mastering the game, buying the Books is an easy way to progress.
If you trust us enough to pay for the game very early (after the third level), we’ll give you the option to unlock all of the levels for a discounted rate. If you decide not to do that, no problem: the game continues normally until you finish the first Book, which is the first 1/4th of the game.

All of the items in the store can be purchased with Notes, which means you can get them all for free as well (if that’s how you decide to spend your earnings). Many of the items make the game significantly easier, and will thus help you acquire more Notes.
Items are priced reasonably based on their in-game effect. The most expensive item is less than $4, and it’s extremely powerful.

With this system you have a choice. If you like a challenge, and you are the type of gamer who enjoys putting his pride on the line, your reward for being awesome is enough Notes to buy all of the Books for free. If you prefer to just speed through the game with upgraded items and you don’t have that completionist streak, you can spend a couple of bucks and access all of the game content. And if you really don’t want to spend a dime, or you live in a country that doesn’t allow in-app purchases, you can choose to earn Notes through Tapjoy, an advertising service (which is otherwise completely hidden until you select it–no popups or ads in our game). The items we sell in the store are cheap and have real gameplay value. Equipping them changes the play significantly–the only “cosmetic” items we have are things we give you for free.

Our goal with is to provide a system that is transparent, has real value, and most importantly, respects the player. We’ve eschewed popular monetization schemes (much to the dismay of some of our friends) because they simply did not fit with the game we were building. We believe that there is room for games with different approaches; if nothing else, Wind-up Knight is an experiment to see if this kind of game can be profitable. If we could have employed some of those tried-and-true systems, we would have, and we may yet in the future. But only when they complement the game design and are done in a way that the user does not feel ripped off. To bolt something on that doesn’t belong in the game is antithetical to our mantra of quality above all else.

Posted in game design, game industry, mobile games, Uncategorized, wind-up knight | 83 Comments