HTML5 Game Dev Tutorials

Building a Google Chromecast Game

Posted 23:23PM on February 02 2016 by Ben Chong Categories: Chromecast, Games, HTML5, Impact.js

Building a Google Chromecast game

The Chromecast USB device is thought of as a device to beam content onto big screens. Its mainly used to beam movies and tv shows.

This “casting” action is done by sending bits wirelessly from phone to the Chromecast USB, attached to a giant screen.

Being game developers, we often wonder …

What if, we could build a game with Chromecast?

We spent some time looking into the documentation. It appears that the phone (sender) can be programmed to beam data to the chromecast USB (receiver).

Based on this simple theory, we could build an interactive game. We could have the user *do stuff on the phone, and the results *get beamed onto the big screen.

We set about building a soccer game. We narrowed it down to the one thing people love seeing: goals!

Q: What’s the closest thing to scoring goals?

A: Penalty kicks!

We first designed a simple wireframe diagram, to classify all objects and entities in the both parts.

Flow diagram

Figure 1 - A simple flow diagram

We split the project into 2 teams.

Team A worked on the sender app, using Android, Cordova and HTML5.

Team B worked on the receiver app, using HTML5.

Both teams had to work on their own challenges, as well as communicate with each other by setting common standards for transmitting data.

Team A’s challenges

Team A had to build an Android (Cordova) app that has a small HTML5 game, that allows user to flick the soccer ball. The view captures that of the player, looking down at his/her feet.

It was initially tricky to place the game into Cordova, but we managed it with a good frame rate. The next challenge was having the phone sync up to the Chromecast USB. This involved careful, step by step following of instructions in the developer docs. Once that’s done, we had to translate that into actionable code in the app.

Team B’s challenges

Team B had to design the goalie and goal scene. They had to figure out where the ball should come out from, given a set of data passed over by the sender app.

Based on the data (generated by the user’s swiping motion), the soccer ball should move/curl accordingly, into the goal net.

To make it challenging, we had a rather smart goalie who would block the user’s shots, deflecting it away from the goal.

The game loop is kept simple: score as many goals with 10 shots. Once the 10 shots are done, we show a quick rundown of results.

The entirety of the receiver is written using HTML5, our top choice for multi-platform code.


Here’s a quick youtube. We added a few fun sound effects as well.


Goalkeeper chiiling

Figure 2 - Goalie chiiling

Goalie working hard to block the shot

Figure 3 - Goalie working hard to block the shot

We hope that this article serves as a blueprint for future innovation in Chromecast games. Ping us if you’ve made something cool, and would like to share it.

HTML5 Endless Runner: History and Design Thinking

Posted 00:44AM on December 20 2014 by Ben Chong

HTML5 Endless Runner: History and Design Concepts

At MarketJS, we receive many requests on how to build Endless Runner games.

Instead of diving into code, we’d like to approach this from a high level form of thinking. At the very least, this tutorial will teach you how to approach building and designing an Endless Runner game in HTML5. For simplicity’s sake, let’s abbreviate this as ER.

What's an Endless Runner (ER) game?

Essentially, this a game where a main protagonist runs forward into the game which never ends. One of my favorite endless runners is Jetpack Joyride.

Alt text

Figure - Jetpack Joyride from 2011


The Endless Runner genre stems from 2D platformer games in the 90s. Back then, 2D platformers such as Super Mario were all the rage. The gameplay was simple, where the player controls all aspects of the main protagonist (Mario), including moving, jumping and shooting.

With the proliferation of smartphones and tablets since 2007, mobile consumption habits evolved to short-term attention spans. Users are more accustomed to ‘snackable gaming’, where game sessions are minutes instead of hours. To meet this demand, developers had to simplify 2D platformer games.

The first variation involved replicating the 2D platformer experience on the mobile device, without movement controls. Developers essentially made the main character constantly run. Players only had two controls — jump and shoot. The games were designed to be in endless mode. This was one of the earliers endless runners. Monster Dash was the perfect example of this. We call this two touch endless runner (2TER).

Alt text

Figure - 2TER

The second variation is even more simplified. Instead of two touches, the game only has one touch control. This makes perfect sense — the mobile user is constantly on the go, holding the device on one hand. Developers started making characters automatically run and shoot. All the user has to do, is tap anywhere on the screen to jump.

This spawned a whole subset of one-touch endless runner (1TER) games, which include Jetpack Joyride (tap to boost the jetpack) and Flappy Bird (tap to fly higher)

Alt text

Figure - 1TER

Mobile gaming habits of users, have actually encouraged developers to be more creative in their game design solutions. Simplicity is heavily rewarded with massive audiences.

