Today our guest blogger is Asaf Barzilay, VP of products from Extreme Reality (www.xtr3d.com). They build the Extreme Motion SDK that enables developers to incorporate motion control into their apps. They’ve also released Pandamania, a dancing game that uses this technology. In this post, Asaf talks about the importance of sound, their experience integrating the Dolby Audio API into their platform, and how easy it was to port this experience to Kindle Fire tablets.

About Extreme Reality

Extreme Reality enables people to interact with computing devices through their body motion, without touch, using only a 2D camera. We are the only company to provide full-body, software-based, motion analysis and control for any computing device or operating system that supports a standard camera. The Extreme Motion SDK enables developers to create a wide range of experiences (applications, games, security solutions and more) that break the physical barriers of current hardware-based technologies.  Our technology works seamlessly with nearly all consumer electronics and on most operating systems: Windows, iOS and Android.

Patented worldwide, Extreme Motion is already in use by game developers for various operating systems and devices, from AAA publishers to indie developers.

Kindle Fire: An Immersive Game Machine

Pandamania is a dance game based on Extreme Motion SDK, which is an image-processing engine that recognizes the player’s skeleton in real time, using the device's integrated camera. The player imitates the panda dance moves, and the more accurate the imitation, the more points earned. At first, Pandamania was intended to be a simple example app to showcase accuracy, durability and potential.

The first thing we noticed about this fun, fast paced dance game is that people instantly connected with the panda; they just loved the animation and effects. The music was appealing but not a major part of the game’s allure.

Prior to Kindle Fire, Pandamania had been ported on most operating systems, such as Windows, iOS and Android. Making the game available on Kindle Fire seemed like the obvious next step as Kindle Fire is one of the 3 leading devices in the tablet category worldwide.

The implementation was simple, since Kindle Fire is an Android based device. Within two days we arranged the overall look and resolution. Then, we looked for a tool that would create a unique advantage for the game on the Amazon Appstore. We discovered Dolby Audio API, a brilliant way to enhance the music aspect of the game.

Enhancing the Sound Factor

The Dolby Audio API for Android provided a significantly noticeable improvement to the background music and game sounds. As the player needs to stand ~6 feet away from the device for the camera to see his body, a good quality sound is a crucial element for a more immersive and fun experience.

We used Unity3d as the development platform for the game, as it is cross platform and easy to work with. Both APIs (Extreme Motion SDK and the Dolby Audio API) are easy to use plugins which do all the heavy-lifting behind the scenes and provide a simple external API for the game developer, allowing him to enable gesture-recognition, and different sound profile enhancements with just a few rows of code, and no need to write any native device code.

"The integration of Dolby Audio API with the Unity3d based game "Pandamania" was simple and intuitive. As this is a dancing game, the quality of the music and sounds was a very important.  By using the Dolby Audio API, the quality of the sound was considerably enhanced, leading to a far better gaming experience"
 - Assaf Lehr, Product Manager, Extreme Reality 

“Extreme Reality’s technology is an impressive offering, bringing full arcade gameplay to the Kindle Fire HD and HDX.  The impressive motion tracking capabilities of Pandamania convert the Kindle Fire HDX into an immersive game machine. By using the Dolby Audio API for Android to drive full, distinct sound to players 6 feet away, Pandamania allows users to concentrate on physical as well as the audio elements of the game.”
Andy Vaughan, Developer Relations Manager, Dolby

Try Extreme Reality and Dolby Audio in Your App

Thanks to Asaf and the team at Extreme Reality. They’re building some fun apps and a platform that enables some really engaging experiences.

Give it a try and see how you could enhance your apps. Let me know if you submit an app using Extreme Reality or Dolby Audio.

You can learn more about the technologies covered in this blog post in the following links:

• Extreme Reality SDK
• Hear the difference Dolby makes
• Dolby Audio SDK
• Amazon Dev Portal and SDK
• PandaMania App

- Paul

@PaulCutsinger

Our guest blogger today is Jason Mark, co-founder of Gravity Switch, a Design and Usability firm that has worked on projects for Disney, The Guggenheim, Dartmouth and Yale. In this post, he demonstrates exactly how important good design and the right screenshots are to your app.

