 Just out of curiosity, how many people were here last year and heard me talk about HTML5 games? OK. What I'm hoping for is that everyone here is into building games. So how many people build games? Yeah, it's getting better than last year. I'm the only person here who's talking about games. And this year, I've been spending the last year going through. And I did HTML5 games since you could actually build stuff in Canvas. And I did that for about two, three years. And then I started moving a little bit more into Unity because I was trying to find some more power and trying to do some stuff that I felt that HTML5 wasn't able to do. And it gave me a good opportunity to kind of explore the two because we always have this argument of what's better is. Is web better? Is native better? Are cross-compilers better? And all this stuff, right? So this isn't going to be like a holy war. This isn't going to be something where we're going to really debate it and come up with a solution. I'm just going to go through and talk about my experiences and which part attracts me to either HTML5 and to Unity. So in the title of the talk, really, is about picking the right tools. As developers, it's incredibly important for us to understand that, one, you can't rely on a single tool to do every job, right? And you have to go through and you have to pick the right tool for the job. So my name is Jesse Freeman. I'm a developer evangelist at Amazon. And my job is to travel around the world and work with game developers and help get them on our platform. And I'll talk a little bit later about our platform and all that. But I put my contact information up here. You can find me on the Twitter. I'm just Jesse Freeman. And also on Twitch lately, I've been doing a lot of stuff where in the mornings, at least in US time, I'll be going through and I just build games. And I try to teach people not only about just publishing games, but actually the art of building games. And then also my email address, too. So if you're working on really cool stuff or you need some help or you want to publish to Amazon, you can email me. It's my rapper name at Amazon. It's FreeJ at Amazon. So pretty easy to remember. I didn't pick that. They gave that to me. You usually have to drop the mic when I give it out. But so last year, I did a talk on the things that I learned from building HTML5 games. And one of the things that was really important was that every game that I made was playable on desktop and mobile. And I thought that that was a really important thing for me. My background comes from web. So I know a lot of different languages. Spanish is not a very good one of mine. I did an opener last year where I spoke a little bit Spanish. But as far as programming languages, I've done everything from I did Ruby back in the day. I've done C++. I've done Java. I've did a lot of stuff with Flash and ActionScript all the way from AS1 up to AS3. And JavaScript and TypeScript and on and on and on and on. So to me, it was always important that whatever game I make is viewable across as many devices and as platforms as possible. And what also attracted me to HTML5, especially while everyone was so much in love with Flash in the end, it was just how there are so many game frameworks. There's so much activity going on and everything was so new and shiny that it really drew me to it. So there's all these really great frameworks out there for doing HTML5 games. I'm not gonna go into this. The joke that I always say is there are actually more HTML5 game frameworks than there are HTML5 game developers. So, and we'll talk about that a little bit as well. What really spurred on my HTML5 game development though was this game jam called One Game a Month. So I think it's been going on for three years now. I only survived one year. And basically you had to build a game each month. And it's as a full-time evangelist and person who literally is traveling every other week and has two kids and is still married and trying to keep everything together. It's very hard to build one game a year, but doing 12 is really difficult. But I learned a lot of really cool techniques with it. And I'll go through these real quick. Because again, this is all stuff that I sort of covered last year. And I think it's really more important to talk about the outcome and how you go and pick these tools for building it. But long story short, how to quickly explore and prototype ideas is incredibly important. And when I give these talks, if you aren't building games, and I was talking about this last night at the Speaker's Dinner, I have been building games my entire career. Just nobody knows it because I've been doing enterprise and agency work. But I sneak game engines into almost everything I built. And a lot of that also stems from everything I learned in enterprise development applies to game development. So learning how to prototype ideas. How do you fail quickly? How do you build stuff and just see what works and move on if the prototype works or not? How to focus on the core game mechanics. What is fun, right? What is it that's gonna hook someone and how do you get that to work well? Also learning how to work on their pressure. If anyone's worked for an agency, there's incredibly long days and it's very tough to work on their agency environment. And so learning how to work on their pressure, if it's your own pressure or it's external pressure is very important. Also, how do you find the motivation to complete a game? It's very difficult to complete a game or to complete any project, right? So the biggest thing I learned is just ship it. I don't care if the game is perfect, you just have to learn how to ship it, get it out there and move on to the next thing or refine it on the next round. And then also just gaining the experience. So publishing an app or publishing a game to an app store or to a web server anywhere is an important experience that you need to learn because it applies to any job that you're doing in technology. And I really love this quote and it's by Stephen King and it's the talent is cheaper than table salt. What separates talented individuals from successful ones is a lot of hard work. And I use this slide almost in every talk. And last night, I was actually talking to a few of the speakers about this. We were talking about what is success and what is drive and what are the things that motivate people? But really success isn't easy. And if you achieve success, most people think, well, that was really easy. Like they did that overnight or they're an overnight success story. Those things don't exist. It takes years of work and dedication. And a big part of this work and dedication of what it leads to this talk is, it's not easy one to switch from framework to framework, but also it's really important to be able to go through and understand what are the core values of a tool that you're using and how to become a master at it so that when you move on to another tool, you can take those same skills and apply it to the next tool. So the real drive behind why I did HTML5 games and why I still kind of explore this is something I call responsive game design. And we're all very familiar here with the concept of what responsive design is on the web. Usually I have this slide in because I'm talking to game developers and they don't know what responsive web design is, but long story short, it's just how do we scale websites from desktop all the way down to mobile, right? And this is pretty much the standard practice, right? We compartmentalize content into grids and then we shrink or expand that grid based on the device that we're at. It works really easy. Most of this stuff is done on the front end. CSS makes this really, really easy at this point and it works really great for web. But if you're building a game and you want that game to scale across any kind of device possible, it's a much different story. So that's why I started coming up with this concept of a responsive game design. And unfortunately on Wikipedia, you can't coin your own phrases. It doesn't work, so it's official. I'm saying it's official, but the idea really is how do we take the same concepts from responsive design but apply them to games? So, whoops, got ahead of myself. So there are four tenants that define responsive game design. And the first one is the most important. This is the one that it most closely associates itself with what we do on the web. And that's taking the graphics in the UI and having it support multiple resolutions. And this is really important and the analogy I like to use is I'm a big civilization player. I loved playing civilization from originally in the DOS. And I was always a Mac gamer, so it took a very long time for the original civilization to come over. And Macs had a much higher resolution. So when it finally came over to Mac from DOS, all the UI and everything was super, super tiny, right? Because they didn't really take into account the difference in the resolution. So thinking about all these different resolutions is incredibly important. Game mechanics, working across multiple devices and types of input. So normally when I do a full talk on this, I have a diagram that shows the game controller starting from the Atari all the way down to like the Xbox One, right? And the evolution of the controls. And over time, game controllers have gotten incredibly complicated. They have up to 10 buttons or more. And how do you build a game that if you're gonna go from touch to controller to keyboard, how does that work across all those? And usually it means it's constraining the input to the core things that you need. Also publishing to multiple platforms with the same code base. When you used to build games for consoles, you actually had to port them from one console to another. These days you can actually build a game with one tool and use a cross compiler in order to get that to run everywhere. And then finally, the most important, and this also goes back to web, is save data that syncs across all platforms. Not everyone has the same device. Some people may have a FireTablet as their tablet device. Some people may have an iPhone as their phone device. Some people may use an Android phone or whatever. But if they buy your game and they like your game, you want them to have the same game data wherever they go. So being able to sync all of this across different devices is incredibly important. So today we're gonna talk about the third tenant, which is how do we publish a game using a single code base to multiple platforms? And that's sort of where this story comes from HTML5 versus Unity. And there are all different kinds of game frameworks out there that sort of do this. This is a picture from Unity, which just has like a one-click solution to all these different platforms. HTML5 supports it as well. There's other engines like Game Maker, which is its own proprietary game framework, but that can output to native and to HTML5. And then you start getting into more complicated stuff like Unreal, which is for consoles, higher end devices, and they also have WebGL support. And what's interesting now at this time is that all of these frameworks that I have on this slide all support WebGL in one form or another. So we're starting to see that these proprietary game engines that were really focused on native are now coming back to the web. So we'll talk about setup, right? This is always the most difficult part, is when you're staring at a blank screen and you're trying to figure out where do you start with a game? How do you build a game from scratch? And HTML5 has a lot of pros. So I assume everyone here is into web technology, right? This is sort of like FutureJS. It's kind of like the theme, right? We have a lot of C++ developers here. Oh, okay, right, no. Hypercard, no, okay. So if you're a web developer, building an HTML5 game is pretty standard, right? You just either set up a local server. You don't need an IDE. So you can use any text editor. So if you use Sublime, Visual Studio Code just came out. So that's pretty interesting too. There's all these different kinds of IDEs that are already built out there for web. WebStorm is the one that I use the most myself. And so that's pretty easy, right? You can bring whatever you want and you're not tied into the IDE. Also, what's important is it's really easy if you've already setting up a web stack and you have a web development environment, you're pretty much ready, and every computer and mobile phone has a browser built into it. So all the tools you need to run the game basically exist. On the flip side though, some of the cons that I've noticed with it is that for people who are new to publishing HTML5 games, the setup can be a challenge. So I used to do workshops in New York and I try to get everyone up and running with Impact.js, which is a really great game framework. And the problem was that Impact.js, while it's a JS framework, also required PHP to compress and zip up the game. And it required some other web technology. So if you've ever had to sit in a workshop with 50 people and try to get everyone to set up Apache or Node, Node actually is a lot easier. It's a little bit of a challenge. There are online tools where you can build games completely online, but also those are sort of limited too because sometimes the more advanced the game gets, building it all on a browser isn't ideal either. And then the most important one is that it's so difficult to choose the right framework. So earlier on in the slides I showed that there was a bunch of different HTML5 game frameworks. I mentioned Impact. Phaser is a really good one as well. And the list goes on and on. And the issue with that is that it becomes overwhelming, right? Where do you start? What's the best game framework? If someone came up to me and asked what's the best HTML5 game framework out there, I don't know. I tell you to go and go find the top five and play with them yourself and find the one that works best for you. So not a lot of people want to put in that much effort into figuring out where to start. Also, each framework has its own requirements. So some of them are strictly JavaScript. Some of them require Node on the backend. Some of them require local storage. Some of them require very high end specifications. Like if you're using Pixie.js, which is a really great rendering framework, it requires WebGL. It could fall back to Canvas, but if you're gonna get the best performance. So that's another thing you have to know is that each framework has its own requirements. Unity on the other hand is a completely different beast. And I affectionately refer to Unity as the new Flash. Like it's prevalent. Everyone's doing it. And it's its own self-contained IDE. And that's usually like a good thing and a bad thing, right? But when it comes to setting up Unity, it's just one click. You install it after like three gigs of downloading. It's installed and it's there. But once it's installed, everything is ready to go configured for you on any computer. And I think they just released a Linux build too. So you can also do Linux, right? There's a built-in editor to run the game. So all your tooling and everything is all still done in the IDE. When you code, you use an external editor. I don't know if I put that in the cons, but we'll talk about that in the cons. And then it's a consistent development environment. And that was one of the issues I had with HTML5 is that as a person who travels a lot, I have three computers. I have my home computer, I have a work computer, and I also have a travel laptop, right? And I'm constantly switching between all of them and getting the dev environment to be in sync across the board is difficult, especially in like web technology. When it comes to Unity, I just got to make sure that I'm on the right version and everything is sort of exactly the same on whatever platform I'm on. When we talk about the cons though, Unity, the biggest thing, just like Flash, is that it's controlled by one company. So your fate is completely tied to that one company. And many a time have I updated to a dot version of Unity and it's completely broken, stuff that I did before. So these are things you have to understand. If you're into open technology and open source stuff, HTML5 game frameworks are mostly open source and free. So you're at the hands of the developer who's building it, but at least you can go in and tinker it. If I go in and I see performance issues in like Unity's new UI, for example, I can't go in and actually tweak that whatsoever. It's a locked system. I can build on top of it, but you have to be careful about that. Also, the Unity IDE is the only way you can make a Unity game. So while it's incredibly powerful and very robust, you also have a lot of difficulty in you can't bring a third party editor. On the cons, which I don't really have here, but I'll bring it up anyways, is that it relies on Mono. So Mono is a dot net open source dot net framework and the editors for Mono are sparse. So Mono develop is one. It's not the greatest editor Xamarin Studio I've been using, but if you're on Windows, you can use Visual Studio Code. So all your code writing is done in an external editor, but you're also at the hands of that. And also you need to use Unity's workflow. So Unity to me reminds me very much of Rails. I love Rails. Once you get off the Rails though, you're in big trouble. Like it's really hard to do stuff outside of that framework without having to add layer upon layer of stuff on top of it. So Unity is the same way. And many times I've built stuff and had to gut it completely to go back and rewrite it because I did it the way that I wanted it to work. And Unity is like, no, no, no, no, no. This is the way you're gonna do it and you're gonna like it. So when it comes to HL5 frameworks, it's JavaScript. I'm like, all right, well, I'm just going to, you know, prototype bark on an array and every time I call an array, it's gonna bark and I don't care. So you can do anything in that, right? So those are some things in this like closed system that you wanna be very careful of. When it comes to building a game, right? This is the most critical part of all is you're picking any of these technologies and how do you actually build a game with it? Well, HL5 is really great at building casual games. And I say that lovingly because some of the greatest games that I even play on mobile are all casual games, right? So it's meant for a very specific audience. And I've seen some longer format, more console-like games come out of HTML5, but not to the same extent that I would see with Unity. So thinking about that is if you wanna build casual games, things that are quick to prototype, games that are fun but have very short game loops and stuff like that are really good for HTML5. It uses JavaScript, which is a pretty easy language to pick up. It's not typed anything like that. So, and like I said, you could do almost anything with JavaScript. Also, you can use cross-compilers. So I'm a big fan of TypeScript. I like strongly typed languages. So when I did JavaScript games, I like to use TypeScript. You can use CoffeeScript, whatever it is, that long as it outputs the JavaScript and the game framework has an adapter, you can use that. And like I said, there's also lots of open-source frameworks to choose. On the cons though, it's not always easy to pick the right framework. And I mentioned this before, and I think this is probably one of the biggest issues with HTML5 game frameworks right now is that it's just so hard to figure out which framework to use. Most frameworks are in various stages of stable or in development, right? They're like the plumber who has leaky pipes at their house. You know, you always have, it's always being refined. It's always being updated. And you're at the hands of a community that's contributing to open-source. So if you're okay with that, then it's something to consider. But a lot of the times, especially for something like Impact, I went in and I gutted Impact and I made it my own framework. I just used a lot of the basic tools, but I wound up rewriting most of the engine myself. Also, limited tool integration. This is probably one of the things that frustrated me the most is that while it's easier to use any IDE you want, I'm a big tool guy. Like I want property buggers. I want to understand how to do proper asset management and art pipelines and all these things you sort of take for granted in more professional game environments. It's very hard to do this stuff in HTML5 because you have to make the tools. So I wound up spending a huge amount of my time just building tools to build my game versus actually building the game itself. And then performance is inconsistent across the board. I've seen really great performance on desktop, obviously, mobile. There's a lot of testing. Now, luckily the web browsers have gotten way better on mobile. Even a year ago when I did this talk, Android was still an issue where some web renderers just didn't render WebGL correctly. iOS now does WebGL. Our devices support WebGL. So all of that is now being fixed, but it takes a lot of time to go through and figure out because you may have the right phone and you may have the right resolution, but there's no guarantee on what version of a web browser someone may have on mobile. For Unity, it's literally designed for building complex 3D and 2D games. So from the ground up, it is a game development environment. So it uses C-Sharp, which is one of my favorite languages. I really, really love C-Sharp. Strongly tight, it has some dynamics. It's a lot better. I feel it in many ways than Java. And on top of it, there's some really great tools. So if you do use Windows, you can use Visual Studio and you can use Resharper, which is a great plugin and makes it a lot more like IntelliJ if you're doing Java development or WebStorm. Also, building games is really easy in the IDE, because everything is drag and drop. They've done an amazing job with you put a game object down on the screen and when you click on it, all the properties of it show up in the window next to you. And then you're able to tweak those at runtime. You're able to tweak them before you play the game. So it's a whole different experience of building a game. Also, it has built-in physics. It has a preview. It has debugging. It has component building. So a lot of the times you can build components and they call them prefabs. So if I wanted to build a player and add a whole bunch of scripts onto it and tweak it, I can save that for later. In JavaScript, you have to do all that generally with code. When it comes to the cons, though, sometimes it sort of gets in the way. C-Sharp can complicate your game logic. So one of the best things I ever did with JavaScript is it's just like, everything's global. Yay! We don't need to have anything isolated. Just put it in the DOM and I'll just find it later and it speeds up game development really well. C-Sharp doesn't want you to do that. And I still do it. I just made one class that manages all my singletons and I make everything global, but it's still sort of not the way you're supposed to do it. The good thing about why I like games over enterprise is because in games, you just sort of throw out all the design rules and you're just like, just make a game. And then later on, we'll figure out how to scale it. So C-Sharp over complicates things. Also, the way that you wind up scripting can be difficult to have reusable libraries. So JavaScript has sort of solved this stuff. Like you look at the way that you have like requires.js and some of the stuff that Node does with its packages and there's a central package repository. Unity has like an asset store. You can buy assets. You can package assets up. But there's no real clean way of updating them and there's no way of telling which version you need. So on Node, if I'm building out a Node app, I can say, okay, I require these things in my setup and it needs to be these versions. Unity doesn't have that. So sharing code between projects is incredibly difficult. And also, it's hard to find where code is because just like Flash, you sort of throw all the code onto objects in the scene. So you wind up a code like literally everywhere. So unless you're really diligent about architecting your game correctly, which I just explained I don't do, it's very hard to find where stuff goes. And then the last thing we'll do is we'll talk a little bit about publishing because this is the most important and this is what really drew me between the two different platforms. So obviously, if you can't get your game out to people, there's no point in making the game, right? And being able to distribute your game so that people can appreciate and love it or hate it or whatever it is is gotta be the number one priority whenever you're picking a technology that you wanna build something with, right? And HTML5, for a very long time, almost since its inception, had sort of solved that problem because it's the best of both worlds, right? You can have games on the web because there's still a huge web community, right? On desktop, people still play lots and lots of web games. And then you can actually take those web games and you can also make them offline too and you can play them on mobile. So it sort of does everything. And it's easy to publish these games to the web, right? So if you're already building web apps, it's very easy to get it up and running. The biggest one which everyone loved from the get go was no plugins, right? We don't have to deal with the plugin or it used to be the missing Lego icon from Flash that everyone loved and then they got rid of that because it was aggravating people too much. So without having plugins, it frees up everyone that it's just the browser itself. And then the other one is that it's ideal for mobile and web browsers. And as we're starting to see now, and I think Google just announced it with Chrome, like they're now auto-pausing Flash ads and they're pushing forward with HTML5 ads. So browsers now have been optimized specifically for HTML5, so you're gonna get really good performance now in modern browsers. The cons though is that it's still a little bit difficult to actually publish these to native. And while there's some really great solutions out there, none of them have been this like one-click easy way to do it. So of course there's things like, you can use stuff like PhoneGap, but PhoneGap relies on the actual devices built in WebView. You can do, there's Chrome wrappers too, where you can actually package up a web browser in with your game, Node, Kit, and stuff like that. So all these sort of exist, but a lot of them require you to build additional tools on top or have integration with the native OS side. So it's great if you have a very simple game and you just want it to be playable, but if you wanna do in-app purchases, if you wanna do things that interact with hardware that aren't available through a public API, you have to build all that glue yourself. And then there's limited reach online. So as the game gets more advanced, it was why I was sort of talking about casual, there's a limited audience to people who wanna play hardcore games in a browser, right? So it's just something to think about. And while we push for this technology and there's some really great stuff that you can do, like I said, Unreal has a version that runs a WebGL, how often are you gonna plug in a game controller, have the right browser, have everything configured, and play like a first person shooter in a browser? It's not a real use case, right? Most of those times, those are gonna be played on consoles or dedicated offline. There we go. So then we'll talk about Unity Pros, right? Unity has a one-click publishing solution. And that's definitely over the past year, one of the things that's really attracted me to it is that I spend a lot less time doing build scripts and a lot more time just actually doing the game. So you can basically choose from a list of everything that you wanna publish and they support tons of platforms. They also support Web, so they have a plugin which actually has now been disabled in Chrome, so another thing to think about. But they do WebGL support, which is still in beta. And then they also do consoles. And traditionally getting games on consoles, web games on consoles has not been an easy task. More consoles are starting to support it. Nintendo does a really great job of using a WebKit to support it as well, but it's a lot easier with Unity. It's easy to publish right from the IDE, so like I said, you either click on a button or there's a plugin I bought for 40 bucks and I just simply go through and I select all the platforms I want and it does an auto build system for me. And it saved me hours of time as when I did Web games, I would have to do all the build scripts myself. And then increased performance. So you're always gonna get, it compiles down to native, so you're always gonna get advantage of the better performance on better GPUs and it's gonna run like native because it technically is native. On the con side though, Unity is really expensive. It's free, so you can download and use Unity 5 for free, but each plugin has an additional overhead cost. So if you wanna get the pro features for iOS, for Android and on and on and for consoles, you have to pay for each one of those features. Also, it doesn't support mobile web browsers or that's WebGL implementation yet. So WebGL takes a long time to compile out and it's literally compiling all of Unity into a WebGL wrapper and because of this, it's just too taxing for mobile phones. And then if you wanna get it on the web, it requires the web plugin, but the other problem with the web plugin, like I said, is that Chrome is now blocking it by default and it's only a matter of time before all browsers are gonna block plugins. It just seems to be the cool thing to do these days. So, if it's saying it's coming for years, right? So, you know, before I start getting into the whole business side of it on my end of what we do for developers and why I'm here from Amazon to talk about it, you know, if you ask me today, which technology do I prefer, I don't know. I don't have a solid answer. Like I said, it's something that I invite everyone to play with and find the right thing. If you're a web developer, definitely go through and check out some of the web stuff. If you're interested in doing more 3D stuff, check out Unity. But there's also some really great 3D game development stuff for HTML5, like Play Canvas, which is really awesome. It's like Unity in the browser and everything is done in the browser for WebGL. And, you know, my message for anyone is this. One, not everyone can build games. I'm sure there's a lot of people in the audience who wanna build games. And I was sort of talking about this last night with some of the other speakers. It's like, my dream was always to build games, but it's not really practical, especially when you live in New York and it's expensive to live in New York. So sometimes enterprise work makes a little bit more sense. But try to take your passion and figure out how to apply that to your day job. And it could just be small little things. The next speaker's gonna come up and talk about game loops in Canvas. And there are many sites that I built that have little game engines for rendering. And I really love the rendering, blitting, and all kinds of like really low level visualization rendering engines and building that stuff into your sites and trying to figure out how to do that. So do that. And then also, if you don't have the luxury of building games full time, make it your hobby. And not every hobby you have to get paid for. It's a very important thing. And I try to talk to developers about this. It's find the passion, find an outlet, make art. To me, games is my art now. I used to paint, I used to sculpt. Now I just make games and I code. So all that being said, once you've found the right tool that you wanna use and you have a game and we're talking about publishing, now's the time that I get to sell you guys on publishing to Amazon. You know, not an outcry of, yeah, it's it. This is, everyone's like Amazon. I buy diapers from Amazon. Published games, okay. So my corporate approved slides of talking through, you know, some of the things I don't think people really get about what Amazon is doing in the digital space is that we have an app store and our app store is on a lot of different devices. And of course it's gonna be on our own devices. We have Fire Phone, we have Fire Tablet, we have Fire TV. Fire TV is what I focus a lot of my energy on. But we're also default app store for Blackberry. And most importantly, how many people who have Android phones? Right, so you can all basically install the Amazon app and you can also order your diapers and you can get digital downloads from our app store as well. And we do a lot of cool stuff about trying to help developers promote that and I'll talk about that in a second. So we're definitely trying to be the A to Z store of everything and to us, digital apps and digital games are just an extension of that. So like I was saying, like if you download our Amazon app, we actually have a digital app store inside of it. And we've been doing a lot of really cool stuff and some of you may have heard we just announced something called Amazon Underground. And Amazon Underground is a completely different shift in the way that developers get to monetize their apps and games. So everyone is sort of used to the whole thing. You're either premium where you do a flat fee. You are either doing in-app purchases or you're hitting people over the head with ads, right? Now, all those are okay, but wouldn't it be really great if you just made a game and we paid you for everyone who played it? And that's what Amazon Underground is. So for customers, the games are completely free, the apps are completely free. We pay you per minute for how much usage you have. And one of the things that got me really excited about it is that I can finally build games as a hobby and I build the game that I love and I think it's gonna be fun and I don't have to focus on the monetization. I just know that if the game is actually good and sticky, people are gonna play it and I'll get paid for every single person who uses it. So there's a lot of things that we're doing to try to just change the way that developers make money. And a reason is that we, there's this, I'm not a big fan of this slide. This is a lot better than the other slide that I showed but there's this thing called the App Store Poverty Line. It's such a weird way to explain this but the reality is a lot of people publish to app stores. Not a lot of people make money from it, right? And the poverty line is something like if you make over $500 a month, you're above the App Store Poverty Line. So of course, because I have this slide, on Amazon, more developers are above the poverty line than below it by like 60%, right? So of course, our customer base is very loyal to Amazon. They also like buying stuff through Amazon. So we monetize very well for developers. But that being said, I think, you know, it's, whenever you're trying to figure out where to publish and the whole goal of this talk is, of course I'm gonna tell you guys all to publish to Amazon, right? But I'm also gonna tell you to publish to iOS. I'm gonna tell you to publish to Android. I'm gonna tell you to be everywhere because in order to be successful, your game has to be everywhere and that's sort of what responsive design is about. So when you build a game, you need to think about being on every platform possible and you need to pick the tools that'll get you there. So, and if you are interested, if I was able to sell you on at least, you know, possibly submitting an app to our store, it's free for developers. We don't make it very hard. We want, like I said, we just wanna be a check box for you guys. So if you're publishing already to Android, anything that outputs an APK will run on our devices. So already you're there and then it's free to become a developer and just put it on our store. So we also make it really, really easy for web developers to publish their app. And I talked a lot about this last year in more depth, but this URL will walk you through, we have a web tool that'll take a URL and it'll publish it like a native app into the store. So the customer doesn't know but we deal with wrapping the app for you and loading it up. And what's interesting is that we've done a lot of work on under the hood for WebGL so that our web canvas is incredibly accelerated on our devices. So not only do you just have to give us your URL, but we also make it faster on our devices because we can optimize for our OS. And then I do a lot of writing. So outside of doing conferences like this and the terrible job of traveling around the world, just so grueling. So I was eating some awesome food here. That being said, I do a lot of writing on the blog. And so we have a bunch of developer evangelists that all talk about different topics. If you wanna learn more about why to publish games on Amazon, I have a very good post here that just goes through and it just talks about what we're doing with indie developers, what we're doing with console developers, what we're doing to get people into our app store and how to make them successful. Because on top of that, we also have so many other ways of leveraging and promoting game developers, especially through the Twitch acquisition. So now we're working very closely with Twitch and getting game developers on Twitch and making that a part of their marketing as well. And if you wanna learn a little bit more about responsive game design, this post goes into a lot more detail. So I think this responsive game design really applies to almost everything. Luckily as web developers, it's really easy to do because you can do a lot of this stuff just through CSS. But even if you're trying to think of how do you build a web app that goes from the web on desktop and feels like a native app on mobile, a lot of these things also have to be played into consideration, right? How do you deal with input? How does the look and feel of your app scale across different devices? And most importantly, how do you keep data consistent across all of them? And so I don't get paid on tips but it would be incredibly helpful if you guys would take a quick survey and give me the best rating possible. I tried to set another conference and I told everyone to give me the worst rating possible and they didn't, which I was lucky about, right? But that being said, I think I have a few, I think I still have some time. Maybe I could take some questions if anyone has some questions. I don't know. We'll just yell. Oh wait, we do have a mic. Do I have time or? No. And I'm cut off. Hi, I'm back. I'm sure it was a very good question. Unfortunately, no time for questions. But we can clap for him, right?