1. Game
  2. Codes and their use in TGSAP submissions

What is a code

A common game mechanic to retain the interest of the player involves a system of unlocking or enabling features to reward the player while they progress through the game. For many games this system provides codes presented to the active player or through abstract methods such as marketing with each code used to represent these rewards/features. Such codes may be given names such as "unlock code", "passcode", "password", "save code" or "cheat code" and other similar phrases. The choice of naming a game uses can bias individuals to interpret them as good or bad. This article follows on from the Global Rules' method and does not differentiate the game terminology used but instead considers all of these styles of reward/feature/save codes as simply "codes" to avoid any individual bias towards a naming convention.

The mention of such codes in the Global Rules is quite short. General Gameplay Global Rules and Guidelines for all Submissions: https://www.twingalaxies.com/wiki_in...ll-Submissions
The use of cheat codes, cheat devices, in-game codes and continues are disallowed as a general rule. Any and all passwords are forbidden. The only exceptions to this rule are: Any game track/variation that explicitly overrides this general rule with its own rules governing the matter within its specific listed rule set.
With that text, a default stance for any track on the main scoreboard is established (note: "main scoreboard" should be interpreted any platform except the "--Speedruns", "--GWR" platforms, nor the "Bounty Challenges").

Track-Specific Rules

As with that default stance, if the track rules specifically state something in relation to codes then the track text is the interpretation which becomes the default stance for that track.

Note for track creators: the scoreboard's Global Rules define the defaults but do not limit your creativity. However, you must be willing to define how your track should be viewed where it differs from those Global Rules. Examples are given below highlighting how some creators, past and present, have written rules.

Examples of tracks which stipulate codes are permissible or limited in some capacity:
Examples of tracks which specifically ban codes:
Examples of tracks which stipulate a ban but leave the interpretation to the adjudicator:

Adjudication and Problems Encountered/Overcome

Having Global Rules and Track-specific Rules overriding them is a great base structure but unless the language used in those rules is tried & tested, there's potentially arguments and misinterpretations ahead. The place this testing occurs, in the current era, is with the Adjudication of submissions.

Each of the examples below is based on historic adjudication and how the codes have:
  • Caused a situation which is not clear.
  • Forced adjudication to settle on an eventual interpretation.

Example 1: save games and codes

Outline: the rules stipulate no or limited code use. The game has been developed for a platform which saves the game and the game automatically or optionally loads the save with each start. Codes that are given to the player can be input in one gaming session and the game subsequently saved - including the code being enabled. When the game is loaded next, the save is automatically loaded and no reference to the code is ever made again.

Nuance: many games in this category will also automatically unlock features through normal play without ever offering a code to the player or requiring a code to be input. In addition to the automatic unlock, codes do exist which perform the same unlock action as though the game had automatically unlocked features (Tiger Woods PGA Tour 2004 fits into this category, for example - see above links).

Adjudication reasoning:
  • Where code use unlocks a game attribute which can be earned through normal play (unlocking cars, unlocking courses or missions, or the like) and the load mechanism for the game provides an invisible or near-invisible barrier to the knowledge of the code use, such "unlock" style codes are typically acceptable for use.
  • Where code use provides the player an added advantage or a game feature which skews normal play and that advantage/feature cannot be unlocked or achieved through normal play then a default stance of not permitting that code has occurred. For example, a code which could enable perfect stability in a game which features imperfect balance (skateboarding, bike games and similar, for example).
  • Where code use provides a feature entirely unlike normal play, the default stance is not to permit the code. For example, a code which turns an entire level of a platform up side down effecting a new path.

While not specifically a code-related subject, submitters and adjudicators must also be aware that the save game in use by a submitter may not be their own. It is the responsibility of the submitter to ensure the save game they use does not break the rules of the track or those Global Rules which have an impact on the track. Equally, the adjudicators must be aware of this possibility and not impose any penalty to the submitter just because the save game being used may have hallmarks not related to the submitter.

Example 2: games with codes, unlockable content but no save

Outline: the rules stipulate no or limited code use. The game has been developed with no capability of using a save game but does have features which unlock with sufficient or specific gameplay.

Adjudication reasoning:
  • For situations where such features are only accessible with extensive gameplay. In effect, the rules penalise those without the ability to record for equally extensive amounts of time and cause undue (effectively useless) video recording to meet expected minimums of proof. In these circumstances, it can and has been argued that changing the Twin Galaxies-owned (typically pre-TGSAP) rules to permit codes is a worthwhile retrofit.
  • For situations where such features are only accessible with extensive gameplay. In effect, the rules penalise those without the ability to record for equally extensive amounts of time and cause undue (effectively useless) video recording to meet expected minimums of proof. In cases where the track was created by a user (i.e., not Twin Galaxes) it may be necessary to reach out (see TG policy for approved methods) to the individual(s) involved in the track creation in order to establish the intent. Before reaching out, however, check previous submissions (including rejections) in case this has already been resolved: it could be the rules are already firm.
  • For situations where an external device or software feature has been used to capture the progress including those unlocked items (in many circumstances this is termed a "saved state"). This falls under the Global Rules as not permitted or may already be permitted by a different track on the scoreboard. An additional adjudication problem involved with this circumstance is that the save state itself cannot be interrogated under normal video evidence as to whether it contains a cheat or other advantage-giving scenario.

Additional Examples. Non-original content (inc. trainers and mods).

The word code has many connotations so this example section is an attempt to cover those possibilities. To a wide extent, examples in this section are covered by the Global Rules as banned and so few, if any, actual instances in the adjudication process can be found.

In the wider sense a code can come in many forms which exist outside of the original game developer's content. However, the source program code for some games (example Doom) have been distributed. Such source code should not be tampered with for submission content as this violates the Global Rules requirement for origiinality (at the time of writing no known track permits source code modification).

Other code types can come in the form of generating memory changes which impact how the game code behaves. Examples of this are those generated by the popular Action Replay set of devices and computer Poke codes (expanded upon below). Many physical peripherals, hardware modifications and emulators have similar features with advanced versions potentially being interactive while play commences. For submissions, try to avoid such devices or emulators where possible to avoid the possibility of accusation. Where such devices or emulators cannot be avoided, highlight the use of the features of the device/emulator in the video submission to confirm no codes are in use before your gameplay commences. Note: in the vast majority of cases, showing such features after your achievement or in a separate video does not convey confidence in their lack of use.

Even in early computers the term Poke invokes a change in the memory of a program and with games this can effect a behavior change. A Poke is usually comprised of two parts: a RAM position and a value. Such codes are often, therefore, described as a pair of numbers. As computers became more widespread, these Poke codes became more intertwined with bespoke loading mechanisms and the term "Trainer" became popular to describe this feature in many cracked software, thus reducing the barrier for widespread use and dissemination.

In general, codes of this nature are easily surmised as banned based on the Global Rules. However, some Poke codes have occasionally been supplied by the Original Equipment Manufacturers (OEM) to correct bugs in their software. One such example is Jet Set Willy on the Sinclair ZX Spectrum. Four Pokes were released by the publisher, Software Projects, to fix bugs enabling the game to be completed:

POKE 60231,0
POKE 42183,11
POKE 59901,82
POKE 56876,4

The specific adjudication of such situations should be documented in the track rules where the track creator is aware of them. Adjudication in situations of OEM patches like these remains a case-by-case basis if the rules are not already clear for the individual track.
Join us