Friday, 11 May 2012

Channel API

Google App Engine is a web hosting service that allows you to write server software in Java, Python or Go. Overall I think it's a great piece of technology that really helps the programmer get into the mind set of writing scalable services, it was also a cool way for me to finally learn Python. Anyway I'm currently interested in the suitability of it for realtime applications like games.

The traditional web model is a request/response based model. The client requests a resource from the server, the server does some processing and returns the resource. That's the end of the transaction. In this model there is no way for the server to update the client without first receiving a request from that client. If you want to build a multiplayer game then this is likely to be very important.

It can be simulated either by regular polling from the client (does not scale well), by some fairly hacky techniques falling under the umbrella of Comet, or by the new WebSockets technology available recently. Google App Engine does not support WebSockets, but it does support Comet under the guise of the Channel API.

Test App here!

I was interested in the performance of the Channel API so I wrote a small test app. I'm a bit of a noob when it comes to Python and HTML/Javascript but if you want to take a look I uploaded my code here.

Overall I was disappointed with the results, and indicates to me that if you want any kind of fast response game then you may have to look elsewhere.
  • Very unpredictable latency (200-1000ms)
  • Big packet overhead of HTTP headers etc
  • No peer to peer support at all (limitation of current web technologies)
  • No support for broadcast messages (server must send to each client in separate call)
  • Sending several messages at once can result in a massive increase in latency

That said I do think the technology is quite promising and certainly opens up the possibility of doing whole classes of games with two way communication. Strategy games, or other games where one player does not directly affect another. Adding chat for instance is a perfect use case for this. If you are thinking about using Channel then I found out a few things that might be useful to you.
  • Reliable - in all my tests all messages eventually arrived
  • Out of order - messages are not guaranteed to be in sequence so if this is important you need to handle your own sequence checks
  • Multiple instances - don't forget the service may spin up multiple instances to handle the requests
  • Development server is much worse than the live server (on Windows at least)! It seems to serialize all messages sent with approximately 600ms between each one.
If anyone has any insights into the poor performance (maybe the server setup is wrong for instance) I would love to hear from you. If anyone from other parts of the world could test and report back your average latency that would be awesome!

Cross posted to AltDevBlogADay which has some great comments.

TortoiseGit and Google Code

As a Windows user I recently struggled to figure out how to make TortoiseGit push my local code to a remote Google Code repository. Google Code gave me a password to use but the client never asked me for it. If you are having the same problem here's how to fix it!

The short answer is to add the password Google gives you to the URL using something like this https://name:password@path_to_repo/

Create your project on Google Code or find the Git hosted project you want to commit to. Go to the Source tab and grab the clone URL (you have to be signed in to get this). Navigate to your local folder you want to hold the repository and clone it through TortoiseGit the normal way.

Once you have cloned it navigate to the directory, right-click and choose TortoiseGit -> Settings
Select Git on the left hand side.
Select Edit local .git/config

This opens up a config file. Look for the URL line that looks something like this

url =

Get your GoogleCode password from here and paste it in so the line looks something like

url =

If all goes well when you Push you should see something like this!

Wednesday, 11 April 2012

Leaving Canada

This is the second time in two years that my wife and I have sold up and moved our lives to another continent. First we moved from the UK to Canada where I got a job with Relic. I worked on, and shipped Space Marine   then moved on to an unannounced title. Along the way I made some good friends, did a copious amount of snowboarding, we had a wonderful baby boy, saw a bear, and many more amazing things too numerous to mention.

It was sad for me to quit my job and move back to the UK. I will miss the great city of Vancouver and the beauty of British Columbia that it sits in, but I'm not going to dwell on these things.

Along the way I absorbed some of the wonderful positive feelings and attitude that seems to be prevalent in Canada. A great attitude to have which sometimes seemed very alien to a cynical Brit! We eventually had to move back to the UK for family reasons, but I know that the 2 years I spent in Canada has given me the confidence to take a risk and follow through with something I truly believe in. So stay tuned for some exciting news!

Footnote: Sorry to hear about the layoffs at Relic recently. In a city with such a thriving games industry I know people will be fine and I'm excited to see the new studios that are going to pop up to take on this rapidly changing marketplace!

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