Crossing Ships

By Alan Abram [12.31.09]


I am currently studying a course in Computer Games Programming at Staffordshire University. I have recently just finished a placement year at Weaseltron Entertainment where I worked primarily on "Jelly Belly: Ballistic Beans" and various other projects. I generally performed well in University and thought that making the change to a 9-5 games industry job would be fairly simple and straight forward. I was wrong.

Crossing Over

When working at university I would generally sit down and work for many hours straight to work on an assignment, and get it to work and then spend a few days fixing up little bugs and minor issues in the game to squeeze out the best mark possible from what I had written. This is a totally different mentality to what was required from me when I was working on the job. The day would start at 9am and end at 5pm and unless there was an impending milestone or anything urgent to be finished, that is where the day would end.

For me this was quite difficult to adjust to as when I worked at university I generally started work around 6pm in the afternoon and worked until the very early hours of the morning, for some reason I seemed to get my best work done during the caffeine laced hours of the day. I suppose another reason for this would be the fact I never had to consult with anyone about the work being done and during the early hours of the day there are very few distractions.

When working for a company this however is not an option, as you always need to consult with various other people in the development team, who would also consult with other people in the team. For example I consulted with the Lead Programmer quite frequently about the best ways of creating classes to integrate with other classes, and how certain things for the game would need to be. He in turn would consult with the Producers and Designers for answers to some of my questions.

This was another thing which was a major difference from working in teams at university. When you work at university in a group, you speak to everyone in the group, you know everyone in the group and you probably are quite close friends with these people and generally nobody is more important that anyone else.

When you work in industry there is a clear hierarchical structure in which everything is coordinated. The programming teams generally work on one side, and the design teams work on another and they are all coordinated via the producer. The producer has a major influence on what happens in the final product and then the Publisher then has the final say on what is to happen in the final product.

If you were working on your own project, and you saw something you wished to change, you would simply change it and see how it goes. In a company you simply cannot just do that. Changing something requires being authorised by the people higher in the chain than you. The people above you are always open to suggestions, and you never know, it might make its way into the final product.


Working in a team on a code base is pretty challenging sometimes. When you work at university it is not very common for people to be working on the same application at once. The application might be passed around a group of people who update small segments of the application and then pass it on. Obviously this isn't a viable option in a business. That's where source control comes in.

The entire project, along with all its assets were stored on a server. Source control software allows everyone in the development team to have access to the latest versions of the code and data whenever they require it, as well as allowing accessing to the history of these files and keeping a safe up-to-date copy of them. Users ‘check out’ the files they need to edit.

 Once finished, these changes are checked  back in to the server, becoming the current version and available to the rest of the development team. This could lead to two people opening and editing the same files and potentially editing the same lines of code., Luckily there are tools to check and resolve code conflicts such as these although they still aren’t perfect, and require you to manually check over the code to ensure its correctness before checking your files back into the server.

Breaking the builds can be very costly for a company, for example if 10 people excluding yourself were working on the project at the time you broke the build, this could potentially stop them all from working on their bits of code. If it takes you an hour to fix the build for everyone then you have cost the company the amount which those programmers would have been paid during that time.

As a someone new to the industry before any of my code was checked into the server, it was "code-reviewed", which basically meant that we would go through the code I had written and make sure everything looked fine and I wasn't doing something totally stupid to make it work.

At first this was quite intimidating, having someone look over everything you had written and then telling you that something needed to be changed, but over the course of my employment I found that the code reviews were very valuable, as whenever something needed to be changed I was always given an explanation as to why it needed to be, and why it was not necessarily wrong but not appropriate for the context in which it was written.

For example, when writing a program for university, you don't care about the amount of memory you application is using, most people have PC's with 1Gb or more worth of RAM, and that pretty much makes it difficult to run out of memory when working on the PC. Generally you don't care about memory fragmentation as that is all handled by your operating system. But when working on multiple platforms which have fixed amounts of RAM and different processing speeds, all these things become major concerns.

 The Jelly Belly: Ballistic Beans game was developed for the Wii, PS2 and the DS, and each had its own set amount of memory which we could use, and as you would expect the amounts of memory varied quite a bit.

A 16 byte memory leak on the Wii or PS2 would not sound like it is a lot and may not get noticed for a very long time, but the DS doesn't have anywhere as near amount of memory and would take a lot less time to make itself known to the user.

Tracking issues like these over a large project could be pretty tedious, keeping lists on your desk and checking each one and crossing them out. This solution may work when you are working by yourself as the only person who will see the list is more than likely yourself and what is on it is down to you to find and close.

We used a bug database to monitor issues and to assign priorities to the issues, allowing us to easily work out what should be done and by whom. For example, a bug which would cause the game to crash would be marked down as a "Class A" bug, meaning it would need to be fixed as soon as possible. Another bug which related to the positioning of a game item or similar would be classed as a "Class C" bug, meaning it had been noted and needed fixing, but it wasn't as important to fix as the class A or B bugs.

One of the cool things with bug databases is the bugs can be assigned to people to fix, for example if there is a bug on the database and two people happen to correct it at the same time, this could become a problem when both people attempt to check in the same fix. One person may have corrected it in a completely different way to the other person which would cause conflicts when trying to submit into the source control system. Assigning bugs to certain people means you can track the workload on people and stop people from correcting the same things as other people.

Returning to University

As I prepare to return to university shortly, the experiences I have gained from the placement will have a direct effect onto my final year university work and how I will go about working on my Final Year Project (FYP) and the assignments given.

The experience which I gained over the course of my placement gave me the knowledge to be able to create "Attack of the Smiley's" on iPhone/iPod Touch from the ground up. In the process I created my own technology base which allows me to use the same base code in another iPhone/iPod Touch which is currently being created. Overall the experience was invaluable.

Thanks to

Return to the web version of this article
Copyright © UBM TechWeb