Kickstarter for game funding

The recent success of Tim Schafer‘s crew to fund their new project through Kickstarter just grabbed my attention, and many others it seems. Tim Schafer, for those that do not know it, is the developer behind the Monkey Island and Grim Fandango games, among others. Myself I am only familiar with the former.

Initially they had a goal of $400 000, and ended up with more than eight times that. This way of funding the development means they are in principle freed from any publisher deciding how the game should be, for better or for worse. I am thinking for the better. I think it allows for a more creativity and taking bigger risks. I wish Tim and his crew the best of luck!

Other interesting projects I came across are The Banner Saga and Wasteland 2. I did not notice the project by Tim Schafer soon enough to participate, but these two have already gotten my money. I am also considering Shadowrun Returns. The former two have a few days left if you want to contribute, Shadowrun ends in 13 days.

Why I am throwing money at these games before development have even started you say? Several reasons. While I do not have much time to spare to actually play these games, I like the development model. If the games turns out good I have gotten some very cheap games. Wasteland 2 and Shadowrun Returns are $15 each for a digital DRM free copy, The Banner Saga only $10. If they turn out bad, I threw my money at some very talented enthusiasts that wanted to develop their dream project. No harm done as far as I am concerned.

Secondly, and at least as important for me, they are all promising a Linux port! For Windows a game with development budget on the order of a few million dollars are medium sized and there are quite a few finished products to choose from. For Linux, this makes the games some of the biggest projects ever to come to the platform as far as I am aware.

While waiting for the games to finish, Trine 2 is up for grabs. I have not tried it yet, but I heard it is pretty good stuff. I have already tried Trine and Braid, both available through Desura. I can recommend both.

Spotify is improving…

Spotify is continuing to improve its usefullness. I recently got the upgrade on my Linux-box which added Spotify apps (yes, I guess I’m about 6 months behind the rest of the world). The Pitchfork app is pretty awesome! Click on the “Best New Albums” sections, it is basically a heaven full of good music recommendations a click away!

Other apps I have added are the Last.FM one, Rolling Stone Recommends and Dagbladet Musikk (for Norwegians).

I have also noticed that they have recognized that they do have quite a few albums registered under the wrong artist. You can easily report anyone you find here.

One major issue I have with it though. After upgrade to Android 4 two weeks ago, it does not work on my phone anymore. Not sure where to complain, Google for how they manage the Android development or Spotify for being lazy (Android 4 is 6 months old already).

c++ precompiler booleans

A short post to show you some of the possible precompiler if booleans you can write. I had to learn how to place several define requirements in one #if statement. Here you go:

#include <iostream>

#define M1

#define M2

using namespace std;

int main()

{

#ifdef M1

      cout << “M1 defined!” << endl;

#endif

#ifdef M2

      cout << “M2 defined!” << endl;

#endif

#ifndef M3

      cout << “M3 not defined!” << endl;

#endif

#ifdef M4

      cout << “M4 defined!” << endl;

#endif

#if defined(M1) && defined(M4)

      cout << “M1 and M4 defined!” << endl;

#endif

#if defined M2 || defined M3

      cout << “M2 or M3 defined!” << endl;

#endif

#if ! defined M3 && ! defined M4

      cout << “neither M3 nor M4 defined!” << endl;

#endif

#if ! defined(M3) && defined M2

      cout << “M3 not defined, M2 defined!” << endl;

#endif

      return 0;

}

This code shows most options I know of. The output is (in case you are too lazy to check..):

M1 defined!

M2 defined!

M3 not defined!

M2 or M3 defined!

neither M3 nor M4 defined!

M3 not defined, M2 defined!

 

git and patches

Sometimes you want to send or receive patches of work done. I found this great tutorial on how you can do that using git, which I will briefly rewrite.

How to create patches using git?

I assume you have cloned the original repository, and created five commits that you want to send back to one of the developers. My favourite way to do that is by

git format-patch HEAD~5

The command will create five separate patch files, which you can attach to an e-mail and send. The ~5 means "the fifth commit before", in other words, the sixth last commit. That would be the last commit that are already in upstream, which you are not interested in. Assuming the work is done on the master branch and the remote repository is called origin, you could also do

git format-patch origin/master

which will do the same, create one patch file per commit since the commit which is already in origin/master.

How to receive patches?

