Playing the Story

Posted on February 15, 2012 by Chris
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
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
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 | 26 Comments

Wind-up Knight for iOS Released

Posted on December 15, 2011 by Chris
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
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

The Other White Meat

Posted on October 22, 2011 by Chris
Chris

We’ve been quiet lately.  We’ll make some noise soon.
Baw-baaaawk!!

Cockatrice tastes like chicken

Posted in Uncategorized | 23 Comments

Play WIND-UP KNIGHT at Tokyo Game Show!

Posted on September 11, 2011 by Chris
Chris

We know you’ve been biting your nails with anticipation for Wind-up Knight, so much so that you’ve started to eat into the fleshy bits at the tips of your fingers.  Fortunately, we have a way for you to avoid all-out epidermal disaster: come play Wind-up Knight at Tokyo Game Show next week!

A fully playable and absolutely ego-destroying sample version of Wind-up Knight will be on display at SonyEricsson’s booth–just look for the large Xperia Play demo station.  Wind-up Knight will be ready and waiting to put you in your place on any of SonyEricsson’s vast array of demo devices.  Make that incredibly long trip to Makuhari Messe worth the trouble by playing our awesome game!

To whet your appetite here’s a new screenshot of a player about to get served by a goddamn wolf.

You about to get chomped!

Robot Invader初のゲームの日本版を遂に発表しました。難しさが半端ない「ねじ巻きナイト」は今年の秋にアンドロイドとiOSに登場します。東京ゲームショーに行かれる方は、是非ソニー・エリクソンのブースのXperia Playでデモ版を試してみてください。難しくてハマりやすいゲームですので、現場で遊びすぎないようにご注意願います。よろしくお願いいたします！

ねじ巻きナイト

 

 

 

Posted in Uncategorized | Comments Off

Announcing WIND-UP KNIGHT

Posted on August 16, 2011 by Chris
Chris

We are absolutely, positively, fantastically excited to announce Robot Invader’s first game: Wind-up Knight, coming this fall to Android and iOS.

Wind-up Knight

Wind-up Knight is a game designed to test your mettle.

We know you enjoy screwing around on your phone when you have an extra five minutes to kill.  There are plenty of games out there that are slightly less boring than shuffling your feet or trying to read the eight month old sports magazine at your dentist’s office.  Sure, maybe they are not great games, but hey, it beats staring off into space.

Wind-up Knight is different.  It’s a platformer, sort of.  It’s a timing challenge, sort of.  One thing’s for sure, it’s designed to test you.  Test your gaming prowess.  We’re talking design with no remorse, diabolically difficult levels that will keep you up at night.  You know how to play games, you don’t need any hand-holding.  Checkpoints are for wimps.  Power-ups are for wimps.  Wind-up Knight is about being totally awesome in the face of insidiously challenging stages.

Oh, and did we mention that it has some of the best art and graphics that you’ve ever seen on your phone or tablet?  You spent some serious dough on that thing and now it’s time to put that fancy mobile technology to work.

Sure, you could play this game for five minutes at a time.  But we think you’ll play for longer than that, a lot longer; brief respite will come only when your phone’s battery dies.  Because after you school one level, there’s another waiting to up the ante just a little bit more.  Look, the dentist can wait.  This is Serious Business.  This is Wind-up Knight.

Lots more information is coming soon.  Watch this space.  In the meantime, check out the screenshots below.

You're about to get chopped, chicken!

Caution: Low Clearance

Keep that shield up!

Oof!

Through the Fire and the Flames

Wind-up Knight Logo

Posted in wind-up knight | 16 Comments

Personality Goes a Long Way

Posted on August 12, 2011 by Chris
Chris

Robot Invader is housed in a small office in Mountain View, California.  The office is located in one of the many featureless business parks that pepper the Peninsula like the aftermath of a boring meteor storm, a rectangular wedge of gray protruding from the landscape.  Personally, I would have preferred some sort of Victorian mansion, not unlike those that dominate the Resident Evil games, complete with a secret underground laboratory for nefarious experiments.  Alas, ours is a utilitarian structure; the architects of our building chose not waste much space on impressive staircases or hedge mazes.

But had we access to long passages with marble flooring and spot lighting, we would use the location to hang portraits of our heroes.  Such a hall would be adorned with images of Suda51, Jordan Mechner, and Hideo Kojima.  Akira Yamaoka, Eric Chahi, and Daisuke “Pixel” Amaya.  Jason Jones, SWERY, and Team Meat (in their matching sweaters) would all have a place.  While we’re big fans of all sorts of game development studios all over the world, these individuals are particularly influential to us because their personalities shine through the games that they make.  Even when they miss the mark, these developers build games that have charm, vision, and a unique internal consistency.  Their work pulls you off your couch, through your TV, and into their head, much like Raz’ brow doorway in Psychonauts.  If we could, we’d put portraits of these people up to remind us that a big part of artistry is the artist himself.

There are designers throughout the game industry with the capacity to fuse their games with distinct personality, but many of them never get the chance.  Game development is a complicated and risky endeavor; modern game teams are often constructed to mitigate risk by any means necessary.  Rather than give any one person complete creative control, many studios attempt to stabilize development by distributing creative responsibility across many different disciplines.  There are art directors, combat directors, game play programmers, producers, and all sorts of other stakeholders that have a say in the development process.  If a lead designer wants some feature but the lead engineer says it probably costs more than it is worth, the safe thing to do is to kill it.  When polish and schedule are your primary concerns, this is a valid method to ensuring that your studio can maintain quality without veering too far from the original plan.

The problem is, this method produces games that, despite sporting high production values and general slickness, have no personality.  They are the game equivalent of our drab office park, built for maximal efficiency and minimal risk.  Such safe games are not bad games per se, they are just, well, routine.  Don’t rock the boat.  An 80 on Metacritic requires a specific set of high-level features, so let’s make sure we have those first.  A bad game shipped is better than no game shipped.  Let’s cut the hedge maze and use that space for more cubical storage.

Not to say that these studios would be better off throwing caution into the wind and just developing willy-nilly with no process at all, like some hedonistic commune or something.  Putting your faith in one person to direct all aspects of game development is a hard thing to do, both for the folks running game development studios and the rest of the team working under that person.  Design is a creative process, and it can be messy; it’s the polar opposite of the “well oiled production machine” that many studios aspire to become.  And sometimes the results are mixed; Deadly Premonition is one of the most interesting games I’ve played and yet it’s an extremely rough game, production-wise.  I’m a big fan of No More Heroes and Killer7, but Suda51′s earlier Michigan is terrible.  Still, nobody else in the world could have made Killer7.  Deadly Premonition wouldn’t exist without SWERY.  Resting an entire game on the shoulders of one person is dangerous, but when it works out the personal touch of the designer improves the game dramatically.

So taken are we with the power of an individual to completely influence a game design that we’ve attempted to create a process to support it here at Robot Invader.  While all of us have titles related to our discipline and roles, there is one title that trumps us all: the Game Director.  For each game we make we select a single person to act as Director.  This person is the authority of the design, the vision holder, and most importantly, the tie breaker.  He may be an engineer, a level designer, an animator, whatever.  The Game Director may not design the entire game from top to bottom, but he or she has the power to overrule any design decision.  He has the power to change the schedule to accommodate a new idea, or to scrap work that has already been completed.  The Game Director takes the game we are making and fuses it with a consistent, singular vision.  If he wants to make a Victorian mansion instead of an office park, that’s what we’ll make.

With a Game Director in place there are no stalemates.  We trust in our ability to implement just about any idea, and look to the Director for final say in what that idea actually is.  We all participate in design, of course; as a small studio we can actually benefit from hard-core collaboration without veering off the road into the Ravine of Kitchens With Too Many Cooks.  But every concept, every implementation, every UI screen passes through the Director, and is often mutated by him in transit.  The resulting work is still a collaborative effort, but it’s one that has been uniquely shaped and molded by the Director in charge.

We think that the resulting games will feel different and unique.  The Game Director responsibility rotates with each project, so our games should also have their own distinct flavor.  In a market dominated by knock-off products and outright clones, we think that the influence of a singular Game Director will give our titles the creative edge, which will translate directly into sales.  Then we can get that secret laboratory installed.

Posted in game design, game industry, Robot Invader | Comments Off

Never Count Nintendo Out

Posted on August 5, 2011 by Chris
Chris

If there are any universal rules or golden constants by which the game industry is governed, one of them is surely this: never count Nintendo out.  It is not an exaggeration to call the Kyoto firm the world leader in video game production.  They have sold more video game hardware than anybody else (Nintendo dominates the top-selling console list; the DS is the best selling game system of all time), their software is among the best in the industry (Metacritic suggests that the only game superior to Super Mario Galaxy 1 and 2 is GTA 4), and they are one of the few giants in this industry that is willing to take risks.  Nintendo does occasionally stumble; their attempts at digital distribution and online games have, thus far, been infantile compared to Microsoft and even Sony, and they can’t be happy about dropping the price of the 3DS by $80 only a few months after launch.  Their WiiU announcement earlier this year was met with a lot of head scratching, and they recently reported their first quarterly loss since 2004.

But whatever you do, never, ever count Nintendo out.

