Getting TortoiseHG working on OSX

These are the steps I took to get TortoiseHg working on OSX (Snow Leopard), using pygtk and the hgtk script included with the TortoiseHg installation.

  1. Download TortoiseHg. The Windows exe or msi files won’t work, so you’ll need to follow the links to download from source, or go straight here and get the latest version. Extract it somewhere memorable (I went with /tortoisehg/) and take note of the path to the hgtk script (for me it was /tortoisehg/hgtk)
  2. Make sure X11 and XCode are installed. If you’ve got a developer setup they probably are already, otherwise you can install X11 from the Snow Leopard disk and download XCode from Apple. X11 and the tools included with XCode are used to display the TortoiseHg GUIs. If you have XCode and the in Applications you’re good to go.
  3. Download and install MacPorts. The Snow Leopard package is what I used. MacPorts will let us install pygtk, which is needed to run the TortoiseHg GUIs from Python. It also turns out to be really helpful for installing everything else.
  4. Install pygtk. You’ll need to open up a Terminal window and use MacPorts for this:
    sudo port install py26-gtk
    There’ll be a bunch of dependencies that will download and build, this took a few hours on my Mac Mini, and a whole day on my virtual mac.
  5. At this point, I had issues with Python. This may not be the case for you, but when I typed “python” at the command line it was launching the Apple version of python that couldn’t import pygtk, instead of the MacTools version. Try loading up Python and typing ‘import pygtk’ then pressing ENTER to see if it works. If there’s an error message you may need to change your Python version – I used python_select to do this, which I installed using MacPorts:
    sudo port install python_select
    and then
    python_select –l
    to see what versions you have. Pick the one that’s not Apple with e.g.
    sudo python_select python26
    (note the sudo: you may not have permissions if you try the command without it)
  6. Install mercurial. I’m putting this as step 6 because if you do it before you’ve selected the Python version you can end up installing it to the wrong Python. Just grab the OSX 10.6 version and install it from the website, or I’ve found using MacPorts works just fine too
    sudo port install mercurial
  7. Install iniparse. This is needed to get the settings working properly for tortoisehg. You can use the website link, or MacPorts again
    sudo port install py26-iniparse
  8. /path/to/hgtk should work now, but it will only display a list of options and then quit out. Create a symlink of hgtk in one of your PATH directories (I went with /usr/bin/ but use “env $PATH” at the command line to find one that works for you)
    sudo ln –s /path/to/hgtk /usr/bin/
  9. Find yourself a Mercurial repository, navigate to it in the Terminal and type hgtk commit. If you get some warnings about RANDR just ignore them, it’ll still work. TADA!!! There’s our favourite commit window!

Okay, now just make sure your username is properly set up in both the global and repository settings, and you’re good to go.

Now get back to work Smile

The TortoiseHg Commit screen: A Love Story

This week I spent an inordinate amount of time trying to get TortoiseHg – the Tortoise-branded interface to the Mercurial version system – compiling and running on my Mac Mini so I could finally replace git as my VCS. My next post will be a howto for getting TortoiseHg running on Snow Leopard OSX, but first: a reason.


I’ve tried a lot of Version Control systems in my 8 years as a programmer: none, CVS, SVN, SourceSafe, Vault, Git and Mercurial.  I’ve noticed over time that they’ve gotten less and less…hmm, how do I put this…annoying. Every source control system gets in the way somehow, that’s the trade off: you have to break flow to commit stuff, but if you stuff-up there’s a backup around. And that break of flow has (mostly) gotten less annoying as I’ve moved to new and improved systems. CVS was command-line, SVN had a GUI, Vault has a nice inline diff, Git is…okay, git is command line again. Technically it comes with a GUI but in the same way you’d say that Halo: Reach comes with annoying douchebags online – it’s more of an annoyance than a feature. But the TortoiseHg commit screen is the best thing I’ve ever had for a versioning system, and one that finally fits into my workflow. Sorry other version control commit windows: I have a NEW girlfriend now!

Like the polish on an indie game, it’s small things that add up to make a big difference with the commit screen. The changed files are all shown on one side of the screen, and an inline diff is shown on the other side, making it very quick to see what’s changed when I’m writing comments for the commit. I can easily switch that to ‘hunk selection’ and choose only to commit certain parts of the file that have changed, and then the rest in the next commit. This is GOLD when I feel like I’ve missed a commit and want to make different commits for the separate functionalities I’ve just implemented. There’s easy access to any of the other tools from the menus (repo explorer, push and pull synchronisation etc.), and lots of ways to filter the list of changed files. And then I can right-click on a file and automatically add it to the .hgignore file, see it’s history, copy it, rename it, edit it. I truly love a commit screen that lets me do the little changes I need to get that commit right without having to go back into my project, stop whatever I was in the middle of and make the changes there.