The patches includes a header which contains the commit message, and author information. Normally you want to keep that. The initial thought is probably to use

git apply file.patch

However, this will only apply the changes, not commit them. Instead, one should first use the apply command to check that the patch is OK:

git apply --check file.patch

If you do not receive an error, it means that the patch will apply without failing. The way to apply it then is using

git am --signoff file.patch

This will commit the patch with original author information, and append to the commit message that it was signed off by you. The patches are numbered, starting with 0001. After you have committed all the patches to your own tree, you should make sure that they are in fact correct. If you find problems, you can always use rebase to remove commits again.

git rebase -i HEAD~5

will open an editor where you can select commits that you want to change. You can delete commits simply by deleting the corresponding line.

That’s it, now you can in an efficient and controlled way distribute and receive patches even when the repositories are not stored in a publicly available place!

Bought new mouse

I was in the store yesterday, and came across the Logitech M195 cordless for 15 CHF (about 18 USD). I figured a nice small cheap mouse would be nice to keep in my backpack for when the trackpad does not suffice (e.g. when I want to play games). The mouse comes with a tiny receiver, which can be stored inside the mouse when you do not use it. It is also so small that you can just keep it in your usb port without any worries that it might break or similar. Only issue I have with that is that my Macbook only have two USB ports, so that wont work for me. The mouse seems to track nicely even on fairly blank surfaces, and a piece of paper is more than enough for good precision. I tried it both in OSX and Linux, and it starts working immediately without any need to worry about drivers or other annoyances. Great value!

CERN and kerberos tokens

This is a short blog post probably only useful for people working at CERN.

For Linux boxes we use afs at CERN, with Kerberos as the authentication method. For people with the default SLC installation, this is set up nicely from the get go. For people like me that use another Linux distribution, or perhaps Mac OSX, it is something you have to set up for yourself.

Installing afs and kerberos is usually not a very compilcated task, and I will not go into that here. What I wanted to do, was to recommend on how to use it. The "kinit" command is used to get a kerberos ticket, and then one uses "aklog" to get the afs token (whatever this means, for me it is some security jibberish). Now you can actually add the flag "–afslog" to the kinit command and directly get the afs token as well. You should also add the "-f" flag to get a forwardable token for some reason.

There is a slight annoyance with the kerberos tickets, they are only valid for 25 hours at CERN. What I figured out today however, was that if you add the flag "–renewable" to the kinit command, then you can renew your ticket with "kinit –renew" without getting promted for a password.

Hence, what you should then do is something like this. Add first to your ~/.bashrc (or other rc if you use a different shell):

alias cernconnect="kdestroy && kinit --afslog -f --renewable user@CERN.CH"

Then, in your crontab ("crontab -e" in the terminal to edit), add the following line

@daily ID=afstoken kinit --renew

With this set up, you can just write "cernconnect" in the terminal and then write your password, and your computer will automatically take care of renewing your token every 24 hours. You can also add the flag "–password-file=/path/to/passwordfile" to kinit so that you do not have to write your password, but take care, if someone gets this file they get full access to your account! This should work on both Linux as well as OSX, though I have only tried it on Arch Linux for now.

Get bug tracker for your gitorious repository

First blog in quite a while this. I have recently been playing around with new tools, namely Apache, MySQL, Gitorious and lately Trac. Getting the http server running on my desktop was much easier than I first expected, and there are too many fun tools out there to try out once you have that going. Today I would like to write a tutorial on how you get Trac to work with your gitorious repository. This tutorial will include a setup that makes it possible to write commit messages that are automatically appended to a given bug/feature request, and even make it possible to close the ticket. I assume that you already have a git repository in a folder /path/to/your/git/repo. If it is not a bare repository, the path is /path/to/your/git/repo/.git/. I also assume you have a python 2 install on your machine.

Configuring Trac

First, you need to install Trac. On Arch Linux this is readily available in the package manager, and I suppose that is the case for most other distributions as well (correct, this tutorial is not for the Windows users of you). Further you need to install the GitPlugin from http://trac-hacks.org/wiki/GitPlugin. This can be done with the command

easy_install http://github.com/hvr/trac-git-plugin/tarball/master

This assumes you are using Trac 0.12. Have a look at the link for further information. Now it is time to set up a trac project. The trac project is a folder which will contain the configuration and information for that bug tracker. This folder can be moved around as you feel like (so backup is easy). Set up the environment with