Nintendo can’t be ignored because they are fundamentally different than the other large game industry companies.  They take risks no other company would take, from the PowerPad to the original GameBoy to the Virtual Boy to the DS, Wii and now WiiU.  Sometimes these experiments fail, but mostly they do not.  When Satoru Iwata announced Nintendogs and Brain Age, two games that resemble nothing else in the industry and are arguably not even games, the incredulity felt by the developer community was palpable.  Many developers had a good chuckle over Nintendo’s utter cluelessness.  Nintendogs and Brain Age went on to sell over 20 million units apiece, putting them both in the top 20 best selling games of all time (a list which, by the way, contains only one non-Nintendo title, GTA: San Andreas).  To put that in perspective, Brain Age has been sold more times since 2006 than The Grapes of Wrath since its first publication in 1937.  Hell, even Brain Age 2 outsold old Steinbeck.

The key difference between Nintendo and Sony or Microsoft is that they build hardware around their games, rather than the other way around.  This approach often results in hardware that is hard to pin down at first.  People had no idea what to do with the DS’ two screens until Nintendo showed them; they had no clue how motion control was going to work until Wii Sports proved it.  Right now I’m sure people are struggling to understand the benefit of the weirdo controller that is the main selling point of the WiiU, but I’m confident that it’s a design that was prompted by the needs of a game.

Nintendo is best when they do this sort of crazy risk-taking.  Sony and Microsoft sure aren’t going to do it.  Nintendo falters when they do not take enough risk; the Nintendo 64 suffered from their decision to stick with cartage-based media, the GameCube was too conservative, and the Virtual Boy was just a bad product.  The problem with the 3DS is that it’s only an incremental improvement over the DS, and so far there hasn’t really been any of that compelling first-party content to back it up.  I think we’ll see what happens to that console this Christmas; all it really takes is a few great games to give the rest of the industry confidence in the platform.

So it is unwise to bet against Nintendo.  This year hasn’t been great for them, but to count them out now would be a very foolish mistake.

That said, here at Robot Invader we are not interested in developing for Nintendo platforms, at least not at the moment.  Nor, for that matter, are we interested in Sony or Microsoft consoles.  We believe that the era of traditional consoles is coming to a close.

I recently wrote an article about how the Sony Ericsson Xperia PLAY has the potential to change the game industry.  It’s a long article, but the point is this: when phones are as fast as consoles, the only reason to keep a console around is for the buttons on the controller.  If phones with buttons like the PLAY succeed, I think the market for consoles will vanish.  It will be increasingly difficult for console manufactures to differentiate themselves from your average smartphone as the quality of smartphones improves, and it’s improving at a breakneck pace.  Nintendo wasn’t even able to be first to market with a 3D screen for the 3DS; an Android phone in Japan with a similar screen shipped a few months before the 3DS launch.  I look at the Playstation Vita and I see hardware that will be in phones extremely soon, perhaps even before the Vita itself launches.  The business model for consoles for the last few decades has been about selling hardware that could be stretched out over a multi-year lifespan, and in the face of rapidly improving phone and tablet technology that model is no longer viable.

We’re in the middle of a transitional moment where the console makers must struggle to remain relevant.  The internet is like a plague of locusts, spreading over traditional business models and eating them alive, and if consoles do not change they too will fall.  Iwata has talked about “preserving the value” of video games (by which he means the existing pricing structure), but I don’t think value is something that any single company is able to control.  Once there’s a market for similar content at much lower cost, traditional $40 – $60 games start to look pretty expensive.  How can any hardware company compete with a platform that does more and has more content for less?

One solution might be to try to adapt existing technologies to weather this storm; I think Microsoft is headed in this direction with their Xbox Live integration in Windows Phone 7.  Another approach might be to stick it out and hope for the best; this seems to be Sony’s idea with the Vita (though, large company as they are, they are also part of the swarm with their various Android devices).

The question in my mind is this: how will Nintendo respond?

Of the three console makers I think the big N is the best positioned to survive this transition.  Their hardware is unique and can succeed without being the most technically brilliant box on the shelf.  Their (game) software is amazing, and their brand power is unbeatable.  But as a company with a lot of pride, I am sure that Nintendo is not content to simply develop for somebody else’s device.  Guessing what Nintendo will do next is always tough, but whatever they decide to do will help shape the future of game development.

Make no mistake: Nintendo isn’t down for the count.  In fact, if there’s one company to keep an eye on as the game industry shifts to new types of platforms, it’s Nintendo.  Developing for consoles doesn’t make any sense for a studio like Robot Invader right now, but who knows which companies will stand out in the post-console world?  I bet the big N does alright.

Posted in game industry, mobile games | 10 Comments