Live Fast, Code Hard, Die Young

I am game developer!

Wow, time flies! Time for a little update here…So many months have passed since my last post that it is almost embarrassing!

So what have I been up to then? Well, as I sit here sipping on my drink and enjoying my vacation I think I have finally landed a bit after a quite intense but truly amazing year. You see, last summer I got an offer to take on a new job as a game developer working with the iOS platform. Making games has been a dream since I was a kid and hacked away on demos all night long so I didn’t have to think long before I accepted this challenge.

Challenge? Why call it a challenge? Game development is just playing around all day and having fun isn’t it? No way José, I can tell you it’s not. Game development is one of the most difficult programming tasks you can take on. It requires skills in so many areas, especially if you are a small team, such as mathematics, physics, graphics, optimization etc. It is truly challenging, and that is why I enjoy it so much. My background in demo programming is worth gold here as I have experienced a lot of the same problems in that area (even though things have progressed a lot since back then).

VS.-Racing-2My full time job this past year has been working on a little racing game called Vs. Racing 2. Since this game is for iOS I had to switch to Mac and learn Objective C and OpenGL. In addition I also learned a lot of Python since we use that for some tools and also on our servers running on Google AppEngine.

As you can imagine, for me this was a leap into the technological unknown after having worked with Windows and .NET for more or less twelve years straight. But it has been very rewarding and fun to learn all this new stuff and I don’t regret it one bit!

In my future post I will try to share the things I have learned such as the differences between C# and Objective C so stay tuned…

Yesterday Github released their long awaited git client for Windows and of course – it is quite awesome. But that is not why I am writing this blog post.

I felt that the time has come for me to reveal a little more about the side project I have been working on for the past ten months. You have probably guessed it by now… Yes, I have been working on a Git client for Windows and it is called Gitly.

Now, why the heck do I want to write my own Git client? Especially now when Github is finally sprinkling their fairy dust on the Windows platform? Well, the plans for writing my own client started over a year ago and my primary motivation was that I believed I could do something better than the mixture of tools that was available back then. So in August 2011 I started hacking away on what I believed would be a project I could complete in a few months. Hmm, didn’t turn out that way. Instead it was a pretty rocky road I had to overcome before I finally had the basic things working. However, I learned a great deal about Git on the way and I still think I can make something that people will find useful.

First release

Today I have released the first version of Gitly to a number of private testers. The application is far from finished and I can’t promise when it will be ready, but I’m quite happy I’ve reached a point where it is actually usable. I’m pretty convinced I will keep working on it as a hobby for the better part of this summer and release new versions frequently.

So I guess you all want to see a screenshot. Remember this is an early version and things are likely to change a lot in the future. Nevertheless here it is:

Gitly - Git for Windows

The main purpose of Gitly is to provide an easy way to introduce Git in your organization where people may be used to traditional version control systems and don’t want to learn to use Git command line stuff. That means you need a user friendly and easily accessible UI, integration with Visual Studio and simple intuitive workflows. All provided in a single easy installation. That is what I aim to provide with Gitly.

I feel strongly about Git and I want to give developers a good alternative to TFS and SVN. I’m hoping that Gitly will provide that. What do you think?


Just recently the demo group Farbrausch decided to release their demo tools source code on GitHub. A few days later we saw the release of the original Prince of Persia source code on GitHub. These two events inspired me to go seek my own roots and look for some of the stuff from my demo scene past. I made a few demos and intros both for Amiga and PC during the 90s and I thought, what the heck, maybe it could be fun to put it up!

So I took some time to dig out an old intro that I actually had kept the source code for and I’m posting it on GitHub if anyone is interested. It is a 64K intro that came 3rd place at Icing in 1995. I got it running in Dosbox and made a video of it below if you want to check it out.

Now remember that this was made back in ’95. There were no 3d cards, no DirectX, no Mp3 audio etc. All you see was coded in x86 assembler, ran on a 486DX4 and it all fits in a 64K file.

Now go check out the source code:


Rake tutorial

Rake is a great tool for creating build scripts even if you primarily develop on Windows and normally don’t use Ruby. In my last article I showed you how easy it is to set it up and get started. This time I am going to show you some more examples of how it can be used.

One thing I really like about Rake build scripts is that you can divide the work into many small tasks that can be developed and tested individually. When you got them all working it is just a matter of chaining them together using the Rake dependency mechanism and you’re done. This speeds up the development of build scripts quite a lot in my opinion.


So how do we setup dependencies between tasks in Rake? Well, it’s very easy. The Ruby language makes the syntax pretty sleek as well:

task :deploy do
  puts "Deploying..."

