Quint Dice update – Facebook and profile

An update on Quint Dice. I turned on all the Facebook registration and login stuff that’s actually been done for a while, but I had off for a few reasons. Users may now sign up with their Facebook account, to make it easier to get started. Adding Facebook support has been one of the bigger time sinks in this project. Here’s a list of what’s done and not, so you’ll see why.


  • Facebook accounts – done!
  • Facebook link accounts (if you have a password based account, you can add Facebook to it, then log in with your FB account in the future).

Not Done:

  • Facebook Canvas – as I mentioned in an earlier post, it looks like ads are a problem within Canvas. I still have to figure out what to do about that.
  • Facebook notifications – The setting is available, so you may opt-out (it’s on by default) but I haven’t set it up to send notifications yet. It looks like I need to have a return URL within a Canvas app to make it work, but I’m not certain, and need to read the FB docs more carefully.
  • Native Facebook in Cordova for Android and iOS. This is turning into an endless headache. There are at least 3 Meteor packages that promise to do this, but each needs a Cordova plugin that I just can’t seem to build (a third one that I’m not sure how to install). I had hoped this would be much easier (and I’m actually pretty sure I once had it working), but it’s costing me a lot of time, so I’m probably going to let it lie for a while.
  • A user who registers with Facebook will have no username – I need to make sure they enter one, since that’s the primary way we do user discovery ATM.
  • No friends list, which is an important feature in my mind – starting games and inviting folks to play.
  • Account merging – if a user signs up one way (password) then signs up again another way (Facebook) then wants to link their accounts, they should be able to. There is a Meteor package (or 2) for this, but I have to implement some glue for it.

Other updates in this round are better styling for forms, and the ability to set other profile data, such as your email address (useful if you forget your password!). You can also change your username if you want, and opt-out of push notifications on mobile.

More soon!

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
	canvas.style.width = width+"px";
	canvas.style.height = 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

SVGView for Xamarin.Android

Instead of making dozens of PNG files for all the various screen sizes for icon assets, I wanted to use vector graphics (such as SVG) in an Android app I’m building with Xamarin.Android. There is a tool for generating images, and that’s better than nothing, but SVG is even easier, and I’m all about easier. I thought this would be relatively easy to do, but it turns out Android has no built in support for vector image formats.

Xamarin has a nice binding project and sample for using an SVG library (I think it wraps SVG-Android on GitHub) in Android apps, but it wasn’t clear how to use that, and there was an annoying gotcha I hit along the way, that I thought I’d document here.

There are two projects in the sample solution. One is the library project, and the other is a sample project, with sample art that you can build to see it working. What we want to do is build the library, and then copy the necessary components into our own Android app project. Here’s how to do that using Xamarin Studio.

  1. Download and unzip the project files from Xamarin (or fork it on GitHub). Open the Solution in Xamarin Studio. You should see something like this:
  2. Put the build mode into “Release” and then right click (or control click) on SvgAndroid (Highlighted in the screenshot above), and then click Build SvgAndroid (or highlight the project and press cmd+K). This will make a release .dll file (a .NET assembly) in the bin folder:
  3. You’ll need to copy two files into your own project. SvgAndroid.dll from bin/Release, and svg-android-1.1.jar from the Jars folder. I put SvgAndroid.dll file in the project/Assemblies folder in in my project hierarchy so that the dll could be managed in git with the rest of my project (the git rule of thumb – include what you need to build, and I need this dll to build the app). The jar file – svg-android-1.1.jar – went into the project/Jars folder.
  4. Add the assembly to the project: Right click on references in the Solution panel, and choose “Edit References.” In there, add the .dll under the “.Net Assemblies” tab.
  5. Add the jar file: Add the jar file to your project using add file or add folder (to add the entire Jars folder). Then right click the jar file, and choose “Build Action” -> “AndroidJavaLibrary” to make sure it gets packaged with your application.

That’s it! Those two files are all you need. Now you can create an SVGView class, and use that in your axml layouts. Here’s a quick and dirty example of the class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Android.App;
using Android.Content;
using Android.OS;
using Android.Runtime;
using Android.Util;
using Android.Views;
using Android.Widget;
using Com.Larvalabs.Svgandroid;

