The falling of Hawking’s Coulton Conway domino of life

By | Games, Random Thoughts, Thing a week, Uncategorized | No Comments

So I had an idea. It’s not an original idea and by the title you can extrapolate where I get my inspiration.

I often feel like I’m the opposite of Jonathan Coulton (if you click this link sign up for his
newsletter he’s an awesome guy!). In his song Code Monkey he talks about a programmer that’s fed up with his career but he can’t leave because he’s in love with a pretty girl. This song is a reflection of his life as a coder that decides to drop everything and go become a musician. My situation is exactly the opposite. I was a professional musician for 10 years and shifted gears to my other love: programming. Ok, that may be an over simplification but at it’s core that’s kinda how things went. While I didn’t completely drop being a musician, coding did take over as how I spend a predominant amount of my time.

To my point! Coulton went through a period where he had something he called “A thing a week” where he wrote a song a week. It was somewhat of an experiment to try and coax some musical creativity out of himself.  Which brings me to my own personal experiment. I’m going to be taking on a small personal project every week. With the goal of exploring different programming paradigms and ideas. At the start I want to set some rules.

#1 The project must be simple enough that it can be completed in one week
#2  If that project is not completed I’ll drop it and move on to the next thing
#3 Each Project will be defined on Monday
#4 All source code will be available on Github and regular updates/thoughts will be posted here

Onward to project 1’s definition and the genesis of that idea.

A week or two ago I was fumbling through my Netflix queue. Coupled with a recent binge on The Big Bang Theory and a general interest in all things science I discovered a show that Stephen Hawking narrates. I think it’s called Into The Universe or something. In the first episode they explore what the meaning of life is. Really fascinating stuff! In the show they talk about a “game” it’s called Conway’s Game of Life. This isn’t new to the world of computer science but it is something I’ve become really interesting in building.

The rules are simple: (From Wikipedia)

Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

I’ve recently gotten really into build automation and testing. For this project I’ll be using Javascript.  I plan to use Grunt for build and test automation. And Jasmine as my testing framework. I want to give the user the ability to set up starting patterns and a start, stop, and reset button to control the game.

A I said before this isn’t new ground I’m breaking. I’m sure there are plenty of other implementations of the game of life floating around out there but as a start to a personal journey I think it’s a fun place to begin!

I’ll post updates as the week progresses. It’s going to be a busy week on the road for me and I’ve got a lot of other things going on with work and other personal projects to this will be a real challenge!

RagNoK: Post-mortem

By | Games | No Comments


     RagNoK was a game I worked on in a prototyping class last quarter. I knew from the start I wanted to work on a game using Unity as our primary engine. After using UDK for several projects in the past and seeing the challenges it offered I wanted to try something new and having studied Unity on my own for a few weeks I had an idea of the benefits Unity could bring to our student project.

What went right:


Bringing assets into Unity was incredibly easy and it made prototyping things quickly a piece of cake. The modular way in which game objects are put together made it really easy to swap placeholder art in and update existing models with textures or fixes as they were available.


The scripting environment in Unity made it possible to create almost anything we could dream up in a short amount of time. I also appreciate the ability to rapidly test code as opposed to something like UDK where it feels like you have to jump through a ton of hoops to get the engine to recognize your scripts and then you have to wait for everything to compile to see if it works. The drag-and-drop plug-and-play nature of Unity makes coding what it should be: a joy.


In the end my team ended up with a complete project that can be built out to play on the web. This is an awesome thing for a student project becasue it allows us to show our game to anyone with a web browser.

What went wrong:

Unfamiliar technology:

One of the hurdles we slowly overcame was everyone on the team being unfamiliar with Unity. Luckily the way the project ran the artists were able to simply work in their prefered 3d package but a lot of models needed to be rotated or resized due to the teams inexpereience with Unity. This ended up creating a bottleneck in the amount of time it would take to get assets into the engine.

Another issue we ran into was in the optimization department. By the end of this project I learned a lot about how things worked in Unity but didn’t realize how many places our game could have been better optimized. As with any new technology I feel like these are the kinds of lessons you get from the experience of seeing a project to it’s completion.

Time Constraints:

I’m sure this happens all the time but due to the amount of time we had to work on the game we had to cut a lot of our ideas. A big example of something that ended up on the cutting room floor was multiplayer. We also could have done more with our GUI and sound.

In the end the learning experience and the creation of a working game makes me proud to have been a part of this project.