Chapter 12
Final Notes
This book covered a large slice of HTML5 game development. Starting in Part I, we learned high level concepts, tools for development, and how to build a small pong game. Then in Part II, we stopped reinventing the wheel by introducing game engines to take our examples further. We used four top game engines to build 4 different demos that could be played on all the major desktop and mobile platforms and learned a lot in the process. Then in Part III, we learned how to package our games to be placed in the top app markets and natively on the desktop so our users can find and play them however they please.
In summary, we learned development and distribution of HTML5 games. So, what could be missing? That is what this chapter covers.
12.1 Plugins
Whether officially or indirectly, many of the tools we used have a plugin system to extend functionality beyond the normal use. This section covers a few of them.
12.1.1 Crafty Modules
Crafty plugins are called “modules.” They are spread around the web, but many can be found at the http://CraftyComponents.com/ website. One that you may be particularly interested in is the Box2D module since Crafty lacks its own full physics engine. To use a Crafty module, you may surround your game with module declarations or create a component.
12.1.2 Impact Plugins
Impact also has a pseudo plugins system (through its “inject()” method) to extend functionality. The home page for many plugins can be found at http://www.pointofimpactjs.com/, but directly searching the Impact forums is a good place as well.
The plugins will include instructions on how to install. In general, it usually involves creating a “plugins” subdirectory from your main “lib” directory and unzipping the plugin there. Then you can include the plugin in your “requires(’plugins.myplugin’)” code.
One Impact plugin you may wish to glance at is “impactplusplus” (or “impact++”).
12.1.3 CocoonJS Extensions
We used CocoonJS to accelerate our JavaScript and package our HTML5 game into a standalone Android game. The CocoonJS services actually go beyond that in the form of “CocoonJS Extensions” located at http://wiki.ludei.com/cocoonjs:extensions. There are extensions available to allow access to various mobile internals not part of normal JavaScript, such as contacts, camera, ads, in-app purchasing, etc. Naturally, if you wish to make heavy use of CocoonJS extensions and acceleration, you will probably develop for mobile first (which is a good strategy anyway) and then target desktop second (if at all).
Some of the extensions require a premium account. Right now, premium accounts are free (like normal accounts). However, you must fill out an application and get approval. Note that the CocoonJS Extensions also work in DOM mode for normal web apps.
12.2 Desktop Stores
Mac and Windows both have app stores that weren’t covered in this book. This is because both are fairly recent additions and fairly easy to bypass to sell the installer directly. However, they are available as another avenue to sell your game.
If you go this route, note that the Windows store has lots of interface guidelines that (for now) only Visual Studio 2012 can pass. Node-webkit will not pass. There is an Impact-oriented Windows bootstrap project located in GitHub at:
https://github.com/gamecook/super-jetroid-starter-kit
Take a look at that to see how to proceed. Note that JavaScript is a first-class citizen when developing for Windows 8, so there are no real barriers to HTML5. You will need to work through the style and approval process. The end result will be a lightweight app that internally calls on Windows 8’s own IE rendering engine to power your app.
For the Mac App Store, node-webkit will not pass their guidelines either. The strategy here is the same as Windows Store: Use the desktop’s native rendering engine. Take a look at https://github.com/maccman/macgap for a method to build your app to run natively as a WebView calling the Mac’s rendering engine.
Note that the capability of your game is dependent on the browser the end user has installed, which usually means targeting the default OS version. Most of the engines should work fine with this strategy except perhaps Turbulenz because WebGL support is very weak in default Windows 8 IE.
12.3 Monetization
Throughout the entirety of this book, there has been little or no coverage on app monetization. The best way to earn money from your game is a complex decision that should be made very early. Therefore, it usually falls into the realm of “game design” while this book tries to focus on “game development.” However, it is worth at least a mention.
There are many ways to monetize an app, but the most common methods include:
- Sell the app directly.
This is very straightforward, and it is the method that was assumed in this book. You write the app. When finished, you put it on the app store and sell it for X dollars. Usually, the app store takes around a 30% cut for itself. - Show ads.
To do this, you would most likely sign up for an ad service, such as iAds or AdMob. A small slice of your app’s screen is reserved for this ad network. There are tons of ad networks with varying methods of paying. Usually, there is a very small fee paid for number of “impressions”, which is a count of how many times it is shown. Often, that number is in the many thousands and is not even a concern unless the app becomes really popular. There is a much larger fee paid if a user actually clicks/touches the ad. That can be an immediate payment of several cents and can add up quick. - In-App Purchases (or IAP).
This is the business model of the “freemium” games. You give a game away for free. Premium enhancements, or perhaps shortcuts for the game, require an in-app purchase. In-app purchases are also sometimes used to unlock a “lite” version of an app to a full version. Usually, the app store takes around a 30% cut for itself on IAP.
It is not uncommon to combine two revenue models. Often a “freemium” game also will have ads. A paid app could have IAP (in the style that many console games have “downloadable content” that costs extra). A paid game usually does not have ads. You could do that, but your users would probably revolt. Also, note that paid apps + IAP is not tolerated well on mobile either.
Regardless of the path you take, you should decide early. Most game engines have a way to support ads and IAPs.
12.4 Signing Off
This concludes the HTML5 Game Engines book. If you have any questions or comments, the support website is located at http://HTML5GameEnginesBook.com/.
Thank you for reading, and good luck with your game!