Coupled with the idea of HTML5 being the driver of fast and nimble games, building an extremely simple ER makes a lot of sense.

Approaching ER design for HTML5

There are many ways to start the design of an ER game. I’ll describe in general terms, how we arrived at our Santa Claus Chimney Challenge game design.

Initially, we didn’t even think of building an ER game. We simply wanted to build a Christmas-themed game that works well with HTML5.

The user plays Santa Claus withs his red-nosed reindeers. It’s Christmas, and Santa has to get to his destination to deliver gifts. We know that Santa goes through a chimney to deliver presents.

The first thought we had, was to have Santa drop into the chimney to deliver presents. This makes perfect sense! The design of the game would involve:

  • positioning Santa into a chimney
  • having Santa climb down the chimney, to a christmas tree, inside a house
  • having Santa deliver the presents to kids, and scoring points
  • drawing the necessary artwork for this

Holy crap! This was orders of magnitude more complicated that what we envisioned. This will be hard to pull off with HTML5. Imagine all the artwork needed to accomplish this. We had to rework and simplify our design. Back to the drawing board.

We also know that chimneys are made of these hard red bricks, which Santa could potentially crash into. To us, chimneys vary from heights (from those tall factory chimneys) to regular household ones. What if, we could make them as obstacles? We could vary the height, and Santa will have to avoid crashing into the chimneys.

Alt text

Figure - Fitting Santa and his red-nosed reindeers between the chimneys

Alright then. Now we have Santa and his red-nosed reindeers. We have chimneys. The scrolling background could be a snowy one with nice homes and some trees. Looks like a recipe for an 1TER game.

Next, we thought about the difficulty of the game. Viewed from a 2D perspective, Santa and his red-nosed reindeers are seen as 5 separate blocks (santa and 4 other reindeers). They would interact with each other via a ‘chain’ mechanic.

This is perfect for us, because it’s naturally difficult to fit a chain in between chimney obstacles. We knew it was going to be fun for the users, because it gets tricky to fit all 5 objects in the chain, between the chimneys!

Now we have to tweak the difficulty of the game. We had to be sure:

  • the chimneys aren’t too tall
  • the jumping mechanic ( the object chain) works extremely well in avoiding the chimneys
  • the chimneys shouldn’t spawn that often (so the players can have some emotional relief in between chimneys)

The rest is simply wrapping it up into an ER mode, where points are scored for the distance covered by Santa.

Link to Santa Claus Chimney Challenge game:


I hope this article helps developers with their game design thinking. This approach can basically be applied to any other game genre for HTML5 game development. For more inquiries, feel free to drop us an email:

Free Introduction to HTML5 Game Development Course

Posted 11:30AM on July 11 2014 by Pascal Rettig

Zenva Academy has released a free introductory game development course.


HTML5 Game Course: Veggies vs. Zombies

Posted 14:22PM on June 04 2014 by Pascal Rettig

Zenva has add a new course on HTML5 Game Development to build a real-time town defense game, complete with angry, shambling enemies and the vegetable-based heroes. 

The course is (as of this writing) available for $27. The course adds to their existing catalogue of courses

HTML5 Game Course: Mobile Game Development by Example – Educational Game

Posted 17:50PM on April 19 2014 by Pascal Rettig

Zenva has add a new course on HTML5 Game Development that walks you through the steps of building an Educational game using HTML5 that pits you against computer racers where you must solve math problems with speed and precision to win. The course is (as of this writing) on sale for $29, from it's regular price of $99.

The course is available in English and Spanish and adds to their existing catalogue of courses

iOS 7.1 - minimal-ui is anything but minimal for HTML5 game developers

Posted 15:16PM on March 20 2014 by Pascal Rettig

This is a guest post from Odobo CTO Peter Mareš.

As the developer program for real-money gaming, we assess the impact that any new software update is likely to have on our developer community. The positive news with iOS 7.1 is that this version presents a great opportunity for all HTML5 game developers and full screen app producers.

The most exciting addition is a modification to how Safari handles web apps: it makes development easier, improves the look of games and enhances the player experience. Better still, it is easy to implement. By updating a small piece of code in our Game Development Kit (GDK), every game automatically updated to take advantage of these improvements.

In this article, we cover some iOS 7.0 history, prior solutions, and the future ahead with 7.1.

iOS 7.0 Safari: a brief history

In iOS 7.0, Mobile Safari hid the address bar and changed the behaviour of both full-screen browsing and full-screen mode. Although the idea behind full-screen browsing on iPhone was great, it was originally designed for scrollable webpages, not full-screen web apps such as media players and games. For gamers and developers this presented more of a challenge than with the previous version of iOS.