namespace unFocus
	public class SVGView : ImageView
		protected string svgSrc;
		public string SVGSrc {
			get {
				return svgSrc;
			set {
				svgSrc = value;
				setupSVG ();

		public SVGView (Context context) :
			base (context)
			Initialize ();

		public SVGView (Context context, IAttributeSet attrs) :
			base (context, attrs)
			Initialize (attrs);

		public SVGView (Context context, IAttributeSet attrs, int defStyle) :
			base (context, attrs, defStyle)
			Initialize (attrs);

		void Initialize ()

		void Initialize (IAttributeSet attrs)
			var a = Context.ObtainStyledAttributes(attrs, Resource.Styleable.SVGView);
			SVGSrc = a.GetString(Resource.Styleable.SVGView_svgSrc);
			a.Recycle ();

		void setupSVG ()
			// svg-android doesn't work in hardware mode, so set software
			SetLayerType (LayerType.Software, null);

			if (null == SVGSrc)
			SVG svg = SVGParser.GetSVGFromAsset (Context.Assets, SVGSrc);
			SetImageDrawable (svg.CreatePictureDrawable ());
			Invalidate ();

And in values/attrs.xml:

<?xml version="1.0" encoding="UTF-8" ?>
     <declare-styleable name="SVGView">
         <attr name="svgSrc" format="string"></attr>

Now you can create SVGViews in axml using:

    android:id="@+id/icon" />

SVG files go in the Assets folder, in whatever tree you want. In this example, they are in Assets/svg/. Build action for svg files is “AndroidAsset,” which should be the default.

There is an irritating gotcha, that’ll have you tearing your hair out if you don’t know about it.

SVG files MUST have width and height attributes on the root element to work with this library. If you don’t have them, and Adobe Illustrator CC doesn’t add them by default, the lib will fail with cryptic error messages. The fix is easy enough, just open the SVG in Xamarin and add width and height attributes. There will already be a viewBox attribute with the correct attributes (viewBox=”0 0 70 70″ <– the second two, width and height). You’ll need to add these: width=”70px” height=”70px”.

Update: One other thing I forgot to mention – this didn’t work on the Xamarin Alpha for some reason. The SVGAndroid binding was failing if I remember correctly (at least that’s where the runtime  errors seemed to originate). So if you are having trouble getting this to work, it might be something in the Alpha channel.

Update 2: What I’ve showed you here will work, but some folks on the Xamarin forums suggest there may be advantages to including third party code in alternative ways (like including an entire project, etc.). Have a read.

Update 3: SVG-Android won’t work under hardware acceleration, which is enabled by default in apps targetting Android 3.0 and newer. You just get a blank space. The easiest way around this is to set the Application, Activity, or the specific view you are working on to use software acceleration.

I modified the SVGView example above to do this automatically, but you can also do it yourself (using the code above) or by setting the android:layerType=”software” on the specific view (or somethings its parent).

This is worth knowing about because other types of drawables (such as animations) seem to display other types of incompatibilities with hardware acceleration (such as fuzzy low resolution renderings), and setting software mode can fix it.


Compiling Mono (and PlayScript) on OSX Mountain Lion (10.8)

Quick update/note: Zynga has pulled the source for PlayScript, and no one has taken it up. Safe to assume it’s a dead project.

A while back, Zynga employees demonstrated a project they are working on called PlayScript, an implementation of AS3 and an ASNext wish-list language they named PlayScript on the Mono Platform. In order to play with it, it’s probably best to compile your own copy, since any binaries they post will quickly get out of date. Wanting to play around with it on my iPhone, I took a stab at compiling the Mono Project on OSX, for use in Xamarin Studio. I used a copy of PlayScript-mono for this post, but these instruction should really apply to any fork of Mono (I think).

The OSX compile instruction page on Mono-Project.com is a bit hard to follow if you are new to this stuff, so I thought I’d write up some more detailed instructions in the hope it would save someone some time.

First, the prerequisites. You’ll need Xcode, and the command line tools. Grab Xcode out of the Mac App Store, and run it. Then go to Preferences under the Xcode menu, then the Downloads Tab/button/icon (organizationally, it’s tab, but it looks like a button with an icon). In there, you should install “Command Line Tools”. This contains some of the stuff you’ll need to build Mono on OSX.

The build instructions on mono-project.com say you’ll need a version of mono installed before you can compile. I had Xamarin and Unity3D installed before I tried to build, and one of them seemed to cover my bases.

There are a couple of prereqs still missing. From various sources, it looks like the make and autoconf tools used to be included with Xcode’s command line package, but they aren’t anymore in OSX 10.8 (Mtn Lion). There are a couple of ways to install them, including building them yourself, but the easiest way I found is to use Brew. Installing Brew is easy enough – copy the ruby command from the brew website, and run it in a terminal.

I always recommend going to the primary source for the correct install method on these kinds of things, so go there, install, and then come back.

Next, use brew to install automake, autoconf, and libtool. You don’t need “sudo” – but don’t worry, brew will complain if you forget. You’ll get a message about libtool being prefixed with a g to avoid conflicts – this didn’t seem to have any unwanted effect for building Mono.

brew install autoconf libtool automake

Note: I had trouble with brew install and libtool on a new mac while writing this post. I didn’t have this problem when I built it on an older iMac. I’m not sure what caused it, but if you get any errors during the brew step (mine was about linking libtool) you can type “brew doctor” in the build directory, and it’ll give you some pointers. My specific problem was that /usr/local/lib wasn’t owned by my user account. The brew suggestion was to “chown” that dir, and rerun the link command for libtool (the step that failed during install), so this was the command I used to fix my brew libtool problem:

sudo chown $USER /usr/local/lib
brew link libtool

There were some other notes about rearranging things in your path for git, etc., but I didn’t bother with any of that.

Now we are ready to compile Mono. The first thing you need to do is download a copy of the Mono source from somewhere. A mainline mono archive or SVN checkout would work, or you could clone a local copy of PlayScript-mono from GitHub, then go inside the folder, which is what I did:

git clone https://github.com/playscript/playscript-mono.git
cd playscript-mono

Now we are up to the configure stage, which is where you will start to run into trouble if you don’t have the proper prerequisites setup. The instructions on mono-project say you can use ./configure from a tar, but I wasn’t able to get that to work from either git or tarball. ./autogen.sh seemed to work from both sources though. Note: the prefix flag is where Mono will be installed when you run “make install” and unless you know what you are doing, you probably don’t want to leave that as the default value. Here’s the bolded warning from mono-project, “It is strongly advised not to install Mono from source in /usr, /usr/local or any other “standard” directories unless you know what you are doing.” I put mine in a directory matching the repo name I’m building from my user directory.

./autogen.sh –prefix=/users/{kevin}/mono-playscript –enable-nls=no
make install

This can take a LONG time!