But the most important thing is that the screen stays open. Nothing annoys me more than committing a file or two, but not all of them, and then having to go back through TortoiseSVN’s right-click menu or git’s command line in order to get the commit window back. And to commit, there’s a nice big button but even better a Ctrl+Enter straight after typing a comment will do the commit for me.

Thanks to TortoiseHg, my version control really feels like a part of my workflow now. It’s not perfect (an ability to select more than one file at once is sorely missing), but it’s better than anything I’ve used before.

TortoiseHg commit window, you complete me!

Now get back in the kitchen and make me some pie.

Warming Up

I hung out with Chevy Ray of FlashPunk fame the other night, and he shared with me some programmer wisdom. Which I now share with you: warm up!!


I always make it a point of mine to spend enough time warming up before physical activities. Whether it’s going for a run, dancing, rock-climbing…anything physical. I always make sure to spend the first few minutes doing some light but similar exercises, stretches etc. It literally serves to warm the joints and muscles, because they become more flexible and powerful a few degrees above body temperature, but it also serves to put me into a more self-forgiving mindframe. I suppose it’s because when I warm up it really drives home the point that I’m human, that I’m not perfect, and that it can take me a little while to get into the groove of something so that I can do my best work.


What Chevy pointed out to me was warm-ups can be made for mental activities as well. Some of the best teachers I know get their students into the right frame for class by throwing around some open brainstorming or opinion questions: mentally warming their students up for the subject at hand. And it’s just as useful to put this idea into practice for the dark art of computer programming. And I don’t know about you, but being more aware that I’m human, not perfect, and need to get into the groove of something goes a long way towards helping out that pesky programmers block :)


So today as I start my programming, I’ll be taking Chevy’s advice: start on a few small things, just change some colours around or tweak some variables, write a piece of code you’ve already written before, change some formatting or variable names. Just to warm up. Don’t get buried in changing little things, just get the mind thinking about programming before moving on to what needs to be done today.

C++, Unicode and localisation

I’ve been dealing with some issues with Unicode at the moment, and trawling the internets looking for answers has revealed to me just how many people don’t seem to have a comprehension of what’s really going on in the string classes they’re using. I was one of them.


The first thing you need to read – before going any further – is Joel Spotsky’s blog on this:

The Absolute Minimum Every Software Developer Must Know About Unicode and Character Sets

If you haven’t read that, go there now. Right now. I’m not kidding, stop reading this and go read that. Come back afterwards. Nowait, don’t start reading more Joel Spotsky – come back! Oh, there you are.


Okay, so that was a simplified discussion about the history of text encodings and what it means to most developers. And it ended with “might as well use std::wstring, it’s native”. Well, here’s the kicker: not necessarily.


