Friday, 9 March 2012

Write Less Code

I write too much code - I always have. Mathematicians have long understood the value of finding the smallest, most elegant solution to a problem. Unfortunately I think too many of us in my industry get carried away with the action of programming rather than the more difficult problem of truly understanding the problem.

For me, when faced with a new problem, it has always been easier to do some research with the debugger then sit down and start banging away on the keyboard with a rough mental plan of how to proceed. During the hacking phase I will often delete and rewrite code many times as new information comes to light but also as my brain works through the problem.

I don't really have a problem with this way of working in the games industry. The better you get the faster you converge on an acceptable solution. It is very difficult to solve a big problem in one go, I think mainly because it is difficult to understand the problem. Existing code generally makes the problem worse, how much worse depends on how inter-dependent the modules are. More dependencies increase the size of the problem space.

However the key to making this hacking work long term for the team is that there needs to be a culling phase before you submit. This is when you understand the problem, you have a working solution, now boil it down to only the bits that are needed. Ensure you are truly happy with everything you check into the code base. Badly named class? Now is the time to rename it! Big function? Break it up or simply examine if it's needed at all. Massive redundant confusing class hierarchy? Maybe you have bigger problems :)

It can sometimes be hard to see past the implementation you came up with. I don't have much advice for this other than imagine you are explaining your solution to someone else. We have code reviews before every check in at work which are great for this very purpose.

Sorry I don't have any examples to hand which means this post is pretty dry. Something juicer next time!

Thursday, 1 March 2012

Friendly Git

I thought I’d start the blog off with a post about my current version-control-system-du-jour - Git. First off I’m using Windows. This means that dealing with the unfriendly command line tools is only a very occasional annoyance. Don’t get me wrong I'm sure the command line is super fast if you use it every day but when I first started using Git every single time I wanted to do anything would require several trips to the man pages.

I was a huge fan of TortoiseSVN and was over the moon when TortoiseGit was released. So if you want to get started and you’re using Windows then hop on over to and get installing (actually one minor annoyance - before you do that you need to install msysGit

Ok now using Git on one machine is cool and all, and if you are happy to have your repository public then there are plenty of free hosting sites. However none of them fitted my criteria of free, private and fast with an unlimited number of repositories.

Enter Dropbox. You probably know of the cloud storage solution (in fact there are others - SpiderOak looks particuarly interesting) and it is indeed very cool. But when you combine it with Git... way cooler than the sum of the parts. I use it mainly to share my project across multiple computers but you can also share the repository folder with other people.

Git with DropBox

  1. Create a new repository on your local drive (for example AwesomeProject27). Make sure you add at least one file and commit it.
  2. Create a folder in your Dropbox with the same name but extension .git (e.g. AwesomeProject27.git). This is simply following git convention.
  3. Inside that folder right click and create a repository and be sure to click the checkbox ‘Make It Bare (no working directories)’
  4. Go back to the repo on your local drive and right-click and choose Git Sync from the TortoiseGit context menu
  5. You need to setup a new Remote URL so click the Manage button
  6. In the Remote field add ‘origin’ (or some other name you like for the remote depo). In the URL add the full path to the folder you created in step 2 and you’re done, click OK.
  7. Select ‘origin’ in the Remote URL field and now click the Push button at the bottom. This will push your current committed changes to the DropBox folder.
Now you have done this setup you can easily make changes on your local machine, commit them and Push them to the DropBox. So how about working from a different computer? Couldn’t be simpler. Assuming you have TortoiseGit simply right-click the folder you want to hold the repo and choose Git Clone. In the URL field enter the path to AwesomeProject27.git and hit OK. This will pull the whole thing down to the new folder.

Working without Git

You may be collaborating with some people who do not give a damn about version control systems. These guys may be awesome at what they do so hey I’m not going to complain! The best way I found to handle this is create a branch for them. Then when they want a drop of the game update their branch with a working build and send then a copy of the app. You switch back to your branch and carry on working. If they have some new stuff for you switch to their branch, copy their data onto the folder (check it still works of course!) and then commit it. You can then merge their changes into your branch. Make sure you Push their branch to the DropBox just in case your machine dies.

Most of these should be easy but I learned a little trick to export a clean copy of a branch which works from the Git command line. If you allowed msysGit to install its Explorer plugin then you should be able to click your repo and choose Git Bash. If not, run Git Bash from the Start menu and navigate to the repo. Say your branch is called 'simon' use this command.

git archive simon -o ..\
This will create a zip file of the current state of the current branch without any .git meta data. Archive creates an archive (duh) but if you actually want it in the unpacked form you can pipe the output into tar directly.
git archive simon | tar -xC ..\OutDirThatExists