Although the changes impacted both device orientations, landscape presented the greatest need for a workaround: if a user tapped the top or bottom of the screen, the browser bars would activate, reducing the screen real estate, interrupting and obscuring the game or application. To complicate matters further, it was not possible to launch the game in full-screen mode.

iOS 7.0 Safari: a temporary solution

Since no browser event was fired when the browser bars appeared, workarounds had to poll the visible browser area for each frame (we used requestAnimationFrame). This identified when browser bars were both visible and unsought. Once detected, the content was resized to allow scrolling, disabled the app, and presented a ‘swipe up’ message to the user.

Once the user swiped up, the app would detect that the visible browser area had been increased, re-enabling and resizing the content back to full-screen.

This provided a solution; however, it was a messy hack.

On the design side, developers had to change their game design practices to avoid the top and bottom areas (each ~100px high) for any interactive elements to prevent users from triggering the bars. While this reduced the frequency of which this feature occurred in apps, it still presented a user experience challenge.

To provide a more natural experience to players, we provided direct feedback to Apple in hopes of creating web app development extensions.

Safari - full-screen ahead

iOS 7.1 arrived with a little-publicised gem for every HTML5 developer: minimal-ui.

In the iOS 7.1 release notes, under Safari, you will find the following:

A property, minimal-ui, has been added for the viewport meta tag key that allows minimizing the top and bottom bars on the iPhone as the page loads. While on a page using minimal-ui, tapping the top bar brings the bars back. Tapping back in the content dismisses them again.

For example, use <meta name=”viewport” content=”width=1024, minimal-ui”>.

This small addition literally changes the game. Simply adding minimal-ui to our viewport’s meta tag (something automatically handled by the GDK) now solves the challenges presented in iOS 7.0 with one easy step - and being native, it performs exceptionally well.

Now, running HTML5 full-screen apps on iOS 7.1 looks and feels great without the need for complicated workarounds sitting behind the UI.

Apple has also gone a step further and removed the ‘dead-zone’ at the bottom of the display, which means that users can only activate the browser bars by tapping the top of the screen. When this happens, the bars appear, with a darkened overlay covering the app below. This provides the user with a true native feeling of being ‘out of the app’. Simply tapping in the content space will intuitively bring back the full-screen app.

So whatever you feel about iOS 7.1 in general, for gaming enthusiasts and HTML5 developers, this new update is one we’re applauding.

About Odobo

This is a guest post from Odobo CTO Peter Mareš.

Odobo is the HTML5 games development program and content Marketplace for the regulated real-money gambling industry. The Odobo Game Development Kit (GDK) provides game developers with a framework for their game client production and access to state-of-the-art technologies to assist in their development of regulatory-compliant HTML5 games for real-money play. Odobo games are made available to participating licensed gaming operators via the Odobo Marketplace - the B2B ‘app store’ for the gaming industry. Developers earn royalties based upon the revenue generated by their games and access additional affiliate commissions when they market their games and drive new players to the gaming operators. Developer’s recently added to those working on Odobo’s platform are: AppleJack Gaming, Wild Game Reserve, Core Gaming, Trimark, Red7 and Probability Jones, with others to be announced soon.

Odobo, based in Gibraltar, is licensed and regulated by the Gibraltar Gambling Commission. The company employs over 80 staff.

Developing HTML5 games (1hr video presentation)

Posted 13:38PM on December 19 2013 by Pascal Rettig

It's a few months old, but this talk by Anders Norås by at the Norwegian Developer Conference in June 2013 walks through creating a HTML5 Game with Quintus.

Create a HTML5 Mario-Style Platformer Game

Posted 10:18AM on August 19 2013 by Pascal Rettig

Pablo Fariazz has posted a tutorial on on building a Mario-style 2D Platformer in HTML5 using the Quintus game engine.

Check out the full tutorial

Creating SpaceDebris: A browser game made in Blender

Posted 12:33PM on August 03 2013 by Pascal Rettig

SpaceDebris is a HTML5 game prototype built by using Blender and ported to HTML5 using Three.js.

The level design and texturing was done in Blender and the game write-up details the workflow for the game.

Play SpaceDebris or check out the detailed write-up and code comments for more on how it was done.

Creating a Mobile Educational Game with HTML5

Posted 16:27PM on July 28 2013 by Pascal Rettig

Pablo Farías has put together an in-depth game development tutorial using the Quintus HTML5 Game Engine describing how to build a mobile educational game using HTML5.

The game consists of a math-powered racer where you solve multiplication problems to win. All the code for each step of the game, as well as the assets are provided in the tutorial.

Check out the full tutorial

1 2 3 4 5 .. 9   > >