Below are 7 apps. Can you tell which is targeted to women only? For doctors only? The most popular? And can you figure out which was made by a $2B company and which is home grown?

Please spend no more than one minute looking at the screenshots below and see if you can identify where they came from. Try to be aware of WHY you think this way.

Which is:

• For women
• For doctors
• Most popular
• $2B company
• Home grown

How did you do?

Studies have shown that within seven seconds of meeting someone, you’ve made at least TWELVE judgment calls about them. You have formed an impression of how wealthy they are, how educated, how liberal or conservative, how intelligent, how much fun, and more.

All in just seven seconds.

The same thing happens when a prospective client first sees your app icon and your screenshots. When a reviewer posts a screenshot or someone sees your paid advertisement, prospective customers are forming a lasting impression about things you many never have realized or intended. How trustworthy are you? How capable are you? How expensive are you? Are you a good fit for them?

If you haven’t given thought to these things, you’re missing a critical opportunity. If you’re not clear about what story you’re telling, then your audience will make up their own story and it definitely won’t be the one you intend.

The truth is, I don’t know which of these is for women, or which is a $2B company, but when I show this test to people they always have an opinion. And you probably did too. You probably *thought* you knew the answer to at least one or two of those questions.

Which is really what brand is all about, remember: Your brand is not what you say it is. Your brand is what other people say it is.

The right way to approach brand

Asking if you should make your icon green or blue is like asking if you should use a list or an array. It's not a committee decision to be made by amateurs. It’s a decision that should be made by trained experts who understand negative space, typography and color theory. 

