Tutorial: Flexbox dividers with positioned labels over top

Leave a comment Standard

It’s so frustrating to make a horizontal ruler with label text positioned on top of it. There are many different ways to do it but they require a lot of custom CSS that makes it hard for you to easily move the label around to a new position if you need to. I’ve come up with a way to fix that problem using FlexBox and I wanted to share. This JsFiddle will let you select from a few different styles of horizontal rulers, whether it is a full span of fixed width and where the label should be positioned in just a few lines of code. Enjoy!

Highcharts Tutorial: Set Custom Tooltip Date Format

Leave a comment Standard
high charts custom date format in tooltip

I spent a good 4 hours trying to figure out how to get HighCharts to use a custom date in the tooltip without using the custom tooltip formatter. Geesh! Why is it so painful?? Anyways, here is a JSFiddle showing how you can add your own custom formats to HighCharts and then use them in the date formats on the tooltip. In this example I’ve added a %c and then I can use that anywhere in HighCharts that I want to use my custom date formatting.


The Game Plan: Creating A Budget

Leave a comment Standard

Now that you’ve designed a plan for your game and you’ve figured out whether or not you’ll be programming it yourself it’s time to make your budget.

At first you might be thinking, why do I need a budget? I can make a game for free! The answer to this is, yes, you can, however you still need a strategy on how to accomplish it. Consider some of the following things you’ll need to make your game:

  • Domain Name
  • Hosting/Servers
  • Graphics
  • Music
  • 3D Models
  • Level Editors
  • Tooling
  • IDEs
  • Graphic software
  • Music software
  • 3D software
  • Software licenses
  • Better computer
  • Upgraded graphics card
  • Bigger computer monitor
  • External speakers
  • Quality headphones

Sit down and map out all of the expenses you foresee as being necessary to complete your game. To make it easy, you can create a chart with all of the things you’ll need for your game, how many of them, the cost per each and then the total cost. Try something like this table below which budgets out a small game being designed by 3 developers.

Item Amount Cost Per Each Total Cost
Domain Name 1 $25 a year $25 a year
Servers 3 $5 a month $15 a month
Graphics 40 per level (3 levels) $15 each graphic $1,800
Music 15 songs $50 per song $750
3D Models 6 characters $250 per character $15 a month
Sound Forge Licenses 3 $50 $150
WallabyJS 3 $100 $300
Adobe Cloud Licenses 3 $30 a month $90 a month
Unity Plus License 3 $35 a month $105 a month
Mac Book Pro 1 $1,800 $1,800
Google Drive Storage Upgrade 3 $10 a month $30 a month
One Time Costs: $4,800
Monthly Costs: $255
Yearly Cost: $25
 1 Year Total Development Costs: $7,885
5 Year Total Development Costs: $20,225

Take your total costs and figure out your one time costs, monthly expenses, and yearly expenses. Now figure out how much it would cost for a year of development, now factor for five years of development time. You can see how quickly your small game goes from something reasonable to something extremely expensive.

If you can’t afford to spend this amount of money on your game then you need to go back to your concept and re-work it until you get a budget that you can manage, especially if your game will require multiple years of development effort.

If you’re really determined to stick with your original concept and can’t trim anything more out of your budget then you can look for some outside investors. One thing to keep in mind, most investors want to see a working demo or extensive documentation of your game before they’ll even consider opening their pocketbooks. Typically investors will demand more than 50% of whatever profits you make from your game and will want reports on your progress and continuous demos throughout the life cycle of your game until it hits completion and then again after it’s running. Reporting to your investors will cut into your time and your profits so this is just something to consider if you want to go that route.

Jasmine Tutorial: Unit Testing Promises In Angular Services

Leave a comment Standard

So recently I’ve been doing a lot of Angular unit tests with Jasmine and Grunt. I have to say, testing promises is extremely frustrating and most of the examples I found out there either 1) didn’t work or 2) wouldn’t allow you to test content in a then block if you had multiple chained promises, or if you had a promise being called from and returned from another service. After many hours of frustrating trial and errors I found a solution I’m happy with so I want to share.

Let’s assume this is your controller:

'use strict';

angular.module('myModule').controller('myCtrl', ['$scope', 'api',
function ($scope, $api) {

  $scope.data = null;
  $scope.message = null;

  * Load some data from the API service
  * @return boolean
  $scope.loadData = function () {

    var config = {
      method: 'GET',
      url: 'http://api.domain.com/someRESTfulEndpoint',
      headers: {'Content-Type': 'application/json'},
      data: null

    return $api.load(config).then(function (request) {
      if (request) {
        $scope.message = 'Your data was successfully loaded';
        $scope.data = request.response;
        return true;
      } else {
        $scope.message = 'The API service failed';
      return false;

And here is the service making your API calls:

'use strict';

angular.module('myModule').service('api', ['$rootScope', '$http',
  function ($rootScope, $http) {

    * Makes the $http request given the proper configuration options
    * @param Object configruation for the $http request
    * @return Object $http promise that resolves to request payload or error
    this.load = function (options) {
      return $http({
        method: options.method || 'GET',
        url: options.url || 'http://api.domain.com/someDefaultEndpoint',
        headers: options.headers || null,
        data: options.data || null
        function (request) {
          //we got a response back, return just the API payload data
          if (request.status === 200 && request.data) {
            return request.data;
          } else {
            return {
              results: false,
              message: 'API request error',
              response: request

Finally, this is your working unit tests:

'use strict';

describe('testing myModule', function () {


  var $controller, $rootScope, $scope, $api, $httpBackend, $q;

    inject(function (_$controller_, _$rootScope_, api, _$httpBackend_, _$q_) {
      $controller = _$controller_;
      $rootScope = _$rootScope_;
      $httpBackend = _$httpBackend_;
      $q = _$q_;
      $api = api;
      $scope = $rootScope.$new();

      $httpBackend.when('GET').respond('test http GET call');
      $httpBackend.when('POST').respond('test http POST call');

      $controller('myCtrl', {
        $scope: $scope,
        $api: $api

  it('has a $scope.loadData() function', function() {

    var testConfig = {
      method: 'POST',
      url: 'http://api.domain.com/endpoint',
      data: { some: 'data'}

    var fakeData = { data: 'is fake' };

    //we spy on the API service and also return a fake promise call
    spyOn($api, 'load').and.callFake(
      function() {
        var deferred = $q.defer();
        deferred.resolve({result: true, response: fakeData});
        return deferred.promise;

    $scope.loadData(testConfig); //call the function we're testing in the controller
    $scope.$apply(); //we have to call this so Angular will try and resolve the promise
    expect($api.load.calls.count()).toEqual(1); //make sure it's called the api service
    expect($scope.message).toEqual('Your data was successfully loaded');

  it('returns an error if the API fails', function() {

    var testConfig = {
      method: 'POST',
      url: 'http://api.domain.com/endpoint',
      data: { some: 'data'}

    spyOn($api, 'load').and.callFake(
      function() {
        var deferred = $q.defer();
        result: false,
        message: 'api error'
      return deferred.promise;

    expect($scope.message).toEqual('api error');

Continue reading

Tutorial: Black Box Testing

Leave a comment Standard

What Is Testing?

Testing is a way to check if your software is running properly by purposefully trying to find errors so they can be corrected or prevented from happening in the future.

Why Should You Test?

One thing that’s important to understand is that software testing cannot prevent all bugs or errors. Instead, it can identify bugs and errors so they can be corrected. If testing is used in conjunction with software development it can quickly and easily identify when and where new changes to the software have caused issues or problems so they may be corrected. However, since testing uses a specific set of conditions to test with, it will not cover all cases and prevent all bugs — but it can often prevent introducing new bugs  for those specific conditions when new or additional software changes are made.

Downsides of Testing?

This is kind of a glass half full, glass half empty question. While testing is helpful in finding bugs it is also a tedious process and it cannot prevent all bugs from occurring. In addition, good testing conditions are hard to establish especially with highly complex and multi-variable software.

Black Box Testing

Tests the input and outputs of the software and focuses on the software behavior and it’s performance efficiency. In black box testing there is no knowledge of how the internal system works, only that when given an input you get the correct output.

Tester Inputs    -> Software
(internals unknown)
->    Software Outputs

Equivalence Partitioning

Test conditions are divided into groups of functionality that exhibit similar behaviors. Instead of testing the functionality individually, which may take a long time, you can test one section of functionality from the group because the other functionality is likely to exhibit the same behavior given the same conditions.


In the image above you can see an example of equivalence partitioning. Each 9 block square of the Sudoku puzzle is a smaller component of code that behaviors similarly to the others. Therefore if we wrote an equivalence test to pass in a number to one of the boxes on the Sudoku board it would return true/false if a duplicate number was found in that section of the box. This test would work exactly the same way for the other colored partitions, therefore there’s no need to write a test for each of the individual partitions.

Boundary Value Analysis Testing

Often times a problem arises with a piece of software when the input value is at the boundary of the acceptable input values. With boundary value testing you identify the valid and input partitions and then test the high and low values of that boundary.

Let’s go back to our original Sudoku puzzle. In this game we allow the numbers 1-9 in each of the squares. That means numbers below 1 and above 9 are invalid. So we can separate our input partition into three partitions, two invalid and one valid:input-boundary-partitions.jpg

In this case we test the value before and right after the ends of our valid partitions. That means testing 0 and 1 and then 9 and 10.


Another approach to boundary testing is to only test the upper and lower values of the valid partition and the upper and lower boundaries of the invalid partitions. For example, testing to make sure 0, 10 are invalid and 1,9 are valid.


Another way to boundary test is to include one number after the boundary and one number before the boundary, as well as the boundary itself. That would mean testing 0, 1, 2 where 1 is the lower boundary and 8, 9, 10 where 9 is the upper boundary.


Decision Table Testing

This allows you to take a complex rule set and and translate it to it’s corresponding actions. Each rule goes in the top section of the table and each action goes in the bottom. Then you create a grid with different rules selected in the conditions section and the corresponding action that should happen when those conditions are met.

Let’s take our Sudoku for example and make a simple decision table for it.

Conditions Rules
User enters valid number Y Y Y Y N N N N
Duplicate number in that grid section Y Y N N Y Y N N
Grid  has no more empty spaces Y N Y N Y N Y N
Highlight the grid square  X  X  X  X  X  X
Validate the user input X  X X  X  X  X  X  X
Check for duplicate numbers X  X X  X X  X X  X
Show an error X X X X  X  X
Check for a winning game  X

In our decision table we added some of the possible game conditions and then outcomes we expect if those conditions are or are not met. Now we can test our game for each of these conditions and assert that the predicted outcomes have been met successfully.

State Transition Table Testing

This table uses the different states of the software and what they should transition to in order to develop tests. First you start with a state diagram, then you translate that into a state transition table. Let’s continue with our Sudoku example where we have a few major states of the game: drawing the board, validating input, showing an error message, checking to see if the game is won or not, handling a winning game, showing a final score and then clearing the board to start a new game.


To make our state transition table we put our state down one column and user inputs across the top rows. Then we fill in the table according to the input to indicate what states the software can transition to once the input is given. So, when Sudoku validates the user’s input after they enter a number it will either find valid input and check the game status to see if they won, or it will recognize an invalid or duplicate input and show them an error message.

Enter A Number Press Clear Submit Score
Draw Board Validate Input Clear Board
Validate Input Check Game Status
Validate Input Show Error Message
Show Error Message Draw Board
Clear Board Draw Board
Show Score  Draw Board
Check Game Status Draw Board
Check Game Status Game Over
Game Over Show Score

Use Case Testing

This kind of testing approaches the different interactions that an actor will  typically use in order to accomplish their goals when they are using the software. An actor is anyone who will be interacting with the software.


If we refer back to our Sudoku example we have only one actor, the person playing the game. Then we define all of the different goals our user will need to accomplish as it’s own use case. Now we can tailor our tests to ensure that all of these different use cases are present and working in the final version of our software.

Fuzz Testing

With fuzz testing you enter values that are outside of the expected input, as well as longer and shorter than the expected input.

fuzz_testing.jpgSince our Sudoku expects a single integer that means we would perform fuzz testing with non-integer values, as well as empty values and more than the maximum characters expected. In the example below we test floats, strings, characters and values with more than 1 character.

Exploratory Testing

This is a by-product of running other black box testing. As a tester, as you write tests for the software you will, by your own creativity, observation or personal experience, think of other good tests that you want to include during the testing of your software.

For instance, if you’re familiar with Cross Site Scripting  Injections (XSS) and while you’re doing Fuzz testing you realize you can enter more than a single character into the Sudoku input box you may then decide to run additional XSS injection tests to make sure the software cannot be compromised in this way.

Grey Box Testing

This is just like black box testing except the tester does have some knowledge of the internal data structures or algorithms used in the software while they are running their black box tests. The tester may only have knowledge of the data structures or a limited access to the code base while they are performing their black box tests.

Tester Inputs    -> Software
(internals partially known)
->    Software Outputs

Testing In Practice

Generally you find three schools of thought when it comes to testing in a real development situation, each have their own reasons for using or not using tests.

No Testing

Testing is extremely time consuming and if you’re developing software that changes often and in a large way the tests you’ve written may not even be relevant anymore. For this reason in rapid development and prototyping you’re less likely to include any kind of testing.

Some Testing

This school of thought is that it’s good to have tests for your software but they don’t need to be exhaustive. Generally if you’re doing some testing you’ll set a threshold for the amount of testing you must have in order for the testing to be considered “good enough”. This is usually found in legacy software systems or systems that are so large and didn’t have tests before than adding in tests to the existing code base would be an enormous and/or exhaustive effort. These tend to be developers that recognize the benefit of testing however, they also realize that testing will not stop or prevent all bugs from ever happening and the software is changing fast enough that tests need not provide 100% coverage on the code base. Also, some things are much harder or impossible to test so achieving tests for 100% of the software may not be possible.

Test Driven Development

In this practice all tests are written before the code has been developed and the test should describe what the code will do. Generally in test driven development you don’t see a lot of documentation in the code base because the tests are representative of that documentation (or should be). Software created with test driven development tends to have fewer bugs but the amount of time invested on creating and modifying tests as the code base changes is a large part of the development cycle for the software. In addition, there are times when it’s impossible to test a piece of code that’s been written which leaves you to question if the code should be re-designed or the test needs to be re-written causing a lot of circling back during the development process.

The Game Plan: I’m Not a Programmer

Leave a comment Standard

If you’ve been following my Game Plan series then you’ve already put your game idea to paper and have a game design document done along with a set of small, easy to complete tasks to get you started working on a MVP or minimum viable product.

But What If You Can’t Do It?

If you lack the skills to do something during this game design journey then it really boils down to these two options:

  1. You outsource the work to someone who knows how to do it. If you go this route then you have to account for what it would cost to hire a knowledgeable person. Don’t expect that you will be able to find someone to do the work for free as this is often not the case, no matter how awesome your game idea is.
  2. Resign yourself to learning a new skill. You don’t have to be an expert programmer to make a game, just an adequate one. If you’re going to invest time into learning a new skill then don’t dwell on it for too long. Learn enough that you feel confident to complete the task at hand and then move on. Investing too much time in learning a skill will start you down a path further and further from a working game.

Outsourcing The Work

If you’ve decided to outsource the work here are a few things you should consider when hiring someone.

  1. Be prepared to pay — nothing in life is free!
  2. Ask for current examples of their work
  3. Communication is key, make sure you can easily understand each other
  4. Setup a timeline and consequences for BOTH parties not sticking to it
  5. Be available to answer questions and be flexible to suggested adjustements, changes and/or improvements
  6. Put everything in writing and set all expectations up front

Learning It Yourself

If you’ve decided to learn how to do it yourself then find a good resource that you like and understand and dig in until you can complete the task at hand. Try not to go above and beyond the task you’re trying to complete — remember that this will steer you away from delivering a minimum viable product. Here’s some good resources to get you pointed in the right direction:



Music & Sound