Working Practices: Introduction

As you may have noticed, I have pretty strong views on various aspects of working practices. 11 years developing computer games has shown me how important some of these things are. However, in my experience, people new to the industry (and even some less new) often have little regard for such things, and see many effective ways of working as just bureaucracy - something which gets in the way of the actual work. Usually after falling victim to one or another of the potential pitfalls of development, the light is seen, but I don't particularly see the need for developers to only learn by their mistakes.

This article is really a list of working practices that don't currently justify having an entire article written about them. In some cases, this is because the topic can be summarised in just a few sentences, and in others it is because I haven't had time to write one yet. As time passes, new points will be added, older ones modified, and some removed as they evolve into complete articles. In the end, I hope that this website contains a good set of working practices that can help many developers to work better.

One of the things that usually comes as a surprise to people coming into the games industry is the difference between working on your own ideas, and the different requirements when you work within a team.

Although the core area of work - the creation of code/ art/ design work remains the same, some of the disciplines and requirements are very different.

Professionalism

I had thought this was obvious, but a surprising number of newcomers to the games industry don't seem to realise this... I appreciate that this may sound insulting, but I've met numerous people who seem to treat working in the games industry as some sort of paid hobby work instead of the important job it is.

When you are creating work for fun, you do the things you want to do. If you have to do something less interesting, most people will try and either do it as quickly as possible, skip it, or try and find something on the internet that fulfills the purpose.

However, when you are part of a development team, being paid for your work, you have to approach any task with all your ability. A large part of making computer games ISN'T that fun, but is very important. Whether it's a series of brick textures, code for menu screens etc, it has to be done well, and in a timely manner.

Each job must be approached in the proper manner - what the end user thinks is important may not be the same as what a developer thinks is interesting, and areas of the game that are done badly reflect on the entire project.

In addition, work shouldn't be skewed away from the desired result according to developer preference, again a common practice when a developer puts their own interests ahead of the game.

Compromise

When working on something as a hobby, you have as much time as you need, or want. This allows you to create, refine, rework, throw away, as much as you want until you are happy with your solution. This is one of the reasons why some mods and user created levels are superior to shipped work.

However, when you are working on a development team, the important thing is to get the work done. Sometimes this means that the work is not quite up to the standard that you would like, but companies make money by shipping completed games, not developing them. Although "good enough" is not a phrase that developers like to hear, it is an important one to remember. Once something is good enough, it should only be replaced when the rest of the game is done, and time is being spent improving what you have. Often this can be irritating - most developers are working in games because they like them, and when you see your game failing to achieve everything you desire, it can be less than inspirational. This does not mean settling for second best - any developer should always try to produce the best possible work within the constraints.

Responsibility

I always like to treat the people I work with respect. Developers are creative, intelligent adults, and I think that all developers deserve to be treated as such. However, this does require that people take responsibility for their work and work ethic.

It is the responsibility of everyone on the project to work efficiently, and ensure that they have all the information required in order to create a piece of work.

Each developer needs to take responsibility for all aspect of the work they do. This means making sure that the work increases the quality of the game, is done in a timely manner, and to the best of their ability given their constraints.

The more responsibility that developers take, the less artificial restrictions need to be placed by team and company management, which results in a more creative and productive environment, which can only be good for the game being developed.

Naming Conventions

Naming conventions are one of the hardest things to get people to appreciate, in my experience. I don't really know why. Naming things in a useful and accurate manner takes very little extra time over completely useless names, but can be very beneficial in the long run.

Although I'm not writing a naming convention here, I strongly recommend any development team having one. The basis of a naming convention is to give assets names that both uniquely identify them, and also describe their purpose in such a way as to make finding the correct asset easy. Something that may seem over the top until you have 300 textures named building001.bmp to building300.bmp.

Newsgroups

I am a big fan of companies having their own internal newsgroups, and not even limited to just development matters.

Newsgroups are excellent methods for online discussions that invite anyone who is interested to take part, but don't interfere with those who have nothing to offer. By using newsgroups, it is easy to see what everyone is working on, examine new ideas, bring up problem issues etc.

However, newsgroups are also useful for non work issues. For example, if a Jokes newsgroup is set up, then you avoid the problem of people's email getting cluttered with lots of unwanted mails. I spoke to a couple of friends recently, and they said that at their company, they get in the region of 50 mails a day from within the company, the majority of which are jokes sent to a large number of people. If a newsgroup were set up, this could be reduced. General chat, game/ film./ book views etc are all areas where a newsgroup may help.

Team Work Ownership

Writing the title for this point made me a little wary. I dislike corporate management speak, and the phrase "team work ownership" sails a little too close to that for me to feel comfortable. It's something I can imaging reading in a Dilbert cartoon. But I couldn't really think of anything short and more accurate, so I'll stick with that for now.

By team ownership, I mean that each individual views the entire game as their (the team's) work, instead of each piece belonging to an individual. This doesn't mean losing appreciation for individual team members who have done well, but it does mean making a group effort to try to address weaker parts of the game, as opposed to each developer washing their hands of any problems that don't directly relate to them

Each individual should take it upon themselves to try and spot areas and come up with ideas that would improve the game as a whole, regardless of where the problems or improvements lie. By seeing the entire project as "our" game as opposed to just concentrating on "my" work, there is a greater focus on what is really important - creating a great game, instead of something that only works towards that - making sure my work, as an individual, is great.

Jargon Usage

Like most specialist subjects, there is a whole language of jargon involved in game development, to cover both technical and artistic subjects.

Although this is fantastic, as it allows complex subjects to be encompassed quickly, sometimes problems occur due to two people having different understandings of the jargon in question. In many cases, one person simply doesn't understand the terms, and this can usually be solved by a simple explanation (although I never did manage to make one of my ex-producer's understand why 8 bit palletised images CAN look better than 16 bit).

However, a bigger problem occurs when two people have two different understandings of the same term. Sometimes this means one person's understanding is incorrect, but more dangerously this can also occur because the same term means different things in different areas.

As an example, on one game I worked on, the term "material" caused confusion, as what 3DSMAX calls a material was not the same as the renderer's definition. Whilst both definitions made sense in context, the fact that the two areas treated it differently did cause problems.

One side not understanding a phrase properly happens more often, but is often easier to correct, whilst dual meaning phrases occur more rarely, but can be more difficult to eliminate. In all cases, encouraging people to speak up it they aren't sure as to what is meant by a phrase can help. This includes speaking up if someone thinks a phrase is being used incorrectly.