Working Practices: Ambiguity

I've mentioned ambiguity in other articles on the website, but it is a point so important I think it is worth devoting an entire article towards it. Although the article is short, hopefully the importance of it will not be overlooked.

Creating games is hard. Anyone who has had to do it knows this. In order to reduce the level of difficulty, the team has to be very focused, avoid wasting time, work efficiently, be creative and all work towards the same goal.

Ambiguity can mess up all of this.

Ambiguity cause wasted effort, poor end results, decreased morale, shortened tempers, anger and despair.

The fifth horseman of the development cycle.

You may think I'm overstating the case, but I hope to persuade you otherwise.

What is Ambiguity?

Ambiguity is a problem mainly seen in requirement definition, whether it is technical, design, artistic or PR. It usually occurs when the person making the requirements does not include enough information to properly identify what needs to be done.

When you start to work on a particular issue, you need to have a clear idea as to what you are trying to do. This allows you to work out how you are going to go about fulfilling any requirements in the most effective way. If your requirements are very clear, then you have a single destination, and it is relatively easy to work your way to that point. However, in some cases, the requirements give no clear destination, which makes meeting them very difficult.

Problems Caused by Ambiguity

Incorrect work

If information is ambiguous, the wrong thing may be done, which results in the work having to be redone. In extreme cases, this work/ rework may happen several times, which both wastes time, and irritates the hell out of the person having to redo the work.

Bloated work

In order to meet an ambiguous request, a developer may do far more than is necessary. In some cases this may just result in some wasted effort, but in others it may mean that something goes into the game that is inefficient, taking up more memory or CPU time than it should. This in turn has a knock on effect, as less system resources are available to other areas of the game.

Loss of focus

Game development works towards the game design. If there is ambiguity, then some work may deviate from this. This can lessen the quality of the game if included, or in extreme cases, require the work to be redone. The game design can and should change as work progresses, but the changes should happen before the work is done, rather than after.

Lower quality results

Resources are always limited, and a part of game development is determining where to use the resources at your disposal. If the work effort is diluted due to ambiguity, the quality of work done is likely to be lower. Not necessarily in any particular area, but for the game as a whole.

If I am told to design a "lot" of puzzles, and I design and create 20, only to find out that we only wanted 5, then the chances are that the five chosen are going to be of a lower quality than if the original request had said 5.

Worsening in team relations

This is a result of the above problems occuring. It isn't something that is exclusive to ambiguity, but it is a very real result. Spending several days doing something, only to find out that it was entirely unnecessary/ wrong causes a large amount of friction. Since team morale and attitude is so key to making a game, things that affect it are very important.

Things to Look Out For

Relative Statements

Words such as "good", "big" and "nice" all lead to ambiguity. If you get a request to build a big table, or write a good AI, what does that mean? In both cases, the information is insufficient. Be far more descriptive - "a dining table for a country mansion. It should have room for 12 of our dining chairs, but can't be more than about 5m long and 2m wide. It should fit in to the style of the other objects used in the house". Even this information isn't perfect, but an artist gets a much better idea about the required object from this description. In a lot of cases you need to leave a certain amount of leeway to allow the developer to use their abilities, but work still needs to perform a function.

I'm not saying that every piece of work requires an essay, but if spending a small amount of time defining something saves a larger amount of time later on, it is worth it.

Assumption

Sometimes ambiguity creeps in because one or both parties assume the other knows what they mean.

For example, if you say "the UI needs to be done in the way we discussed during the meeting yesterday", you are assuming that a) the recipient remembers that meeting's conclusion, and more importantly, b) both of you came out with the same conclusions. On many occasions I've seen/ done work, only to find out that someone else had a completely different idea of what was necessary.

Intentional Ambiguity

Sometimes people are ambiguous simply because they can't define the subject more accurately because they don't know exactly what they are after.

For example, earlier I mentioned "good AI". If a designer doesn't really know what they want from an AI, that might be counted as a reasonable request. However, this is going to result in trial and error, and a lot of wasted work. In cases like this, the originator needs to come up with extra information, and the programmer should not do anything but the most basic work before the information is available. If a designer can't describe what they want properly, they can still write down a list of what function the work needs to perform. Even if it isn't exhaustive, it still provides the recipient with some accurate detailing as to what needs to be done. If something has to be added at a later date, the amount of extra work should be small, which is better than having a bloated system wasting time and using system resources.

Sometimes the source of the request may be someone who is incapable of creating accurate and unambiguous requirements. In those cases, someone else should make them, and then get the originator to approve.

Reducing the Level of Ambiguity

Getting Additional Information

If you don't feel you have sufficient and suitable information, go and get more. Ensure that your vision for what you are doing matches the requirements. Make sure the information is written, thus avoiding confusion. Often people get nervous about asking for clarification, and will avoid doing it, but by asking for extra information, you not only increase the chances of doing the current work right, but also educate the other people as to how to present requests.

Regular Check Ups

The earlier mistakes are caught, the less costly they prove to be. If you are unsure as to whether what you are doing/ what you have requested is correct, then check. Having a quick check, correcting any small problems, and then carrying on, can result in few problems even when the original request was not phrased well.

Reporting Problems

Chances are, every ambiguous statement in any of the documentation will have been read by many people. If you read something that you feel is ambiguous, let someone know. Sometimes the issue may be in hand, but at others, a useful point will have been raised, and a potential pitfall spotted.

Ok, I was maybe overstating the importance of ambiguity within the development process. It probably isn't the fifth horseman. But it is regularly underestimated, and often left free to wreak havoc.

*This article isn't finished, even by this website's standards, but I wanted to get some information on this subject up nice and early.