 Well, as this is the first article, I guess its time for an introduction. My name is Phil Carlisle, I am currently a games programmer at Team17 (makers of Worms among other titles). Presently working on 3d effects for a new T17 game. I cant promise to update regularly, but I'll try and do my best.. Of course I wont be able to answer all emails about this stuff, but if you want to try and contact me, my email is phil.carlisle@team17.com (please note, I hope people can be sensible about questions and emails, dont expect a reply straight away, and if its a stupid question, dont expect a reply at all). Through the new articles I am going to try and cover things that aren't really catered for in other articles. Some of this will be my own experience, some will be from what I've learned from others or research, but hopefully it will all be informative (or at least readable). Through the next few weeks/months/years I'll try and cover things like: There's also going to be the usual rants and raves (most likely rants i guess, I'm known for it :)) So lets get on with it.. Team Working - The ups and downs of working in a team. One of the biggest issues of modern games, is the size of the development teams needed to produce the technology that is required (this isnt strictly the case, but it happens more often than not). The size of development teams brings with it a whole set of problems, in this article we will look at a few of those problems and look at solutions to them. The first problem is recruitment, I dont want to cover this in any detail here, but recruitment is possibly THE biggest hurdle to overcome, after all, a project is only the sum of the talent of the people producing it. So assuming you have a team to produce the game, what other issues do you need to cover? The next important issue is design. It is wise to include in the technical part of the design, information on coding conventions. These are important to a multi-programmer project, because it can be incredibly difficult to read anothers code when you are both using completely different scheme's for things such as variable naming, data type definitions etc. If you do any substantial sort of team code, you need tools to enable the easy maintenance and inclusion of new code into the codebase. I have seen times where perhaps 1/5 of a programmers efforts are taken by hand modifying someone else's code so that it fits in with the overall project. Often sub projects need to be split off from the main codebase so that individual elements can be worked on without slowing the project as a whole. Its as this point we introduce an element into the mix that SOME of you might not have come across before. A Code Versioning System (or CVS), basically, this is a piece of software (there are a few out there, and I will describe one in action in a second) that allows multiple programmers to work from a single codebase by ONLY working on files they need. Generally these systems involve having read only access to source files, only have write access to files they are currently editing. One such system is sourcesafe (a microsoft product). Sourcesafe basically allows multiple programmers to "check out" files from a sourcesafe maintained database. Once modified, these files are then "checked in", which does a comparison with previous files, stores the changes, compresses the changes, and marks the version. The advantages of this type of system are numerous, not only does it provide a good backup for your source, it also allows you to see changes that were made throughout its history. Imagine a scenario where you change a fairly substantial part of your code, but the changes arent really working, you look for an earlier backup before the changes, but it hasnt got the old code in yet!. With sourcesafe this just doesnt happen. Also with sourcesafe you are able to review changes OTHER people have made, and it allows you to review multiple changes, so you can choose which version to use. I dont want this to seem like an advert, there are quite a few similar tools out there, I am just advocating a similar system for ANY multi-programmer project. The final part of team working I would like to cover is communication. This seems to be one of the biggest problems for teams (other than clash of personality, or lack of skill). Communication is essential to keep the project moving. Nobody wants to feel like they are carrying a project, so its vital that ALL team members meet regularly, and update the others on progress made. It is also a good idea that each team member actually produces something for the others. This helps foster the idea that each team member is contributing. One of the biggest problems for many "virtual" teams, is that thier communication isnt regular enough, and when it is regular, its allowed to lose focus. I would advocate a regular meeting, at a regular time. People should commit to this meeting, generally, if they are unable to commit, they will not be able to commit to any part of the project fully. At each meeting, set an attainable goal for each member, make it known that EVERY member is expected to produce SOMETHING (whatever it is that commited to) for the next meeting. Well, I will cover a lot more stuff in the future.. hopefully this will get us off to a good start. One thing I am REALLY hot on right now is Non-Photorealistic Rendering.. so expect some REALLY interesting stuff on that soon. Phil. 
|
