Karl Brightman

Indie Game: The Movie

2012-07-06T00:00:00-07:00

I love watching documenatries. Good documentaries will tell a story in such a beautiful way that it captivates me completely and I can’t do anything but watch and listen. Silhouetted frames of someone in the distance, the post-rock-esque music over the top and the poignant dialogue combine and go straight to my head, no filter, it’s amazing. No other documentary has had such an effect on me, and left me in such a state of awe than that of Indie Game: The Movie.

Indie Game: The Movie was always going to be in my good books. It’s subject matter hits home. I’m a gamer and I love to develop and design. Combine the two and you have yourself the stereotypical indie game developer. How could I not enjoy it?

This movie is nothing short of amazing. Each frame has something interesting, the in-game videos, the hotel bars, chandeliers, crowds of gamers lined up for a convention. They all work. The music by Jim Guthrie is just fantastic and since watching the movie the soundtrack has been on repeat over and over and over again. If you enjoyed the music of Swords & Sworcery then you must get this soundtrack. Your ears will love you.

The real star of the movie though is of course the developers and designers themselves. The movie takes you into the life of an indie game developer. You hear about the way they get up at 5 in the morning and eat left over pizza while checking emails and going over the list of bugs they wrote on an oil-stained piece of paper the week before, the wife that still spends time with her partner but only ever see’s his back as he sits at his work desk and the backlash from so-called ‘fans’ as they become impatient. It all sounds pretty negative until the game launches, and you hear of their success and how it was all worth it, how they can live comfortably(while working on a new game) and pay off their parents mortgage.

The scariest part about this movie was how it made me realise that I could be one of the indie games developers in the movie. I am the type of person that can sit at my desk and can sit in my text editor or photoshop and keep working. As much as the thought of putting hours into something that could potentially turn into a disaster scares me, another part of me finds it exciting and a source of inspiration.

Knowing all this, I won’t be starting a game anytime soon. Yes, it seems exciting. Yes, it’s scary. But the sacrifice you have to make not only affects yourself but the people around you. Indie game developers are mental, and i applaud them. Get this documentary and watch it, immediately.

RequireJS + Mocha + Chai

2012-06-08T00:00:00-07:00

I previously wrote about testing your JavaScript and Asynchronous Module Definition with RequireJS. A recent project idea was a perfect candidate for RequireJS Modules with AMD and decided it would be a good time to tackle testing RequireJS modules using my testing framework of choice, Mocha.

I found some existing examples showing how to accomplish this, the AMD Testing repository from Dave Geddes was a step in the right direction and was the perfect starting point for what i wanted to do. I jumped into my command line and start typing.

Two hours later I had my RequireJS + Mocha + Chai Bootstrap. It’s not perfect and there are plenty of areas I want to improve, most importantly including some sort of build script for the tests themselves, but its a good start.

How it works

If you’re familiar with RequireJS then you shouldn’t have any problem opening up SpecRunner.html and following the trail. For those of you that are not, here is a quick overview on whats happening.

package.json

The start of our testing journey is within our package.json file. All NPM packages contain this file. It holds all the information regarding the project including version, author, name, description, dependencies as well as scripts associated with the project.

I have included a script for running our tests. The command simply opens SpecRunner within your browser. Please note, chances are this will not work on windows, and quite possibly various Linux distributions. h3. SpecRunner.html The spec runner does exactly as its advertised, it runs the specs. The markup is minimal and all the action happens within the single script tag.

<script type="text/javascript" src="src/vendor/require.js" data-main="scripts/SpecRunner.js"></script>

We load our RequireJS library and provide it with a data-main attribute. This tells RequireJS what file to load once RequireJS is ready for use.

SpecRunner.js

The core of the system. This sets up our testing envirionment and starts Mocha.

require.config({
  baseUrl:'src/',
  urlArgs: "v="+(new Date()).getTime()
});

Here we configure RequireJS to use the src folder as our base URL. This means that any references to scripts within RequireJS will be relative to the src folder. Which is convinient considering all our specs and library are held here and the final product is pushed out to our build directory.

The second attribute ‘urlArgs’ is a string that is appended to all script URLs. I’m using this as a cache buster. Let’s say we require ‘lib/person’. Require JS will no interepret this as ‘src/lib/person.js?v=1339120131756’, we can change this file, refresh the page and the version parameter will have changed causing the file to be loaded again and ignoring cache. Simple, but effective.

