ATTRIBUTION RULES
International Game Developers Association
Back to Credits Main Page PDF Version 8.5
[edit] ATTR.1 – Credit must include a name and role, not just a name. Several names may be grouped under one role if it sufficiently defines the role of each person being credited and clearly indicates the discipline of work. Refer to the disciplines in ATTR.9.
[edit] ATTR.2 – Credits for work in like disciplines should be grouped together (e.g., Art credits together, Audio credits together).
2-1. Where a conflict arises between Rule ATTR.2 and Rule ATTR.5, Rule ATTR.2 should prevail.
2-2. As an [optional] exception to rule ATTR.2, credits for up to five [5] especially noteworthy team members may be listed first, before all other credits, to signify the key visionary team. Credits under this option should replace the equivalent credits in the main section for the individuals concerned. The five maximum corresponds to the number of main disciplines (Design, Programming, Visual Arts, Audio, Production) listed in ATTR.9, although a strict one-per-discipline correspondence is not required.
2-3. As an [optional] exception to rule ATTR.2, credits in one game worked on by two geographically separate teams (e.g. different studios) who are both doing creative work (e.g. Design work in France, Programming in Russia), development credits may be divided by company but this is not recommended. Instead, like disciplines should be grouped together with the company name appearing in parentheses after each name or not at all. If the latter is chosen, separate credits should be added for each company without reference to individuals (e.g. a French studio credited for Design, and a Russian studio credited for programming, but no correlation between individuals and their companies).
[edit] ATTR.3 – Leads in each discipline should be credited first.
[edit] ATTR.4 – (Optional) Senior/junior distinctions should NOT be used in screen credits:
a. unless the distinction applies to managerial, financial, administrative, executive, marketing, public relations, localization, information technology, and customer support
b. if the Senior functions in whole or in part as a hands-on Lead, to prevent functional Leads from losing award attributions. Note: The Senior/Junior appellation is entirely appropriate and encouraged for use in resumes and for job advertisements to distinguish seniority.
e. Seniority may be reflected in job titles and resumes but is not recommended for screen credit because it often creates problems in identifying appropriate award recipients for industry and press awards. In many cases, a Senior is denied an award in deference to a Lead because the awards group has no way of determining that a Senior is also functioning as a Lead. Furthermore, there is no industry consistency in whether or not a Senior also functions as a Lead. The intention behind the recommendation to avoid “Senior” in screen credits is more important than the universal application thereof; where there is no possible misconception arising out of the “Senior” credit, this rule need not apply.
f. Refer to Rule ATTR.10 for other hierarchical credit, and see the Question and Answer on this topic in a later section.
[edit] ATTR.5 – Development credits should be listed ahead of publisher credits and non-creative or non-technical credits, such as managerial, financial, administrative, executive, marketing, public relations, localization, information technology, and customer support positions. Where a conflict arises between Rule ATTR.2 and Rule ATTR.5, Rule ATTR.2 should prevail.
[edit] ATTR.6 – When two or more individuals share an identical credit they are to be listed in order of number of days spent working on the project. If the number of days spent on the project is equivalent, or if there is an extenuating circumstance that renders this approach unworkable (abusive practices such as intentional over-working to get top billing or inaccurate time records), individuals are to be listed in alphabetical order (in such a case, it should be clearly marked within the credits, e.g., “Programmers, in alphabetical order”).
[edit] ATTR.7 – In accordance with Rule METH.3, the number of multiple credits for a single individual should be capped in a reasonable manner in accordance with the threshold in Rule INCL.1 without otherwise forcing the individual to disavow significant contributions in any craft discipline.
7-1. Where Rule INCL.1 precludes another screen credit (e.g. a role performed in less than 30 days), Rule ATTR.10 may or may not be applicable and should be extremely limited in application.
7-2. Fewer credits that are broader in scope may be appropriate to limit the amount of roles and contributions that can be claimed, notwithstanding Rule ATTR.1.
7-3. Managers supervising multiple disciplines should receive a single managerial/executive/producer credit covering all disciplines.
7-4. Leads serving exclusively in managerial and/or executive capacities should receive a single managerial/executive/producer credit covering all managed disciplines.
Example 1: A hands-on Programmer is promoted in the middle of a game to a Lead Programmer position whose duties are strictly to manage people. This person should receive one credit as “Programmer” and one credit as “Programming Manager.” As an alternative to Programming Manager, Lead Programmer could be used if it does not replicate the screen credit title of anyone else. Example 2: A jack-of-all-trades designer/programmer/artist is promoted in the middle of a game from a Lead Artist people manager to a Lead Designer people manager. This person should receive one credit as “Manager, Art and Design”, not separate credits.
7-5. Leads serving predominantly but not exclusively in managerial and/or executive capacities should receive a single managerial/executive/producer credit covering all managed disciplines and may also be recognized with specially created credit that refers to the discipline of work and does not replicate the screen credit title of anyone else.
g. Multiple crediting is often needed when team members are promoted to a different role in the middle of a project.h. Beware that multiple crediting can be extremely nebulous and problematic when roles are defined too narrowly within disciplines.
[edit] ATTR.8 – [Optional] Team approval is required to limit pressure from authority figures to decline credit. An individual is allowed to refuse his or her own credit if:
a) he or she feels he is not deserving of the credit, b) the removal is requested in writing, and c) there is a majority of approval from those in-house team members in the affected discipline of credit.
[edit] ATTR.9 – [Optional] In general, notwithstanding Rule ATTR.2, disciplines are recommended to appear in this order:
- Design/Writing
- Programming/Engineering
- Visual Arts
- Audio
- Production
- Quality Assurance/Testing
9-1. In multi-platform development with different teams working on different platforms with some common members between teams, discipline order should prioritize the disciplines that spread most widely among various teams. Remaining disciplines should follow the general proposed order above.
9-2. Discipline order can reflect the structure of the teams developing the game, such as a programming-centric studio listing programming credits first. In this way, discipline order should not reflect only the opinion of managers, executives, producers, or administrators.
i. The main purpose in this order is to protect the primary recognition of the “visionary” role. While an industry standard for discipline order should arise at some time, at present there appears to be no overwhelming benefit to such requirements.
[edit] ATTR.10 – [Optional] Extraordinarily useful or otherwise significant contributions from non-regular or non-active participants on a given project may be recognized with specially created credit that refers to the discipline of work and does not replicate the screen credit title of anyone else.
j. Non-regular or non-active participants may include but are not limited to short-term contractors, senior employees working mostly on other projects but making small significant contributions, and individuals who make quick but watershed contributions, such as fixing a critical bug. Specially created credit should not create the sort of confusion identified in the annotation for Rule ATTR.4. In general, hierarchical or specially created credit should be extremely limited.