task :default => :deploy do
  puts "Done!"

In this example I have two tasks called deploy and default. The default task is dependent on deploy, which means that Rake will run the deploy task first and if it is successful it will continue with the default task. Pretty simple really.

You can also create empty tasks that simply depend on others. If you have more than one dependency just surround the tasks in brackets:

task :release => [:newversion, :deploy, :package]

By default Rake will run the default task. If you want Rake to run the release task instead you can do that:

C:\>rake release

Internal and public tasks

Once I started filling my build script with different tasks I ran into the situation where I wanted some tasks to be considered “internal”. I wanted to run them on my own for testing purposes, but they were not meant to be run by others. Instead I wanted to expose some sort of public API of tasks to be run from the command line to guide the user of what was possible. Rake has a way of handling this by decorating tasks with the special keyword “desc”. If you put a “desc” statement before the task it becomes the public documentation for that task, which to me is a great way of exposing it as part of a public API. This is how you do it:

desc "Perform a deploy and package a release version"
task :release => [:newversion, :deploy, :package]

To view a list of documented tasks you simply run Rake with the -T parameter. Here is an example of how this looks in one of my projects:

An example of output from Rake

This gives a nice list of all the commands available to a user that is new to my project. I like this a lot. 🙂

If you want a little bit more involved example you can take a look at the rakefile that I use for one of my projects. You can find it on GitHub.

Next time I will show you how to use Rake to build .NET projects. Stay tuned!

Last year I started using Rake for my .NET build scripts and it has been a quite pleasant experience that I wanted to share with you. “Hmmm, isn’t Rake one of those scary Ruby tools from the other side of the fence?” you might ask. Yes, indeed, it is a Ruby tool! Many good things have come from the Ruby community but sadly many .NET developers seem to be scared of even learning about them. “Yuck, strange Ruby stuff from the Linux world! I can’t use my .NET knowledge and that must be a bad thing, doesn’t it?” Well, that’s a shame! Rake can be used on Windows! And besides, I think it never hurts to at least dip a toe in the ocean once in a while and experience something different than the usual stuff you work with. When a tool helps you to accomplish things with simple elegancy it couldn’t hurt to try it.

So what is Rake?

Rake is a tool for creating build scripts. It is a modern variant of the good old Make tool where you describe different tasks and the dependencies between them. Each task is a series of Ruby statements to be executed when the task runs. The flexible nature of the Ruby language makes the task descriptions very brief and elegant.

Here is an example of a task called “deploy” that copies files:

task :deploy do
    src_path = File.join(BASE_PATH, "Output/bin/.")
    dest_path = File.join(BASE_PATH, "Deploy")
    puts "Deploying files..."
    FileUtils.cp_r src_path, dest_path

Why use Rake?

Okay, now we know a little about what Rake is, but you may still ask why do we need build scripts at all? Can’t we do everything with Visual Studio and some pre/post build commands?

Sure, we can do quite well with just Visual Studio for small projects. But in larger and more complex projects we often run into situations that require some form of automation and we don’t want to do them every time we build with VS. We need scripts to do various stuff such as deployment and packaging. Maybe we need to update some files with version info, compile an installation kit, upload it via ftp to a server and so on. I’m sure you can come up with a range of time consuming stuff you do on a regular basis that could be done more quickly and reliably by a script instead. The more you can automate the tedious repetitive tasks the more time you can spend doing things that really matter to the customer.

So why not use a simple bat file to run some commands? Yes, that’s one solution but bat files have some significant problems. One is that the error handling is quite cumbersome, you have to use goto statements for flow control and you cannot easily reuse functionality across different bat files. In my experience, as soon as the complexity of the build script rises it will quickly blow up in your face and become a maintenance nightmare. Another glaring omission is the ability to express dependencies between tasks. That is one pretty important thing for structuring a build script successfully that bat files lack.

But what about MSBuild? Wasn’t it created for this purpose exactly? Yes, I have used MSBuild (and before that NAnt) and it sort of works, but it feels very limited. Both MSBuild and NAnt are XML based and declarative. For me, declarative programming is not very intuitive (XSLT anyone?). I feel that I have to think harder before I get things right, instead of just describing what to do in the order I would do it when performing the task manually. With MSBuild I get these set of predefined tasks that I can use, but if they don’t do exactly what I want I’m out in the cold. To me, it feels much more powerful and flexible to write code to do what I want in a build task, and easier to understand and maintain too. Maybe it’s a matter of taste so ultimately you’ll have to decide for yourself…

Getting started

Many people are scared because they think it is difficult to setup Ruby and Rake on Windows. This is not the case. To get started you simply run the Ruby Installer that you can download here:

After installing Ruby, hit the Windows key and type “Ruby”. Then click “Start Command Prompt with Ruby” in the list that appears. This will bring up a command window where you can use Ruby commands.

To install stuff in Ruby you use “gem”. To install Rake simply type:

C:\>gem install rake

Now you are good to go!

Your first script

By default Rake will look for a file called “rakefile.rb” so create a text file with that name and write your first build task like this:

task :default do
    puts "Wonderful world!"

Then launch this script like this:

Wonderful world!

Pretty simple, wasn’t it?

In a future post I will show some more examples of what the build scripts may look like, so stay tuned!

Windows 8 is here!

Feeling pretty excited after watching the keynote announcing Windows 8 today!

First and foremost it erases all doubts people have had about Silverlight/XAML going away. It’s not going away but instead it is becoming a primary and native technology for developing Windows apps. Another cool thing is that XAML is no longer restricted to .NET but it can also be used from C++ if you need to squeeze out that extra performance in your app. In addition to this you can also write apps using HTML5 and Javascript to run natively on Windows using the same new WinRT APIs. This is great because all those different technologies are good in different situations. To be able to choose the one you like is excellent. To me, it’s like Christmas!

Not only is this a great platform to build stuff for, but it also feels great that you can use the awesome tools Visual Studio and Blend to do it!

All in all, I just wanted to make a quick post about this because it’s such great news. Windows 8 has a lot of new cool features that I recommend you check out.

The preview version of Windows 8 will be available later tonight from so make sure you try it out!

I’m happy to announce the first public release of Deployer – a deployment tool that we have been using in house for the past six years (and still continue to use today) to successfully handle updates for several large web sites and applications. It is written in C# using traditional WinForms and .NET 2.0 so it should run on most Windows systems (including Windows XP).

We are releasing this tool for free (and as open source) and hope you will find it useful too. Even though the tool was primarily developed to fit our needs it is pretty flexible and can be used in various situations. For instance, it does not have to be used to deploy a .NET project but can be used on any set of files where you need a little bit of control over what to copy and what not.

Now go ahead and download the tool or check out the source if you are more into that.

First look

So, still curious for more information? Well, let’s take a quick look at the main GUI of the application:


Deployer is similar to the Windows Explorer and shows the folder structure to the left starting from the root folder of your deployment project. The files in the selected folder are shown in the panel to the right. Files in red have been changed since the last deployment and need to be deployed again. This can be done by selecting them, right clicking and selecting “Add file(s) to queue” and then pushing the Deploy button.

A faster way to deploy files is to simply click the button in the toolbar that states “Queue files modified since last deployment” and then press the “Deploy queue” button next to it. This gives you a pretty quick workflow without having to remember what you have changed. Of course, you need to deploy at least once before you can do this.


So what are the key features of the Deployer then? I would say the flexible deployment rules and the plugin system.

The Deployer determines the deployment method to use based on filters. This means that you can deploy different files using different methods and to different targets using configurable rules. Some files can be sent to one FTP site while others a sent to a completely different server. You can also rename files and folders so that it fits the destination structure.

Out of the box the Deployer has support for deploying files via FTP or to a network file share. However, it is extensible via plugins so you can add your own transfer protocols quite easily if you want. For example, at work we have developed plugins to deploy custom objects via a web service directly into a CMS system.

There is also plugin support for “hooks” which can be used to hook into the deployment procedure to provide special services. We are currently using this to stop and restart a Windows service on a remote server when you need to deploy a new version of it.

Multiple configurations are supported so you can have one for deploying to a test server, one for staging and another for live.

Unfortunately right now some features such as multiple configurations and deployment hooks can not be enabled from the GUI but require some manual tweaking of the project file. Usually this is pretty easy to accomplish since it’s just plain XML and quite easy to understand. Hopefully I’ll be able to implement support for configuring all of this from the GUI in the future.


Back in 2004 when I started developing Deployer we needed a tool for uploading files via FTP. Using a traditional FTP client was painful, since you had to go through each folder of a site and pick out the files to upload. We also had to deploy some custom objects to a CMS system by hand which was quite cumbersome… Clearly we needed something better. So, I developed a first version of the tool that used file filters to determine which files to deploy and where to deploy them and the ball started spinning. Soon we needed more features and I continued to work on the code and added things such as comparing database changes, deploying to multiple targets, specifying filter rules in subfolders, having several configurations and so on. This little tool grew into something that we found quite useful at our company. I’m hoping that by releasing it to the community it may help you too.

Download & source

You can download the setup from Github:

If you want to peek at the code and maybe even contribute you can find it here: