Seeing the light at the end

The last few months I’ve been working on a small game for the iPad, and it’s finally nearing completion. Naively I decided on making a chess game, since the iPad seemed so well suited for that particular purpose. What I didn’t consider was that chess is a very well established game with some pretty obscure and difficult to handle rules, and that there is a long history of computer chess games that all have had years and years of work put into them.

Perhaps not quite the right thing to start with (should have made a fart app) considering I’ve never programmed for a Mac before. The development environment is new, the language is new, the SDK is new, the device is new. Lets make a game!

Despite things taking a bit longer than I had hoped, it is turning out to be quite the nice little product, and I’m pretty proud of having managed to do it all pretty much on my own. It’ll be incredibly sweet to finally see it up in the app store!

More information on the game, screenshots and video and all that hype will soon start appearing on the ohm interactive blog, a site me and a friend started as a kind of software collective for anything that we produce (all indie, all the way). So the game will be called Ohm Chess HD and be mainly featured there.

Also check out our twitter feed for more coming up.

A bit of technical insight into the process of making it: I’ve been using the Cocos2D 2D game development library. I am currently on version 0.99-3, and this will most likely be the version that I release. I have some minor patches and features added to the library that I’ll put up on github soon, and depending on how things go with the game I might put all the sources for it up as well.

In general Cocos2D has been great for starting out on the iPad, though it doesn’t really handle orientation as well as you’d hope on that platform. Integrating with UIKit (the regular iOS widget set, buttons and so on) has been a bit of a pain as well, although that can probably be chalked up to my own inexperience with UIKit itself.

Advertisements

artifex

I used to work in a predominantly Windows-based environment using Visual Studio to write my source code. This is the norm in the games industry, at least here in Sweden. When I moved away from that, I ended up using Emacs as my development environment, and now I have a great dislike for IDEs and huge, cumbersome editor/debugger/compiler suites.

One thing that Visual Studio did bring, however, was a standardised way of managing project builds. I haven’t quite settled on anything like that in Linux. In the beginning I was using plain Makefiles for the most part, glancing at autotools but getting frustrated with the slowness of it and having to update .in-files constantly. Since then I’ve found waf, and that does the job most of the time.

I did develop something of a passion for writing build systems in the process, however.

The first one I brought to a pretty much functional state (meaning that it bootstraps itself) is cake. Written in C++ and lua, it is pretty much something that tries to do what waf does better. I abandoned that a while ago.

Just recently, I wrote artifex. This time, it’s all python, and the purpose is somewhat different: I don’t want or need a tool that replaces the more complicated build systems like waf or autotools. I’m more interested in something lightweight which does things the way I want by default, so I can keep the build files per project as small as possible. There is some work left to be done on this front, but as of right now I can use artifex with tiny build scripts to manage most of my projects where I’m using C or C++.

Here’s a quick example of a build script for a small project:

#!/usr/bin/env python
from artifex import *
@program
def myprogram(self):
    self.source = "main.c util.c"

This will track dependencies for the two source files, automatically rebuild the minimal set of files needed when something changes (using a combination of timestamps and SHA-1 checksums) and compile them into an executable called myprogram. By default, the executable is placed in a folder called bin/ and all temporary files into obj/, but this is easily changed.

A more complicated example is the script I use to build another of my projects:

#!/usr/bin/env python
from artifex import *

@config_h
def breakout(cfg):
    cfg.name = "config.hpp"
    cfg.DEBUG = 1

@program
def breakout(s):
    s.pkgconfig(["freetype2", "gl"])
    s.pkgconfig(tool="sdl-config")
    s.include += ["-Iinclude"]
    s.libs += ["-lGLU", "-lfreeimage"]
    s.source = "src/*.cpp test/breakout.cpp"

This shows off some other features like config.h-generation, globbing in source directives, compiler flags and pkg-config support.