C++ is fantastic because it’s cross-platform. It can compile for Windows, Unix, OSX, iPhone, Android, DS, Playstation – you name it, if it supports native code there’s probably a C++ compiler for it. Unfortunately, not every C++ compiler treats everything the same. There’s a lot of ‘holes’ in the specification that let the compiler decide what it wants to do with certain data types, how big it wants to make them (e.g. on a 32-bit processor, the int datatype is 32 bits. On a 64-bit processor? You guessed it, 64. There needs to be room for compilers to set the size that works best on the native hardware and operating system. But this leads to issues when you want one piece of code that compiles to all platforms.


On Windows a std::string uses a single byte, which essentially means it can only support the first part of a UTF-8 encoding. On Unix a std::string is 2-bytes, and can happily use a UTF-16 or UCS-2 encoding. On Windows you need to use a std::wstring (wide-string) to have any Unicode-based foreign language support. On Unix, a wide-string uses 4-bytes, which can lead to strings being memory hogs and requiring conversion to and from the strings used natively by the operating system.


There are basically three ways around this:

  • use the time-honoured tradition of selective #defines and macros to compile using std::string for some systems, std::wstring for others etc. The Microsoft header <tchar.h> does something similar (using char or wchar_t arrays instead of STL classes)
  • define your own basic_string<uint16_t> template or similar that always uses the same size for a character. String literals become harder to use then, and need a macro-hack to work properly. C++0x (if it ever gets ratified), will introduce new Unicode support to make this method much easier. Interoperability with other APIs or libraries can easily lead to issues though.
  • go ahead and do what Joel Spotsky says: just use std::wstring and allow it to be UTF-16/UCS-2 on one system and UTF-32 on another. So long as you want your game running on a system and not sending text between systems/servers etc. this should be fine.

Personally I prefer the second option. I use string literals a lot less than I use everything else, and when writing Objective-C I have to prefix my string literals with an @ anyway, so wrapping them in a macro isn’t an issue for me. Plus it makes it easier to move forward with the next version of C++. Until that gets released though, hopefully you now know enough about Unicode to decide how to go about supporting (or not supporting) it in your next project.

The power of TODO

Lately my latest project has been slowing down. I haven’t been getting as much done on it as I was when I first started out. I had a few theories for why that was: partly because I’d spent the last month moving out form my apartment in Sydney, getting rid of all my stuff, living out of a suitcase, moving to Vancouver, and trying to find an apartment in Vancouver; partly because the core gameplay is done – and it’s fun – but now I need to add timers, high scores, menus, particles systems etc. to move it from feeling like a prototype to feeling like an actual game; partly because I’ve had new ideas since this project started and despite writing them down and thinking “I’ll look at them after this project”, there’s a certain latent excitement I have for trying these new ideas as quickly as possible.

But it wasn’t until last night, and a fantastic speech by Shane Neville at the October Vancouver Indie Game Developers Meetup, that I realised what the greatest influence on my work had been: I’d stopped writing TODO lists.


At the beginning of the project, my excitement drove both my passion and my organisation: I wrote code, design documents, sketched concept art and created Milestones. Over the course of the project though, as I hit (or slightly missed) those milestones and completed tasks, I’d been forgetting to create new ones as the scope of the project evolved. Gradually, and subtly, my task list had moved from pen and paper (and Trac and Wiki versions) to being stored in my head. Which is, without a doubt, the worst place to store anything important.


It simply doesn’t work to be keeping track of the important changes in my design in my own head, without anything written down. Thanks to that prompting speech from Shane, and a renewed excitement after meeting all the fantastic people in the Vancouver Indie games scene, my TODO lists have been placed back into their rightful physical form and the work on my project is progressing at a much greater pace as a result.

Conversations in Interaction

A recent blog post got me thinking about the essence of conversation, and how it manifests itself in games and other interactive media. The concept is that a book, or a movie, is a conversation between the writer and/or the director and the audience.


The big difference with interactive media is in the name: interactive. The ability to dynamically respond to the audience allows for a much greater, more in depth conversation to be had. The sad truth is that it rarely is: options are usually limited to the choose-your-own-adventure style of storytelling. To me this is like having a conversation with someone whose response, every single time, is to play a round of “would you rather”. “Would you rather be a sadistic, granny-hating killer or the world’s biggest mommy’s boy?” “Would you rather kill this character who wronged you in some way, or let him live despite the fact he’ll probably come back for you?” Although it’s been said many times before that most games lack a true greyness to their morality options, I can’t help but feel like this is a symptom of a larger problem rather than the problem itself: many games don’t create good conversation.


Conversation, in my experience, has a lot of different aspects to it. When meeting someone new, some of the most fun parts of a conversation are when you discover something in common (“Oh my god, I read that book too, when I was like 10!”). The interactive equivalent for that is finding things that both the player and designer thought of doing in the world, like typing “LHC” in Scribblenauts and spawning your very own Large Hadron Collider (and in fact, pretty much every other random thing you can spawn in that game). But usually we have to ask questions, in order to discover these commonalities. And one of the big differences between feeling involved in a conversation, and feeling like you’re watching someone else talk, is listening.


In my experience, people are willing to talk for longer than I expect when I don’t try to interrupt them. In fact, there’s like a shell: people start answering a question superficially; but when they’re given the time and interest to expand they truly talk about themselves, explaining links and concepts through their personal stories and ideals. Their eyes dart about in reflection of the awesome process of memory, creation and language that takes place in their mind as the conversation truly becomes about them. It truly is amazing to watch. Yet so many games fail to take the time to really let us put this kind of brain power into our interaction.


Game worlds are themselves massive and complex, as anyone who has – like myself – tried to build one knows far too well. The interactive equivalent of asking a player a question and then giving them time to answer is limited by just how creative they can be in the world around them. Every little piece of interactivity that could be possible needs to be manually designed, created, tweaked, tested etc. The way in which a player can be truly creative in their answers can often feel so limited by just how large or complex the team can possibly create the game world. But a game I’ve recently been playing – Minecraft – has me thinking another way. By limiting itself to ‘bad’ graphics and boxy, blocky elements (everything in the game world is a block, and blocks can be transformed into other blocks or special resources through crafting) Minecraft gives players the freedom to use their own imagination to fill in the gaps. It’s a technique which has fostered cult-status in games since the early days of text-based adventures – leaving space in the game world for the imagination to fill – but in Minecraft it’s really the essence of waiting for an in-depth answer to a question: what would you do in this situation?


In Sun Tzu’s Art of War, there’s a particular passage that comes to mind:

8. There are not more than five primary colors (blue, yellow, red, white, and black), yet in combination they produce more hues than can ever been seen.

The same can be said of elements in interactive media: it’s not about how many there are, but how many ways they can be combined that truly creates the space for players to exercise the creativity they each have.