require(['require', 'vendor/chai', 'vendor/mocha'], function(require,chai){

We require our testing libraries – RequireJS, Chai and Mocha. Once all these libraries have been loaded we set them up.

assert = chai.assert;
should = chai.should();
expect = chai.expect;

Chai is my assertion library of choice as it provides 3 interfaces to use and gives us some flexibility on how we want to write out tests. We provide these 3 interfaces to the user by referencing them before our specs start running. Personally I prefer to use ‘should’ as I think it’s the nicest to read within specs and i’m a sucker for pretty things.

  mocha.setup('bdd');

We setup Mocha to read the BDD spec syntax and use the BDD reporter.

require(['spec/person'], function(person){
  mocha.run();
});

Finally we require our first spec and start the tests once loaded. The requirement here will ultimately become something more akin to ‘spec/base’ or ‘spec/all’ in which all specs will be loading. I plan to include a build script to handle this for you rather than having to manually type these files out into a large array.

spec/person.js

From there its fairly basic testing which should be covered in my previous post. The only difference here is that we need to tell RequireJS to load the files we are testing against.

define(['lib/person'],function(Person){

Personally I think this line fits quite nicely into the way I like to test and allows the user to know where to look for the implementation the tests are running against.

Improvements

There are a lot of areas I want to improve within my boostrap. The most important of which are the build scripts. I plan to provide a build script for users to export a minified,uglified version of their script with the possiblity of using source maps. Paul Irish did an excellent talk at Fluent 2012 explaining source maps as well as a bunch of other cool workflow improvements.

I also plan on providing a test-prepare script that will be run everytime you run ‘npm test’. This script will setup your ‘spec/all.js’ or ‘spec/base.js’ that will allow you to add specs without having to worry to add them to your require call within SpecRunner.js.

Suggestions

If you have any suggestions, complaints then please feel free to contact me via Twitter. Alternatively you could always fork and pull apart my repository on github.

Start Testing Your JavaScript

2012-05-30T00:00:00-07:00

Not interested in a bit of a background and the process behind how to get setup and why you should test? Click here

A Bit Of Background

I’ve done what many, many developers do during early days of a project. Scrapped everything and started over. My recent work on my Terraria JavaScript project was OK, but it was meant to be more of an experiment than anything. A playground of code to ensure what I wanted to do seemed feasible within JavaScript and NodeJS.

With a plan of attack on how to accomplish what I want to accomplish. I decided the best thing to do was to start over. My file was full of comments, code everywhere, horribly written with little to no refactoring. It was a mess. I’m now looking at a clean code base with a folder structure that makes sense and, as stupid as it sounds, a .gitignore file that works!

Another reason for starting over was to start TDDing the project. For those of you that don’t know, TDD stands for Test Driven Development and may drastically change the way you used to work. The idea behind TDD is to write failing automated test cases, write the code to make the test pass, then refactor the code to ‘acceptable standards’. Rinse and repeat.

I’ve always been a big fan of TDD and the work flow it promotes. The only issue I had with it was that I am not a developer at my day-to-day job, but a designer. When I do develop I often don’t have time to TDD unless the project is spanning across more than a month and even then I feel as though I don’t know where to start. What tests do I write? how verbose should they be? I get bogged down in the theory of TDD and not enough time in the tests and code itself.

Getting Started

The introduction of NodeJS and the Node Package Manager has made distributing useful JavaScript packages incredibly easy. There are a wide range of JavaScript test frameworks out there including JSUnit, QUnit, http://en.wikipedia.org/wiki/Jasmine_ and more. I’ve experimented with a couple of them and think I may have founded my JavaScript-testing home within Mocha.

The Mocha homepage gives you a quick rundown of what you can do with it, from asynchronous to synchronous tests, reporters and useful string diffs. What I find interesting is the best practices they provide at the bottom of the page. Incredibly useful if you have never done TDD before and not sure where to start. Place all your tests within the test/ folder and include a command to run these tests within your MakeFile.

Writing tests within Mocha is incredibly simple and when written correctly are easy to read. Below we are writing a test for the indexOf method of Array. We describe what we are testing and what we expect the outcome to be. The Array.indexOf() method should return -1 when not present.

describe('Array', function(){
  describe('#indexOf()', function(){
    it('should return -1 when not present', function(){
      assert.equal([1,2,3].indexOf(4),-1);
    });
  });
});

Now, this is nice enough, but if you are writing a lot of JavaScript then I highly recommend you move over to CoffeeScript. The same test with CoffeeScript looks like this:

describe 'Array', ->
  describe '#indexOf()', ->
    it 'should return -1 when not present', ->
      assert.equal [1,2,3].indexOf(4), -1

The removal of the parentheses and braces make the tests much more readable and nicer to work with. Then again, each to their own.

Mocha and should.js sitting in a tree

Although the two tests above read quite nicely, the line that stands out as a little odd is ‘assert.equal [1,2,3].indexOf(4), -1’. Yes, its JavaScript but there are way to make this a little nicer – should.js from the same guys who made Mocha.

should is an expressive, readable, test framework agnostic, assertion library for node.
It extends the Object prototype with a single non-enumerable getter that allows you to express how that object should behave.
should literally extends node’s assert module, in fact, it is node’s assert module, for example should.equal(str, ‘foo’) will work, just as assert.equal(str, ‘foo’) would, and should.AssertionError is assert.AssertionError, meaning any test framework supporting this constructor will function properly with should.

Including should with our tests is simple, rather than require the file at the top of every testcase file we can simple pass it was a parameter to mocha. The original MakeFile line from the Mocha homepage now becomes something a little more like this:

test:
  ./node_modules/.bin/mocha --reporter spec --require should --compilers coffee:coffee-script

Alternatively you could use a mocha.opts file within your test directory and remove the parameters from your MakeFile line.

-- reporter spec
-- require should
-- compilers coffee:coffee-script

Now you can change your tests to make them a little easier to understand with should.

A small change, but definitely worth it as your test cases get more and more complex and verbose.

All Across The Watchtower

If you’ve been following these some-what steps you should be at a point where you can start testing. Looking back at this article and the content inside of it I realise I may not have actually put across what I wanted to put across. TDD is a huge subject and there is a lot involved. The core of it though, is to test your code.

I’ve put together a small setup that you will help you better understand whats going on and if you really wanted to, you could download the repository and start use within your own projects.

TDD is a fantastic way to keep your mind on track and will help you organise your code. Taking the time out to write the tests first and interface to your code will produce better results.

On Hashbangs and AMD

2012-05-30T00:00:00-07:00

Twitter today put out a post regarding improving performance on their website. Its an interesting read and it’s great to see them taking everything into consideration as well as sharing their thoughts with those intersted.

No more #!

The big highlight and change for Twitter is the fact that the hashbang has left the building. They share a link from Dan Webb about the limitations of hashbangs and say their primary reason for ditching them was to improve the initial page-load performance.

The hashbang meant that the user was hitting a page, downloading the JavaScript then executing that JavaScript to load another page based on the hashbang path. A slow process when you all you want to do is tweet.

Something I found really interesting was how they obtained their findings or how they reduced the ‘time to first tweet’ as they put it. The Navigation Timing API was used on a sample of users. The number of users wasn’t shared, neither were the times taken from that sample, but they were signifcant enough to move Twitter to using CommonJS modules being delivered via AMD. Something I am surprised hadn’t been done sooner.

I wanna be just like the big boys

Now this is all well and good and for someone like Twitter with a web application being driven by JavaScript, its a fantastic solution. But this isn’t something that everyone should jump onto the band wagon for and start thinking it will work for them.

Alex Sexton, the creator of the fantastic asynchronous conditional resource loader YepNope put together a great article on script loaders which I feel ties in perfectly with the poster from the Twitter engineers.

I sure hope AMD doesn’t become a buzzword over the next few weeks. Anyway, wouldn’t that be more of a buzzacronym than anything?

Jekyll + GitHub = <3

2012-05-23T00:00:00-07:00

What started out as a fairly straight forward night of hacking JavaScript and trying to get my binary data parsed turned into a rebuild of this very blog.

The first couple of posts on this blog were using Middleman, a fantastic static site generator that I use for any personal projects. It allows me to use HAML,SASS and CoffeeScript with next to no issues. A simple ‘middleman build’ command and your static site has been generated, smushed images and all.

Middleman worked well, the blog extension allows you to create markdown files and smush them together with an associated view. The only problem you have is deploying these files. Sure, you can get fancy with some Capfile or some hooks with a remote git repository but why waste your time when someone has already fixed this for you? Let’s not the wheel.

Enter Jekyll. Not only Jekyll, but Jekyll + GitHub. Jekyll, a static site generator(I see a trend…) built by none other than Mojombo of GitHub founding fame.

The way Jekyll works is exactly the same as the blog extension found in Middleman. The great thing about using Jekyll though? Deploying to GitHub. GitHub uses Jekyll within their GitHub Pages system, which means it’s available for user pages. This help page has a good run down on how to get setup.

No longer will I have to worry about scp and Middleman, I simply write and push. The way it should be.

All About The Hex

2012-05-17T00:00:00-07:00

Beginnings

So now that I have a blog(of sorts) I figure it is probably best that I actually explain what I am currently working on. Keep in mind that although my initial work isn’t directly a playable game, it does compliment an existing one and something I would like to take on to replicate as a personal challenge.

“It’s Minecraft, but without the boring…”

I was recently convinced to give Terraria a go. I got it gifted up to me via Steam and jumped in ready to experience all these amazing boss battles and dodging lasers that I had been told about.

That didn’t happen. Instead I spent 4-5 hours upgrading pickaxe after pickaxe mining ore and dirt. Wait a minute, isn’t this Minecraft? I thought I had been tricked until I was shown some of the weapon drops and areas that you can explore. Then finally, a boss battle.

I’m not saying this is an amazing game, it’s not something I would recommend to everyone. Much like Minecraft, this game is, well, a game. I have only played it while sitting on Skype talking with a friend. Social games or get out.

The idea

So why on earth would I want to develop something that has any correlation with a game that I am somewhat interesting in? It all started the way most personal projects do. A friend (via Skype) just happened to say “Hey Karl, wouldn’t it be cool if you could see a large overview of where you had been on the map?”. BAM We have the idea and we’re off.

I did a little bit of research to see what had already been developed, there is a lot of people working on mods, even after the developers have stopped work on the game its self. The community is large and passionate. There are a lot of ‘map viewers’ out there but their primary use is to let you see where certain types of ore, chests etc are. This means you no longer need to mine randomly in a hope that you’ll find that precious ore you’ve been looking for. The map viewer does the easy work for you. This takes a lot away from the game and wasn’t what I was looking for. I wanted something that simply showed an overview of the map, where you had been. Basically screen shots from a players perspective placed next to each other until the whole map is visible.

I had my idea, I had some research(including some source code for existing viewers) and knew how I wanted to do it. I wanted to plot the world right into canvas, right into the browser. It seems kinda crazy considering the file size of some of the worlds but I figure it’s a personal project.

This ain’t no vooodoo!

First things first, I had to find out exactly how to get this information. The world files themselves are stored locally in a ‘Worlds’ directory. They use a .wld file extension. It all sounds amazing – easy file structure, file extensions that make sense etc. Then you open up a file, you hope that it will be some JSON type format, you HOPE it’s easy to read. It’s not.

› hexdump -n 64 ~/Development/karlbright-terraria/example.wld
0000000 27 00 00 00 07 42 72 69 6c 79 6e 6e 95 f8 d2 65
0000010 00 00 00 00 80 06 01 00 00 00 00 00 00 4b 00 00
0000020 b0 04 00 00 68 10 00 00 38 08 00 00 fa 00 00 00
0000030 00 00 00 00 00 d0 75 40 00 00 00 00 00 d0 78 40

We’re dealing with binary data. Reverse engineering Terraria and working out order the data we need is definitely the way to go from this point. My options were to use a disassembler/decompiler like .NET Reflector or hope that another developer has already done this work and provided some documentation.

It took a long time and not everyone was all that helpful but the developer of the map viewer titled Terrafirma was nice enough to not only provide the .wld file format, but information on the Terraria Network Protocol and UV Mapping. Interesting read if you’re interested(like me) in that kind of thing.

Now it’s just a case of using this data to read out the values and draw them to canvas. So far I’ve managed to use NodeJS to read out the file and print the world header section and am moving onto the tile section. Once I have everything it comes down to drawing them in canvas in such a way that i don’t break anything.

All about the hex

“Stay awhile and listen”

I have an issue though, a roadblock, something that is stopping me from progressing any further. On this project I am dealing with hex, a lot of hexadecimal. Oddly enough, I’m dealing with hex in another little project.

Diablo 3 has consumed me and is occupying a lot of what would be development time. But that’s OK right? Diablo 3 is a fantastic game and I should play it. I like to call it research.

The future

Once I have slain the beasts of hell and driven back the evil forces from Caldeum and Tristram I will be able to get back to my CoffeeScript(it’s better than JavaScript). I hope to show you some tiles drawn in the near future.

Hello World

2012-05-10T00:00:00-07:00

It looks as though I have a blog of sorts.

I have never been a huge blogger, i always find that I start with the best intentions and end up abandoning it while I get wrapped up in other personal projects, work and everything else.

This blog was thrown together in a couple of hours after realising how useful it can be to document your progress on a project. I was inspired by Liza who has been blogging frequently about her development progress on a game built within Javascript. I suggest you check out some of her posts.

I started brainstorming ideas on a similar project this week and with a coffee in hand and a couch to sit on I was able to expand on it to the point where I could open up my text editor and start coding.

Really must start a blog for my javascript gaming endeavours

It wasn’t until I tweeted the above and got a few positive responses back that I decided to take the plunge and throw something together. The design is simple for a reason. I don’t want to get carried away designing how my blog should look and end up with no content to fill it with. There are no comments, just a white screen and content. I have twitter, if there was anything you want to discuss or comment on, thats where you can find me :)

So watch this space, I will be providing some RSS functionality soon but like I said. I want to get some content in and not focus on the blog its self.