While code is about functionality, design is about intent. It’s about what we want people to feel, and what do we want them to do (see: http://www.webdesignerdepot.com/2013/05/design-emotions-usability/ ).

A great designer starts by understanding your intent.  What do you want people to know, feel and do?  Once those things are understood, the details around how you accomplish those goals via colors and fonts is much easier.  You’ve already established the criteria – your intent – so it’s easier to make decisions on the details.

A great designer understands how margins and colors can convey the correct messages. They listen and reflect back where you’re going visually. They won’t ask which concept you like best, they’ll remind you of your goals and ask you which one “works” best, or if you have a really great designer they’ll TELL you which one works best. If you’re “stuck in the how" maybe it’s time you took things up a couple of levels.

You can find Jason on the following sites.

http://GravitySwitch.com

http://JasonOnDesign.com

Today, we’ll be talking to Executive Producer Starr Long about crowd funding, crowd sourcing, designing for mobile and his latest game, Shroud of the Avatar. Are crowd funding and crowd sourcing really that effective and what’s the catch? In this article, Starr elaborates on the different criteria and the processes that he frequently uses, in order to make crowd sourcing successful.

Starr Long has been making videogames for twenty years. Starr started his career in 1992 with Richard Garriott at the legendary studio Origin Systems, where he was the Director of Ultima Online, the longest running MMO in history. In 2010, Ultima Online was inducted into the Online Game Developers Conference Hall of Fame, the first MMO to be so honored. In 2000 Starr co-founded Destination Games with the Garriott brothers, and later that year it was acquired by NCsoft. In 2008 Starr was named one of the Top 20 Most Influential People in the Massively Multiplayer Online Industry by Beckett Massive Online Gamer Magazine. In 2009 he joined The Walt Disney Company as an Executive Producer, where he produced the Disney Parent App for Facebook, 8 learning mini-games in Club Penguin, Club Penguin mobile 1.0, 5 Educational Game apps for iOS, and the Disney Connected Learning Platform. He is now Executive Producer on the crowd funded and crowd sourced RPG Shroud of the Avatar at Portalarium. He also has his own video game consulting company: Stellar Effect.

Exploring Shroud of the Avatar

Starr thanks for taking the time to talk with us. The Amazon Developer blog is focused on helping mobile app developers take an idea and turn it into a product that people love. To that end we’re always trying to build services that help them, share best practices that we’ve seen or share insights from the leaders in the industry.

I see that you’re working on a new MMO – The Shroud of the Avatar. You have built several major MMOs now and I’m curious to know where you’re taking this one.

Shroud of the Avatar: Forsaken Virtues is a computer role playing game being created by Lord British (aka Richard Garriott), creator of the genre defining Ultima series of computer games, me (Starr Long), director of Ultima Online, and Tracy Hickman, author of the Dragonlance series. It combines rich story, like those of the single player Ultimas, with deep and varied multiplayer experiences, like Ultima Online.

Players will adventure in an interactive world where their choices have consequences, ethical paradoxes give them pause, and they play a vital part in weaving their own story into the immersive world and lore surrounding them. Play options will include solo, friends only, or open multiplayer via the Selective Multiplayer system. Players can specialize in a wide range of combat and non-combat skills, provided by a robust, classless skill system, and full-featured crafting and housing mechanics.

Shroud is crowd funded and that allows the developers to work directly for, and with, the player, versus working for a large publishing corporation. Shroud is also crowd sourced so players can submit Unity compatible content (art, sfx, music, world building, etc). Once submitted content is approved the submitter can choose to be compensated in real or virtual currency. We also do crowd sharing where we do things like improve content we buy from places like the Unity Asset store and then give the improved versions back to the developer for free, we just ask that them say “As seen in Shroud…”.

Built using the Unity Game Engine, Shroud of the Avatar will support Win/Mac/Linux. Backers have early access to the game once per month currently.

Finding the Right Balance in Games

You’ve done some interesting things with the classless system and the variety of magic in the game. How do you get the right speed of progression and the right balance of power?  What do you do before you launch vs after you launch?

Our goal with a classless system was to provide the player more choice about how they could play the game and not just limit that to an initial choice but a constantly evolving choice. It was a decision to let the player decide how they wanted to play each and every play session. Today I might want to play a swordsman while tomorrow I might want to play a wizard and next week I might want to play a wizard swordsman hybrid! The old adage of “easy to learn, difficult to master” is still the best strategy for balancing progression. The player should start off feeling powerful but not be overburdened with too many options (number of spells, stats, etc.). After playing for some time the player should be increasingly challenged while at the same time they should be presented with an ever widening number of options. Once the players start using your game you have to be prepared to tune that balance because however balanced it was while you played it internally it rarely stands up to actual users input. It is the Art of War paraphrase…“No plan survives contact with the enemy.”

Starr Long’s Secret behind Crowd Sourcing

You’ve raised about $4 Million through crowd funding ($1.9 Million with Kickstarter, $2M on the website). That’s a different way to raise funds and there are a lot of indie studios that would like to break through that way. You raised a lot of money in a few short days, and then even more over the following year. What has been your marketing and sales strategy? Do you believe that you need to “bring your own crowd” to Kickstarter? What’s the one best thing you did with your Kickstarter and what’s one thing you’d never do again? 

We had a distinct advantage with our crowd funding because as you noted we were able to “bring our own crowd” because Richard Garriott is known for creating some of the very first computer RPGs ever and Ultima Online was the first major commercial MMO ever (and in fact coined terms like MMO, MMORPG, shards, rares, etc.). This created a built-in fan base who were ready to support anything Richard did that hearkened to those ground breaking Ultima titles. What is important to note is that they were only willing to do that on the promise that he was doing what he was known for, specifically not doing something different. So the double edged sword there with a built-in crowd is they want you to build something like you have done before. They will not support you if you try to do something very different. So our strategy started fairly simple: “Make what they want.” Kickstarter provides a great framework to get things started with a tier structure, communication tools, etc. From there we used that structure to provide rewards to backers that were themed to the product and capitalized on some of our unique features and strategy. For instance because we are doing crowd sourcing we created a level called Developer where that level got assets from the game for free that they could use to either make their own games or make content for us that we would then pay them for. The biggest tips for doing a Kickstarter are:

• Have a very clear message about what you are making exactly (gameplay description, platform(s), visual style, etc.)
• Have a great video demo if possible. Using off the shelf tools like Unity are the best way to get this done quickly
• Have lots of pretty art
• Don’t over promise what you can make with the amount of funds you are asking for or make sure potential backers that Kickstarter will only be one source of funding
• Leverage social media constantly
• Have new content and new information at least every few days that you can release to keep interest going (interviews with the team, concept art, videos, etc.)

Once we finished the Kickstarter and transitioned to fundraising via our own website our strategy became “develop in the open.” We have done that through the following ways:

·         Daily Standup Update: We actually post the notes from our daily standups to our forums. So every day our backers can see exactly what each person on the team is doing.

·         Weekly Updates that include the following:

o    Art Assets representing the rewards promised to backers. This means building the game model and putting it in the game. This content includes player houses, pets, clothes, tools, etc.

o    Content for our Add-On Store: a la carte unique purchases outside of the regular pledge structure (player houses, pets, tools, property deeds, etc.)

o    Events: Upcoming Calendar plus retrospectives of past events (pics, descriptions, etc.)

o    General Status updates

• Release Schedule: We publicly broadcast our monthly releases including details about what each month’s release will contain. These schedules detail out one quarter at a time (3 months).
• Monthly Early Access Releases: Each month we allow our backers to play the game over a long weekend (Thursday through Monday). We then take their feedback and fold that into our plans for the following releases
• Developer Hangouts: We do semi-regular Google video hangouts that our backers can watch. During those hangouts we generally answer questions that are being submitted in real time
• Forums & Internet Relay Chat (IRC): We have forums and IRC where our backers can interact with each other and the developers. Every single day at least one of our team is either on the forums or in chat talking to the players answering questions or posting updates about schedule, game designs, etc.

A Look behind the Producer

I’d like to better understand your perspective as a producer. When you’re looking at a game for the first time, what do you think about?

I start by asking myself (and the team) a bunch of questions:

• Can this be done at all? Is this project even feasible? Many times (especially with either inexperienced teams or naïve executives) games are way over scoped beyond what is actually possible.
• If the game can be done can it be done either quickly or affordably? A game that either takes too long or costs too much to make causes the cost of success to be too high. This can doom a project before it even reaches customers.
• Will this game be fun? This should be super obvious but many times the focus will be too much on monetization or a cool license property and this gets lost in the shuffle.
• Do I know enough about this type of game to make it successful? If I don’t can I learn about it fast enough? Am I passionate about this game? Often producers will try to make a game they either aren’t familiar with or passionate about. When that happens the team and the product invariably suffer for it.

The Tradeoff when Building a Game

Let’s talk about the process of building a game. What does your product cycle look like? How do you get to something that’s fun? When building games there are a ton of trade-offs - could you give an example of a trade-off that you had to make and how you were still able to make a great experience?

On our current project we started by creating an overall plan for the entire project cycle that we painted in very broad strokes. From there we created a 3-4 month plan that outlines what we want to build for that quarter. We then divide that into monthly releases so that puts us on a 4-5 week cycle. The first 2-3 weeks are about putting in as much content as we can and then the final weeks are all about polish and testing. Because each of those releases go directly to our players (even though we are still in pre-alpha) we get immediate feedback on what is fun and what isn’t. We love this structure because it really keeps us honest about what is good or not. It is easy to fall in love with your own ideas and lose some objectivity. After each cycle we make sure to modify the next cycle’s deliverables so we can react to feedback from the users. There are always tradeoffs that have to be made but as long as the tradeoff doesn’t sacrifice the overall vision of the game or reduce the fun factor then they don’t have to be damaging to the product.

Top 3 Tips for Developers

You’re one of the rare people that have done a lot with both MMOs and with mobile games. What are your top 3 tips for mobile developers?

1. Size: Make sure your title’s initial download can be done relatively quickly over 3G. From there if you stream content to increase size remember that when you want to update the app you will lose that ability and if you make it too big there might not be room on the device to download the update
2. Business: Because we have so many tools now that allow us to make games that means anyone can make games (especially on mobile). This has resulted in an explosion of content and it is increasingly difficult to get recognized. This means it is no longer enough to know how to make good content…you have to know how to make money, too. This means you need to know what are the best monetization models for your product, how you can manage costs to acquire customers, etc.
3. Community: Figure out a way that your project can build and maintain a community rather than just be a standalone product.

Thank you Starr, we appreciate the time and it’s exciting to hear your perspective.

Readers, if you would like to help make Shroud of the Avatar through funding and/or making content (art, music, sfx, etc.)  or in play testing in the alphas, then please visit their website, www.ShroudOfTheAvatar.com for more information.

Most people prefer to use apps in their own language, but many developers consider app localization a dark art.  Where do you start?  How will your code change?  Who will translate?  If you’ve never localized an app before, the process can be intimidating.  It’s a critical first step, though, if you want to reach a worldwide audience.

Here guest blogger Jean-Claude Cottier demystifies app localization.  A veteran game developer and architect, Jean-Claude has spent 18 years developing 3D technology for AAA titles and mobile apps.  He has released many apps in the global marketplace through Ovogame, an indie studio he founded.  In this practical guide, Jean-Claude explains how to plan for localization, track and organize what will change, support different languages in code, and find translators to localize your assets.

Localization: a Winning Solution

Thanks to digital distribution, we now live in a global market and a lot of our potential customers simply don’t speak English. Having your applications localized will increase their global reach and will open new opportunities for your business. You’ll be more likely to find local partners and distributors interested in your products. Supporting more than one language isn’t a complex task once you’ve setup everything and streamlined your development process. Most of Ovogame’s applications are localized in many languages (English, French, German, Spanish, Italian, Russian, Japanese, etc.). It’s well worth it for us as we generate about 45% of our income from non-English-speaking territories. In this article, we’ll give you directions and tips about the technical side of localization. At Ovogame, we are using our own multiplatform engine (Fire OS, Android, iOS, Windows, OSX, BB10). As it is possible to use these techniques on all systems, we’ll stay as platform-neutral as possible.

No Text in Your Code

The best way to handle localization is to think about it from the start of your project. You shouldn’t treat your primary language (English) differently than the other languages supported by your apps. English may be set by default, but that should be the only difference with the other languages.

The golden rule is to NEVER have any text hard-coded inside your source code. Instead, it should all be stored in an external file (like any other data). Supporting different languages means creating different files per language and loading the correct one.

As you can’t have any actual text in your code, the best way is to handle them with keywords. For example, if you want to display a greeting message like, “Hello world,” you could use the keyword GREETING instead. Your code could look like this:

String message = Translate(“GREETING”);

	DisplayText(message);

The function Translate returns the correct sentence to display. If the application language is set to English, it will return, “Hello world,” but if it’s in French, “Salut monde.” The function Translate needs a simple list of keywords linked to their localized sentence. It will scan this list and once the right keyword is reached, it returns the corresponding text. In practice, it’s wise to cache this string; there is no point to call Translate every frame.

Using keywords is very nice because you can still understand their meaning when reading your code. As they are proper strings, you can build some of them dynamically (mainly when they’re indexed: RATING_0, RATING_1 …) to simplify your code.

Using Excel or Open Office

We like to use Excel’s files to store all our localizations and there are many good reasons for this choice. Everyone can view and edit these files, so the persons localizing or proofreading your text will be comfortable with this format. You can add more information (extra columns and lines) and use different colors to help them. It’s also easy to provide links to images (often better than a long speech). Basically, Excel is a very practical tool for creating and managing all your localization.

The other great advantage is that your database is automatically created. The relationship between your keywords and their localizations is obvious: each line contains a keyword and its corresponding translation (stored in two consecutive cells). We need a way to extract this information so you can use it in your application. Excel’s files are complex and coding a function to read such a file format would be a lot of work. Thankfully, we don’t have to do this because it’s easy to convert them into a basic ASCII text file. If you are serious about localization, you should handle text files supporting two bytes per character. If you want to localize in Japanese or Chinese, you must support this anyway. It isn’t mandatory, but it would be a shame to not support it. Simply store your characters in 16 bits instead of 8 bits.

Before converting your Excel file, you might want to do a bit of cleaning first. You should remove all unwanted information and just keep the first two columns (keywords and localizations).

If you are using Microsoft Excel to convert your file, simply save it as a Unicode text (*.txt) file. This new file contains only ASCII characters stored on 16 bits. As the following picture shows, it’s a very simple format. You can use it directly in your application.

Remember that every ASCII character in that file is stored using two bytes (16 bits). The file starts with a magic number (one character: ASCII value 65279) that you can skip. A TAB character (ASCII value 9) is used to separate the keywords from their localization. A carriage return (ASCII value 13 and 10) is used to separate the different lines. As you can see, it isn’t difficult to code a little function to load this file into memory and create a linked list or lookup table of these keyword/localization pairs.

If you are using Open Office instead of Microsoft Excel, you can save your files as Text CSV (.csv) (*.csv) using UNICODE for the ‘character set’ option. The file format isn’t the same as the previous one, but you won’t have difficulties figuring out the differences by yourself.

Selecting the Correct Language

At this stage, you have a specific text file for each of your supported languages. You just need to load the correct one. A nice little feature is to automatically select the language used by the device. So, if the device is set to French, your application could automatically start in French. With most platforms, it’s very simple to find out the language set on your device. For example, with Android, you can simply call a function from your Activity class:

	Configuration config = getApplicationContext().getResources().getConfiguration();

	String lang = config.locale.getLanguage();     

The function getLanguage returns strings like en (English), fr (French), de (German). You should check the value of lang and if you don’t support that language, set it back to your default one (en in our case as we want English to be default). This string will be used to identify the current language during your application life cycle, so keep it safe. You can use these abbreviations (en, fr, de…) to setup a simple naming convention for your files.

With this convention, it’s simple to know which file to load. Also, you can find out dynamically if a language is supported by your application: simply check if the corresponding language file exists. This way, you can add new languages without changing a line of your code. It’s always a good idea to make your code as generic as possible and let the assets handle themselves (data-driven instead of code-driven).

If you are developing your applications for different platforms (iOS, OS X, Windows, etc.), you’ll find similar functions as getLanguage on all systems.

Localizing Other Assets

Sometimes, you need to localize more than just text. You might have textures containing some writing. You should use the same naming convention as before.

To simplify your code, you can dynamically create the names of your localized textures using a simple function:

	String name = LocalizeName("gameover", "png");

The function LocalizeName concatenates the current language and the extension (.png in this example). So, if the language is Spanish (es), the name returned will be gameover_es.png.

You might have some assets that need to be localized in some languages but not for all of them. For example, in France, we are comfortable using the Anglicism ‘Game Over’ (translating it would actually sound weird). It would be a shame to duplicate the default asset just to create a fake localized one (gameover_fr.png). Instead, the function LocalizeName could test if the file exists (it’ll need the complete path for that). If the file doesn’t exist, the function should return the name of the default file. For our example, in French, LocalizeName would return gameover_en.png.

Finding the Right People

You should work with native speakers for all your localization. Don’t ever use automatic translation tools (online software) like Babel Fish or Google Translate. The result is so bad that you are better keeping your application in English.

There are many online services where you can hire translators, like dystranslations.com and tethras.com. We haven’t used them, but they were recommended by fellow game developers.

We did find an alternative way to get very motivated translators. We ask our fans if they can do it. These people enjoy our apps and know them almost as well as we do. We develop a much closer relationship with these users than we would ever get from hiring someone via an online service. They are very keen on making the best localization. We send them beta builds so they can test if their localization is perfect. It really feels like they are part of the team.

Final Tips

Give your translators as much detail about your application as possible. If they can test a proper version (like our fans do), it is even better. The more they know about your application, the better they’ll localize it.

Be careful with the size of your UI (buttons, message box, etc.). Most English words are small compared to other languages. Usually, German words are very long and it might be wise to check if they fit in your UI as early as possible. It’s also useful to have a way to auto-scale your text, so you can be certain it will always fit inside a specific area (like a button).

Don’t hesitate to add formatting information inside your text. For example, “Chapter [NUM]” contains the tag [NUM]. We will substitute the proper index in code (Chapter 1, Chapter 2…). It’s very useful because for some languages, the formatting is completely different (in Chinese, it’s in the middle 第[NUM]章). Using this solution will remove most of the formatting problems.

There are many other aspects to be considered when localizing (fonts, testing, etc.), but that would be too long for this article. Hopefully, this quick overview has convinced you that the technical side of localization is accessible to anyone. It’s a simple way to increase the visibility of your application; you should do it.