Showing posts tagged with Fire phone

Amazon is hosting a Developer Day on April 25th at the Cross Campus in Santa Monica, California. Amazon Developer Evangelists will share industry best practices and help mobile developers learn how to grow their app business via the Amazon Appstore. Amazon technology leaders will be on-hand to answer developer questions and lead talks on topics such as building apps and games for Android devices, BlackBerry, Fire tablets, Fire phone, Amazon Fire TV, and how to build voice controlled experiences for Amazon Echo. Attendees will also learn best practices around how to make fun games and to market your game to influencers and build a fan base.

The format of the workshop will be split between morning lectures and afternoon “App Hours.” The App Hours will allow developers to get 1:1 support to publish and tests their own apps and games to the Amazon Appstore, guidance around building apps and games with Android, Unity and Xamarin, and hands on experience with the Amazon Mobile App SDK, Fire Phone SDK, Fire TV SDK and Amazon Echo SDK code samples. Developers will also be rewarded with Amazon gift cards for successful app submissions to the Amazon Appstore during the App Hours’ time period.

Agenda

Check-in and Breakfast9:30am-10:00am

An Overview of the Amazon Devices and Services for Mobile Developers10:00am-10:45amDavid Isbitski, Developer Evangelist, Amazon We will start the day off with an overview of Amazon's current developer ecosystem. Learn how you can take advantage of Amazon’s Mobile Apps SDK, Amazon's Appstore and the new line of consumer Fire devices like Amazon Fire TV, Fire TV Stick and Fire tablets, as well as monetization services such as in-app purchasing.

Building Spoken Language Apps and Experiences for Amazon Echo10:45am-11:45amDavid Isbitski, Developer Evangelist, Amazon Echo is a new device from Amazon designed around your voice. It's always on—just ask for information, music, news, weather, and more. Tucked under Echo's light ring is an array of seven microphones. When Echo detects the wake word, it lights up and streams audio to the cloud, where it leverages the power of Amazon Web Services to recognize and respond to your request. With the release of the developer SDK you can now build your own apps and experiences for Amazon Echo. This session will cover everything you need to know starting off with how to use the SDK, how to build your first app, and end with the app submission process.

Lunch11:45am-12:00pm

How We Made a Game No Fun12:00pm-12:45pmPeter Heinrich, Developer Evangelist, Amazon There are lots of suggestions about how to make a game fun. Best practices are everywhere, but you can't just follow them blindly. To create a fun game, you have to figure out how best practices integrate into your specific game. Come see what we did wrong, and what we learned along the way.

How to Evolve Players into Fans12:45pm-1:30pmPeter Heinrich, Developer Evangelist, Amazon We’ve analyzed the top mobile games to see what best practices make them stand out from the crowd. Several trends emerging now will amplify those best practices, and games will have more opportunity than ever to excel. In the future, the top games will have fully realized fan bases that will drive their user acquisition and engagement engines. That fan base will include players but also content creators, advocates and potential new customers — this will open up a wider range of monetization options. Come see how top mobile games drive more engagement and revenue and learn how to you can do this with your own game.

Break1:30pm-1:45pm

App Hours1:45pm-3:45pm Get 1:1 support to publish and test apps and games to the Amazon Appstore. Learn how to build apps and games with Android, Unity and Xamarin. Get hands on experience with the Amazon Mobile App SDK, Fire Phone SDK, Fire TV SDK and Amazon Echo SDK code samples.

Raffle and Wrap-Up3:45pm-4pm

Seating is limited so be sure to register for the event to reserve your spot. Hope to see you there!

As the size of mobile apps get larger, and services and tools get more complex, they add more method references to our apps. Google Play Services alone adds 29,460 methods (reference). The result is that we are hitting the original design limitations of Android build architecture. Specifically, we hit the inability of a single Dalvik Executable file (dex file) to support more than 65K Method references. When that happens, your code will generate build errors and won’t run.

And a Few Methods More

When you compile your code and are short of the 65K limit, you may reasonably believe you don’t need to worry about this problem. That is, until you submit it to an Appstore. Most appstores, (the Amazon Appstore included), add additional method references as part of the ingestion process. If your code is ”too close” to the limit when submitted, your code may fail upon submitting to an Appstore after the additional references are added. This has always been the case. However, with the release of Android 5 (Lollipop) we have started seeing a lot more of these “too close” dex file problems. To help you avoid or work around this limitation, we have some suggestions below:

What Hitting the Wall Looks Like

You’ll know when your app references more than 65,535 methods because you’ll see an error something like this:

Or

If you see these errors, you can certainly address them before submitting to an Appstore. But even if you’re close, you’ll want to try some of these practices to stay comfortably away from “too close”.

How Close Are You to 65K Method References?

To find out how close you are to 65K method references, you can utilize a tool called dex-method-counts to get the method count and what is referencing them:

“Too close” will be different for each Appstore and each device OS, so there is no single correct answer. But Google sets max methods to 60K if Multidex is used, so you can be pretty sure that 60K methods is a safe number for newer Android devices. (Devices running older Android OSs may need that limit closer to ~55K methods).

Use ProGuard to Help Remove Unused Libraries

The first (and easiest) step is to remove as many unnecessary libs and methods as possible. To help in this task, you can use ProGuard (part of the Android SDK) with -dontoptimize –dontobfuscate in the configuration which will remove unused methods from the dex file during build time. (See this helpful blog post on using ProGuard by Crashlytics)

Using More Than One dex File

If removing unused libraries doesn’t work for you, you can try using the Multi-dex approach, which splits up classes.dex into multiple dex files.

There are few caveats to this approach however; the main one is the requirement to use Gradle. You may also find that it may not remove enough methods to go below the limit without performing a few extra steps which are outlined in the “Using the Multidex Library” section below. You can use the dex-method-counts tool referenced above to check the method count of your resulting classes.dex file.

Using the Multidex Library

