Derek Gebhard, Solutions Architect for Amazon, is our guest blogger for this post.
One of the things you will spend time on when building a Kindle Fire app is testing and debugging. Using a Kindle Fire emulator is the recommended way to test and debug your mobile apps if you do not have the device available. This post will cover tips on increasing the performance of the KindleFire emulators, including the newly released KindleFire HD 8.9” emulator, but will also apply to most other Android emulators.
For Ice Cream Sandwich-based Kindle Fire emulators(Android SDK 4.0.3, API level 15) you can enableGPU emulation to significantly improve the performance. One thing to be aware of: GPU emulation is currently an experimental feature in the Android tools suite, and may not work on all host hardware configurations or operating systems. If you experience issues, you may need to disable this functionality.
To enable GPU emulation, launch the Android Virtual Device Manager. This can be done by running “android avd” or clicking the Android Virtual Device Manager icon in Eclipse.
For existing emulators:
When creating a newemulator:
Image 1:Changing the GPU emulation property
To showcase the effect of GPU emulation property, there are two screenshots below. These GPU measurements were taken on a Windows desktop,using the Kindle Fire HD 7” emulator. This test included starting the emulator,running SDK Tester, and accessing the Kindle Fire settings. As you can see, GPU emulation must be enabled in order for the emulator to leverage the GPU’s dedicated memory.
Image 2:GPU emulation set to “no”
Image 3:GPU emulation set to “yes”
There are also a few other things that can help when running apps on the Kindle Fire emulators. Below is a list of the other ways we can increase performance and save time:
We’ve recently updated our marketing resources available for mobile app developers, providing two new badge styles to promote your app’s availability on Amazon. The badges are available in three colors (black, grey, and white), and are localized for all of the countries where our store is currently available. Please use these badges wherever you promote your app’s availability on other app stores.
In addition to the badges, we’ve posted layered PSD images of Kindle Fire tablets for your use in line with the KindleTrademark Guidelines. You can layer in your app’s screenshots to showcase your app on a Kindle Fire tablet.
To link to your app on the web using the badges, use this link structure:
http://www.amazon.com/gp/product/ASIN number/ref=mas_pm_app_name
Replace “ASIN number” with your app’s ASIN (Amazon Standard Item Number). The ASIN is available on your product page on Amazon.com. Replace “app_name” with your app’s name (and be sure to use an underscore instead of a space). Linking on to your app on the web is currently only available for the US store. Instructions on linking will be available for international stores when their web stores launch.
More details on these resources, including guidelines for use, are available within the Trademark Guidelines on the Mobile App Distribution Portal.
E-dan Bloch, Solutions Architect for Amazon, is our guest blogger for this post.
The new Kindle Fire HD 7” and 8.9” tablets introduce high definition screens that provide a great opportunity for mobile app developers to deliver an improved user interface, high resolution images,and apps that take advantage of more “screen real estate”. While native layouts make use of these higher resolutions by default, layouts within WebViews may require some HTML adjustments to be made.
WebView control may display pages that are logically longer and wider than the physical screen size, allowing users to pinch to zoom and scroll through a web page. To accommodate the difference in size, the WebView control takes two properties into consideration: the native view size (the size of the control itself) and the logical view port size (the size of the content currently visible within the control).
The viewport, with respect to the WebView control, is the area of the page currently visible to the user. The native Android layout engine controls the view size, and the HTML page determines the logical viewport size. For example, when the WebView displays a page that is zoomed in, the logical viewport size is smaller than the actual size of the control (hence the zooming). This can lead to seemingly unexpected behavior of web apps, especially when JavaScript is used to create the page’s layout.
There are two key properties that mobile app developers leveraging WebViews should be familiar with: the viewport metadata property and the android:theme property.
The “viewport” metadata property is represented as <meta name="viewport" content="…" />. Adding this entry to the <head> section of your HTML pages will allow you to better control how your pages are displayed on users’ devices. Control this property by setting its content attribute with the following descriptors:
height = [pixel_value | device-height],
width = [pixel_value | device-width ],
initial-scale = float_value,
maximum-scale = float_value,
minimum-scale = float_value,
user-scalable = [yes | no],
target-densitydpi =
[dpi_value | device-dpi | high-dpi | medium-dpi | low-dpi]
By default, the target-densitydpi descriptor assumes the medium-dpi value. For Kindle Fire HD devices, you should change this setting to high-dpi so that your content will display properly. Alternatively, you can use the device-dpivalue and have the WebView control determine the density dynamically according to the device being used. This automatic setting will cause the viewport to scale differently for each device’s pixel density.
To use this automatic setting, add the following line to the <head> section of the HTML page being viewed:
<meta name="viewport" content="target-densitydpi = device-dpi" />
In instances where a web page uses a fixed-size layout, or a purely relative (fluid) layout, we may also want to have the width and/or height descriptors set to device-width or device-height (respectively). Setting these values will set the logical size of the WebView to match that of the device being used. So the viewport property would look like this:
<meta name="viewport" content="target-densitydpi = device-dpi, width = device-width" />
Combined with the auto-density selection we get:
<meta name="viewport" content=" target-densitydpi = device-dpi, target-densitydpi = device-dpi, width = device-width" />
To demonstrate the effect of the latter tag, here is a side-by-side comparison of a simple web page displaying different size values with and without it:
Notice how, in the example on the right, the ViewPort size matches the WebView size. The difference, in both examples, between the screen size and the WebView size are due to the status (above) and menu (below) bars.
The second property is the android:theme property. Although it relates to the Android activity itself, and not just the WebView control, it can impact the screen real estate that your apps use. A good example is full-screen browsing. The Kindle Fire’s soft-key menu provides developers with power over the amount of screen their app can use by allowing them to hide both the title bar and the menu buttons. To use this feature, you can add the android:theme attribute to the <application> or <activity> elements in your AndroidManifest.xml manifest file and set the appropriate theme. For example, you can use@android:style/Theme.NoTitleBar to hide the top title bar, or
@android:style/Theme.NoTitleBar.Fullscreen to hide both the title bar and the soft-key menu bar. For example, if you want your entire app to operate in full-screen, your AndroidManifest.xml file might look like this:
<application
android:icon="@drawable/icon"
android:label="@string/app_name"
android:theme="@android:style/Theme.NoTitleBar.Fullscreen">…</application>
This last value gives you the most screen area to work with. However, this option should be used with care as it affects the user experience by minimizing standard controls such as the clock and battery indicator, as well as the “back”, “search”, and “home” buttons.
To demonstrate, here is a side-by-side comparison of the default theme versus the Fullscreen theme:
Notice how, in the example on the right, all buttons are hidden until the user taps on the pull-up button seen on the bottom.
For more information, please also see the User Experience Guidelines.
One of the great new features that the Kindle Fire HD offers is a set of dual-driver stereo speakers on both sides of the display. This sound setup opens new possibilities to game and app developers by allowing for a more comprehensive and immersive sound experience.With minor adjustments, any app can leverage the stereo speakers and enhance the user experience. By default, Kindle Fire HD uses both speakers to output balanced sound (left speaker = right speaker). By changing the volume on either side, we can achieve an effect of localized sound. As a simple example, we can consider a conga drum app. The app will have two conga drums displayed, one on the left and one on the right. Tapping on the left conga produces sound only in the left speaker and similarly, tapping on the right drum produces sound only in the right speaker.
The way to control the volume on the speakers depends on the method being used to actually play sound. For the purpose of this post, we will assume that the MediaPlayer class is used, but most other methods should be similar if not identical in nature. The following code will create a MediaPlayer instance that will play audio only through the left speaker:
import android.media.MediaPlayer;
…
float leftVolume = 1.0f;
float rightVolume = 0.0f;
MediaPlayer mPlayer = MediaPlayer.create(…);
if (nPlayer == null) {
mPlayer.setVolume(leftVolume,rightVolume);
}
The leftVolume and rightVolume parameters can be set toany value between 0.0 (“off”) and 1.0 (“full volume”). The volume level is relative to the master volume of the device so changing these values is basically just changing the balance between the stereo channels or, in this case, the two speakers.
Using the SoundPool class is not all that different:
import android.media.SoundPool;
…
float leftVolume = 1.0f;
float rightVolume = 0.0f;
SoundPool sPool = new SoundPool(…);
// Load an asset into the pool
int streamId = sPool.load(…);
sPool.play(streamId,leftVolume, rightVolume ,0, 0, 1.0);
Zillow is a home and real estate marketplace dedicated to helping homeowners, home buyers, sellers, renters, real estate agents, mortgage professionals, landlords, and property managers find and share vital information about homes, real estate and mortgages. We recently had a chance to speak with Steve Perrin, Mobile Development Manager at Zillow, and Leo Liang, Sr. Software Development Engineer at Zillow, to get their feedback on working with Amazon to power their marketplace via Amazon Web Services and to distribute their apps via Kindle Fire tablets and the Amazon Apps mobile client.
With Amazon Web Services, Zillow uses a combination of SQS (SimpleQueue Service) for processing, S3 for storage, Elasticache for scalability, and ELB for server load balancing. In addition, they use EC2 as an on-demand service whenever they update their Zestimate algorithm. “We love the simple API and comprehensive set of solutions in the cloud stack that AWS provides,helping us get things done quickly at every product stage,” Leo said.
When it came time for Zillow to choose between service providers, they chose AWS for their reliability, flexibility and support. Leo noted that “in addition to not being limited to any particular development platform, AWS provides EC2 instances on-demand, and a comprehensive cloud stack that helps get things done quickly and with high quality, while keeping future scalability in mind.”
When Amazon launched the Kindle Fire, the Zillow team was quick to optimize their Android app with the new tablet. “It was important to Zillow that our apps worked well on the Kindle Fire since it was a competitive addition to the tablet landscape.” Mobile devices make up 40% of Zillow’s traffic, which grows to more than 50% on weekends. The team followed up by working closely with Amazon in preparation for the launch of the new Kindle Fire and Kindle Fire HD this fall. Steve was able to implement the new AmazonMaps API quickly, thanks to a compatible API that fully met their needs.
Optimizing an Android application for a tablet is more than just stretching the UI, and Zillow has defined a layout that works well on the Kindle Fire, Kindle Fire HD and the new Kindle Fire HD 8.9” device. As well as Maps, their app leverages Location Services and has enhanced performance for the PowerVR GPU. Says Steve, “The best thing about working with Amazon’s Mobile App Distribution Program is the great support that we receive from Amazon’s team. They’ve been extremely helpful in getting our apps optimized for the Kindle Fire HD. In addition, their new Maps API was easy to integrate, and made it easy for us to give our users a great map experience on Kindle Fire HD.”
Zillow Real Estate is available on Kindle Fire tablets and the Amazon Apps mobile client.
For those of you who attended AWS re: Invent or AnDevCon, it was great meeting you. It’s always a pleasure to be able to meet with our developers face to face. For those who were unable to attend, we’ve pulled together some of the highlights from our participation at both AWS re: Invent and AnDevCon.
Although we’ve assembled this recap here, we were live-tweeting highlights during both of the conferences. If you don’t already, follow us on Twitter (@AmazonAppDev) to receive those highlights during future conferences, as well as other short bursts of information of interest to mobile app developers.
In addition to videos of the keynotesessions during AWS re: Invent, our friends at Amazon Web Services have posted videos of the mobile app-focused sessions:
Copies of the presentations are also available on the AWS Slideshare.
At AnDevCon, Ethan Evans, Director of App Developer Services at Amazon, presented the keynote session on best practices for developing mobile apps using both native code and HTML5. Ethan discussed the success that his team has had developing the Amazon Appstore app using native code, connected to HTML5 using a JavaScript bridge,allowing them to roll out updates to the store more efficiently.
We are heading to many more developer conferences soon. See you in 2013!
Amazon Device Messaging is a new service that lets you send push notifications from the cloud to Kindle Fire devices that run your app. Amazon Device Messaging makes it easy for you to drive engagement with your customers and to create new opportunities for monetization and use.
With Amazon Device Messaging, you can send messages to individual users on specific devices. You can update customers on game play, invite them to purchase a related product, or send other messages that create a richer app experience.
The Amazon Device Messaging service is now available to developers who are accepted into our beta program. Apply here. We’ve created the Amazon Device Messaging API to be not only easy to use, but also:
Kindle developers have already started to express their interest in Amazon Device Messaging. “We are very excited that Amazon is extending the Kindle platform capabilities with push messaging and look forward to building on top of it for a richer, more engaged application experience,” notes Scott Kveton, CEO of Urban Airship.
Amazon Device Messaging is now available as a limited-access beta and is supported on Kindle Fire HD and Kindle Fire (2nd Generation) devices. Applytoday to get access through the Amazon Mobile App Distribution Portal,and see just how easy it is to stay in touch.
One of the early interactions that customers have with an app,even before purchase or download, is through its metadata: icons, screenshots,videos, and related imagery. Well-designed and high-quality visual assets have a positive impact and lead to a better customer experience. For you, that means greater customer acquisition and superior brand perception for your apps.
In our earlier blog post “SubmittingVisual Assets”, highlights the following points to consider while designing these assets:
In the same post, we provide steps to submit visual assets on the Amazon Mobile App Distribution Portal. This blog post provides further details that you should consider while submitting visual assets to ensure high quality.
There are multiple placements possible on Kindle Fire tablets and Amazon.com for images submitted through the Distribution Portal. Some images might be re-sized to fit the placement. To ensure high quality after resizing or prevent resizing for certain placements, submit images with following resolutions:
Here are some of the prominent placements for the visual assets on Kindle Fire and Amazon.com website:
An image might require up-scaling before submission. Quality of image after up-scale depends upon the interpolation method used. A few common interpolation techniques supported by imaging software are cubic, lanczos2 and liner. Cubic interpolation delivers the best quality but it is a time consuming operation. Lanczos3 method also delivers excellent results however it is not supported by all imaging software. Linear interpolation takes less time but at the cost of quality.Up-scaling is quickest if no interpolation method is used but delivers low quality output. Therefore we recommend using cubic interpolation method for highest quality scaled images.
Use sharpening to improve the quality of the image. Sharpening is a common feature in most image editing software.
Images uploaded on the distribution portal must be in PNG format. This format allows alpha-transparency that enables dropping shadows for various backgrounds.
Promotional videos submitted with other the visual assets are placed with the screenshots on Kindle Fire tablets and on Amazon.com. The best format for video is mpeg4 (H.264) 1080p. We will automatically downscale the video as needed. Several video editing tools are available for video editing on PC & Macs. On-device screen recording is not available on Kindle Fire tablets.
Today, we announced a new,free A/B Testing service for developers like you, who distribute their app or game through the Amazon Mobile App Distribution Program. This service was built to help you improve your customer retention and monetization through in-app experimentation. Amazon’s A/B Testing service is easy to integrate, simple to control, and is built on Amazon Web Services. This means you can be up and running in less than a day and trust that the service will scale with your app.
When we set out to buil dan A/B Testing service, we met with developers to learn what they needed most.We discovered that it was something very simple--to better understand customer needs and to be able to react to those needs quickly. Our A/B Testing service provides simple to integrate tools that enable you to continually create and run experiments, view how customers are reacting to these experiments, and release new, improved experiences without writing any more code or resubmitting your game or app.
The service’s benefits include:
Free to Use: our A/B Testing service is free to use for developers distributing their app or game through the Amazon Mobile App Distribution Program.
Easy Integration: early partners report that the SDK can be integrated and ready for release in less than a day.
Precise Control: set up experiments and monitor results from the familiar Mobile App Distribution Portal.
Painless Deployment: server-side logic allows you to quickly iterate tests and deploy new, improved experiences to customers without having to resubmit your APK or write any additional client-side code.
Effortless Scaling: built on Amazon Web Services, Amazon’s A/B Testing service lets you focus on building great games and apps instead of architecting scalable back-end services.
With Amazon’s A/B Testing service you no longer need to guess when deciding between different customer experiences.You can evaluate which in-game promotion drives better performance, which button design maximizes customer click-through, or which tutorial offers the highest conversion rate.
The Amazon A/B Testing service is currently available in beta. Learn more and get started with A/B Testing here.
Amazon recently introduced two new HD tablets: the Kindle Fire HD 7” and Kindle Fire HD 8.9". While most developers have had few problems transitioning apps from phone layouts and hardware to run well on the Kindle Fire HD tablets, customer feedback, as well as our own Quality Assurance reviews, has identified a few development tips you can use to deliver a great experience on the new HD tablets.
Customers love the larger format of the tablets. That's why it's important to make sure your app is designed for high-density screens with correctly sized images, and fill the screen size by using appropriate layouts(e.g., res/layout-sw800dpfor the Kindle Fire HD 8.9" and res/layout-sw533dp for the Kindle Fire HD resource directories). Appropriate use of the screen is especially important for apps that want to use the HD designation.Make sure to check out the documentation we provide on optimizing for high-density screens on the Mobile App Distribution Portal as well as onthe blog.
For your apps to support multiple devices, you will want to make sure to display the right assets in the right place. If your app will be downloading additional resources based on the platform, it's important to make sure you are selecting the correct assets for the device. The best way to future-proof your app is usually to use feature detection or resolution detection, but as a fallback option you can use device user-agent or Build.MODEL strings. If you are relying on device strings, we recommend managing that list on a server, so you can easily add new devices or update existing ones. If instead you hard-code the strings, you'll have to deploy a new .apk each time you wish to update or add a new string. You can find the Kindle Fire android.os.Build.MODELand user-agent strings in our Device and Feature Specifications.
Every Android tablet defines top of the screen differently.On the Kindle Fire HD tablets, the default rotation is in landscape mode with the camera at the top (ROTATION_270),whereas landscape might be the opposite (ROTATION_90) for other devices. If your app is designed to work in landscape mode, then we recommend that you use sensor-based orientation rather than relying upon the rotation value, e.g. setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR_LANDSCAPE);
With the larger screen sizes of HD devices, efficient memory management becomes even more crucial for your app, as more memory is required for displaying larger bitmaps.
In your app, ActivityManager.GetMemoryClass();returns the heap size and will help you understand how aggressive you need tobe in memory management. The default application heap size is 48MB for KindleFire HD 7” and 64MB for Kindle Fire HD 8.9”. If your app attempts to exceed thedefault heap size, you will receive an OutOfMemoryException.
The best way to understand how memory usage is affectingyour app’s performance is by using Logcat, via DDMS or the command line, to examinethe logs for Garbage Collection events and analyzing heap usage and memoryallocation. The Dalvik Garbage Collection logging statement contains a lot ofinformation that will help determine if your app has potential problems such ashigh memory usage or potential memoryleaks. For an overview of how to use DDMS and MAT to analyze memory issues,we recommend reading MemoryAnalysis for Android Applications.
GC_CONCURRENTfreed 380K, 17% free 16204K/19335K, paused 1ms+2ms
The first statement describes why the Garbage Collection actionwas performed. It can have the following values:
It is normal to see a healthy amount of GC_CONCURRENT logstatements as your app is running. However, watch for large amounts ofGC_CONCURRENT calls in areas where response time is critical. A consistentGC_FOR_MALLOC could indicate that your app is close to the edge of its memoryconstraints.
The logging statement also indicates how much memory wasfreed, how much of the heap is currently free, and how long Garbage Collectorhad to pause the app to complete its work.
Android also provides a way to expand your maximum heap sizeby adding android:largeHeap="true" to yourapp's manifest. This will increase your maximum heap size to 256MB. However,this is not silver bullet solution. A larger heap size means longer pauses for GarbageCollection and a degraded overall user experience as background apps aretrimmed to free up memory. The performance hit is not trivial, so only use whennecessary and for apps that don’t rely on a real-time user response, such as afast-paced game.
Our QA teams run a number of tests to make sure apps willrun as expected on the Kindle Fire HD tablets. For example, we run an automatedanalysis of the manifest and app. We also do in-depth usage and “stresstesting” to try and identify issues before our users might see a problem. Ourtesting, however, can’t identify every possible issue, so the more testing and optimizingyou can do before you submit your app, the better experience your users willhave. Make sure to follow our pre-submissiontesting guidelines before submitting your app.
We are pleased to announce that you can now distribute your games and apps to Amazon customers in Japan. Check out the press release here.
Thanks to our community of app developers, Amazon's mobile app distribution continues to expand internationally. Together, we are making it easy for consumers to shop, discover and buy new content on their Android device, Kindle Fire or Kindle Fire HD through personalized recommendations, customer reviews and differentiating programs like Free App of the Day.
Amazon’s developers have reported strong monetization from the apps they've distributed, thanks to the In-App Purchasing API and Amazon’s 1-Click purchasing. And we encourage you to customize your apps for different countries to ensure customers have the best experience possible. You can learn more about Android localization tips and resources and steps for localizing your app in the Distribution Portal in previous posts here on the blog, or learn more about developing for Kindle Fire from Kindle Fire Development Resources. Plus, check out tips from Gamevil on localizing for Japan.
New to Amazon?
We’re currently waiving all first year program fees
It’s free to register for a developer account and it’s easy to download our SDK here.
Starting today, the Amazon Maps API is now open to all developers.
We first launched the API as a public beta in September. Since that time, we have received a great deal of interest in our Amazon Maps API offering and partnered with developers to integrate mapping into Kindle Fire tablet apps. Developers like Hipmunk, Evernote, Trulia and Zillow now use the Amazon Maps API on Kindle Fire HD and the all-new Kindle Fire.
The Amazon Maps API has two core features:
The Amazon Maps API is now part of the Amazon Mobile App SDK. Learn more about how easy it is to add maps to your apps in the Mobile App Distribution Portal.
The Amazon Mobile App Distribution team will be on-site at Amazon’s first developer conference, AWSre: Invent, all this week. Stop by our booth and meet with marketing and technical representatives—we’ll be there to answer your questions about getting your apps optimized and marketed on Kindle Fire.
As a mobile app developer, here are some sessions that may interest you:
Distributing Apps through Kindle Fire and the Amazon Appstore for Android
November 28th– 10:30am to 11:20am
Aaron Rubenson, director of the Amazon Appstore, will provide an overview of the Amazon Mobile App Distribution Program, the Amazon Mobile App SDK, and resources available to developers for Kindle Fire tablet optimization. Learn how to grow your business by engaging new customers and monetizing your apps.
Monetizing Your App on Kindle Fire: In-App Purchasing Made Easy
November 29th– 10:30am to 11:20am
Mekka Okereke, developer services lead for the Amazon Appstore, will discuss how in-app purchasing can help you monetize your app and grow your business, as well as how to integrate the Amazon In-App Purchasing API into your mobile apps.
TinyCo’s Best Practices for Developing, Scaling, and Monetizing Games with AWS and Amazon
November 29th– 3:00pm to 3:50pm
Suli Ali, Co-Founder and CEO of TinyCo, will share their best practices for developing engaging titles that work across mobile platforms. TinyCo has learned how-to scale their AWS app servers and databases to handle viral demand, and they will talk about what they learned while they were developing their gaming platform and code libraries. Additionally, TinyCo was successful marketing and monetizing their game with the Amazon Appstore and Kindle Fire, and they will explain how-to integrate with Amazon’s in-app purchasing service.
To learn more about our participation in AWS re: Invent,read our earlier post here. We hope to see you there!
It’s that time of year again—when games provide bonus holiday levels and Santa hats pop up on app icons everywhere. It’s also the time when customers will be opening up new gadgets, phones and tablets as gifts. We won’t be closed during the holidays, butyou should submit your apps and app updates now to make sure they’re live in time for gift opening.
TashaKim, Public Relations Manager, GAMEVIL, is our guest blogger for this post.
GAMEVIL is a leading mobile games publisher and developer headquartered in Seoul, Korea,with branches in Los Angeles, California, and Tokyo, Japan. GAMEVIL has expanded their global presence over the years through an ambitious lineup of internal and third party titles localized in eight different languages. GAMEVIL specializes in mid-hardcore mobile games and prides itself on their strong following of players who enjoy their RPG-based titles.
At GAMEVIL,we believe that localization is one of the most important steps during post-game development. Correctly localizing a product not only promotes accessibility toa wide range of players across the world but also establishes global brand awareness. Our games are localized in over eight languages through in-house translators as well as third-party companies. Due to the geographical closeness and cultural similarities, our games are heavily popularized in Asia. Japan, in particular, holds a high percentage of downloads and monetization. We believe this is in part due to the localization of our content into the Japanese language and culture.
Below are a few guidelines we learned in our experiences localizing to Japanese as well as other Asian countries that may help other developers:
Translation is Not Localization
There are countless outsourcing companies overseas that will offer a literal translation of the language, but because so many RPG titles hold a rich and deep storyline,a literal translation would render the story awkward, bland, and lose the interest of the player. At GAMEVIL Japan, we translate the game internally and often outsource to third-party translators as well. Then, we initiate a second round of in-house translations. This portion focuses more on the cultural nuances and idioms that might not have translated seamlessly.
Understanding the Culture: The Importance of Physical Presence
We believe that it’s not enough to simply localize into a language through text, but that a full immersion is the best way to understand a culture and what is relevant in the region. The staff members at our Tokyo office are Korean/Japanese who have a sound comprehension of the social and cultural nuances. As similar as East Asian cultures may seem, there are still dynamic differences linguistically between countries that require sensitivity and attention. Once a literal translation is done, GAMEVIL Tokyo will go through a proofread, cross checking the text of the original document and implement any necessary changes. This process usually consists of omitting phrases that are irrelevant and adding text that will vibe well with the Japanese gaming culture.
The Importance of Proofreading
One key aspect that remains an extreme priority in our localizing is in the final steps of proofreading. We check each line to make sure that the meanings and expressions held behind each word and phrase flows seamlessly. The last thing that you would want is to make your game seem foreign to native gamers. We will usually have at least three rounds of thorough review before the translation is released to the public.
Localize the Entire Experience
One common misconception is that localization simply ends with the text, but localization often applies to the whole game. We cater each game according to regions. For many of our titles, we will implement Global, Asian, and Korean servers to create an experience that is relevant and user friendly. In addition, we take a user’s environment into consideration. For many Japanese users, gameplay will take place during a commute on the subway or bus in addition to heavy gameplay at home. We try to focus on quick loading times to encourage gameplay during short sessions. For our strong RPG and sports titles, we create short side quests such as the Abyss system in ZENONIA® and Exhibition Mode in Baseball Superstars® that can be enjoyed in short sessions. Japanese users are also big gamers and enjoy the anime RPG-style of many of our titles. With an immersive storyline and high-quality visuals combined with a well-polished text, our titles have seen success in terms of downloads and purchases in Japan.
We want to put out a product that seems indigenous to the users as they play the game. Our end goal is to create a game that transcends language and cultural boundaries that can be enjoyed by people regardless of age,gender, and ethnicity.