No results found

Try a different or more specific query
Developer Console
Amazon Developer Blogs

Amazon Developer Blogs

Showing posts tagged with Games

June 28, 2018

Emily Esposito Fulkerson

Gaming has evolved into an all-around entertainment phenomenon. If you add up all playing and viewing hours, gaming is the world’s favorite pastime. And, with more than 2.3 billion active gamers in the world this year, this trend isn't going anywhere. 

[Read More]

August 04, 2014

Peter Heinrich

Fire TV is the perfect platform to showcase your Android game in a whole new way: through the home theater. With a Qualcomm quad-core Krait 300 CPU, Adreno 320 GPU, 2 GB RAM, Dolby Digital Plus Certified surround sound, and support for multiple game controllers, Amazon Fire TV packs a lot of power and features into a small package.

Game Catalog Growing Fast

Some of the most entertaining and recognizable game titles are already available on Fire TV, with more favorites launching every day. Shiny Box recently released a Fire TV version of its hit role-playing game Dungeon Quest, as did Disney with Castle of Illusion Starring Mickey Mouse. Other game makers, large and small, are also bringing their best games to the new device. Grand Theft Auto: San Andreas (Rockstar Games), The Wolf Among Us (Telltale Games), SoulCraft (MobileBits), The Bard’s Tale (inExile Entertainment), and Transworld Endless Skater (SuperVillian Studios) are just a few examples.

Huge Potential

It’s no wonder Fire TV is generating excitement among game developers. Fire TV offers a unique opportunity to reach more customers, making your games accessible on the largest and most prominent screen in the home. The high-performance Fire TV hardware is designed to make your game’s “ten-foot experience” look, feel, and sound great.

Built-in support for up to four game controllers (with extended support for up to seven) lets you engage the whole family in your multiplayer game. Add an alternative “second screen” interface to your game for an even richer and more immersive multiplayer experience.

Fire TV also supports Whispersync for Games, so you can ensure player progress is always safe and synchronized. Players can pick up your game right where they left off, even if they started playing on some other device, like a phone or tablet.

Easy Development

Fire TV is built on Android, so creating games for the living room is as comfortable and familiar as the mobile development you do today. Optimizing an existing Android game for Fire TV is also straightforward, so you can get the most out of the hardware—and guarantee the best player experience—with little effort. It’s easy to get started.

See our online documentation for information and tips on programming for the Fire TV remote and game controllers, ensuring your game will look its best on an HD TV, and using ADB to debug your APK with Fire TV. You can also learn about responsive game design, which makes it possible to develop games that scale across desktop, mobile, and TV.

Games and More

Games aren’t the only apps to benefit from Fire TV’s raw horsepower and programming flexibility. Music, Photography, News & Weather, Sports, and Entertainment are just a few of the categories growing fast as app developers expand into the living room. MLB.TV (MLB Advanced Media) and WWE Network (WWE) are excellent examples of mobile apps looking great for the 10-foot experience.

Take the Next Step

Fire TV has the power to make your Android games shine on the big (home) screen; take advantage of the opportunity to publish them directly to the living room. Check out our online documentation and blog posts about developing for Fire TV.

-peter (@peterdotgames)


July 23, 2014

Jesse Freeman

Welcome to part 3 and the final installment, of my Introduction to Phaser. In the first post, we configured our dev environment as well as the code we’ll need to run Phaser itself. In the second post, we covered preloading, displaying sprites and setting up the game modes. If you missed the two tutorials, please go back and follow those steps before moving on. In this tutorial we are going to cover the following:

  • Building A Wall
  • Spawning Walls
  • Debugging Walls
  • Handling Collision Detection
  • Adding Score
  • Adding Sounds

Let’s get started.

Building A Wall

Right now our game isn’t very fun or challenging. To help with this we’ll add walls with a small gap in the middle for our player to fly through. To get started, we’ll need to create two functions: one to spawn a wall and the other to put two walls together with the gap for the player to fly through.

Step 1. Add the following method to our state object:

spawnWall: function(y, flipped){


This function accepts the y position for the wall and if it needs to be flipped vertically. This is important since we will be using the same wall graphic for our top and bottom wall sprites. We’ll need a way to group them together into a single manageable game object.

Step 2. In our create() method, right under where we setup the background TileSprite we should add our wall group:

create: function(){
    this.background = this.add.tileSprite(0,0,,, 'background');

    this.walls =;

It’s important to create this after our background so it shows up on top. Now we’ll be able to access each of the wall sprites in our game from a single group which we are calling walls. This will make a little more sense later on when we add in collision.

Step 3. Add the following to our spawnWall() method:

spawnWall: function(y, flipped){
    var wall = this.walls.create(
        y + (flipped ? -OPENING : OPENING) / 2,

This adds a new wall sprite to our walls group. The staring x position is set to the width of the game so it starts off-screen and we also use the supplied flipped value to detect if the wall going to be displayed on the top or the bottom. To do this we take advantage of something called a Ternary Operator. Basically the way that this works is we have a condition to the left of the question mark and then the value if true followed by the value if the condition is false. Here is a representation of this:

condition ? true : false;

Step 4. Add the following constant to the top of our script:

var OPENING = 200;

Step 5. Add a few more lines of code to our spawnWall() function:

wall.body.allowGravity = false;
wall.scored = false;
wall.body.immovable = true;
wall.body.velocity.x = -SPEED;
    wall.scale.y = -1;
    wall.body.offset.y = -wall.body.height;

This disables gravity for the wall.  Then, we set the y scale to -1 if it’s flipped, or 1 if it is staying the same. We also need to adjust the y offset value of the body if the wall is flipped to account for the scale change we made on the previous line. Finally we set the velocity.x of the wall to our SPEED constant. You’ll notice we make this value negative. That way it moves to the left of the screen giving the impression that the player is flying past it.

Step 6. Add the following line to the end of the spawnWall() function:

return wall;

This will allow us to get a reference to the wall instance being created every time we call the spawnWall() method. We need to test if this works, but we’ll need to add a little bit of debug code first.

Step 7. Add the following line of code to our create method:


Step 8. Refresh the game in your browser and now you should see your first wall fly by below the player:

Step 9. To test creating a wall on the top of the screen, simply modify the wallSpawn() function to look like this:

this.spawnWall(300, true);

Step 10. With true being passed into wallSpawn() you can refresh the game to see the new wall on the top of the screen:

Spawning Walls

At this point we have the foundation in place for us to spawn the walls in our game. We’ll create a method to generate both a top and bottom wall as well as connect it up to a timer.

Step 1. Before moving on, make sure you comment out the spawn code we used to test with in the previous section:

//this.spawnWall(300, true);

Step 2. Now add new method called spawnWalls() with the following:

spawnWalls: function(){
    var wallY = this.rnd.integerInRange(game.height *.3, game.height *.7);
    var botWall = this.spawnWall(wallY);
    var topWall = this.spawnWall(wallY, true);

Take note that we added a s to this function’s name since our spawnWall() function only generates a single instance. In the spawnWalls() function we are taking advantage of Phaser’s RandomDataGenerator class. You can access it from the game object by calling this.rnd. This utility has a lot of useful methods for helping create random values in your game. We’ll be taking advantage of integerInRange() which requires a minimum and maximum value to return something in-between the two. Finally to keep the walls within the screen area we calculate the “safe” zone were we would want our walls to spawn by taking a percentage from the top and bottom of the visible area.

Step 3. Now we are ready to start a timer to spawn new walls. In our start() function, add the following code:

this.wallTimer = * SPAWN_RATE, this.spawnWalls, this);

Step 4. We’ll also need to add a new constant at the top of our script:

var SPAWN_RATE = 1.25; 

Step 5. Refresh your browser and you can now fly through an endless supply of walls being randomly generated at a set interval.

Debugging Walls

Everything is looking good but there is just one minor issue. While you may not see it, the walls that have moved off the screen are still in the game. We need to do a little bit of cleanup to make sure that we destroy any wall that is no longer visible.

Step 1. Add the following code to our update function right after we test if player is out of bounds:

if (this.player.body.bottom >= {

this.walls.forEachAlive(function (wall) {
    if (wall.x + wall.width < {

Remember back to when we set up our walls in the group? This forEachAlive loop allows us to easily iterate through all the wall instances inside of that group still active in the game. From there we setup a generic function to test if the instance’s x position is greater than the game world’s bounds.left value so we can destroy it. Calling kill() on an instance completely removes it from the game and from memory as well. Without this function, the game would have a memory leak which would cause performance issues and a poor user experience. Phaser also has some really great pooling classes but for this intro level tutorial we’ll just do this manually. The game is simple enough not to worry about the extra overhead we incur by creating new wall instances from scratch.

Step 2. In the reset() function of our state object add the following line:


This ensures we get a clean slate when starting the game over. And while we are on the topic of starting over, you may have noticed that the walls still scroll by when the game is over?

Step 3. Next, we’ll need to stop the walls from moving when we end the game. Add the following to our setGameOver() function:

this.walls.forEachAlive(function (wall) {
    wall.body.velocity.x = wall.body.velocity.y = 0;


This function will iterate through each wall instance and set the velocity.x to 0 to stop it from moving. We also stop the wallTimer to make sure nothing else gets created while the game is over.

Step 4. Run the game and make sure that the walls stop when game over before continuing on.

Handling Collision Detection

Now that we have walls, we can define what happens when a player hits a wall. Luckily for us, collision detection is really easy to implement in Phaser.

Step 1. To get started we’ll need a way to detect the actual collision. To do this, we add one line of code to our update function right after where we test if the player hits the bottom of the screen:

    if(this.player.body.bottom >={
    this.physics.arcade.collide(this.player, this.walls, this.setGameOver, null, this);

This tells the physics engine to test for any collisions between two game objects or in this case a single object, the player, and the walls group. The next parameter is the callback the collision check should trigger if an overlap is detected.  Finally, we need to pass the game’s scope to the callback parameter.

Step 2. At this point, everything else is already setup for us to build the game over state. Now if you test the game, you’ll see the game ends when the player touches the walls.

Step 3. When a collision occurs you may notice that the player actually bounces back. Add the following to the setGameOver() function to fix that:

this.player.body.velocity.x = 0;

Step 4. Run game and you’ll see the player no longer bounced back because we set the velocity.x to 0 when the game is over.

Adding Score

In this section, we learn how to add a function that increases the score when a player flies through the walls. To get started, we are going to need a way to determine if the player has flown past a wall, and then give them a score for it.

Step 1. We’ll need to add a new function called addScore() to handle the collision callback:

addScore: function (wall) {
    wall.scored = true;
    this.score += .5;
    this.scoreText.setText("SCORE\n" + this.score);

Here you can see we are getting a reference to a wall instance, adding a score and updating the score text. One thing to keep in mind is that since we have 2 instances, a top and bottom, that make up a single wall we only add half a point to the score. As the player flies past each wall section they will add up to a single value of 1 and the player will not even notice.

Step 2. Now we need to add in the logic to call addScore(). In the forEachAlive loop within the update() function, add the following:

this.walls.forEachAlive(function (wall) {
    if (wall.x + wall.width < {
    } else if(!wall.scored && wall.x <= state.player.x){

Step 3.  Now you can refresh the browser and as you fly through each section of wall you’ll see the score increase by 1.

Adding Sounds

We now have a functional game. The only thing missing is fun – we need to add some sound effects to round out the playing experience.

Step 1. Before we can access any sound effects we’ll need to load them up. Add this to our preload method:"jet", "/assets/jet.wav");"score", "/assets/score.wav");"hurt", "/assets/hurt.wav");

Step 2. Next we’ll create variables for each of our sound effects so we can access them easier. Add this to our create method:

this.jetSnd ='jet');
this.scoreSnd ='score');
this.hurtSnd ='hurt');

Step 3. Now it’s time to play our sound. In jet() function right after we set the player’s velocity.y to our jet constant add the following:

    this.player.body.velocity.y = -JET;;

Step 4. Now if you run the game and make the player fly, you should hear the sound. One thing to keep in mind is that each browser supports specific sound codecs. If you have any issues running the sound effects, make sure you are in Chrome or a browser that supports .wav playback.

Step 5. Next we’ll want to let the player know when they score.  To enable that, we need to add the following script to our addScore() function:;

Step 6. Add this to the end of our setGameOver() method to let the player know when they hit a wall or go out of bounds:;

Step 7. Now that we have the rest of our sound effects integrated, we can refresh the browser and test. You should now hear sounds when the player flies up, scores and dies.

Wrapping UP

At this point the game is basically done, and hopefully you’ve learned how some of the core mechanics of Phaser work.

To recap, we have covered importing assets, creating sprites, managing collision detection and playing sounds. There are a lot of really great resources out there to help you as you dig deeper into the Phaser framework. Make sure you check out the documentation as well as the samples included with the source code.  Also, feel free to take my existing codepen project and fork it to create your own variation of it.

One last thing I wanted to highlight is just how easy Amazon’s Web App tools are to use, helping to make publishing an online HTML5 game in the Amazon Appstore simple. I’ll be talking about how to take any HTML5 game and submit to the Amazon Appstore in a future post but the process couldn’t be easier. Here are the steps:

  1. Host your game online
  2. Download our Web App Tester to your Kindle Fire or Android device
  3. Put in the URL to your game to test that it works
  4. Sign up for free for an Amazon developer account and submit your game.

To learn more about the process, check out the documentation on our developer portal and the following reference links:

Related links:

- Jesse Freeman (@jessefreeman)

July 16, 2014

Jesse Freeman


For game developers, Fire’s Dynamic Perspective SDK opens up all kinds of new ways to let players interact with your game’s environment. The phone’s four dedicated cameras offer x, y and z data that you can use to determine where the player’s head is in relation to the device’s screen. This allows you to shift the perspective to reveal new angles on what would have otherwise been a flat image. Over the course of this tutorial, we will walk through how you can convert a simple splash screen to take advantage of a perspective camera, add Dynamic Perspective and create a parallax layering effect to give the scene more of an immersive feel. Before we get started, let’s take a quick look at how the splash screen appears before modifying it:

The above splash screen was built using Sprites in Unity 4.5 and setup with the Orthographic camera. You can download the original Unity project from HERE.

Getting Started

Once you have the project downloaded, open up the Splash scene inside of the Scenes folder so we can walk through how everything is set up.

Here you can see we have 5 sprites and our main camera. You’ll notice that our camera is set to Orthographic. We also have a black background to handle the outside areas around our artwork. Finally, each of our GameObjects has their own custom layer order so they render correctly.

If you run the project, you should see that our player moves up and down (appearing to float), and the start text blinks on and off. Inside of the Scripts folder you’ll find two scripts – “Blink” and “FloatEffect” that make this animation possible.

Now that you have a general understanding of how the project is set up, let’s start making the modifications to work with the perspective camera and lay down the foundation for adding in Fire’s Dynamic Perspective SDK.

Working with the Perspective Camera

Step 1. Select the Main Camera from the Hierarchy tab and change its Projection from Orthographic to Perspective.

You’ll see in the Camera Preview window that everything becomes smaller since the new perspective camera’s Field of View is set to the default value of 60.

Step 2. To start, let’s setup the game to run at the native resolution of the Fire phone (we’ll change this later). Go into the Game tab and select the resolution drop down. We’ll need to add a new resolution called 720p. It will look like this:

Step 3. Select the 720P resolution we just added and re-select the Main Camera so we can play with the Field of View until we find something we like.

Here I have set the Field of View to 30. Now the artwork is centered in the display correctly. Next, we’ll want to move things around a bit so that we add some depth to the scene.

Step 4. Go back into the Scene tab and change the following GameObject’s Z indexes like so:


Z Position











You should now see there is a difference between what you see in the Scene view (Object A, Left) and what you see in the Game tab preview (Object B, Right) due to the perspective camera and the new Z positions we just setup.

In the game, the objects closer to the camera such as the player, the title, and the “click to start” text are now larger. It’s important to keep in mind that you won’t see these perspective differences in the Scene tab so it’s best to do our layout work in the Game tab.

Step 5. Now we can start testing out how our camera will react as it changes position and rotation in preparation for adding the Dynamic Perspective logic. We’ll run the game and be manually changing the values of the camera on the fly.

Here you can see we are testing by modifying the X position and X,Y rotation values of the Main Camera to simulate our scene being moved all the way to the right-hand side of the screen.

It’s also important to note that we will use this technique to determine our minimum and maximum camera values of the scene inside of Unity itself. This is not something I advise doing on the hardware because moving the phone while trying to test it distorts the view. Instead, I recommend you test all the measurements in Unity. Before we move on, let’s make a few corrections. We’ll want to alter the Main Camera’s Z position to move it closer to the graphics and we’ll need to readjust the Field of View as well.

Step 6. While in the Game tab, you can preview the changes you just made. Change the Main Camera’s Z position to -4.2 to bring the camera in closer, and reset the Field of View to 67.2. This will center the screen better and help give us a better effect later on when we add in Dynamic Perspective. You’ll want to play around with the camera based on you own needs to find the ideal zoom level as well as distortion when the camera rotates based on the head tracking position.

You’ll notice that the perspective is a lot more dramatic. Now when the user is moving their head or the phone as the game is tracking their head position. Widening the Field of View and moving the Camera closer to the objects in the scene will create a little more distortion at the far ends of the screen helping emphasize the effect.

Step 7. Let’s make sure we stop the game, permanently make the Position Z and Field of View changes, and save the scene.

Correcting Layout for Perspective

Step 8. While our GameObjects look OK in their current position, we should make a few adjustments to ensure they stay in place as the camera moves around. To get started, make the following modifications:


X Position

Y Position
















Now all of our GameObjects are aligned a little higher on the screen to account for the shift in perspective. In a production game, you would want to detect if the Dynamic Perspective API is available via HeadTrackingReceiver.isAvailable() and possibly move the camera down a bit to compensate for the higher shift in perspective. You can just lower the camera since the code we’ll add will automatically reset the camera for you, but we don’t want to yet.

At this point you can run the game, play around with the X and Y Positions, and see the rotations of the camera. This will give you a sense for how everything will look when we add in our Dynamic Perspective logic.

Setting Up the Amazon Head Tracking Asset Package

Step 9. Now we are ready to import the libraries that will enable us to add Dynamic Perspective logic to our splash screen. You’ll find the Unity asset files in the Fire Phone SDK. From inside of Unity, select the Asset drop down and pick Import Package then Custom Package.

Step 10. You’ll need to find the Fire Phone SDK Unity Asset Package from the SDK folder. Once you select it, you’ll be presented with the following screen.

Here we are just going to import everything in the package. While we’ll only be focusing on the AmazonHeadTracking Plugin, you can also add Fire phone’s Motion Gestures to your game as well to add in support for those APIs. Once installed, you will now have a plugin folder along with the source code and sample scenes you’ll need to test out all of the features of the Fire hardware in Unity.


Creating the Dynamic Perspective Logic

Step 11. Let’s create a new script called HeadTrackingCamera. We’ll be using C# for the Script. Once you have the script open, add a few properties to the top of the class.

public float movementScale = 5.0f;

private Vector3 newPosition;

Step 12. The first property will represent the multiplier we will use on the X and Y position we’ll receive from the Dynamic Perspective API. The newPosition property will store the updated X and Y values for the camera after we do our calculations on the raw Dynamic Perspective data. Now add the following to the Start() method:

newPosition = transform.position;

This will save our initial camera position, and, moving forward, we will modify the X and Y properties of this vector instead of creating a new one from scratch.

Step 13. In our Update() method we are going to need to test that the Dynamic Perspective API is working and that we can access its data so add the following:

void Update() {
if (HeadTrackingReceiver.isAvailable &&
(HeadTrackingReceiver.lastEvent != null && HeadTrackingReceiver.lastEvent.isTracking)) {

Here you’ll see that we can talk directly to the HeadTrackingReciever class and access its data. We’ll be testing if it’s available, that the last event isn’t null and that it is still tracking the user. We want this to shut down if it stops tracking the user’s head.

Step 14. Now we can add our position calculations. Add the following inside of the new conditional we just created:

newPosition.x = Mathf.Clamp(HeadTrackingReceiver.lastEvent.x * movementScale, -.7f, .5f);
newPosition.y = Mathf.Clamp(HeadTrackingReceiver.lastEvent.y * movementScale, -.2f, .5f);
transform.position = newPosition;

We are getting the last event’s X and Y values, multiplying it by the movementScale we set up at the top of the class and using a Clamp() to keep it within a certain range of values. I have figured out the optimal values for you based on how far the scene will look when at the edges of the screen, which should help keep our scene in the camera’s view later on when we add the rotation to the camera.

Step 15. Before we test, we’ll need to add this script and the HeadTrackingReciever, which samples for new data every update during the Unity game loop, to the camera.

Step 16. At this point you are ready to test your game on the Fire device. Make sure Unity is set to Android as your platform and do a Build and Run of the game.

When you run this for the first time, you may be asked to locate your Android SDK. Just point Unity to the root of the SDK folder. You may also get the following error:


If you haven’t already done this, you’ll need to change the Bundle Identifier. From the Build Settings menu, select Player Settings, then change the default value of the Bundle Identifier.

Also, while you are in the Settings for Android tab, change the rotation to Landscape Left.

Finally, save your Android build to its own folder in your project.

Once you have the Scene deployed, you should now be able test out the Dynamic Perspective.

Step 17. We’ll also need to add a few properties to the class to make this work:

public float smooth = 1.0F;
public float tiltAngle = 2.0F;

Step 18. After running the project on the phone, you may notice that the parallax effect isn’t very dramatic. While it’s a cool effect, we can greatly enhance it by simply modifying the rotation of the camera in addition to changing its position. Below where we set the new transform value, let’s add this code:

float tiltAroundX = HeadTrackingReceiver.lastEvent.x * tiltAngle;
float tiltAroundY = HeadTrackingReceiver.lastEvent.y * tiltAngle;
Quaternion target = Quaternion.Euler(tiltAroundX, tiltAroundY, 0);
transform.rotation = Quaternion.Slerp(transform.rotation, target, Time.deltaTime * smooth);

Step 19. Now if you re-run the project on the phone, the effect will be a little more dramatic since we are also rotating the camera to match the shift in X and Y position.


At this point, you now have a reusable script you can apply to your camera that takes advantage of Dynamic Perspective in your Unity games. You don’t have to limit this to just the splash screen; I’ve been playing around with adding it to my main game scenes as well wherever I can take advantage of subtle shifts in perspective. When done correctly, the Dynamic Perspective effect is incredibly powerful. Use it to show off parts of the scene that may have normally been blocked by other items in the foreground, or just as a subtle way to add a little more depth to your Unity scenes. I also suggest checking out the Motion Gesture examples included in the Head Tracking Asset Package to add peek and tilt events to your game as well for menus and even to control elements in the game itself.

Now Is the Time to Submit Your Apps for Fire

Create immersive apps that respond to the way a customer holds, views and moves the phone. We have updated Appstore Developer Select, Amazon Mobile Ads API, and Amazon Testing Services with more incentives:

  • Appstore Developer Select: Optimize your apps for Fire phone and get enhanced merchandising and 500,000 Amazon Coins incentives for your customers. Get the details here.
  • Amazon Mobile Ads API: Developers earn $6 for every thousand interstitial ads displayed across any supported device in August and September (up to one million impressions per app per month) when they distribute their apps on Fire phones and send the first ad request from a qualified app. Get the details here.
  • Amazon App Testing Service: Most Android apps just work on Fire mobile devices. Test your app's compatibility in 90 seconds by dragging and dropping your Android APK into our testing tool. Sign up for a free developer account to test your app's look and feel on devices and get the results within 6 hours. Test your app now.

Now is the time to submit your apps and games! Apps that are submitted by July 18 and approved will be in the Amazon Appstore when Fire ships on July 25.

Fire Developer Resources:

July 01, 2014

Peter Heinrich

Starting today, there will be a single, centralized place where customers can easily find discounted apps on the Amazon Appstore, called Deal Center. Deal Center makes it easy for customers to discover deals set up through the Developer Promotions Console, as well as promotions offered through Amazon’s Appstore Developer Select and Free App of the Day programs.

Reach New Customers with Deal Center

Deal Center is a special section of the Appstore on Kindle Fire HDX and HD devices dedicated to promotions and discounts. It is designed to help developers acquire new customers. Deal Center is implemented as a collection of widgets, each of which displays a different type of deal or product. Customers can see several offers at a glance and follow links to browse all discounts that are available.

Discounts that were previously visible only from the detail page associated with your app are now easier to find, and feature individual Buy buttons to simplify purchase. Customers can install apps right from Deal Center without having to navigate to the detail page for each app.

Deal Center is the home for all promotions across the Appstore, so apps that feature Amazon Coins back offers as part of the Appstore Developer Select (ADS) program are prominently visible. The Free App of the Day will also have a new home on Deal Center.


How Do I Participate?

You don’t have to do anything special to benefit from Deal Center’s high visibility and eye-catching placement of deals and discounts. Discounts set up through Developer Promotions Console will be featured on Deal Center without any additional steps required. If you are an ADS developer, Coins back offers on your apps will be featured on Deal Center in addition to being featured on the Appstore on Kindle Fire.

For more information about setting up price adjustments and promotions, see Easily Manage Pricing & Discounts: Developer Promotion Console.

-peter (@peterdotgames)


June 19, 2014

Peter Heinrich

Were you able to attend Amazon’s Pre-Conference Developer Day at GDC 2014? Video recordings of all the sessions are now available online, so it’s not too late to learn how Amazon can help you build, engage, monetize and distribute your game.

Cross-Platform Services by Amazon Support You All the Way

Amazon hosted a day of pre-conference sessions at GDC 2014.  Amazon experts demonstrated how AWS and Amazon’s mobile services can simplify every stage of game development including: building the backend, expanding to additional platforms, and scaling to handle more players.  The day also featured customer case studies that revealed best practices around: game architecture, game design, cloud technologies, and monetization strategies.

The sessions videos and supporting slides are shared on our GDC 2014 page.  The sessions posted include:

  • AWS Architecture — Nate Wiger, Principal Solutions Architect, Amazon Web Services: Mobile, AAA, and MMO game companies alike are leveraging AWS to build cost-effective, scalable online games.  Learn how game studios are using AWS services such as Elastic Beanstalk, DynamoDB, Amazon S3, CloudFront, and ElastiCache to build online games that can scale from 1,000 to 1,000,000 users, while paying only for what they use.  Finally, Nate shares some thoughts about the future of cloud gaming based on worldwide trends.
  • Game Analytics — Nate Wiger, Principal Solutions Architect, Amazon Web Services:  Free to play is now the standard for mobile and social games.  But succeeding in free-to-play is not easy:  You need in-depth data analytics to gain insight into your players so you can monetize your game.  Learn how to leverage new features of AWS services such as Elastic MapReduce, Amazon S3, Kinesis, and Redshift to build an end-to-end analytics pipeline.  Plus, Nate shows you how to easily integrate analytics with other AWS services in your game.
  • Engaging Your Audience with Mobile Push Notifications — Jon Turow, Senior Product Manager, Amazon Web Services & Mike Pesce, Senior Manager, Amazon: Mobile push notifications are a fast and universal way to engage and retain players.  Amazon Simple Notification Service (SNS) provides one simple API for fast, reliable, scalable, inexpensive push notifications to Apple, Google, and FireOS devices.  In this session Jon and Mike cover how to use Amazon SNS to publish cross-platform notifications and then, architectures and techniques for utilizing game data to send the right message, to the right player, at the right time.
  • Amazon AppStream – New Gaming Experiences Using the Cloud for Game Streaming — Collin Davis, GM of Amazon AppStream, Amazon: In this session you’ll see how AppStream, Amazon’s low latency application:  streaming service, can help you create new compelling gaming experiences across many platforms.  Collin details how one team used the flexible platform to remove device constraints and enable new gameplay experiences.  You’ll see a tablet demo that exhibits a massive scale and streams from AWS to the tablet to create one single “hybrid” game that goes beyond what you could do on a tablet alone.
  • What's Working in In-App Monetization — Mike Hines, Developer Evangelist, Amazon: In this session we share data and tips that Amazon has gathered from the top 50 revenue-generating apps that use IAP. Then we look at some innovative mobile ad ideas and explore the re-discovered future of in-app monetization…e-commerce. 
  • A/B Testing with Air Patriots — Paul Cutsinger, Developer Evangelist, Amazon & Russell Carroll, Senior Producer, Amazon: A/B Testing is about using data to challenge assumptions and test new ideas, often leading to increased engagement and monetization.  In addition to showing you the latest cross-platform testing services at your disposal, we discuss the "happy accident" that the Air Patriots team made. It was unexpected and led to an increase in both retention and monetization.
  • Large Scale HTML5 Games on Desktop, Mobile & Tablets with KANO/APPS — Jesse Freeman, Developer Evangelist, Amazon & KANO/APPS: Join us as we explore the current and potential future landscape of HTML5 games with our guest speakers from KANO/APPS, makers of Mob Wars: La Cosa Nostra, Zombie Slayer and more. We discuss how they transformed the iconic Flash game Free Rider into a thriving online HTML5 destination. We also demonstrate how Amazon enables publishing these kinds of HTML5 games to the Kindle Fire.

Learn More

For more information about developing cross-platform games with Amazon, working with the services discussed in the videos, and expanding to additional devices such as Kindle Fire and Fire TV, visit our developer website and the AWS gaming page.

To register for a free developer account, click here.

-peter (@peterdotgames)


June 18, 2014

David Isbitski

Today in Seattle, Amazon founder Jeff Bezos unveiled Fire, the first phone designed by Amazon. Fire is the first and only smartphone with Dynamic Perspective and Firefly. Dynamic Perspective is an entirely new technology that responds to the way a customer holds, views and moves the phone. For example, Zillow is using the Dynamic Perspective SDK to create the ability to zoom in on pictures within their app by just moving the phone closer to the user. The revolutionary Firefly technology already recognizes movies, music and more and 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 can identify. As a developer, these new technologies enable you to create more immersive experiences in your apps and games that increase user engagement.

The Fire SDKs are available now, and make it easy for developers to take advantage of these features in their apps. These SDKs were designed to offer developers power and flexibility with pre-built controls, low level APIs, and complete UI frameworks. You can download both SDKs here.

How Developers Are Using Dynamic Perspective

Fire apps are built with the same familiar Android development environment you are used to. Fire provides a powerful set of hardware to bring your apps alive. With 2 gigabytes of RAM, a powerful Qualcomm Snapdragon 800 Quad-core 2.2 GHz CPU and an Adreno 330 GPU, Fire will support the high performance game experiences customers crave. For detailed technical specifications of Fire, click here.

Zillow used the Dynamic Perspective SDK to integrate real-time information into their app’s user experience. In the Zillow app for Fire, customers can view new listings or nearby homes for sale and rent, right on the Fire carousel without having to open the Zillow app. In addition, Zillow brought a new photo experience to the device so users can use their head to zoom in on a bedroom or peek to see what's around the kitchen corner. “Real estate shopping is an inherently mobile experience so any chance we have to bring listings or new information to a home shopper while they're out on the go is a great thing,” said Jeremy Waxman, Vice President of Marketing and Mobile, Zillow. “Photos are incredibly impactful for home shoppers—it is the most common activity for users of our app. We are thrilled to be able to go one step beyond static images and offer our users the opportunity to zoom in on the photos and then peek around the room with the Dynamic Perspective SDK.”, the creators of Snowspin and Crazy Snowboard, used the Dynamic Perspective SDK to allow a customer to navigate the endless runner game with just their head—no tapping on the screen necessary. Using head and hand movements, users can control direction and speed. Users can interact with games in a more immersive way – without their hands getting in the way of game play. Additionally, created a special flip jump in Snowspin currently exclusive to Fire customers with just a flick up of the head. “Porting our existing Android versions of Snow Spin and Crazy Snowboard to Fire couldn’t have been easier, and we were able to add new innovative game moves such as a double backflip with just the flick of your head, enabling even higher scores,” said Simon Edis, CEO of “The Amazon team had all the tools ready to go, making it super easy for us to just drop them in our games and publish.”

CrowdStar used the Dynamic Perspective SDK to create the ability for Covet Fashion users to select their favorite fashion choices for their model. Using zoom and tilt, players can see details of outfits to vote on looks. “Dynamic Perspective is so innovative we’ve just begun to figure out how to take advantage of all the technology has to offer. The simplicity of the user interface and design around a one handed experience will really allow us full creativity as we look ahead in our portfolio of apps and games,” said Jefferey Tseng, CEO of Crowdstar. “Dynamic Perspective has unlocked capabilities we’ve always wanted to create in our game—incorporating zoom and pan in an incredibly natural way without having to touch the screen, is the first example.”

Firefly – Experiencing the World around You

Firefly understands your surroundings, instantly helping you to learn more, discover new things, and take action on the world around you. It can scan physical objects, identify them, and obtain related information about them. Everything from book covers, album covers, bar codes, QR codes, movies, television shows, songs and more. Developers can use the Firefly API to supplement item identification or build actionable options for customers after an item is recognized. For example, iHeartRadio used the Firefly SDK’s built-in music recognizer and music database to identify a song playing. Then they built their own Firefly action to create a station based on the song Firefly recognized.

Go beyond Touch with Shortcut Gestures

Because phones are often used with only one hand, Fire also offers one-handed shortcuts that go above and beyond touch. These shortcut gestures allow you to simply angle the device and “peek” into additional information that your apps can display on screen. For example, customer ratings in the Amazon Appstore instantly appear over each app’s icon when the device is tilted. Navigation is enhanced with gestures: moving back is as simple as flicking up on the screen with a finger, while tilting the device in either direction brings up two additional panels for navigation and contextual information. Gestures can even be integrated inside your games so that users can experience the game in a more intuitive way. Imagine moving a character on screen simply by titling the device instead of having to cover what’s on the screen with your finger.

Creating Multi-Dimensional Experiences inside Your Apps with the new SDKs

Fire enables new ways of interacting with your phone by simply rotating the device around X, Y and Z axes. These gestures were designed to be used with only a single hand, a common scenario when using a phone. We’ve created a framework that integrates directly with these gestures and Fire’s new sensors, making it a simple process to integrate within your own apps.

Fire SDKs and APIs

The underlying technology for Dynamic Perspective and Firefly is sophisticated, but Amazon makes it simple for developers to harness their capabilities. See a full breakdown of the SDKs and their contents here.

Dynamic Perspective SDK

The Dynamic Perspective SDK includes a series of APIs and Controls to help developers create peek, tilt and zoom capabilities within their app based on customer head movements, create multi-dimensional game play, or provide quick navigation menus by tilting the device to the left or right. These experiences are created through a variety of visual effects including adding shadows, depth and tracking head and motion gestures. For example, you could create an app that allows you to peek at how many pages are left in the book you are reading, or browse your apps as if you were flipping through a physical file drawer. Flat cartoonish icons and graphics could be replaced with realistic visuals that use lighting, shadows and motion to create an experience you would want to show off at every opportunity.

Firefly SDK

With the Firefly SDK, developers can build apps that recognize real world objects—music, movies and more—and let customers interact with them. As a developer you can create more immersive experiences that increase both engagement and the frequency of app use. The Firefly SDK comes with built-in recognizers and databases for products, music, movies, URLs, and websites, as well as built-in actions such as dialing a phone number, looking up an object on Amazon or going to a website. Developers can use the Firefly SDK to take advantage of the built-in recognizers, databases and actions.

Fire is Android Compatible

Fire is based on Fire OS so if an app runs on Android it can run on Fire with little to no work. For a developer who just wants to get started with Fire they can do a simple port, or they can use the Fire SDKs to easily integrate UI features such as shadows or hovering images within the app or game, or creating left and right panels based on Fire’s three-panel UI design.

Fire uses the same familiar Android development environment, and while Android Studio is fully supported IDE, you can also use Eclipse and other IDEs. Android Studio Gradle support is also supported for builds. An API simulator for the Side Panels and Carousel is included to test code on stock Android emulators and devices without needing a physical Fire device.

We know that many Android apps and games are built with various technologies so the Fire SDK includes support for those as well. Unity, HTML5 and C++ are all supported. For additional details on using third-party frameworks click here.

Now Is the Time to Submit Your Apps for Fire

By optimizing your apps for Fire, you have the opportunity to create compelling experiences that combine realistic visuals, with both depth and perspective allowing customers to use their smartphone in ways never done before. Starting today we are updating Appstore Developer Select offerings, Amazon Mobile Ads API, and Amazon Testing Service with special Fire incentives.

Amazon Developer Select: Amazon will offer 500,000 Amazon Coins ($5,000 value) for each of your qualifying paid apps or apps with in-app purchasing that meet the additional program requirements for Fire Phone. You can create campaigns via the Promotions Console to give these Coins away to consumers purchasing any of your paid apps or in-app items. For more details on the Amazon Developer Select program for Fire click here.

Amazon Mobile Ads API: Developers earn $6 for every thousand interstitial ads displayed across any supported device in August and September (up to one million impressions per app per month) when they distribute their apps on Fire phones and send the first ad request from a qualified app. For more details on the Amazon Mobile Ad Network Interstitial CPM Offer promotion click here.

Amazon App Testing Service: We have also expanded our testing tool to Fire. Developers can now test their Fire apps before submitting them to the Amazon Appstore. Developers simply drag and drop an app and most will receive feedback about their app’s compatibility within 90 seconds. Additionally, registered developers have access to additional Fire test results that check the app’s experience. These tests enable developers to see how an app looks and performs on an actual device sitting in an Amazon device lab.

With the launch of Fire, Amazon now offers a complete device and apps ecosystem spanning across tablet, phone and TV. Customers pay for your apps once and interact with the experiences you create across all their screens. As a developer, you only need to submit your app once and with few changes make it available to your customers across all Amazon devices. Now is the time to submit your apps and games!

Additional Fire Developer resources:

-Dave (@TheDaveDev)


May 20, 2014

Jesse Freeman

If you followed along from the first part of this series you should be up to speed on how the Unity IDE works. In this post we will dig deeper into the code side of things. I am a big fan of C#, and while Unity Script is useful, eventually you will need a little more flexibility in your code. So, to help you along, I thought it would be valuable to write a quick primer on working with C# in Unity, as well as some of the most common APIs you will be using when we build our game.

Picking a Code Editor

In order to code in Unity you will need to pick an external editor since Unity doesn’t have one built in. By default, Unity ships with MonoBuilder, but you can just as easily switch it out for something a little more robust, such as Visual Studio if you are doing your development on Windows. Simply go into the Edit > Preferences menu and change the path to the external editor.

Once you have picked an editor you like, you are ready to start coding. In this post, I will be showing the code from Visual Studio, but MonoDeveloper will work similarly to Visual Studio but on Windows and Mac.

Data Structures

C# is a strongly typed language and is very similar to Java or ActionScript 3. If you have some background in JavaScript, it should feel familiar as well. Let’s take a look at the basics of the language. To start with, we will look at variables and lists, which are the building blocks of any language. To make a variable, simply declare it, like so:

var name = “Jesse Freeman”;

While C# is a typed language, it supports type inference, meaning that when you declare a variable you don’t always have to define the type. There are a few primitive types you should know about:

string name = “Jesse Freeman”;
int age = 34;
bool alive = true;

When it comes to numbers, you should also understand more complex types, such as Float:

float speed = 4f;

Notice that we use the f suffix for our float. Floats are numbers that contain decimals and are used for more granular positioning within the game world, as well as in the built-in physics engine. Ints are useful for whole numbers where you don’t need to perform calculations that would generate fractions, such as a player’s health. You should always be aware when using Int, Float, or other number types because you may be forced to cast it to a specific type in order to perform the calculation and you may incur a performance penalty. Here is an example:

float example = (float)age * speed;

You can learn more about the different types in the C# reference docs at The next set of building blocks is Array and List. An Array is collection of multiple variables, usually of the same type.

var stringArray = new string[2];

In C#, Array are fixed meaning you can’t alter their length. You can modify its contents via their position in the Array itself. The position is an id, which represents a unique number for each location in the Array. In C#, arrays start at 0.:

stringArray[0] = “Jesse”;
stringArray[1] = “Freeman”;

You can access values in an Array by their index just like we modified it. Here is how I would create a string with my full name from the above Array:

var name = stringArray[0]+” “+stringArray[1];

Unity also supports Lists as part of the C# library. In order to use this, you will have to import its package (System.Collections.Generic) at the top of your script, which I will show you how to do later on. For now, here is an example of a list:

List<int> listOfInts;

This is what we would call a generic List. The term generic refers to a dynamic type we can assign at runtime. Generics are a core part of the language, and something you should get familiar with as you gain more experience coding in C#. In this example, we can create a list with a type of Int. Now this generic list can contain whole numbers. For performance, you will want to use lists over arrays when you don’t know the exact size of the data and expect to be adding or removing values at runtime. An Array by contrast has a set number of items you can have in it and shouldn’t attempt to modify the length at runtime.

The last data object I want to talk about is a vector. Unity makes use of a Vector3, but now with the addition of the 2D workflow, they now rely on Vector2D a lot more. Here are examples of both:

var v3 = new Vector3(0,0,0);
var v2 = new Vector2(0,0);

Vectors allow you to store 3D or, in this case, 2D points in space so you can access the value of x, y, and z from the vector. Here is an example:

Debug.Log(v3.x); // will output 0

One quick note is that you see I am calling Debug.Log. This will output the value to the console window.

This is similar to most other languages, such as JavaScript’s console.log and ActionScript’s trace. It’s also the first step in debugging your apps if you ever need to see the value of an object or property.


C# takes full advantage of classes, interfaces, and a host of other ways of packaging up code for reusability. Unity itself is built on a very easy-to-grasp composition system, which it favors over inheritance. Let’s look at how to make a simple class. Go to the Create menu and select a new script.

As you begin to create a new script, you will notice you can select from the three built-in languages. Select C# and call the script HelloWorld.

Unity will stub out the code you need for your class for you. Here is what it will look like:

using UnityEngine;
using System.Collections;

public class HelloWorld : MonoBehaviour {

	// Use this for initialization
	void Start () {
	// Update is called once per frame
	void Update () {

As you can see, you won’t need to memorize how to create a class from scratch, so I will simply focus on two main parts of the script: the import block and the methods. By default, each new class extends from MonoBehavior. There are numerous methods you can take advantage of, but we’ll start with the first two: Start and Update.

Let’s go back to our previous example of a generic list. While this isn’t the traditional way of doing a Hello World example, I’ll be able to show off in a little more detail what it is like to import external libraries, create properties on a class, and output that to the console window. To start, look at the top of the class at the import statement and add the following:

using System.Collections.Generic;

Now, just before the Start method, we are going to add a property. Properties are variables that are scoped to the instance of the class itself. That is a fancy way of saying that anything inside a block of code will have access to its contents. Depending on how we declare the property, other classes will have access to it as well. C# supports private and public variable denotations. If you don’t declare one, it will automatically default to private. Add the following property above our Start method:

public List displayText;

Now, in our Start method, add the following:


Now we need a way to display this text. Add the following to the Update method:

Debug.Log(displayText[0] + “ “ + displayText[1]);

Here you can see we are using the Debug.Log method again, and we are accessing the first and second values of our list. It’s important to note that arrays and lists are 0 based in C# just like Java, AS3, and JS. Now we have a script that will output Hello World to the console tab on each frame, but we don’t have a place to put it. Go back to the Scene and select our camera. From here, scroll down to the bottom of the Inspector panel and select Add Component. Now select our HelloWorld script and it will attach itself to the camera.

Now, if you run the game and look at the Console tab, you will see Hello World outputted on each frame.

While this is a simple example, let’s do something a bit more interesting. Go back into your script and let’s have the camera scroll to the right. The camera is a GameObject just like any other primitive you add to the Scene via the Create menu. All of these GameObjects share some common properties, with position, size, and scale being just a few of them. Also, all of these GameObjects share the same API we are taking advantage of right now, which are the Start and Update methods. Let’s look at how we can programmatically move the camera. To get started, let’s add a new property called:

public float speed = 2f;

Next we’ll want to replace our Hello World Debug.Log call with the following:

transform.Translate(new Vector3(speed, 0, 0) * Time.deltaTime);

As you can see, we have taken the transform position property and are modifying it with a new Vector3 that contains our speed value and is multiplied by the Time.deltaTime. If you simply increased the x position by speed, you are not taking into account any slowdowns in the game itself. By using the delta between each frame, you are able to keep your movement consistent from frame to frame, regardless of dips in the frame rate. This isn’t a magical formula; all it means is that your GameObject will move at the desired distance over time. So if the frame rate drops, movement will look jerky but won’t slow down or speed up as the FPS naturally fluctuates based on other things going on in the game.

If you run the game, you will see the camera move. It will appear like the box that we created earlier is simply scrolling off the left side of the screen. Stop the game and take a look at the camera’s Inspector panel. If you scroll down to the script area, you will see we now have a new input field called Speed we can alter.

This is an important concept in Unity. Basically, any public property on a script can be edited from the IDE in the Inspector window. So, while it’s important to create default values for your properties, just know that you can alter those values on an instance-by-instance basis, and even temporarily at runtime when you are debugging. This is incredibly powerful and something we will be taking advantage of later on. Not only does this work with simple properties, such as Strings, Numbers, and Booleans, but it also works with collections, such as Arrays and Lists.

If you remember back to our first example, we had a list called displayText, which we also made public. You should see it in the Inspector panel as well, but the value is hidden. Simply click on the arrow next to its property name. You can even add new items to it by changing the Size value.

So, at this point, you should have a basic concept of how scripting works in Unity. Everything we covered here will be re-introduced in the following chapter. There is just one last thing I want to cover, which is how to think through scripts for GameObjects.

Composition over Inheritance

If you come from a traditional computer science background or have worked with other object-oriented programming languages before, you may be familiar with the argument on composition over inheritance. One of the cornerstones of OOP languages is the concept of polymorphism. While inheritance plays a large role in game development, Unity strives for the use of composition as much as possible. I consider scripting in Unity to follow the decorator and component design pattern. Each script adds additional functionality to your GameObject, but they are mostly self-contained. While some scripts rely on others to function, as we will see in the game we end up building, we really strive to create small, reusable blocks of code that can be applied to multiple GameObjects. When put together, each of these smaller scripts build up to a greater set of logic that builds up the functionality of each GameObject. While inheritance is possible, I strongly recommend thinking through composition as a means to not only create more modular, self-contained code but to also separate and encapsulate independent game logic. This kind of thinking is critical when it comes to grasping the true power of creating scripts in Unity.

Wrapping Up

By now I am sure you are itching to get into more coding, so start playing around with some of the great tutorials out there on Unity. We’ll continue to add new posts about Unity, especially with working with the new 2D workflow, over the next few months so make sure you keep checking back.

Also, don’t forget that to checkout Amazon’s GameCircle plug-in for Unity to help you integrate cross-platform leaderboards, achievements, and game data synchronization. The plug-in works on iOS, Android, and Fire OS plus with the built-in Whispersync for Games component you can back up all of your user’s game data to the cloud across all three platforms. You can now download it from the Scripting/Integration section of the Unity Asset Store.

Additional Resources

-Jesse Freeman (@JesseFreeman)


May 19, 2014

Jesse Freeman

Unity is the de facto game framework and IDE for a lot of the success stories you read about on multiple platforms. The IDE is very polished and easy to use. As Unity was previously just a 3D tool, there was a certain level of knowledge you needed before getting started. Now with the addition of an all-new 2D workflow, things have gotten a lot easier for game developers looking to build simple, non-3d games. In this post we’ll take a look at how the Unity IDE works for 2D game development.

Over the next few sections, we will take a look at the IDE itself and how to navigate around it and GameObject, which are the building blocks of your game. There are a lot of resources out there on Unity, but for people who have never opened it up before, this post will help get you acquainted with the basics in the IDE.

Creating a New Project

When you create a new project in Unity, you will see the following wizard:

As you can see, you are given an option to set the location of where you want to create your project, as well as packages you can include when it is created. The final thing to note, which is new in Unity 4.3, is the 2D setup tab at the bottom of the window.

By setting this to 2D, your project will automatically be configured for 2D game development. Let’s create a project called SPMS2D and toggle 2D.

Once you create your project, you will go into the editor and see the “Welcome To Unity” screen. I highly suggest going through some of the videos to learn more about how Unity works and get a sense for the workflow. Most of it is geared toward 3D, but it still applies to the stuff we will go over in this blog. I also suggest checking out the forums since there is a lot of really good information on there that can help you out when you get stuck as you are getting started learning Unity.

How to Use the IDE

At first, Unity may be a little intimidating, but I personally find that the new 2D mode actually simplifies things greatly. Here is a high-level overview of the IDE. When you first open up a project in Unity you will see the following window.

Let’s go over each section of the IDE’s window by window. First, we’ll start with the main area.

This is where you will lay out objects, preview and test your game, and also work on animations and other visual-based activities. As you can see from the tabs, the Scene and Game tabs are already open. Below the tabs, you will see a few quick-access menus. The most important is the 2D toggle, which is already activated. By unchecking it, you will go back into Unity’s native 3D view.

I’m not going to go into the 3D navigation tools since we will be focusing on 2D instead so let’s look at the Hierarchy panel.

As you add stuff to your scene, you will be able to see and access them from here. For now there is a single object, which is the camera. Also, you have access to a Create shortcut menu, which we will be using a little later on. The same options can be accessed in the IDE’s top menus as well.

While you are looking at the Hierarchy tab, select Camera so we can discuss the Inspector panel next.

Here you can see all of the properties that make up the camera for our game. Unity does a great job of visualizing all the parts that can be configured on each object in your Scene. The Inspector panel not only allows you to modify values, even on the fly while the game is running, but it also lets you add additional functionality onto any GameObject via the Add Component button.

We will get into some of these components a little later on, especially scripts, which will make up a huge part of your coding experience. For now, it’s important to note that a GameObject is anything in the game itself and may be the camera, the player, or even more complex objects like levels, UI or even utilities we build to help us visualize elements in the game. Next up is the Project tab.

Think of this as a view into the project folder itself. To help you better understand it, go to where you created your project on your system and open it up.

As you can see, in addition to all of the additional files that make up the Unity game project, you will see there is an Assets folder. This becomes your default location for everything you put in your game. Here we will store artwork, sounds, scripts, and prefabs, which are reusable pre-configured GameObjects.

The final two things I want to cover may be self-explanatory but are always useful to review. In the upper-left corner you have a set of controls to help you navigate the Scene window.

While these tools are mostly focused around navigating a scene in 3D mode, they don’t have much use in 2D mode. When working in 2D the tool you will use the most is the Hand to simply drag the screen around on the x- and y-axis.

The other set of controls handles playback and allows you to test the game.

Simply hit Play to start the testing in the Game tab.

You will also notice the Pause and Step-Forward buttons. These are incredibly helpful in allowing you to move through the game frame by frame to see what is going on. You can also go back to the Scene tab while playing the game and modify values of GameObjects at runtime. It’s important to note that any changes you make in the Inspector panel while running the game don’t get saved; it simply allows you to try things on the fly without having to stop testing, make a change, and recompile.


Before we get into the coding and specific 2D tools, I wanted to provide some information about GameObjects, which are the building blocks of a Unity game. As you begin to flesh things out, you will start by creating these GameObjects in the Scene. Some of them will represent your Player, bad guys, and level while others will make up utilities and Gizmos, which we will learn about later on, to help you manage other GameObjects in the game.

To get you used to working with GameObjects, let’s just create a simple cube and position it in our Scene. Go to the GameObject menu at the top, or the Create menu from the Hierarchy panel, and select Cube.

Now, if you check your Hierarchy panel, you will see the cube and the camera. Select the cube to bring it up in the Inspector panel.

If you run your game now, you will not see the cube. Likewise, you can click on the camera to preview the Scene without even hitting Run.

We can fix this by adjusting the cube’s z-axis in the Inspector window to 0.

Now, if you run the game, you will see the cube.

Notice that we still have the Inspector panel open with the cube. You can continue to play with the cube’s properties while the game runs. If you roll over any number property, you will see the cursor change into a two-sided arrow, and you can use that to click and drag the value in the field up and down. Give it a try with the x and y properties of the cube. Since we are in 2D mode, modifying the z-axis will not do anything eventful. When you stop running the game, all of the values will reset themselves.

Wrapping Up

At this point you sound be familiar with the Unity IDE and the new settings for working in 2D. In the next post I’ll cover a primer on C# in Unity and how to start making basic scripts for your own games. Stay tuned!

Also, don’t forget that to checkout Amazon’s GameCircle plug-in for Unity to help you integrate cross-platform leaderboards, achievements, and game data synchronization. The plug-in works on iOS, Android, and Fire OS plus with the built-in Whispersync for Games component you can back up all of your user’s game data to the cloud across all three platforms. You can now download it from the Scripting/Integration section of the Unity Asset Store.

Introduction to Unity Part 2: Learning C#

- Jesse Freeman (@jessefreeman)


April 25, 2014

Paul Cutsinger

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

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

Exploring Shroud of the Avatar

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

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

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

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

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

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

Finding the Right Balance in Games

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

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

Starr Long’s Secret behind Crowd Sourcing

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

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

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

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

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

·         Weekly Updates that include the following:

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

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

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

o    General Status updates

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

A Look behind the Producer

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

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

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

The Tradeoff when Building a Game

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

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

Top 3 Tips for Developers

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

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

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

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