 My name is Raktesh Radhika. I run the game development studio in Pune, New York, in Puebla. We're a cross-class form game development company, and that's sort of our untrained to the whole HTML5 devs reports. So, we've got a couple of demos up on that URL, which I'll be referencing in the talk in the next half an hour. And we'll add to it more as this demo put up to know from this presentation as well. So, just show fans how many people in the audience have developed a game before. How many of those who have developed a game before are planning to develop a game are thinking about it? A little more. How many have games in JavaScript? Okay, cool. So, I'm hoping to learn from you, because what I found is it's a bit of a jumble of them. So, just to get some definitions, what are we talking about? I'm talking about games that run in standard browser. So, I can't think of solutions like Unity, which lets you code in JavaScript, but then compiles it down to your platform. So, that's one thing. That's the definition of the game developer. It's time-busted. Games itself are such a big range of games out there, right? So, what games actually run in browsers these days? Just like some games that won't be running in your browser anytime soon. Skyrim, it's probably Game of the Year 2011. And, you know, it doesn't run in your browser. It's not going to anytime soon. But this definitely is the goal for a lot of people, it sounds like both browser manufacturers as well as game studios. So, but, you know, this looks like a little ways away. But then there's also the less complex kind of games, like Facebook. These definitely run in the browser. Between these two games, there's like a whole range. So, it's interesting. It looks like you can do some things with HTML5, like this kind of game, at least this complexity. But somewhere along the way, you're limited by what can be done at least if you want a reach. So, that's the hard part, figuring out what is really supported. And I tried to figure this out. I went to this HTML5 game conference in San Francisco a couple of months ago. It looks like everyone was confused about it. This is what the city of Zinda, Germany always has. And that seems to be the case. Everyone was so excited about HTML5. The Bible came out there. Pretty interesting thinker in the space. So, that's your own understanding. I think this is... Can you help me? Okay, anyway. So, it's really knee-deep into this, like a lot of game developers. And it's really... It's really having the existing state of HTML5. In fact, he compared developing for HTML5 to a pain machine. This is a pain machine that gives you a bit of an electric current when you play with the zapper. So, that's what he compared developing HTML5 for games right now. So, this added to a lot of confusion. I mean, if these guys who are at the forefront of game development are struggling with it, what does that mean? What are the trends? So, that was the basis for our investigation into the space to try our first act. There's obviously no way to believe somebody else's experience. So, I'm going to just try and clear up some confusion and also learn from everybody else here. It's clear that there's lots of different starting points because there's so many different devices but there's also so many different types of games. Which I think ultimately is a great thing because complexity is not a must. Creativity has a lot to do with successful games. And a lot of the successful games that have been around for thousands of years are actually quite simple and very social. So, this is not a hands-on session. After an hour is too little to do code walkers and stuff like that. I'm just going to share our story of how we got to where we are and hopefully by that you get a sense of how to get started for different types of games that you might want to develop. Just to jump back a little bit. So, I run Codevala and what we do is cross-platform game development. Somebody comes to us and says, if you want a game, it's got to run on MSN games, Yahoo games, Facebook, iPhone, Android, Windows phone, etc., etc. Because that's what they need. And then for us it's like this total nightmare of figuring out how to exactly get that done in a timely manner or at all. And depending on the game you have a bit of a, you know, there are tools that help you get more mileage on getting more than one platform at a time. But for the most part we kind of have to reinvent the game quite a bit. So, this is like a daily pain point for us. And I'm sure it is for any game developer or game development studio because ultimately you're in the content business and, you know, the more viewers you have, the more reach you have for your game, the better chance of a return on your investment because you probably get one hit out of ten games, right? So, just a quick note on how we're structured. Like the studio, you know, there's people who focus on game design, there's people who focus on production, people who focus on the art, on the technology. There's not just all developers or hackers. Even within technology there's people who are doing front-end stuff, there's people who are doing back-end. You know, depending on the game you have maybe a lighter front-end or a heavier client side. In terms of technologies that we use, you know, like for all the online stuff, we've been using Flash a lot. You know, for mobile, now that mobile is coming back, we use Corona when we can, when the games are simple, and our 2D is a good tool. We also use Unity 3D when we need to make a 3D game. That's also cross-platform. I mean, it'll crunch it down to native for different hardware. So, these are some of the tools that we use right now. And sometimes none of these work. You have to just go native, like code in OpenGL, what not. Naturally, this means we need lots of different skill sets. In our company we're about 50 people, and a lot of people pretty much do the same, different versions of the same game. So, you know, needless to say, we're highly motivated to explore better ways to get cross-platform game development. You know, there's lots of challenges, like I mentioned, it's a hits-driven business at the end of the day. You know, there's constant time pressures, as always. But on the other hand, unlike an application, you know, your game quality and game performance just cannot be compromised, right? It has to be visually, it can't just be functional, it has to be fun. So, it's pushing the system quite a bit. On top of that, you know, there's a big learning curve, right? You have lots of different skills. There's all these algorithms for game development, new languages, math, physics, what not. So, you really want all the tools you can at help, because otherwise, you know, the days of studios getting years and years to make a mainstream game, those are totally gone. So, you know, just a quick little look at the structure of a game program, right? So, a game program, more or less, is pretty much initialized, and you have an update loop during which you get it, you get your input, and you render your screen. If it's a game that has, it's continuously moving, then you have the notion of it being timer-driven, and you have a deal with, like, keeping our goods frame rate up. In other cases, it might just be based on, like, what conflicts and events. But still, there's this update loop, and then you terminate, right? But apart from that, so that's, like, the simplified structure. But apart from that, you really need really good tools and utilities to help you with scene management. Usually you're making a game with multiple levels. You know, a game usually is, like, got a ton of graphics and sounds and whatnot. You really need toolkits to help you with your asset management. Needless to say, if you're making a multiplayer game or a social game, you've got to have some way, some help to ease your network communication. Lots of games need a very good animation engine. Within animation engines itself or the whole world, you have, you know, you have your standard meaning-type spline-based animations, you know, motion-path-based animations. And then you have procedural animations. Physics is pretty much a common expectation in games right now. So, we're looking at, you know, a pretty large amount of code that you really don't want to have to be writing yourself. And thankfully there's lots of tools out there to help you with all of this. Any, any of, all of this has to sit on top of, any animation framework obviously has to sit on top of a pretty good graphics framework. And that, you know, hopefully the graphics framework is set in the context of HTML5 is smart enough to deal with the underlying hardware and the underlying, you know, flavor of HTML5 that you have. You can do it for you transparently, so you can switch to HTML or Canvas or CSS as the case may be. Because you really don't know with HTML5 what your end-user has. Audio is a must, it's a big, big deal with games, and it's also a big, big hole in the HTML5 ecosystem at the moment. Well, you know, you get better, right? But at the moment, it's definitely a pain point. It's not well supported. And, you know, some things are not just about technology. What we're finding is with audio, for instance, you know, the iPhone browser actually went back and took out some audio support. So I don't understand that. I mean, I guess I do because they want to keep the ecosystem more closed, Apple does. So there are these challenges beyond just, you know, browsers and devices getting better technically. A good addition to your game toolkit, game development toolkit are things that will help you build, you know, typical templates for standard game types or game packs for different types of games so you can reuse and write your games faster and faster. And needless to say, nowadays you have, you need a lot of back-end services so you can get a sense of, you know, how people are actually playing your game, not only to just measure usage but also as a game design technique. So with social games, especially, the idea is to get the game on quickly, don't get too fancy about it, get all the feedback and do analytics and then keep tweaking it really, really, really fast, right? That's sort of how modern social game studios are set up. They're more like web design companies or web development companies. The et cetera has all kinds of other packages, all kinds of other services which help a game development studio, be it monetization from advertising, offers, is that the other. So all this is to point out that what a game developer, those of you who have done game development already know this, but those of you haven't yet, I just want you to know that you need a lot of help, a lot of tools and that's what you would look for in any solution. So that's kind of where we came from and that's what we were looking for also. Yeah, so the solutions that we have, like I said, are, you know, some of them are virtual machine-based like Flash and some are cross-compilers like Unity. HTML5 was another solution that popped up to us and we started looking at it. That's a strange exception. That's VM-based, but it's allowed, it's okay by the Apple ecosystem. So, you know, and we saw lots of interesting demos. You know, they're very impressive demos from Google I.O. and other hacks and whatnot and some big companies. But we really didn't know what it took to make one of these. What about ease of development? What about from the developer side of things? So, in any case, we couldn't continue with Flash because Flash is not supported, so that was the end of that. And obviously we couldn't look at Unity because it's a plug-in-based environment, a plug-in-based solution. So yeah, so like I said, we started looking at HTML5, we got a pretty good sense of the landscape, and then started looking at the solutions. And there's tons. There's all kinds of game development tools and packages out there. Some are like hacks, like small little hacks that people have put together on a weekend type of thing. Some are really fancy and, you know, let you make pretty good games even without any programming. There's a lot of like, like authoring tool type things. But we couldn't really use those because we have, as a game developer, we have like very specific and high commercial requirements in terms of performance, the kind of customization we need, the amount of integration we need to do with other systems and so forth. I mean, there's a list of the ones that we actually looked at. Later with the URLs if you want. But all of these have support for HTML5, they claim. And some of them are really awesome and we've used them on other projects. But for the most part, not really applicable. The one that, you know, the one that we thought was the most interesting was Play-In from Google. It's a game abstraction toolkit. So if you go to Google and look for a Play-In, it's called For Play Before, you can get a sense of what that does. And we were really impressed with it because, you know, the angry words on the Chrome Web Store was made with it and whatnot, so we thought, wow, this is like a done deal. We figured it out and, you know, it's Google, so the performance and everything is gonna be good, it's gonna be supported, all that. But when we started using it, we found out that that was completely not true. First of all, the sound in that game is not even JavaScript, right, it's Flash. It really doesn't work on non-desktop environments, which is without a fail. And I think they pretty much had to get the Rovio developers to write that code to make Play-In actually work to that extent. So it seemed like a hard, you know, not exactly the easiest platform to jump into. Further, you have to program everything in Java. It's a GWT-based solution. So that, again, was a bit of a fail for us. We thought that if you're developing HTML5 and HTML5, then you should be able to code straight in JavaScript itself. But we considered it because, you know, it's ready. We can get up maybe time to market and so forth. But it was completely closed in terms of extending it. So once we couldn't extend it, we really couldn't consider it seriously. No closed system can be considered seriously by any game studio because you've always got to connect to, you know, some new thing or the other, which is out there. And so we looked at Cat, which was a, you know, a simpler offering, but it was pure JavaScript. It's open source. So it's Play-In, by the way. So Cat was not claiming to be a gaming framework as such. It was pretty much, it's pretty much an animation and graphics framework, I would say. And we found it to be, you know, reasonably non-inclusive, very easy to use, plain Manila JavaScript. So we said, okay, let's try that. And so we made three games. So I don't have much of a good connection here. So I recorded the screen capture, right? So first what we did was took a flash game, an existing flash game, a simple one, and we ported that over. These links, these games, you can actually see them from that website. So as you can see, it's a simple memory game made by this company, Bulma City, Bulma Slabs, where you just, you know, remember stuff. And we thought, if we can't even port this game to HTML5, then, you know, it's a fail. And surprisingly, we had a lot of trouble, even though it's such a simple game. We realized that flash has really optimized animation engines, has a really optimized animation engine. So even doing things like a cubic interpolation and stuff like that would turn out to be a lot of map for your JavaScript runtime. Dealing with big images, something as simple as a big animating water image in the back turned out to be like, you know, slow on a lot of devices, including like an iPad and whatnot. So that was pretty much a disappointment, even a game with such basic requirements you couldn't really do. So that was one experiment. The other experiment that we had was a slightly more complex game, but still really, really simple in terms of, this is a hidden object type game. This again is just a test that we put together in a couple of weeks with some existing graphics. And this worked fine, it worked pretty much on anything, but obviously it's not doing a whole lot of help a lot. But you know, it's a really popular genre hidden object games are super popular. I think the most popular game on Facebook that, you know, bumped Zynga out was something called Gardens of Time, which is basically a hidden object game adventure. So that was not a fail. We did have problems with audio, obviously, so that wasn't so exciting, but at least graphics-wise it looked like, you know, as long as big images aren't moving around, no problem. Then we decided to try like pure WebGL, sort of the high-end, like what we could do. And we had expert OpenGL developers and our team were also Flash developers. So they tried to do a quick little test and we based it on this Happy Tree Friends character, just a simple avoidance game. So this is all written in straight WebGL. You can see the source and box 2D for the physics. So it received like the performance was really good. This is obviously a movie, but you can check it out on your system. Obviously, it only worked on, you know, computers that have WebGL in support. So cool. So around the end of the year, we had these three little tests done and two were with Cat and one was with Pure WebGL. So, you know, I was a little disappointed actually because the lowest common denominator seemed even less than I thought. So I was clearly getting too influenced by the blogosphere reading about HTML5. The reality was a little bit even less, right? So, but at least it was a check. And we now had to decide, well, what do we do? Do we only support games for the cutting-edge browsers? Do we support everything? And it became clear to us that there's no point really supporting only a minority of the Brawlers, right? So we started focusing on reach. We wanted to make our games run on the biggest range of devices that support HTML5. And that sounds like, you know, contradiction to the whole quality requirements for game development. But actually, you know, like I said, some of the games are very simple on the graphics side, but are more complex on the, maybe not even that complex, but are just popular because of game design and creativity. I mean, these are the stats for words to French. It is 18 million people playing it. This is like from a couple of hours ago. So not too bad for a low complexity asynchronous backend kind of game, which many of you probably play at work. So this is good. You know, we realized that, all right, we're living in a great time where games have become mainstream. I don't think Skyrim has done so well, but we're awesome game. So this is really exciting because even, you know, it's not about graphics performances that are reach and creativity can give you lots of, and you know, existing games, social, all come together and give you lots of, lots of options. So we were actually pretty, pretty excited about that. You know, I mean, this is Martin Pinkett's, right, Zynga CEO. And I just like this quote from him, where he says, all of the newer games that we bring out are trying to reduce session times. So his goal is that people should play his games less at a given, in one session because one of the biggest reasons people don't play games is that they say they don't have time. So really, graphics, this, that, is all like secondary compared to time. So having this reach, being able to play your game wherever you are, turns out to be like the highest priority amongst everything else. And I guess he knows what he's talking about, right? He's had a $10 billion IPO. So he said, okay, we've got our conclusion, so now what do we need to make? And clearly, you know, we're making this for developers, right? I mean, as developers, it's important that the development environment be easy, be as good as possible. We're talking about web developers who've been doing web front-end stuff. We're talking about Flash developers who are familiar with developing an action script, that kind of thing. Really, for the front-end, we're talking about C++ or Java type guys. So I think it's... I think for us, we think the development environment part has to be in Java script for it to be, you know, useful for a game studio that's making a high-reach game. Needless to say, the front-end is all about having all those tools that lets you do physics and lets you do animation and everything at a level that satisfies your game idea, right? For the back-end, if you want to support a game like Works for Friends right now, it's not that simple, but you still need a pretty good back-end, because you're playing with people, with multiple people at the same time, there's 80 million of them all playing at the same time anyway, that many sessions. So a pretty high-scale back-end is like a more important thing for your little simple front-end to succeed, right? And then of course, social gaming is also part of the multiplayer aspect of your game, the social aspect then becomes important. So it's all about being creative to make the best of the current environment, as opposed to sort of fighting it and just making a game that looks good in demos and in conferences. So based on this, we've decided now to, in fact, build some products around this concept, because the challenges are huge. The opportunity is larger, right? And that's what we're going to be focusing on. We're taking some of this learning and like open-sourcing some of the pieces of it and some of the back-end pieces we'll try to make a service, whatnot. But here are the examples. Here are some of the examples of games made by externally. You can see the games we made. Here's a list of some other games that we thought are pretty interesting that work. Again, not across the board, but still a pretty good job. The links to the videos as well as the actual site. So what does the code really look like for a game like this? So, ideally, this is all totally work in progress. So ideally, you want it to be as simple as having the entry point, having a blue framework which is got the notion of a scene. Typically, game engines, game frameworks have the concept of scene and director and the effect kind of thing. We really need to easily add images, buttons, so, scene management, stuff like that. Creating container, adding a background image, creating a button initialization and then setting that scene in games. This is a simple role to dice game. So nothing fancy, nothing complex. It's got to be fairly easy and look like some flash code or maybe some pretty high level code on any other platform. So for now, we're building everything on top of CAT that other engine that I talked about and we're building a product that's going to make this easier for all of us internally as well as for the community. So I think I'm out of time. So, thank you. Way of new animation tools that are coming out including the Commodore V where they take your flash code and compile it to HTML5. The performance isn't still there yet but you think it'll actually be mainstream someday. Flash is the tool of choice right now for game development. I'm sure Adobe wants to keep it that way and place where you will be performing responsive games on the browser. Yeah, so that was very good. The question was what about tools that take the content of the animations created in flash to be able to be used in HTML5? I'm actually a little disappointed in what I've seen so far because I don't understand why but there are a few tools out there I don't know what's what's limiting it but I think what's going to happen is the tools aren't there yet and I'm guessing they'll get better over time but it doesn't look like flash Adobe as a company is thinking of flash as a game engine a truly game engine so when they want to export from flash they want to support all this other stuff and really if you suck that into HTML5 you don't really want all of that so it's not optimized as a workflow or a pipeline for game development really the flash is a way of doing things I think was really optimized for its high CPU programming native animation engine and when they just if you can just import the data it's way too heavy for an HTML5 runtime HTML5 we don't have compiled animation engines baked into HTML5 so right now there's that big gap that was our experience I I don't know what they're going to do in the future it's not clear where do we go then? it depends on your context and that's the other thing there's such a range of games and it depends on your project if you have a project that has to come out in 3 months and it only has to run on desktops I think flash is a perfect choice but if you know that you have to get it on more platforms like on the iOS or any mobile device then I would say don't even start with flash because you're going to have to rewrite all that code again in HTML5 so yeah so if you're going to do it in HTML5 for tablets and on desktop HTML5 is super powerful it does a lot of things leaving the desktop part for the tablets and smartphones will if HTML5 works still well will the screen size and the dimensions will that be constant again because what we do for iOS or iPhone if I'm using the same set of graphics for a tablet it wouldn't match and general expectation of a user for a mobile device is to cover whole of the screen not like that of a desktop in a browser window so when it be again you will have to the same problem I don't think this HTML5 is going to solve you're still going to have to decide how you want to deal with real estate either your layout is procedural or you have different assets for different designs so a game framework should help you with that as well but there's no nothing in the HTML5 to help you with but it's still a big savings it's incremental what are the options you have for parking HTML5 other options other options are native right I don't know the native options yeah so there are tools, there are lots of tools like flash there's Unity, Cocos Corona, Game Salad there's lots of tools and the Q program in their environment maybe in another language like Lua or C sharp or something so that big list there's actually tons of what we found is that there are tons of products out there that help you but again if you want reach if you want like the maximum number of devices to be enabled then there's no one good solution other than writing it yourself how about monetization of the vegetables monetization of the vegetables monetization of the vegetables monetization of the vegetables how about monetization for monetization so your game is a it's part of the browser right so you have access to all the monetization techniques of traditional content for example, traditional techniques like access and all these things don't work for applications in game stores in the app store yeah, you can't use it you have to go for some other alternative or otherwise you have to create a which has to be necessarily the solution and you can use that API or implement it later right for apps there is no other alternative so you can't you can't use the AdSense for games in Chrome Web Store it's against their policy that's a policy thing, that's interesting sounds a little counter intuitive so now about HTML5 but basically you have these cross-platform mobile development cool kits like Titanium we have the experience for those when it comes to developing games not Titanium but to those games we use other frameworks that do the similar thing which is you have to be right in their framework and they compile it down to name a lot of performance phone gaps it's pretty good but it's limiting because you know I need I need the runtime cannot be this native thing when I'm trying to make I'm trying to use JavaScript as a scripting language to make a native game or a native app that works well but they're not somehow giving me highly optimized programming with that that can be run in a browser so that's been our focus that's been our focus getting games to run without plugins in the browser even on the phone because you know like for reach you can't leave out a certain device just because it doesn't have high performance but these browser-based games if you're seeing the interface on the mobile it's going to be the web browser and not a native app are they going to be available offline as well like how does a game ever get paid in such a model I thought I'd buy a browser-based game just like you buy other web content I guess but then we have to be continuously online with it not always we need to have offline and for a lot of people they will debate it into whether it's running or not because I haven't ever seen one of the mobile browsers yet that's it simple games will work fancy games alright thank you everybody