If you work in the video game industry, you have probably experienced in one way or another a situation in which some kind of work (art, music, sound, code, etc) needs to be revised, corrected or even redone entirely. These situations a commonly referred to as reworks. In video game development, reworks can be massively time consuming and stress inducing, especially when a deadline is quickly approaching. The good news is that there are ways to ensure that reworks are kept at a minimum.
Whether you are the one doing the reworks (artists, composers, programmers, etc) or the one asking for them (game designers, producers, directors, etc), this article should help you save a potentially massive amount of time for you and your team.
Before we start preventing a problem, we must know what are the causes. In my experience, the two most common causes for reworks are:
- Design changes. Reworks caused by design changes occur when one or more fundamental aspects of the game's design is changed by the developers, making the previously approved work unfitting for the project. Reworks of this kind can be quite unpredictable and difficult (sometimes impossible) to prevent.
- Lack of proper communication. This is the most common, preventable issue and will be the focus of this article. Reworks of this type are caused by miscommunication between the work provider and the game designers, resulting in work that does not fit the artistic and/or technical direction of the project.
Now, let's go through some easy steps that will allow us to drastically reduce the occurrence of reworks caused by lack of proper communication:
Information is Gold:
Always provide/ask for all the relevant information about the game. To increase the chances of creating work that perfectly matches the vision of the developers, it is important to make sure that everyone is working on the same wave length. The best way to do this is to have as much information as possible available for the contractors.
This may sound like common sense, because it is. But unfortunately, common sense is not always common practice. Game developers who have been living and breathing their vision for months may unintentionally regard a certain piece of important information as common knowledge, failing to disclose it clearly to other team members. Or, a team member who comes in later at the development may unknowingly receive outdated information about the project, resulting in work that must be remade.
The best way to prevent this kind of miscommunication is to have organized and up to date sources of information. Good examples are game design documents, concept art, script, screenshots and early game builds. This is especially relevant to team members coming in later in development and also to those working off-site.
If you are new in the development team, never hesitate to ask for more information. If you are a developer bringing someone new to the team, be proactive to provide it. This will for sure prevent misunderstandings and unnecessary reworks.
Learn to Interpret:
Game developers work in co-operation with professionals of many different areas. It is almost impossible to know the technical vocabulary proper to the expertise of everyone they work with. Because of this, it is important for contractors to develop a "sixth sense" when communicating with the developers.
For a simple example, if a developer asks a composer for a "high energy" music track, the musician could probably interpret that as a reference to fast tempo. Some situations like this can be much more complex, requiring better interpretation skills from the contractor.
The ability to interpret will come largely from the accumulation of experience in dealing with different people in different projects.
As a developer, if a contractor speaks to you in technical terms, don't hesitate to ask for clarification in order to avoid misunderstandings. As a contractor, sometimes your interpretation skills won't be enough to give you a clear picture of what the developer means. This brings me to my next point:
Ask For/Provide Reference Material:
Having reference material available is probably the best way to make sure the work will turn out to be as close as possible to the developer's vision. It makes it possible for everyone to take inspiration from the same sources, making the request for a rework less likely.
Contractors can use this material not only as direct reference, but also as a parameter for their own research on other material similar to the one(s) provided. It is also possible to provide/ask for reference for what kind of work should NOT be done, making the boundaries between what is desired and what is undesired very clear.
In addition to providing the reference, the game developers should make sure to use it to its full potential by implementing what is described in my next point:
Is not uncommon for misunderstandings to happen even when reference is provided. A relevant detail in the reference, if not mentioned, can easily go completely unnoticed by the contractor.
What exactly the developer likes about the reference material? What elements should be replicated in the contractor's work? What elements should be avoided? Having these details settled in advance will prevent having to rework them later.
These steps are very simple and effective but are not always practiced in the video game industry. Working fast is one of the best qualities someone can have in almost any industry and you will certainly stand out among others when word comes out that you value your team's time.
Find me on: