No results found
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.
Already have an Android app? Bring your APK for a chance to win cool prizes! Click here to register now!
Check-in and Breakfast
An Overview of the Amazon Devices and Services for Mobile Developers
David 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 Echo
David 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.
How We Made a Game No Fun
Peter 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 Fans
Peter 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.
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-Up
Seating is limited so be sure to register for the event to reserve your spot. Hope to see you there!
February 12, 2015Mike Hines
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.
You can learn more about this issue here: https://developer.android.com/tools/building/multidex.html
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:
You’ll know when your app references more than 65,535 methods because you’ll see an error something like this:
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”.
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:
What is “too close”?
“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).
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)
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.
The quickest and safest approach for using multi-dex is to use the Multidex library with Gradle Plugin: https://developer.android.com/tools/building/multidex.html.
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:
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.
To implement multi-dex for Pre-Android 5.0 releases follow the steps below:
Make sure you have updated your Android build Tools to the latest version – You will need at least 21.1.x, current version as of this writing is 21.1.2
android-support-multidex.jar library into your project. You can find it in: \android-sdk\extras\android\support\multidex\library\libs
Add multiDexEnabled true and Multidex dependency to your buildConfig in the build.gradle file. An example below:
You can override the android.app.Application class, or declare MultiDexApplication class in AndroidManifest.xml file as shown below:
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.
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:
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.
StackOverflow has some handy info.
The source code of how Gradle automatically generates a main dex list is here.
There is also a tool that can automatically generate this main-dex-list here.
This blog post has an example of a useful proguard-rules.txt file that accommodates the AWS SDK and some other popular tools.
February 10, 2015Jesse Freeman
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.
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:
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.
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.
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:
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.
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!
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:
- Jesse Freeman (@jessefreeman)
February 06, 2015Jesse Freeman
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.
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.
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.
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.
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:
- Jesse Freeman (@jessefreeman)
January 28, 2015Jesse Freeman
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.
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.
“Thomas Was Alone”
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.
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:
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/
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.
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:
- Jesse Freeman (@jessefreeman)
January 22, 2015Jesse Freeman
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.
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).
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.
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.
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:
- Jesse Freeman (@jessefreeman)
January 15, 2015David Isbitski
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:
We announced a new version of the Amazon Maps API, offering an even richer customer experience with 3D vector maps, 3D landmarks, drawing API’s, fragments, multiple maps, and more.
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 a free Xamarin Evolve video that covers how quickly and easily you can target Amazon devices, including Fire phone, using C# and Xamarin Studio.
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 chatted with HandyGames about customer reactions to the new experiences they’ve built using Fire phone and Fire TV.
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.
We walked through the process of adding Fire phone Dynamic Perspective to a Phaser based HTML5 game.
We walked through how to quickly add Dynamic Perspective to your existing Unity game.
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 covered testing your Fire phone app with our free App Testing Service.
We covered Fire phone’s new enhanced home carousel and how you can expose content from your app directly on the home screen.
We posted examples of how developers are taking advantage of Fire’s new Firefly capabilities.
We covered some of the design principles behind the Fire UX and what you need to know to design the best customer experience possible.
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:
January 12, 2015Jesse Freeman
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.
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 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 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.).
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.
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 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:
- Jesse Freeman (@jessefreeman)
December 29, 2014David Isbitski
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!
This session covers everything you need to know about the Amazon Developer program, the free cross-platform Amazon Mobile SDK, and Amazon Fire devices.
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.
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.
This session covers an overview of AWS Mobile Services and shows how you can quickly use it to scale your own games for millions of players.
For more information about getting started with Amazon Fire devices and the Amazon Appstore, check out the following free resources:
Amazon Appstore and Devices
Amazon Fire TV
Amazon Fire Phone
AWS Mobile Services
November 24, 2014Peter Heinrich
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.
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 today to increase player engagement. Getting started is easy: