define('DISALLOW_FILE_EDIT', true); Javascript – unFocus Projects – Kevin Newman and Ken Newman

Introducing Quint Dice!

I’ve been working on a game for the last few months in spare time. It’s a dice game called Quint Dice, a social dice game. What makes this different from so many dice games out there is that it’s based on dice that have color pairs, and you can play it with more than two players.

What I’d like to avoid with Quint Dice is pay to win forms of revenue. Currently there are no bonus rolls. I’ll eventually add some, but you won’t be able to buy them or stock pile them to gain advantage over your opponents. I think I’ll add one bonus roll per game, and if you don’t use it in that game it goes away. I may also add a second bonus type – an extra dice. The idea is to add a level of strategy and flexibility to the play, without allowing a fundamental shift in advantage for one player or another just because they paid for an advantage.

The only revenue source built into the game at launch is a small banner ad at the bottom. I’d also like to add custom dice packs, and maybe some full on themes. I’m hoping this will be enough to turn this into something that pays for itself. I may also play with interstitial ads, but only as a voluntary way to earn points to buy custom dice packs and themes without shelling out cash, for users who prefer that route. I like this better than pestering players with involuntary interstitial ads as a way to get them to pay. Annoying players is not my favorite model, no matter how common it is in mobile gaming. Finally, there will eventually be an option to remove the ads.

I built Quint Dice with Meteor and React, and I would like to eventually port to React Native, but I’m using Cordova for the time being on Android and iOS (soon!). Like so many of the projects I play with under the unFocus banner, this has mostly been a learning exercise. But I’m happy with the results, and thought I should probably dust off this blog, and may start to share some thoughts I have as I develop these things.

To kick that off, I’ll share a couple of things I learned while getting this out the door, in no particular order. If you’d like to know more about any of these items, please leave a comments, and I’ll see about writing a follow-up post.

  • Facebook integration is easy/hard. Getting notifications to work seems pretty easy, but getting a canvas app to work posses some challenges, particularly where advertising is involved. You can’t use AdSense inside an iframe, which is needed for FB canvas. Instead you’ll need to go with one of Facebook’s approved ad vendors. They all have that institutional feel to them, if their websites can even be reached. Not a fantastic dev experience. The solution I’ll probably go with is to create a Facebook canvas based landing page, and then flow my users to my domain from there, instead of having them play within the canvas page.
  • Meteor’s accounts system is awesome! With very little effort you can get up and running with a full accounts system, and there are a ton of Meteor packages to expand functionality. I ended up building custom UI in the end, but to get started I used the off the shelf accounts-ui, so I didn’t have to wait. I’ll probably be using a link accounts package to add the ability to associate facebook, google+ and maybe other third-party accounts services (Amazon perhaps) to existing Quint Dice accounts. I may also use an account merge package to make it so users can merge their accounts if they accidentally sign up with two different auth sources and want to combine their accounts into one. There are two different packages for that – and these are the kinds of things that make Meteor so fantastic! I can’t think of another platform where something like that is so easy to set up. Setting this up has some interesting challenges in terms of user flow, and it’s probably worthy of a blog post or two.
  • My on boarding process is a mess in the current iteration. I hope to fix that with the above mentioned packages link and merge packages. I may also play around with having an anonymous user for anyone who comes to the site and is not logged in. That way they can just get started.
  • Finding players is another messy area so far. I basically only collect one bit of information from users – a username. To start a game with other players, you are presented with a giant list of every player. This clearly needs work. Eventually I’d like to add Facebook friend support, and maybe even a friends list internal to Quint Dice. I’ll also add more profile data and some way to search on that (this is on my short list).
  • Push notifications are relatively easy to set up on Android. Relatively more complicated on iOS, but I should have that out soon (this is the only thing hold up an iOS release). I did figure out how to get a nice black and white notification icon to work, and that maybe warrants its own blog post (see this Meteor forums post for now). I’m using raix:push package in Meteor for that.
  • Meteor’s React support is build around a React Mixin, which basically wraps a single method on a component to make it reactive. This makes sense given that Meteor typically doesn’t enforce any kind of application architecture on the developer (a good thing IMHO), but I will probably switch to using something more Flux like. For non-reactive data sources and application state, I’m already using a Flux like pattern/architecture (using SignalsLite.js), but I may look into something like Reflux (or maybe Redux, or Alt) and then figure out how to move my reactive Meteor handling to that level. This probably warrants a blog post or two.
  • I used Adobe Animate CC to create the animated dice roller (output as HTML5 Canvas of course). CreateJS is pretty sweet, even on mobile. I may experiment with OpenFL for new dice packs, and see how well that runs. I’m thinking that custom dice packs will stay in HTML5, even if I eventually transition to React Native, so that they can be truly cross-platform. The only challenge with that might be an eventual port to Apple Watch, and AppleTV, which don’t support WebViews. I’m curious though if there is a way to use the JS behind my canvas based mini-apps, and render that through some HTML5 canvas wrapper from within a JavaScriptCore instance (is JSCore on Apple WatchOS and Apple TVOS?). When I figure this out, I’ll almost certainly blog about it. Of course, I may not even need all that if I go with OpenFL, because they have a native c++ compiler.

Going forward, I’ll try to post more, probably when I make an update. There are a ton of other important packages (aldeed:simple-schema and aldeed:collection2) and technologies to cover, and I’m sure I’ll mention them eventually.

HiDPI/Retina for CreateJS (Flash Pro HTML5 Canvas)

Adding HiDPI and Retina screen support to a CreateJS (Flash HTML5 canvas publish with EaselJS) is easy enough. Just add this code after where the stage is defined in your published html file (either inside the generated init function, or handleComplete if there are external assets to load):

if (window.devicePixelRatio) {
// grab the width and height from canvas
var height = canvas.getAttribute(‘height’);
var width = canvas.getAttribute(‘width’);
// reset the canvas width and height with window.devicePixelRatio applied
canvas.setAttribute(‘width’, Math.round(width * window.devicePixelRatio));
canvas.setAttribute(‘height’, Math.round( height * window.devicePixelRatio));
// force the canvas back to the original size using css = width+"px"; = height+"px";
// set CreateJS to render scaled
stage.scaleX = stage.scaleY = window.devicePixelRatio;

IE 10 doesn’t support devicePixelRatio, but you can get a resonable devicePixelRatio with this (include it before your CreateJS script, and call window.getDevicePixelRatio() instead of using the standard property):

/*! GetDevicePixelRatio | Author: Tyson Matanich, 2012 | License: MIT */
(function (window) {
window.getDevicePixelRatio = function () {
var ratio = 1;
// To account for zoom, change to use deviceXDPI instead of systemXDPI
if (window.screen.systemXDPI !== undefined && window.screen.logicalXDPI !== undefined && window.screen.systemXDPI > window.screen.logicalXDPI) {
// Only allow for values > 1
ratio = window.screen.systemXDPI / window.screen.logicalXDPI;
else if (window.devicePixelRatio !== undefined) {
ratio = window.devicePixelRatio;
return ratio;

If you like to load your CreateJS based animation in an iframe (I do) and the canvas content is the only content, you may also want to add some styles to avoid scrollbars and extra padding:

body {
canvas {
display: block;

Before making these edits, I recommend copying the main html page, so that you don’t have to worry about the publisher wiping out your changes when you publish again (if certain things change, you may need to reintegrate your changes).

Some Notes:

  • Some (slightly) older versions of Safari on OSX with Retina screens seemed to automatically apply a pixel doubling to canvas elements, so this might be redoubling again (I’m really not sure). It doesn’t seem to do this in the latest version though.
  • If you use “cacheAsBitmap” the content will be cached at the normal resolution. If you can find the place in code where that’s being set, you can actually apply the devicePixelRatio multiplier there by passing it in as a variable to the function that sets CAB, but CreateJS does not do this by default.

Relevant info for devicePixelRatio and supporting HiDPI / Retina displays

A Simple State Manager for History Keeper

Someone asked how to store a key value pair in HistoryKeeper recently, and this was my answer.

History Keeper does not provide any state management features beyond the information you store on the actual deep link (URL hash). However, you should be able to use the deep link information to grab the data you need out of a standard JS object (using it like a hash table):

[cc lang=”javascript”]
var storage = {
“/”: {
key: “home value”
“/about”: {
key: “about value”

Once you have your values stored like that you can use the storage object to lookup your chunk of data by the deep link string:

[cc lang=”javascript”]
function onHistoryChange(hash) {
unFocus.History.addEventListener(‘historyChange’, onHistoryChange);

You can make the “value” as deep as you want ( key: {more: “complex”} ), I only used a simple string for demonstration purposes.

This example is JavaScript, but the concepts are the same for Actionscript as well.

I hope that helps!

Trace Actionscript in a Browser

Testing Flash apps in a browser can be cumbersome, but it needs to be done for some browser only functionality, such as deep linking and back button functionality – as well as checking other things that might change once you are out of the Flash “test movie” sandbox, and into the browser – things like file path issues. The convenient trace window is not available in the browser, but there are alternatives.

Flash Content Debugger and “Allow Debugging”

While it’s not essential for tracing, the first thing you should do, is make sure you are running a content debugger version of the Flash Player. You need both the Active X version for IE, and the Plugin version for everyone else (Firefox, Chrome, Opera, Safari, etc.). Both plugin types have their quirks with regards to JavaScript (and other platform differences), and really require specific testing in each, so make sure you grab both versions. Once you have those, you’ll be able to see uncaught exceptions in AS3 swfs right in the browser. You can even use the Flash Content Debugger from the browser, though I haven’t found a smooth way to do that yet. For many thing, a simple trace is all you need.

A quick tip that took me a while to notice – the “Allow Debugging” checkbox in Flash’s Publishing Settings dialog, actually causes the Flash compiler to add debugging symbols to the compiled swf, symbols that give you useful information like the actual line number of an error, in addition to the stack trace. The “Allow Debugging” verbiage, is most definately not enough to communicate that difference – I thought it was more of a locking mechanism. Hopefully you haven’t stumbled around for too long with that, like I did when I first switched to AS3..


The easiest way to trace from Flash is to use Firefox with the FlashTracer extension from With FlashTracer, you can use the regular old built in trace method without any extra work on your part. Make sure you download the one from (2.3.1), since the one from (2.2.0) doesn’t work in Firefox 3.5. For many things that’ll be all you need. But sometimes, you’ll need information in other browsers, and will want to trace to the browsers JavaScript console. In addition to simple trace messages, you can also call a number of other methods that will out put your messages in different formats and colors, making it easier to spot what you might be looking for.

Check out the Firebug Console API for more information.

Enabling the JavaScript console

If you are already familiar with the various JavaScript consoles, please feel free to skip to this part.

Each of the major browser vendors has a JavaScript console implementation, and thankfully, the API is mostly compatible with one another. The GUI is a bit different in each (except Safari and Chrome – both are based on WebKit), so here’s a quick rundown on how to access the JavaScript console for each:


You should get to know and love Firebug. It is currently the best developer tool available on any platform – so good the others all copied it, even if they won’t admit it (*cough*Microsoft*cough*). Firefox is oddly enough, the only browser that doesn’t ship with a JavaScript console, and requires you to install an extension. While running Firefox, you can find and install that extension at

Once Firebug is installed, you will notice a little bug (insect) icon in the bottom right hand corner of the browser window, on the status bar. Click that to open and enable Firebug for the page you are currently viewing. Firebug will only turn itself on, on a site by site basis, and only after you click on that bug icon. Once it has popped open, you will see some tabs, with many goodies like the fabulous “Net” tab (very useful to make sure swfs are being loaded in the browser), and the “HTML” tab, which contains a live, nested version of your html code, which can be edited in real time – it’s hard to describe how much better life is in the Web Development since Firebug. Anyway, the tab we are interested in, is the “Console” tab – click that. On the actual tab, there will be a little down arrow – click that to open a menu, then click “Enabled” to turn the console on (the onscreen instructions are a little odd, their picture is of the “Script” tab – the arrow you want is on the “Console” tab, not the “Script” tab).

Internet Explorer

You’ll need to upgrade to IE8. If you are stuck on IE6, I’m sorry for you. You will not be able to easily debug Flash apps – that browser is simply difficult to work with, and you’ll probably need to output to either a text field within flash, or to a div element using JavaScript. Go and download IE8 now, if you don’t already have it. Once you have IE8 installed, you can find the “Developer Tools” under “Tools” menu. You can also press F12 to bring them up. The dev tools in IE8 are docked to the main window, along the bottom of the screen, very much like Firebug. You will notice 4 tabs in a blue bar, below a row of link buttons – click the “Script” tab to open the script tools. You will have two panes at that point – in the left is a debugger, and in the right pane, you should see a button for the Console.


You’ll need to enable the developer tool first, before you can turn on the JavaScript console. Click on the gears icon on the main toolbar, and choose “Preferences”, then click the “Advanced” tab (the one with the gear icon). On that page, there is a checkbox labeled “Show develop menu in menu bar”. Check that, and close the window. Now under the Page icon menu, you’ll see a sub menu called “Develop”. In that sub-menu, choose “Show Error Console”. This will open the “Web Inspector” window. You can dock the window along the bottom of the main window by clicking the dock button in the bottom left of the Web Inspector window. To the right of that button, there is another button with a greater than sign, and three lines. That button will toggle the JavaScript console.


Click the page drop down icon on the right of the main toolbar to open the main menu, then go to Developer, then JavaScript console. This will open the “Developer Tools” window, which contains the many things, including the JavaScript console. You can dock window inside of the main window by pressing the dock button on the bottom left of the popup window. To the right of that button, there is another button with a greater than sign, and three lines. That button will toggle the JavaScript console for Chrome.


Under the Tools menu, choose the “Advanced” submenu, then choose “Developer Tools”. This will open a panel along the bottom of the main window (sensing a trend here?). In that panel, click on the “Error Console” tab. If you’d like to only see JavaScript errors, you can click the bottom JavaScirpt tab (under the white output area of the Error Console). Note: Their is an alternative “Error Console” under Tools -> Advanced -> Error Console. Try them both, and use the one you prefer.

Tracing to the Console

Once you have familiarized yourself with the JavaScript console, you can start to trace to it. The JavaScript command is simple enough:

[cc lang=’javascript’ ]
window.console.log(“your message”).

From Actionscript you’ll need something like this:

[cc lang=’actionscript’ ]
import flash.external.ExternalInterface;“console.log”, “your message”);

Since we are using ExternalInterface, you’ll need to make sure you have the allowScriptAccess object param, or embed attribute set to an appropriate value – either “always” or “sameDomain” (sameDomain is the default, so as long as you have your html/javascript/swf all on the same domain, you should be good to go).

You should now be able to trace (or something like it) in the browser. Next time I’ll cover some more advanced uses, as well as some more specific snafus with deep linking and browser back button functionality.


unFocus History Keeper is a JavaScript based library for managing browser history (back button) and providing support for deep linking for Flash and Ajax applications.

What I’m proposing is taking History Keeper and making a jQuery plugin, and also a WordPress plugin to include the History Keeper library for use in WordPress. I am primarily interested in this for the process of it: to learn more about making plugins.