Making a speedy html5 game


Published on

membuat game speedy html5

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Making a speedy html5 game

  1. 1. Making a Speedy HTML5 Game Published by Sean SoriaThis is a guest post by Sean Soria of Gamzee, a leader in HTML5 game development. In this post, he describes the potentialof creating a city build using HTML5, as well as the trial and tribulations and how you can avoid them.Back when we started Gamzee, a lot of people in the game industry were down on HTML5. The hopeful ones said that HTML5was the wave of the future, but it just wasnt stable or fast enough to make the big sort of Ville-type Flash games thatdominate social gaming today. So what did we do? We set out to make a big, isometric game in HTML5. And not only would itrun on Facebook on desktop Web, but it would also run on mobile Web, utilizing Facebook Platform. On all iOS devices andAndroid phones.Pretty unambitious, right? Well, it’s what we did in making Skyscraper City -- an HTML5/node.JS game that runs on a singlecodebase and was built by a single team. As our first game as a new company, no less.In case you dont want to read the rest of this blog post, the results of all that work is here ( you can, indeed, play it on Facebook on the Web or on mobile on your iOS device or Android phone. Skyscraper City is acity-building game that combines the gameplay of social builders with the fun of Lego-style blocks. You can stack almost anycity unit on top of any other to build towers, elaborate structures, or whatever you want.What We LearnedWas it easy to make? Heck no.What did we learn? Here are the highlights.Way more people play the game on mobile devices than we expectedOne of the reasons we wanted to make a cross-platform HTML5 game is because were all gamers. I play CityVille, and I wantto check into my city on my phone while Im out and about. Zynga did launch CityVille Hometown, and I can download that ifIve got an iPhone or and Android phone, but its not the same game and its not the same city. Our game is truly cross-platform; you can play on your computer, your tablet, and your mobile device and maintain your progress on all those devices.Thats how we thought most people would play the game, too -- mostly playing on a computer, then continuing on a tablet orphone while they’re not at their computers. But there are more people playing the game on the iPod Touch or the iPad thanthere are on a Mac, for example. And way more Android phone users playing than any of those devices combined.Had we known that at the start, we could have spent more time optimizing mobile and less on Mac browsers. While we builtwith mobile in mind, we envisioned mobile as a secondary play environment. We recommend that game developers makingcross-platform focus on delivering a great mobile experience as their primary goal.
  2. 2. You have to do a lot of experimentationWe started with the idea that wed use Canvas (yay, HTML5) to render our game. That worked great on desktops -- noperformance issues. But on an iPhone 3GS, the performance was horrid (rendering less than 5 frames per second when wewere working on the game; performance has improved a lot with the release of iOS 5.0).So we had to create another render engine. And another one. And another one. Until we have the one we use now (a DOMrenderer), that works pretty well on most devices. The DOM renderer uses CSS animations, creating and animating in divs. Italso allows us to use a little kludge, using fake 3D CSS transforms on our 2D images in order to trigger hardware accelerationon mobile (which gives us a little boost in performance).Some things youre just not going to be able to do wellSound performance in HTML5 is still pretty iffy. The expectation in game development is that you’ll have mutliple sounds thatcan play in response to cues in the game and gamer inputs. Despite a lot of experimentation, its hard to get low-latency cuedup sound (i.e. a sound that reliably plays in response to a game or user action) and impossible to get multitracking (sound andmusic playing at the same time, for example) on most mobile devices. So we opted for sound and music on desktop and justmusic on mobile Web.Similarly, a simple trick to speed up performance on the DOM is fake 3D transforms on your CSS. That triggers hardwareacceleration on most mobile devices, resulting in better performance than Canvas, for example.For some reason, this doesn’t work on some Android phones, like Samsung’s Galaxy S2. As a result, you don’t get aperformance boost there.Here’s code that we used to trigger 3D transforms. And, as a bonus, we’re also showing you how we prevent the user fromselecting big chunks of text/graphics inadvertently and how we prevent the game from displaying the text cursor occasionally(both fixes help make the game feel more like a native app than a Web app).
  3. 3. /******************************//* Makes screen non-selectable and prevents text cursor from displaying *//******************************/div { margin: 0; padding: 0; -moz-user-select: -moz-none; -khtml-user-select: none; -webkit-user-select: none; /*3D transform */ -webkit-transform: scale3d(1, 1, 1); -o-user-select: none; user-select: none;}If youre going cross-platform, you have to design that from the ground upWe wanted to achieve as close to 1:1 parity as we could on the mobile experience as the desktop Web experience. So thatmeant turning off pinch to zoom on phones, not having rollover item/drop pickups on the Web version of the game, andfiguring out ways to implement rollovers on mobile (ours are either activated off of a button or by holding down your finger onthe item in question).Something like Cityville wouldnt work on mobile, at least not without substantially changing the game experience, because itwasnt designed around mobile screens. The menus are too large and complicated, and theres too much going on in a city toeasily show on a (relatively) tiny iPhone screen (hence the separate app Cityville Hometown for iOS and Android rather thanan integrated experience).Dont do stacking(!)One of the cool features of our game is that ability to stack I mentioned earlier. Its really fun to make a giant robot in your cityor construct an odd, stepped reverse pyramid supported by four thin columns.Unfortunately, stacking presents a host of issues on mobile. People with less than slender fingers sometimes have a hard timeaccurately picking what they want to click on. And, like Flash, render times increase the more objects youre drawing onscreen.We start our players out with a 10x10 city grid. You can get that up to 11 stories tall. If you slapped down 1-tile buildings thathigh, thats 1,100 buildings. Thats a lot of buildings to render. (And thats before the expansions we just added that let youquadruple the size of your grid). So while stacking is very neat, it can bite you in the butt with a very large city, making thegame take a while to load (up to a minute-plus on some mobile devices; the problem isn’t noticeable on desktop due to largerprocessing power). We’re making optimzations to how the game renders large amounts of objects. But we would have beenbetter served by realizing this in advance and coming up with another gameplay feature instead of stacking.
  4. 4. Love CSSYoud better be good at CSS, because getting a game working on all major browsers on desktop Web and Android phonesand all iOS devices requires a lot of the stuff. We have one Web Developer whose whole job is focusing on that, building outmenus that will dynamically size for various mobile devices and master versions for Web and tablet. One of the axioms ofvideo game design is that its 50% menu work. HTML5 cross-platform games are probably 50% CSS work.Areas of focus and useful toolsSo what did we take away from our experience?  We validated that you can make a cool, rich isometric game in HTML5 and have it be cross-platform.  We learned that if people can play a game on any device, a lot of them are going to do it primarily on mobile or tablet.  We learned that HTML5 cross-platform games require a lot of experimentation.  We learned that as great as HTML5 is, some things still arent quite there yet;  That designing a cross-platform experience means you need to think about the user experience on all devices from the ground up (in your game design);  That you shouldnt have a game on mobile that does a lot of stacking or overdrawing;  And that youd better love CSS and be good at it.Hopefully you learned something, and hopefully youll enjoy our game.And for those of you who read through to the end, here are a few things that made our lives easier as we developed a cross-platform HTML5 game on Facebook Platform.1) Viewporter. Zynga’s open-source code allows you to get screen size on any deviceand to scale your game to match. It saves a lot of time from writing it yourself (we know because we’ve used Viewporter andwritten our own).2) Weinre. A remote debugger that works like Web Inspector, but on mobile devices. Areal lifesaver when it comes to tracking down console errors on devices like iPhones and iPads.3) JQuery. Why write your own code if you can leverage a library? For things like text animations, JQuery’svery solid. We’ve made a few modifications, and JQuery Mobile now exists, which is better optimized for mobile devices, butJQuery gave us a huge headstart.4) node.JS. When you’re working in Javascript, it saves a lot of time and effort when you can have yourclient code and server code match as closely as possible. node.JS also scales remarkably well when acting as a game server.Building a game using HTML5? Leave your feedback below!