trac-admin /path/to/folder/wher/you/want/trac/project initenv

This will ask you for the project title and what kind of database you want. SQLite is the default option, and a good one in my opinion since you then have all information contained in this folder. Now you open the folder /path/to/folder/wher/you/want/trac/project/conf/trac.ini where you need to add some options under new categories, namely

[components]
tracext.git.* = enabled
tracopt.ticket.commit_updater.committicketreferencemacro = enabled
tracopt.ticket.commit_updater.committicketupdater = enabled

[git]
cached_repository = false
persistent_cache = false

The git category is some specific options for the plugin. The components-category contains the plugins you want activated. This includes the CommitTicketUpdater plugin that is included in the default Trac installation. In the trac category you need to change the following options for the git plugin:

[trac]
repository_dir = /path/to/your/git/repo
repository_type = git
repository_sync_per_request =

Remember that the path to your repository should include the .git folder if it is a normal repository. Finally, for the CommitTicketUpdater plugin you need to add some parameters in the ticket category. This is further explained in the link above.

[ticket]
commit_ticket_update_envelope =
commit_ticket_update_commands.close = fixes
commit_ticket_update_commands.refs = <ALL>
commit_ticket_update_check_perms = false
commit_ticket_update_notify = false

This finalizes the configuration of Trac. Lastly you probably want a way for people to log in. What I chose (and it is probably a weak solution but it works), was to use htpasswd for this purpose. This is explained in the installation wiki for Trac. To add the first user I used

htpasswd -c /path/to/folder/wher/you/want/trac/.htpasswd <user>

and then for successive user accounts I dropped the "-c". You can then start your server with the command

tracd -p 8000 \
--basic-auth="*,/path/to/folder/wher/you/want/trac/.htpasswd,Some Credential" \
/path/to/folder/wher/you/want/trac/project

and open it up the link http://localhost:8000 in your browser. Note that you can have many Trac projects, just add the path to each project separated by space in this command. You probably want to create a small script that contains this command and call it something like "start" so that you do not have to manually write this command every time… Put it in /path/to/folder/wher/you/want/trac/.

Adding a hook to the git repository

Now, in order to get your commits to automatically append to tickets, you need to add what is called a hook to the git repository. This is essentially a program that is ran at a certain point during your interaction with git, for example every time you make a commit (pre-commit or post-commit). For a bare repository you find them in /path/to/git/repo/hooks, and for a normal repository you find them in /path/to/git/repo/.git/hooks/. What you need to do is to get your git repository to execute a command in trac-admin which updates the tickets with the new commit(-s), namely the command

trac-admin /path/to/folder/wher/you/want/trac/project changeset added <repository-name> <commit-hash>

If you just want this to work for yourself locally, it is quite easy. The script named "post-commit" is executed after every commit, and since you can only commit one commit at the time (right?), you can then just get the commit hash from your log. Add this to post-commit:

#!/bin/sh
commit_hash=$(git log --all -1 --pretty="%H")
trac-admin /path/to/folder/wher/you/want/trac/project changeset added changeset added '(default)' $commit_hash

The repository name is ‘(default)’ by default. This is there to support multiple repository functionality (I haven’t gotten that far yet).

For a more practical case you might want a bare repository that several people have push access to, so that every time someone pushes changes to this repository the tracker gets updated. This complicates things, because there are no hooks that are ran once per commit (to my knowlegde), so the script above would only add the last commit sent in a commit stack. Luckily there is help, and the GitPlugin guys wrote two scripts for the purpose which you can find here. There is one script for pushing changes from all branches, and one script for only letting changes to the master branch be appended to the tickets. Add the one you want into post-receive, which is a hook that is ran after each commit stack has been pushed to the repository.

Now you are all set (if I have remembered all the stages). Try to log into your tracker, create a new ticket, and then try to commit (and push if you chose the second option) and see if your changes appear. You can refer to a given ticket in your commit message with #1, like "This is related to bug #1". In the configuration above we set commit_ticket_update_commands.close to "fixes", which means that if we write "This fixes #1" in our commit message, then ticket #1 will be closed automatically. Obligatory screenshot below.

If you find some missing information then please let me know and I’ll try to update the walkthrough.