My first Unity game

A few weeks ago, I started a course in game development with Unity3D. So far, it’s been a lot of fun to do something completely different to my day-to-day work. I finished my first project, which is a Arkanoid/Breakout clone. It only has four levels, but that’s fine, I guess. Although I built it by following the course, I went outside the curriculum for the level building. In the course, you create the levels completely by hand. You place each block where you want it, which is quite a lot of work.

As a developer, I want to do tedious stuff like that through code, not manually. So, I created some code that positions the blocks based on a two dimensional array. This allows me to quickly create some layouts. Of course, it’s limited to straight rows, so it is a bit more limited than manual crafting. But for my purposes it’s perfectly fine.

This is the code that loads the layout array and processes it.

using UnityEngine;
using System.Collections;</code>

public class BrickBuilder : MonoBehaviour {
  void Awake () {
    int[,] layout = LevelLayout.GetLevelLayout(Application.loadedLevelName);
    Object prefab;

    for (int y = 0; y &lt; layout.GetLength(0); y++) {
      for (int x = 0; x &lt; layout.GetLength(1); x++) {
        Vector3 position = new Vector3(x +.5f, (y * 0.32f) + 9f, 0);
        if (layout[y, x] == 9) {
          prefab = Resources.Load("Unbreakable");
        } else {
          prefab = Resources.Load(layout[y, x] + " hit");
        }
        if (prefab != null) {
          Instantiate(prefab, position, Quaternion.identity);
        }
      }
    }
  }
}

And this is the code that returns the layout array, plus an example array.

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class LevelLayout : MonoBehaviour {

static private Dictionary<string, int[,]> layouts = new Dictionary<string, int[,]>();

void Awake() {
layouts.Clear ();
int[,] level01 = new int[,] {
{ 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0 },
{ 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1 },
{ 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0 },
{ 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1 },
{ 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0 },
};
layouts.Add ("Level_01", level01);
}

static public int[,] GetLevelLayout(string loadedLevelName) {
if (layouts.ContainsKey(loadedLevelName)) {
return layouts[loadedLevelName];
} else {
return null;
}
}
}

Use the links below to download it.

BlockBreaker (Windows)

BlockBreaker (Mac)

How to test a site hosted in a VM on your mobile device

I’m currently working on a .NET MVC site, while using a Mac. To make this happen, I installed Windows through Boot Camp. At first I would just boot into Windows and work like that, but then I needed access to Sketch files for the designs. So I needed to be running OS X. Since switching back and forth is not a good option, I looked into using my Boot Camp install as a VM. This turned out to be relatively simple and once I got that set up, I was able to work in the VM with Visual Studio, while still being able to access all my Mac programs. Just for fun, I also added a hosts file entry to my Mac, to allow me to access the .NET site in my OS X browsers.

But then came the point where I needed to test the site on mobile devices as well. I came across this blogpost, which described how to do that using Charles Proxy. But being the cheap-ass that I am, I didn’t want to pay money for this functionality. So I turned to Squid, the open source proxy. Installation was simple through Homebrew. Setup was a matter of running the SquidMan app. Because I have other stuff running on the default port of 8080, I changed that to 7777 and then I was ready to go.

On my mobile device, I set the proxy to my Mac’s ip address and the port to 7777. After that, I was able to just connect to the site running in the VM on my Mac.

Controlling a directive in a parent state with Angular UI-Router

A while ago, I ran into the following problem: I had a page with a sidebar that could be toggled on and off, with a sliding transition. At some point, it was needed to add a sibling state to the page that didn’t need the sidebar. However, when I switched states, the sidebar would stay on the screen for the duration of the slide transition. No matter what I tried, I couldn’t get Angular to ignore the transition and it became quite frustrating.

However, after using the power of Stack Overflow, I came across some hints that pointed me in the right direction. I managed to solve my problem by moving the enabled/disabled flag up to the parent state’s resolve block and then injecting the resolved object into the resolve block for each state. Okay, that sounds way more complicated than it actually is. Just take a look at this fiddle:

If you click on “State B” and then back to “State A”, you’ll notice that the block to the left appears and disappears without waiting for the duration of the open/close transition.

Debugging Mocha tests in WebStorm

I’m a recent convert to the WebStorm IDE and for Node development especially, the debugger is a godsent. No longer do I need to add console.log statements to my code to figure out what’s going on, I can just set a breakpoint and go from there. Simply awesome! However, I wasn’t able to do this for Mocha test scripts. I tried these instructions that I found, but that didn’t work for me.

When I came across a post on Stack Overflow asking if Mocha could be used as a Node.JS module, I immediately figured out the solution. Create a Node.js script, include Mocha as a module and start the tests like that. Using the Mocha JS API, this was a simple task.

var Mocha = require('mocha'),
	path = require('path'),
	fs = require('fs');

var mocha = new Mocha({
	reporter: 'dot',
	ui: 'bdd',
	timeout: 999999
});

var testDir = './test/';

fs.readdir(testDir, function (err, files) {
	if (err) {
		console.log(err);
		return;
	}
	files.forEach(function (file) {
		if (path.extname(file) === '.js') {
			console.log('adding test file: %s', file);
			mocha.addFile(testDir + file);
		}
	});

	var runner = mocha.run(function () {
		console.log('finished');
	});

	runner.on('pass', function (test) {
		console.log('... %s passed', test.title);
	});

	runner.on('fail', function (test) {
		console.log('... %s failed', test.title);
	});
});

The only problem is the Mocha timeout setting. When you’re debugging, the timer will continue to run, so by the time you are done debugging, the timeout will have fired. Of course, this can be solved by setting the timeout value to a sufficiently high value for debugging. Running the tests can actually be done more easily by invoking mocha from the command line.

How to use Mocha.js to unit test YUI

We’ve recently started using YUI as the basis for a new version of our product. It’s a very solid library, which provides a lot of high quality code. And although YUI has a nice testing framework as well, we wanted to use Mocha.js, so we could run tests continuously. At first, it was unclear how to integrate YUI into Mocha tests, but in the end the solution was very simple:

var path = require("path"),
    YUI = require("yui3").YUI,
    chai = require("chai"),
    expect = chai.expect;

(function () {
    describe("MyModule", function () {
        var Y, myModule;

        before(function (done) {
            Y = YUI({
                modules: {
                    'mymodule': {
                        fullpath: path.join(__dirname, '../modules/mymodule.js')
                    }
                }
            }).use(['base','mymodule'], function () {
                done();
            });
        });

        beforeEach(function (done) {
            myModule = new Y.MyModule();
            done();
        });

        it('should instantiate the MyModule class', function (done) {
            expect(myModule).to.be.a('object');
            done();
        });

        it('should have a title', function (done) {
            myModule.set('title', 'test');
            expect(myModule.get('title')).to.be.equal('test');
            done();
        });

        it('should have a description', function (done) {
            myModule.set('description', 'test description');
            expect(myModule.get('description')).to.be.equal('test description');
            done();
        });
    });
})();

The trick is to use the ‘before’ method of Mocha.js to create a YUI sandbox and assign that to a variable that is in the larger scope, so it can be accessed in the other classes. To make sure everything has loaded, the ‘before’ method’s ‘done()’ call should be done inside the callback function of YUI’s use method.
And finally, the required YUI modules for custom modules aren’t loaded properly, unless they are mentioned in the use method’s first parameter.

Questions? Ping me on Twitter!

Fronteers 2011 – The videos

All the presentations at Fronteers 2011 have been recorded, and the first presentation (The Future is Native by Aral Balkan) has now been uploaded to vimeo, the other talks will follow soon. View the presentation below:

Aral Balkan | The Future is Native | Fronteers 2011 from Fronteers on Vimeo.

All videos will appear on this page at a later time:
http://vimeo.com/channels/fronteers11#30659519

Fronteers 2011 Day 2 – more thoughts

The second day promised to match the quality and depth of the talks on the first day and it totally fulfilled that promise. Although it started off a bit rocky for me, because I arrived about 20 minutes late for the first presentation, I still managed to get the most important information out of it. So let’s go through the various talks.Read More

Fronteers conference 2011 Day 1 – my thoughts

The past two days, I’ve been at the Fronteers 2011 conference. Fronteers is the Dutch trade union for front end developers and this is the fifth year they’ve organized this conference. Last year was the first time I went to the conference, which was okay. This year’s conference, however, was very much worth the time and money spent.

Read More

Recreating a C64 game

To challenge myself as JavaScript programmer and to learn new things, I’ve decided to try and rebuild a Commodore 64 educational game called “Topography Netherlands”. I couldn’t find a C64 video of it, but this MSX version is basically the same. The idea is that the game gives you a name of a Dutch city and you need to fly there as fast as possible. The goal is to score as many points as you can in a set amount of time. The game was intended to teach younger children the location of Dutch cities. Later versions of the game also offered German and European maps.

As you can tell from the video, the game isn’t that complex. Here’s my shopping list:

  • an animation of a helicopter
  • a map of the Netherlands
  • coordinates of all Dutch cities
  • a clock
  • a scoring system
  • a randomizer to select different cities
  • some form of collision detection to determine if the helicopter is at the required location on the map
  • a way to convert keyboard presses into directional controls

To make things slightly more interesting, I want to use a canvas element. It would probably be easier to use a collection of divs, but where’s the challenge in that, right?

I’ve already found a nice, large map with all Dutch municipalities on it that I can use as a basis for my map and for my coordinates list.

As I’m doing this in my spare time, I’m giving myself one month to finish it. Also, I’m not going to use any library (except for excanvas.js to make it work in IE as well). Reason for this is that I’m not used to work without the safety net of a framework, and I notice that it limits me in being a good JS programmer (basically, I’m too used to the Prototype.js idiom). This will probably mean that I’ll need to look at code optimization at some point.

I’ll start on this next week, after a weekend of relaxing. I hope you (read: someone) will follow my endeavours and maybe learn something from it (as I hope I will).

The problem of massive CSS

In the past few years, I’ve worked on several big websites as part of a front end team. And all those sites have the same problem: a cancerous growth of CSS. The problem starts out small; a designer changes the look of a new component of the site in such a way that existing CSS classes can’t be used, so the developer adds some new classes. However, over the years this process turns a few hundred lines of CSS into a few thousand lines (or even more than a few). And at some point the developer might not even try to reuse CSS code, because it’s easier to add a few more classes than to find the proper classes in all those lines of CSS. And so the problem of massive CSS is born.

So what is the solution for this problem? In my opinion, the solution has multiple layers. Firstly, for a large site a very strictly adhered style guide and component guide is a requirement. It might not be as much fun for the designers, but it is a very good way to maintain cohesion in the designs across a site. Secondly, build the component with reusability in mind. Don’t make them location dependent (i.e. it should be possible to put a component in the main column and in the sidebar without adding new CSS). This is quite difficult, but not impossible. If there is no other way, make sure to document this in your CSS and HTML. However, the hardest part to solving the issue is getting people on board with any new solution. People don’t like change, and there are actually people that thrive in the chaos of massive CSS.

Technically speaking, I think the best solution is Nicole Sullivan‘s Object Oriented CSS approach. Although the link goes to Github, it’s not only a technical solution, it’s a mindset solution (just like OOP). You need to learn to “see” the “objects” in a page that can work with the OOCSS approach. OOCSS also isn’t a silver bullet, you can’t use it for every single part of your website. However, it can work for the interface elements of your site: the elements that keep popping up all over your site. Things like content boxes, a picture with some text or a form field and label. The clue of OOCSS is figuring out a singular way of building a component and then sticking with it. Of course you can extend a component so that it becomes a new component (just as you extend a class in OOP), but you shouldn’t have two components that look similar on the same level in your “OOCSS hierarchy”.