With Android 5.0 Lollipop release, a new support library (android-support-multidex.jar) appeared in Android SDK ver 21.1.x and Android Support library 21.0.3. You can find it in:

\android-sdk\extras\android\support\multidex\library\libs. It contains two new classes: MultiDex and MultiDexApplication and simplifies the Multidex loading process. According to Multidex documentation (http://developer.android.com/tools/building/multidex.html) it does not provide additional functionality on Android 5.0, which already has built-in support for secondary dex files. Rather, on previous versions of Android, it allows additional .dex files from the APK archive to the classloader. The library allows the archive to become part of the primary DEX file of your app and manages access to the additional DEX files.

If you have any additional libraries in your project, be sure that you disable pre-dexing on them. Unfortunately the --multi-dex option is not compatible with pre-dexed libs.

You can do this by adding the example below to your app/build.gradle file.

Step #6

You have to configure build instructions to endure that your Multidex app is optimized for the Amazon Appstore and our ingestion process. As of this writing you have three options:

Option #1 – Manually create the main-dex-list file.

In app/build.gradle file we have to add:

There are two params:

--multi-dex - enables splitting mechanism in build process

--main-dex-list - file with list of classes which have to be attached in main dex file (we will address this one in Step #5)

To ensure your Multidex app will ingest and publish properly in the Amazon Appstore you should use the --main-dex-list param to put the following in the main .dex file:

Custom Applications

Activities

Services

Receivers

Providers

Instrumentations

Annotations

Option #2 – Ignore the multi-dex and multi-dex-list parameters.

If you are using studio 0.9.0+ gradle 0.14.2 and use the dx.additionalParameters to manually set the max number of referenced methods in your main classes.dex file, then the main-dex-list will be auto-generated and you don’t have to set the multi-dex and multi-dex-list parameters. It will look similar to:

Option #3 - Ignore the multi-dex and multi-dex-list parameters if you are using studio 0.9.0+ gradle 0.14.2 and let the build tools automatically limit the dx.additionalParameters parameter to 60,000.

This should work for most applications, however if you have a very large number of classes in your app you may find that you will need to manually set your max number to something less than 60,000 to have your app ingest properly in the Amazon Appstore.

Welcome to the final part of this five part series on making games for the Amazon Appstore. Part one, two, three and four helped you build the foundation for your game’s design and in this final post we will talk about how to actually market your game.

So you have finally finished your game and are ready to release it to the world. While there is a lot you can do after you have completed your game to help make it a success, you should always be thinking about marketing your game from the very beginning. The following section will help you with everything from naming your game to how to help it stick out in an overcrowded mobile store. While marketing a game is not an exact science, and its success has a lot to do with the quality of your game and pure luck, you can still take the necessary steps to ensure it gets the most attention possible out of the gate.

Naming Your Game

The name of your game is going to be the single most important decision you make. Companies spend huge amounts of money doing market research to come up with product names, and what you come up with for your game has lasting effects. The most basic thing you can do to help your game be more successful is to simply give it a descriptive name. Look at other games and how they came up with their names:

“Mario” – Named after the main character. While it doesn’t describe what you will be doing in the game, it helps establish the lead and his name defines the brand.

“Legend of Zelda” – The word legend implies a deep story told a long time ago, and saving Princess Zelda is the main objective of the game.

“Grand Theft Auto” – The name alone implies stealing cars and breaking the law. It clearly describes the main gameplay mechanic the player is going to expect to be doing.

“Angry Birds” – Doesn’t get any more basic than this. You play as a bunch of angry birds.

Naming a game isn’t always an easy task, but make sure your game’s name is clear, descriptive, and easy to remember. Also, make sure your game’s name makes sense for sequels and continuations if you find yourself with a hit on your hands.

Getting People to Play Your Game

This topic really goes back to the beginning section on what platform to build your game in. The key to success is really getting your game in the hands of as many players as possible. To do that, you will need to pick a platform with the most reach possible. While HTML5 has the incredible advantage of being published to the Web, you will find that it is more difficult to publish to a native store. Frameworks like GameMaker and Unity will allow you to publish to multiple platforms, but they charge extra for that service. Some features are free, and while GameMaker allows you to export an HTML5 version for the Web and Unity has a Web Player for its game, you really need to do your research and pick the right tool from the beginning.

The ideal scenario is that you are able to release your game on all of the major platforms: Web, iOS, Android, FireOS and desktop. From there, you have some granular options to decide on, like what devices to support on each mobile platform, and even what version of the OS you can support. Don’t forget Web stores, such as Chrome Market and Firefox’s new Web-based Phone OS. Also, there are online game portals that do revenue sharing based on ads around your game. While mobile is all the rage, don’t forget how many people still use Web browsers, and every modern mobile device also supports playing Web games, so you get even more bang for your buck. I am now working on having all of my games as Web-playable demos pointing to the app store versions to help broaden my audience, since being found on the Web is much easier than in an app store.

If the Web isn’t your thing, also keep in mind cross-platform desktop publishing. A lot of indies have had success with Steam Greenlight, as well as bundle deals like Humble Bundle. Both of these distribution solutions leverage desktop compiling and usually want games that support Windows, Mac, and Linux. If you intend to ever get your game on Steam, make sure you are able to offer a desktop installer.

Charging for Your Game

With all of this talk about distribution, you are probably thinking through all of your monetization options. Let’s take a look at the three most common options out there now:

Flat rate – Your first instinct is probably to charge a flat rate for your game, like 99 cents or more. Some games can command a very high premium on the mobile market, but gone are the days of charging $5, $10, or more, especially if you are just starting out. When it comes to pricing your game, you should do a lot of research on your game’s genre, its competition, and what it costs. If you see a lot of high quality free games similar to yours, it’s probably best to consider an alternative option.

Free with ads – This was popular for a long time before in-app purchases were introduced. Basically, you make the game free and use ads to help generate money. While there are clear advantages to making your game free, which allows anyone to download it, it is also incredibly hard to monetize from ads. As an example, my most successful game on Android with almost 50k downloads (roughly 1-2k players a day) only generates $1 or less each day. In order to really make money with ads, you will need at least 100k players a day or more, and show larger, more obtrusive ads that tend to slow down the game’s flow or frustrate players.

IAP (in-app purchases) – The final approach, which has gained considerable popularity lately, is relying on IAP (or in-app purchases). Usually, the game is free and you try to upsell so users buy more levels, items in the game, or even ways to speed up their in-game character’s development. What’s good about this approach is that your game is completely free, so you get my people playing your game, and if they like it or you have compelling IAP, they end up paying more than they normally would had your game been sold at a flat rate. This model is extremely hard to pull off successfully, and it’s a fine line between adding additional value to your game and trying to exploit the player’s compulsion loop.

The reality is that, if this is your first game, chances are high that you will not make a lot of money off of it. Having a successful game is kind of like winning the lottery. I am not telling you this to discourage you; I want first-time game developers to have a clear idea of what they are in for. Even seasoned game developers have a difficult time monetizing their games without help from marketing firms. Even getting good reviews on game sites, which is hard to do, doesn’t always translate into lots of sales. The best thing you can do is get featured on the app store itself, but once that promotion is over, unless you have a real hit on your hands, you will see a natural drop off in your game’s sales or downloads.

The last thing I want to talk about, which leads into our next topic, is that making games is a learning experience. The more games you make the better you become as a game developer and grow your chances of making a hit game. While it’s very frustrating for first-time game developers to work hard on something and not see people download it or buy it, you shouldn’t give up. One of the best things your game can be is a promotional tool for you and even your next game. Always be sure to have links to your other games inside of your game to help promote everything you are doing. You may be surprised to realize that, over time, you actually end up building up a following of people more willing to pay for your next game if they continue to play and like the ones you are releasing now.

The More Games You Make the Better

I talk to a lot of game developers each day, and they all have the same story: the more games they have in the store the better their sales are. This happens for two reasons. The first is that, when you make more than one game, they are all featured on your game’s download page under a section that highlights other games made by the same author. That means that each additional game you make basically gives you free advertising for your other games. The second thing that happens is that, when a person likes your game, they naturally want to play more games you have made. This means they will look at anything else you have created, which is the basis for building your own fan base. So each successive game you release will naturally help drive downloads and sales of your past games as well. This is another reason why you should not give up if your first game isn’t an instant success and just keep making as many games as you can!

Conclusion

The good news is that publishing to the Amazon Appstore is free and easy, especially if you are already building Android games. Simply sign up for a developer account at the developer portal to get started today. Here are some additional links to help you gets started:

We are now 4 topics into this series on how to make games for the Amazon Appstore. If you missed the original posts, make sure to check out part one, part two and part three to get caught up.

Once you have your game up and running, and you begin to approach being able to release it, you are going to want to go over all the details and make sure it’s polished. Sure, you can put a game out there just to see how it does, but in today’s saturated market of mobile games, you need to make sure you put your best foot forward when releasing your game. Here are a few things you should do in your own game before you release it.

Consistent Design

One of the most important things you should do in your game is make sure your art style is consistent throughout the game. Your in-game graphics and your UI, and even the splash screen, should all look and feel like they belong together. The best example I have of this is Mega Man 2.

As you can see the box art for “Mega Man 2”, on the left, is completely different than what the actual game looked like, on the right. While there is a time and place for being creative with your game’s art style, just make sure you don’t set the wrong expectations for your perspective players. This is especially important when it comes to creating screen shots to entice people to pay for or download your game. In the end, keeping everything consistent will help make the overall game feel more polished.

Supporting Multiple Resolutions

How to support multiple resolutions is probably one of the most common questions I get asked at all of my game design talks. Outside of supporting mobile resolutions, which are all over the place, desktop monitors have been driving game developers crazy for years. When it comes to designing for multiple resolutions, you just need to understand how aspect ratio works and decide whether your game will attempt to maintain it. To help myself out, I always start with a comp of the three main resolutions I want to support.

Here you can see that the native resolution of my game is 800 X 480. This is a 5:3 aspect ratio. From there, I can easily scale my game to 1024 X 768, which is a similar aspect ratio of 4:3. My game will also support 1366 X 768, which is a 16:9 aspect ratio. The key to this system is that my game camera simply shows more of the game screen as I change aspect ratios, and the UI moves based on the resolution as well. Here is an example of the game at two different resolutions.

Here is the game at 800 X 480. As you can see, the camera shows less of the action, but I make sure the UI scales down nicely to support the lower resolution without any overlapping.

And here is the game at 1366 X 768. As you can see, both versions of the game are fully playable, but you end up with a little extra screen real estate at the higher aspect ratio.

Perceived Performance Optimizations

The last thing I want to talk about when polishing your game is perceived performance. A lot of the time, developers spend days upon days trying to optimize their code when they end up forgetting that a few minor tweaks to the way their game runs will help give the impression of better performance to players. Sure, optimizing artwork is a key part of any performance optimization, but why not make your loading screen look more interesting while people wait, or work on making the transitions from screen to screen more seamless. Even tricks like lowering the FPS could actually help out if your game is struggling to maintain 60 FPS. Most games can easily get away with 30 FPS. Also, having more animation transitions and frames can help remove the feeling of slowness or unresponsiveness in gameplay.

Conclusion

The hardest thing to really understand is how to support multiple resolutions. Once you understand that you will be on your way to being able to make games across multiple platforms and screen sizes. To help get you started here are some resources to help you better understand our Fire Phone, Fire Tablet and Fire TV resolutions and tips for optimizing:

As we continue our game design series we’ll focus on one of the most important aspects for any game, adding artwork and sounds. Don’t forget to check out part one for picking a game framework and part two for game design 101.

If you don’t come from an art or music background, you might find this part of the game creation process the most stressful. Building a game for the first time will stretch all of your skills, like programming, creativity, design, and more. It’s easy to get bogged down in the details and forget the most valuable part of making a game, which is building something fun to play. In this section, I will talk about some approaches to adding artwork and sounds into your game.

Working Without Art and Sound

The first thing I tell people just starting out is to use placeholder art and sound while building a game. It may be hard to believe, but you can always get artwork later, and sound is just as easy to find online or get help making. To be honest, if you build a compelling enough game, you may even be able to convince an artist or musician to work for you and share the profit from the game. But none of that will happen if you don’t have a fun game to begin with. It also helps to take a look at other games that use minimalistic or dynamically generated art as inspiration as well. The following are a few very successful indie games that do that.

While “Thomas Was Alone” looks deceptively simple from the screen shots, there are a lot of subtle visual effects that add depth to the art style. But, at the end of the day, the game is really about a set of primitive shapes and basic geometric levels.

“Super Hexagon” was a hit as soon as it was released. It revolves around the simple concept of not touching the walls that rotate and move to the music. As you can see, the levels appear to be dynamically generated, and while its creator uses a really great soundtrack to move the levels along, all of the visuals can be sorted out once you have the basic gameplay mechanics down.

Let’s talk about how to make art and some ways to package it up into your game.

Working with Artwork

I love pixel art. It’s super easy to make, and most of the games I build are based on old Nintendo games I used to play as a kid. While pixel art isn’t for everyone, here is a list of some design tools to get you started:

Photoshop – This is one of the most popular and expensive art tools out there, but with Adobe’s new Creative Cloud plan, you can pay for it monthly. Photoshop is great for creating rasterized artwork, and you can do vector art as well. I use Photoshop for all of my game design and layout work.

Illustrator – Just like Photoshop, this is the most popular vector-based art tool out there. I suggest using a vector-based editor if you are going for a cartoony look or want to make sure your game’s artwork can scale to any resolution. Not a lot of game engines support vector artwork like Flash did, so that’s something to keep in mind.

Aseprite – If you are doing pixel art, this is one of the best editors out there. Not only is it free and open source, it’s just great for making pixel animation and even supports importing and exporting sprite sheets.

GIMP – If you are looking for a Photoshop alternative, I suggest checking out GIMP. I was never able to get into it, because I’ve been using Photoshop since version one, but GIMP is free and a lot of game developers and artists I know use it.

I could probably write an entire book on tools for making artwork for games, but you should take a look at other online tools I may have missed or that you might already own. At the end of the day, it’s all about doing the best you can when it comes to making artwork, and if your game is good enough, you will eventually find someone to help clean it all up. I actually outsource all of my artwork even though I have a background in art because I want to focus on the game and let someone else carry the burden of making good game art. You can find my own collection of open source art work at http://jessefreeman.com/category/game-artwork/

Working with Sounds

Just like artwork, creating sound effects can be a daunting process. I suck at sound design, and it’s another thing I try to outsource as much as possible. I do have a secret weapon, though, called Bfxr, which you can use online or install on your computer as an AIR app from http://www.bfxr.net/.

This app is perfect for generating simple 8-bit sound effects for your game. It may look intimidating at first, but as you can see on the left-hand side, there are a bunch of pre-defined sound templates, such as pickup, laser, explosion, and jump sounds. But the most important button is Randomize. I use this all the time to come up with new sound effects, and you can use the Synth option in the middle to modify it. I use these as placeholder sound effects in most of my games, and over time, I have built up a nice little collection of sound effects I can use from game to game to help speed up my development. You can download my collection at http://bit.ly/gamesfx.

Once you have some sound effects, you are going to need a way to convert them. Bfxr likes to generate .wav files, but you’ll be hard pressed to find a game frameworks that still use that file format. That is why I use a program called Audacity, which you can get at http://audacity.sourceforge.net/.

For example, when it comes to HTML5 games, you are going to need to output .mp3 and .ogg files, since each browser supports a different file format.

Conclusion

While this is just a small part of what you will need to produce artwork and sound effects, I have a few links below to open-source artwork and additional resources to help you get started:

As we continue this multi-part series on how to make your first game for the Amazon Appstore we’ll dig into the fundamentals of game design. If you are just finding this post, make sure you check out part one which covers picking a game framework that supports exporting to the Amazon Appstore.

For most people, it usually starts the same exact way. You have a game idea and just want to start building. Making a game is more than just having a good idea and the skill to code it; you have to think through the gameplay, the target audience, and map out what it is you are going to build. I love this tweet by Sean James McKenzie of @baconandgames about your first game idea:

To help you simplify your idea to something manageable you should start by getting it down on paper. No one builds a house without a blueprint, and you shouldn’t make a game without a solid plan either. This could be something as simple as a task list with everything you need to do or something more specific, such as a document outlining all the details. Either way, your game design process is going to start with a blank page. Let’s talk about how to fill it in.

Document Your Idea

In traditional game development, you are encouraged to make a game design document. This is usually a large document outlining every aspect of a game. It’s the blueprint that the rest of the team must follow when building out the game. If you are a single developer, this is overkill. You can easily boil down a GDD into a single list of tasks with a few introduction paragraphs and any collateral or references, such as screen shots and links to other games or game mechanics you like.

It’s up to you to find the best way to document your idea, but the more you work through the details the better the project will end up. It’s very “cheap” to work out your ideas on paper or in your head before you start coding. Once you begin the coding process and need to go back, you amass what we call technical debt that can make your code unmanageable or, even worse, kill your productivity altogether by forcing you to constantly hack together new solutions or refactor code you’ve already written.

If you are having trouble getting started I highly suggest checking out the 1 Page GDD by Javi Cepa (@JaviCepa).

Getting Feedback

The most important part of this documentation process is sharing your idea with others and getting their feedback. I know you want to protect your idea with your life, but the reality is that most people starting out making games need feedback from others. We all start out with the lofty goal of “making a game I want to play,” but the reality is that you are just one person and, in order to be successful, you need to appeal to larger markets. I’m not saying you should post your game ideas online for all to see, but find a select group of trusted friends and run it by them. You’ll find that some feedback is hard to take, but being able to filter out what will actually make your game better is a valuable skill to have.

Play More Games

Perhaps the most important thing outside of documenting your own ideas is to start playing games … a lot of games. As a game maker, your hobby should be playing games, taking them apart, and figuring out what makes them tick. You should keep a notebook of all the games that you play, and even the ones you don’t play but see online. Use something like OneNote, or any note-taking app. The idea is to write down what you like about the game, what you don’t like, and some of your big takeaways from playing it. There should be screen shots if you like the art style and links to any collateral information on the game that will help you with your own ideas later. Since you never know how a game will inspire you, it’s important to be as detailed as you can. It sounds like a lot of work, but it’s honestly the most valuable tool you will ever have when it comes to finding inspiration and avoiding common pitfalls.

Conclusion

Once you have mastered these three steps for writing down your ideas, vetting them out and finding new inspiration you will be on your way to making your own game. To help get you started, here are a few games I suggest trying out on the Amazon Appstore which inspire me:

Amazon Fire phone is the only smartphone with Dynamic Perspective and Firefly. Dynamic Perspective is an entirely new sensor system that responds to the way a customer holds, views and moves the phone. The Dynamic Perspective SDK gives developers access to algorithms that identify the X, Y and Z coordinates of the head, enabling a whole new class of apps and games. Firefly quickly recognizes things in the real world—web and email addresses, phone numbers, QR and bar codes, movies, music, and millions of products, and lets the user take action in seconds—all with the simple press of the Firefly button. With the Firefly SDK, developers can extend the use of the Firefly button to enable new actions their users can take based on what they identify.

Here is a recap of helpful Fire phone posts on the Amazon Apps & Services Blog in 2014:

Each November, Amazon holds the re:Invent developer conference and this year there were several sessions designed for mobile developers and the Fire phone. The slides and videos are now live so if you weren’t able to make it to the conference you can still get the content right here.

Recorded live at AWS re:Invent 2014 this free video will introduce you to Fire the first phone designed by Amazon. You will learn about the new customer experiences it enables and how top developers have updated their Android apps to take advantage of Fire phone.

We shared an overview of the AWS Mobile SDK and how to get started. The AWS Mobile SDK helps bring the power of the cloud to your apps while enabling you to build high quality mobile apps quickly and easily across multiple platforms including iOS, Android and Fire OS.

We announced new support for web apps submission to the Amazon Appstore giving you the option to submit self-contained, packaged web apps that run on Amazon devices including Fire TV and Fire phone. You can now submit your web app as a standard zipfile in addition to the existing hosted web app solution or have web apps in the Amazon Appstore that use both.

Have an Android app already but not sure where to start with Fire phone? We offer plenty of tips and tricks to get your app quickly up and running on Fire phone and how take advantage of its new capabilities.

We unveiled Fire, the first phone designed by Amazon. Fire is the first and only smartphone with Dynamic Perspective and Firefly. With Fire Develop SDKs available now, these new technologies enable you to create more immersive experiences in your apps and games that increase user engagement.

For more information about getting started with Fire phone, check out the following additional assets:

In this five part series you will get the basic foundation you will need to get started. In part one we’ll cover picking a framework and why you should use one designed specifically for game development.

Whether you are a seasoned game developer or just getting started making your own game, chances are you are going to need a good game framework to build upon. A game framework could be as simple as a collection of code packed up into a library in a specific language, like JavaScript, or a more complex system of scripts, tools, and workflow built on a specific platform. Both types are designed to help speed up your game’s development. The last thing you want to be doing, especially when getting started, is reinventing the wheel. Here is a quick rundown of things to look for in a good game framework:

Speeds up development by including collision and physics, and handles input

Has good documentation and an active community to help answer questions

Is easy to pick up and matches your skill level (drag and drop for non-coders and low-level access for seasoned developers)

Easy multi-platform distribution, allowing you to get your new game on as many devices as possible

To help you pick the right game framework, I have highlighted a few of the most popular ones which work great on Fire OS devices and are perfect for people getting started making their first game. I have arranged these from easy to hard based on the above criteria.

Construct 2 (Beginner)

Construct 2 is as easy as it gets for making a game. It employs a drag-and-drop behavior system, where you build up game logic from pre-made scripts that are attached to your game’s elements.

Construct 2 games are built in HTML5 (although you never have to touch the code itself) and, because of this, it’s ideal for publishing your game on the Web. Construct 2 games also run on a number of different platforms too The only down side to Construct 2 is that you are removed from the coding aspect of making the game, so you are fully dependent on what Scirra has provided. And, while you can add additional functionality via plugins, it’s not ideal if you come from a coding background and want to manually tweak things yourself.

GameMaker (Beginner to Intermediate)

GameMaker is a great tool for making 2D games. It’s incredibly powerful, and a lot of well-known indie success stories got their start in GameMaker (“Spelunky,” “Hotline Miami,” etc.).

GameMaker is similar to Construct 2 in ease of use since you can perform drag-and-drop, event-based coding, and more advanced users can take advantage of its built-in scripting language called GML (GameMaker Language). GML is C based, so if you know C, JavaScript, Java, or C#, it will be familiar. But the language does have limitations, such as limited data structures and no classes. While the UI of GameMaker takes some getting used to, it’s still an excellent tool for 2D games, and its support for publishing to desktop, mobile, and HTML5 shouldn’t be overlooked.

Unity (Intermediate to Advanced)

Right now, Unity is a very popular game framework. Similar to GameMaker it also has it’s own IDE and you can drag and drop behaviors but Unity requires a baseline of coding skills to get up and running.

The IDE is very polished and easy to use, but being a 3D tool means that there is a certain level of knowledge you will need before getting started. Unity supports three languages: UnityScript (which is similar to JS), C#, and Boo. Unity now has a free version that supports exporting to desktop and mobile that displays the Unity logo on startup. The pro version gets incredibly pricey but adds lots of must-have features for more advanced game developers. Also, Unity released a new Sprite workflow for anyone interested in making 2D games.

HTML5 (Intermediate to Advanced)

Sometimes you want to control every aspect of your code. HTML5 is a great place to do that, and it’s one of the only game platforms that allows you to target multiple platforms with the same code base, and include the browser on desktop and mobile as well.

There are a lot of really great HTML5 frameworks out there, but the two most popular are Impact ($100 license) and Phaser (free). The one thing to keep in mind is that you will have to manage browser compatibility across desktop and mobile, and native app distribution is still an issue. Also, in many cases you will need to bring your own tools, but seeing a game work perfectly in a mobile browser without a plugin opens up a lot of doors you would not get in a native mobile app store. On the flip side, we make it incredibly easy to test and publish HTML5 games on our devices via our Web App Tester.

Godot (Advanced)

Godot is a new and completely open source game engine that just caught my attention.

While I’ve not used it, it looks incredibly promising and one I wanted to put on other developers radars. It uses a scripting langue similar to Phython and promises to export to multiple platforms. It’s one that I hope to dig into a little more in the new year plus being completely open source means you can tinker with how the engine works under the hood.

While I could probably write an entire book on different game frameworks and platforms, I don’t want to overwhelm you. The good news is that, if you are just starting out, there is guaranteed to be a framework that is right for your skill level or game idea. If you are looking for some more resources on how to get started, we have a few blog posts to covering Phaser and Unity, which you may want to check out:

As an end of the year gift to all of our readers we have unlocked the GDC Vaults and made our Amazon Developer Day content free to watch! Recorded live at GDC Europe in Cologne, Germany this invite only workshop includes everything you need to get your apps and games into the Amazon ecosystem. You will learn first-hand from Amazon developer evangelists about the Amazon Appstore, Fire phone, Fire Tablets and Amazon Fire TV. You will also learn how to build your own scalable mobile game backend using Amazon Web Services. So pull up a chair, sit back, relax and enjoy this free developer workshop. Happy Holidays!

Launching Enhanced Games on Fire Phone

This session will get you up and running with Android Studio and Amazon’s Dynamic Perspective and Firefly SDKs. See how you can quickly add 3D elements to your existing Android games with minimal coding. Multiple code samples are covered as well as live demos on Amazon Fire devices.

Reach Customers in the Living Room with Fire TV

This session will show how you can get your existing Android games running on Fire TV. Setting up the developer environment, debugging on the Fire TV, tuning for the living room experience and publishing to the Amazon Appstore are all covered.

An important success metric for any app is engagement: a measure of how frequently and how long people play your game. Amazon GameCircle is designed to help developers increase engagement through player Achievements, Leaderboards, and saved game syncing across multiple devices. Once you integrate GameCircle, players can seamlessly play games and interact with other gamers across mobile devices.

Now GameCircle social APIs offer new ways for you to improve player engagement by making it easier for players to connect with new friends. Using a simple API you can now pull GameCircle friends data into your game for players who use Amazon devices. Players using Amazon devices are able to create a profile for themselves, including a nickname and profile image, and can add other GameCircle players to their friends list. You can access this data and display it in your own games or use it to leverage custom social interaction features.

Make It Easy for Players to Find Friends

Players with friends play longer, but not all players have real-life friends playing your game right now. The GameCircle Friends API helps you solve that problem by enabling you to show your customers a list of suggested friends. By integrating a ‘Find Friends on GameCircle’ button into your game, players can easily click-through to their GameCircle Friends page to discover new friends who are also playing your game and add those suggested friends in just two clicks. GameCircle Friends doesn’t require players to grant your app permission or sign-in to access friends, so players can find and add new friends quickly and get back to playing your game sooner.

Add GameCircle Friends to Your Game

Add GameCircle Friends to your game today to increase player engagement. Getting started is easy:

Are you a C# developer looking to publish your apps and games across multiple mobile platforms? Did you know that Xamarin fully supports Amazon’s growing ecosystem of devices including Kindle Fire tablets, Fire TV and Fire phone.

At Xamarin Evolve 2014 this month I facilitated a session on building native Amazon Fire phone, Fire TV, and Fire Tablet apps with Xamarin Studio (Click the image below to see the video).

This free video will walk you through how to quickly use Xamarin to run your apps and games on Amazon devices, as well as provide an overview of Amazon Appstore services that help developers get their app discovered and increase customer engagement and monetization. Now is the time! Using the same C# language you love and the power of Xamarin you can reach millions of potential new Amazon customers.

For more information about getting started with Xamarin Studio and Amazon Fire devices, check out the following additional resources:

Hi everyone, we’re gearing up for AWS re:Invent, which is happening at the Venetian in Las Vegas from Nov 11-14. And we’re getting pretty excited about the sessions that are designed specifically for mobile developers.

"Fire phone's Dynamic Perspective adds a whole new dimension to UI and customer interaction, combining dedicated hardware and advanced algorithms to enable real-time head-tracking and 3D effects. This session goes behind the scenes with the Dynamic Perspective team, diving into the unique technical challenges they faced during development. Afterward, we explore the Dynamic Perspective SDK together so you leave the session knowing how to add innovative features like Peek, Tilt, 3D controls, and Parallax to your own apps."

Usually, it’s not fun to watch while people test out their code demos, but this one is pretty interactive!

A common theme that developers often face is deciding which platform they should make their apps available on next. Are the users on this platform engaged enough? Will I be able to make money on this platform? These are only some of the questions that developers face, before investing their time on transferring their apps. For Playtika, a company which builds highly immersive social games, expanding their apps onto as many platforms as possible has become a core strategy.

Playtika’s app Slotomania currently holds the #8 spot worldwide for highest grossed mobile app on iOS and Android. In addition to iOS and Android, Playtika has also launched on the Amazon Appstore, which has proved to be a big success. According to Playtika, the Amazon Appstore provided the team with the highest ARPU (average revenue per user) compared to other platforms and also contained the highest retention rate amongst its competitors. Recently I had the chance to sit down with Elad Kushnir, VP of Business Development, to discuss how their apps were doing in the Amazon Appstore and their experience working with Amazon.

“The Amazon Appstore does not only make the migration easy from an existing Google Play app, but it also has outperforming KPI’s as well.” says Elad. The team has seen some impressive results since their app has gone live in the store and have done fairly well for themselves in terms of revenue. “When we compared our 2014 data, we noticed that ARPU on Amazon was 70% higher than on Android and 15% higher than on iOS”- Elad Kushnir

The team credits the unique audience that Amazon brings in and how engaged they are. “When we looked at retention rates for 2nd day and 7th day metrics, the retention was relatively the same across all platforms. However on the 30th day, retention on Amazon Appstore was 10%-20% higher than on iOS and Google Play.” Says Elad.

Playtika Sees 150% Higher Conversion Rates from Players to Payers on the Amazon Appstore Compared to iOS and 170% compared to Google Play

Getting users engaged is only half the battle. With a free app like Slotomania, conversion rates (paying users/ DAU) is crucial in terms of making revenue which is why Playtika is using Amazon’s In-App Purchasing API. So how many of these users are actually purchasing within the game? From Playtika’s data in 2014, they determined that the average user on the Amazon Appstore is 150% more likely to become a paid user than on iOS and 170% more likely than Google Play.

Figure 1In-App Purchasing

From Google Play to Amazon Appstore with Little to No Work

When the team came together to decide on their next platform, they chose the Amazon Appstore immediately. So why did the team decide that Amazon Appstore was the right choice?

“When we were deciding on our next platform, we already had our app on Google Play. We realized that moving our app from Google Play to the Amazon Appstore would be pretty easy since Fire OS is built on Android. Once we started, we got our apps up and running in a couple days and the process itself was seamless. The best part was that it had relatively low development costs.” – Elad Kushnir

From previous tests, we actually found out that more than 75% of the Android apps we tested just work on Kindle Fire with no additional development required. The team has now launched several of their games on the Amazon Appstore and are working on the getting the remaining ones up and running within the next year.

Moving into Fire Phone and Amazon Fire TV

Moving forward Playtika plans to take their apps to the next level by getting them onto Amazon’s newest devices. Their current focus is to get their app on Fire, in which their team is already planning on integrating Fire’s exclusive feature, Dynamic Perspective. In 2015 Playtika is planning to also have their apps on Amazon Fire TV. For now, the Playtika team tells us that they are very happy with how things are going and plan to release even more apps on the Amazon Appstore in the near future.

Today, Amazon announced the availability of Fire phone, Amazon’s first smartphone, in the UK and Germany. Fire phone is currently available in the US and will ship on September 30, 2014 in Germany and the UK.

Fire is the only smartphone with Dynamic Perspective and Firefly. Dynamic Perspective is an entirely new sensor system that responds to the way a customer holds, views and moves the phone. The Dynamic Perspective SDK gives developers access to algorithms that identify the X, Y and Z coordinates of the head, enabling a whole new class of apps and games. Firefly quickly recognizes things in the real world—web and email addresses, phone numbers, QR and bar codes, movies, music, and millions of products, and lets the user take action in seconds—all with the simple press of the Firefly button. With the Firefly SDK, developers can extend the use of the Firefly button to enable new actions their users can take based on what they identify. For more information on the Fire phone SDKs, click here.

Optimizing Your Apps

Have an Android app already but not sure where to start with Fire phone? We offer plenty of tips and tricks to get your app quickly up and running on Fire phone.

A great way to get started is by using the app widget in Fire phone’s enhanced carousel, which enables you to expose content from your app directly on the home screen. Our enhanced carousel is not just limited to launching an app anymore. You can create app widgets that display actionable content below your app’s icon on the carousel. This experience makes your application more visible and accessible to your users. Users can immediately jump to any area within your app that you define or get important information they care about without having to open your app directly. Learn more.

Fire phone represents an incredible opportunity for HTML5 developers to create new experiences. Developers now have direct access to the hardware sensors that power Fire’s Dynamic Perspective, which opens up all kinds of new ways to let users interact with your web app content. Just like native devs, Fire phone’s four dedicated cameras offer x, y and z data that you can access directly to determine where the player’s head is looking at the screen, and shift the perspective to reveal new angles on what would have otherwise been a flat web page.

Over the course of this tutorial, we will walk through how to create a simple splash screen for a game in Phaser (a popular open source game framework). We’ll also cover how to take advantage of the ability to run web apps next to native ones on the Fire phone and how to add Dynamic Perspective to create a parallax layering effect which gives the scene more of an immersive experience. Before we get started, let’s take a quick look at the splash screen we’ll be creating:

Here you can see a standard splash screen for a game where the main player will float up and down, giving the scene some sense of motion. The start text also blinks to let the player know what action they should take.

This project will give you everything you need to run our project and has step-by-step instructions on how to get everything configured to run locally. Once you have everything set up, rename the Phaser Project Template to DynamicPerspectivePhaserDemo, then navigate into it via the command line. You’ll want to run the following command to get everything configured:

> npm install

Once that is done running, you should be able to launch the project by typing in the following:

> grunt

This will start a local server and open up your browser to http://localhost:8080.

Now we have everything up and running to build our Phaser splash screen. Just download the artwork from here. You’ll need to create an assets folder inside of the deploy directory of the Phaser Project Template. Once that is created, put all of the artwork you just downloaded into it.

One note: if you are using WebStorm, you will want to exclude the deploy/js folder from the Directories setting so you don’t have any performance issues as our grunt script automatically rebuilds the JS code for us.

Building the Splash Screen

Step 1. Let’s create a clean slate to work from by opening our main.js file in the src/game folder of the Phaser Project Template. Once you have it open, simply delete all the boilerplate code in that file.

Step 2. Next we are going to create our new state object and Phaser game instance from scratch by typing out the following:

This will calculate where we will center the background image. We’ll also save out the value for the background in order to use it as a reference point later on.

Step 6. If we refresh the browser, we’ll see our first glimpse at how the splash screen will look:

Step 7. Let’s get back into our code now and add in the player as well as the title and other elements that will help complete the scene. In our create() function. Below the background code we just added, put the following code:

Here you can see we are setting up our player as well as creating and setting a fly animation. We also save out our player’s start position, which we will use later on when we start modifying it based on the Dynamic Perspective code we’ll add for Fire.

This code will make the player float up and down as well as make the start text blink. You can test this by refreshing the browser again.

At this point, we have our entire splash screen laid out. Let’s talk about how to set up the Web App Tester on Fire phone to get our splash screen ready for adding the Dynamic Perspective APIs.

Configuring the Web App Tester

Just like you can currently do on the Kindle Fire, you’ll need to download the Web App Tester on the Fire phone for this next part of the tutorial. You can get the latest build from the Amazon Appstore here.

Step 11. Once you have the Web App Tester installed, you’ll want to look up your computer’s IP address.

Step 12. When you have the IP address, you can enter that into the URL field and save it.

Step 13. Now you can pull up the Amazon WebView to make sure everything is working. Once it’s loaded, you should see the splash screen running at full screen on the device. One thing to note is that we are not locking the rotation in this simple demo, so make sure you are holding the phone in landscape. Here is the splash screen being rendered at full 720P resolution on the Fire phone:

As you can see, the process for installing and testing hosted web apps on Fire phone is straight forward. We’ll be using the Web App Tester and Fire phone for the remainder of our tutorial to make sure we can properly test the Dynamic Perspective APIs.

Adding Dynamic Perspective

The good news is that the Dynamic Perspective APIs are built into the Amazon WebView we’ll be testing within the Web App Tester. That means that you don’t have to add in any extra JavaScript libraries to start using Dynamic Perspective in your own HTML5 apps and games, it’s ready for you right out of the box. Let’s get started:

Step 14. We are going to want to make some global variables to store the motion tracking data points we’ll be using in this example. At the very top of our project above where we declared our state object, add the following:

var dpX = 0;
var dpY = 0;
var faceDetected = false;
var scale = 2;

Here we are going to store the x, y values for the Dynamic Perspective x and 7 axis, whether facial detection is working, and a scale factor to help us manipulate the raw data into something more manageable.

Step 15. Now at the very end of our create() function add the head tracking event listener:

This will save the head tracking position values into our global variables that we set up previously. You’ll also see that we are dividing it by our scale to reduce the value a little so we don’t see large x, y values shifts since the original artwork is being scaled up to 1280 x 720 from 854 x 480. Remember that the data returned is relative to the size of the phone’s renderable screen area - not your game - if it’s up-scaled like we are doing here. You may want to modify these factors by the games scale factor instead. Here I am simply dividing them in half.

Step 17. Now let’s calculate the new position we’ll use to apply to each of our layers. Add the following to the top of our update() function:

Here we are using a method called clamp() which is part of the Phaer.Math lib. We supply our Dynamic Perspective x and y values along with a limit so it stays within the specified range. One thing to note is that since this splash screen is designed to run in landscape we need to swap the Head Tracking x and y values since they don’t change based on the phone’s orientation.

Now if you run the game on Fire phone and look at the device as well as move it around, you’ll see the background now subtly shifts in response to your head movement.

Step 18. Let’s add the same effect to our player. You’ll want to replace the current this.player.y line of code where we calculate the floating animation with the following:

Now we are modifying the player’s x position and adding the newPoistionY to the end of where we calculate the up and down value to create some additional movement along the Y position. You may also notice that we are not dividing the new x and y values by 5 like we did in the background. This allows us to give the layers a parallax effect so that the background will move at a slower rate.

Step 19. Run the scene again on Fire phone and you’ll see the final effect.

Publishing Your App

If you have previously published a web app to the Amazon Appstore, you can follow the same process. For those who are new to this, there are 3 easy steps after you have set up your free developer account and specified that you want to create a new app in the portal:

Step 1: Verifying Your Web App’s URL

You can now validate your web app’s URL right from the developer portal.

Simply put in the URL for your web app or game with the Fire phone code and click the verify button and the tool will let you know if the contents of the URL pass the preliminary submission requirements.

Step 2: Declaring Web App’s Permissions

Once your URL has been verified, you can select your app’s permission. Simply check off the options that apply to your app.

Step 3: Select Compatible Platforms

Then you can define which devices this web app can be published on.

While the Kindle Fire HD, HDX and Fire phone devices offer the best performance for web apps, make sure you test your web app on older devices to ensure the performance is ideal for your users. Intensive web games and anything using WebGL should be distributed on Kindle Fire HD and above.

While you can install web apps in the Amazon Appstore on any Android device that has the store installed, it will default to the native WebView on that device. This means that your app will not have access to the Dynamic Perspective APIs on other Android phones.

Step 4: Certification of Distribution Rights

Finally, certify that have the necessary rights to publish your web app.

Conclusion

As you can see, not only can you easily publish HTML5 apps and games alongside native Android apps through the Amazon Appstore, you also get access to the Fire’s Dynamic Perspective API just like native Android apps do. So be sure to submit your app to the Amazon Appstore to tap into millions of potential new customers.