Skip to content

Developer's Code of Conduct

This document covers developers' rights, responsibilities, and rules for fair play.

If you are not a dev, check how to become a developer.

See Also: Users Code of Conduct.

Golden Ruleslink

  1. Respect your fellow developer and communicate through any issues you have civilly.
  2. Make room for other developers to get a chance to work on games they like, in their own way.
  3. Anyone can become a developer if they put in the effort.
  4. All achievement sets are open for improvement.

Developers must do the following to keep in good standing:link

Reserving a game for achievement developmentlink

1. How to Reservelink

The only way to reserve a game is claiming it on the specific game page, as explained here.

  • No other declarations, plans or lists posted anywhere else are to be considered in this.
  • Code notes do not reserve a game (if you have added notes but not reserved the game in the forum, any other developer is free to work on it).
  • It is recommended that you post a list of planned achievements, so the community can review your work and give you feedback.

2. Concurrent Reservations Limitlink

As in the maximum number of achievement sets one developer can have reserved at once.

  • Junior Developer: 1
  • Developer: 4
  • Note: Joining another developer in a cooperative effort does not reduce from this total.

3. Reservation Timinglink

  • Only reserve a game for development when you start working on it. In other words, do not reserve games just to block others from working on it.
  • Please reserve a set as soon as you begin working and not as you are finishing your work.

4. Reservation Renewalslink

You can renew your reservation every three months if you have not finished your set.

  • Once a reservation has expired, the set is available to be claimed by another developer.
  • Once a reservation is more than a year old, a detailed progress report will be required for any subsequent renewals. The report should provide an overview of the development situation and include details such as:
  • Memory digging status
  • Rich Presence and Leaderboards Status (if applicable)
  • List of planned achievements
  • List of achievements already coded (local or unofficial)
  • Progress of badges creation
  • The reports will be reviewed by the Developer Compliance team, who will decide whether the progress is sufficient to warrant another renewal.
  • If the renewal is denied, a cooldown of 1 month will be applied and after this period the developer will be allowed to reserve the set again if it is available. Detailed progress reports will be required for any further renewals.
  • If a claim is dropped and resumed in less than a month, the initial claim date before dropping the set will be mantained.

5. Respecting Reservationslink

  • Do not ask, pressure or discourage anyone from working on any game, in public or in private (of course, assuming the person is already following all other standards on this Code of Conduct).

6. Reservation Cool-Downlink

Upon reserving a set, wait at least 24 hours before promoting it to core. This allows time for reservation review and to clear up any possible reservation disputes. If you believe a set is ready for core within 24 hours, an early promotion may be subject to approval.

Important Noteslink

  • If you post a complete plan, be open to suggestions; you can get excellent input and suggestions this way.
  • You must adhere to the Basic Achievement Design Guidelines, otherwise your set won't be allowed.
  • When you publish your work you are giving it over to the community to be reviewed and reworked over time.


  • Let others know if you welcome collaborators.
  • If you've recently reserved a set and someone else voices desire to work on a set that you've reserved within the last 24 hours (beyond suggesting ideas), consider ways in which you can collaborate with them.
  • If someone reserved a game you're interested in before you, don't get frustrated. You are encouraged to request collaboration. You can post your desire to collaborate in the forum or send them a message to get permission from them to publish your contributions. You can also wait and go through an Achievement Set Revision after the set is published.

Basic Achievement Design Guidelineslink

Unwelcome Conceptslink

You can (and should) be as creative as you can, but there are some concepts that are NOT welcome for achievements, such as:

  1. Require Glitches/Bugs1 (acceptable in Bonus sets).
    • Historically significant glitches and well-known, not-hard-to-execute glitches of importance to the game's community are allowed with the approval of DevCompliance. It should be clear that the glitch is needed for the achievement(s) and serve to highlight the glitch's importance or significance.
  2. Require two players (acceptable in "Multi" sets).
  3. Require perfection all game (maybe acceptable in Bonus Sets).
  4. Dying (simply), or playing bad without any purpose (acceptable for extra content like special cutscene).
  5. NSFW content in text or image.
  6. Achievements popping frequently with little effort from the player (including multiple achievements for doing the same task, such as one for beating a boss and another one for getting the item left by the boss, etc.)
  7. Achievements obtainable with zero effort for no meaningful purpose (example: start the game as character X, collect one coin, watch a video). It's acceptable if there's something fun/historical/interesting you want to address.
  8. Require excessive repetitive grinding, such as reaching level 99 in an RPG, for no meaningful purpose (maybe acceptable in Bonus Sets).
  9. Rely entirely on randomness, especially when there are extremely low odds. However, for games where the randomness is a major aspect, it may be appropriate.
  10. "Secret Achievements", where the players have no indication of what they're going after. If you want to prevent spoilers give at least a clue on the Achievement Title/Description. Otherwise the players will start to search on web or mess with Achievement Editor/Memory Inspector, and in the process they can stumble across even worse spoilers.
  11. Sets for games that lack gameplay (videos, music visualizers, jukeboxes, etc.) won't be accepted without explicit approval. Approval will be handled via a vote by the Dev-Compliance team on the Discord server, and requires implementation of sufficiently creative concepts. Book sets are still allowed, but must be worth 0 points. Example: SporyTike's GBA Video Series was presented with the idea to include a leaderboard quiz at the end of each episode. This unique plan involved gameplay past pressing start and was approved.
  12. Sets for compilations featuring games that share the same console as the compilation. An example of this is 6-Pak for Genesis/Mega Drive, which contains six Genesis/Mega Drive games.
  13. Prototypes/Beta sets if there is no discernible unique content from the main game. (This is just an extension of the demo rule).

1 Glitches/Bugs are errors within a game's code which often cause unintended behavior. Examples are memory overflow, incorrectly loaded levels, and clipping into objects.

Note: With every rule, there are exceptions. This is especially true with unwelcome concepts. All unwelcome concepts have some wiggle room, so when in doubt, consult with the admin team.

Every Achievement Set MUST Havelink

  • All game page information filled out, and game images uploaded (if you're not a full-dev, send the images to the code-reviewers).
  • Game Badges for each achievement (they don't need to be distinct from each other, just don't leave them blank).
  • Content covering up to completion so long as the game can be beaten. Whether it be defeating the final boss, completing a first loop, or completing all puzzles, achievement sets that do not cover at least beating the game are deemed unfinished and therefore subject to demotion. Arcade-style games where the focus is on high scores (such as Pac-Man and Crystal Castles) are exempt from this rule.

Protection for situations where the players can get achievements without effort, such as:

  1. Demo mode;
  2. In-game cheat codes;
  3. Battery saves;
  4. Passwords.

See also: Achievement Templates and Real Examples for some well known protection techniques.

  • Basic Rich Presence (only available for full-devs).
  • Leaderboards for scores and time challenges.
  • Missable achievements flagged, especially for RPGs and long games.
    • Use [m] in the end of achievement's title to flag it as missable. This is the standard format and must be used for consistency.
    • Avoid overuse. If most of an achievement set is marked as missable, the mark becomes meaningless for that set.
  • An achievement guide. Guides can be created and posted here.
  • For games with text-triggered achievements (especially RPGs) it's recommend to find an event flag instead of hooking onto text or text ID. Text presentation varies between regional versions making multi-region support difficult.

Achievement Scoringlink

When scoring achievements match your scores to one of these 5 tiers. There is no achievement set point cap.

  • 0-5 Easy / Minor Significance
  • 10 Medium / Intermediate Significance
  • 25 Hard / Major Significance
  • 50 Very Hard / Completion Level Significance
  • 100 Sadistic (Typically for bonus sets)

When scoring there are other factors to be considered, such as achievement spread and game length.

Tools to Help you Succeedlink

We have a roadmap you can use as a guideline to create a good achievement set.
We also have an achievement design guide on how to design good achievements, not the technical side but the conceptual. Creating a balanced set is one of the most difficult aspects of development, we have a set balance guide which will help you in thinking about how to create a set that flows.

It is preferable and recommended to work on one set at a time. But if you have more, be open for a teamwork or even delegate the set creation if another dev contacts you.

Revisions - Working on Sets with Existing Achievementslink

Revisions, as in working on a set that has existing achievements typically requires community approval by presenting your plan in the forum and in the #revision-voting channel in Discord. Not all changes need approval. See Achievement Set Revisions for details.

Code Noteslink

Leave accurate code notes for each address you use for achievement conditions. This helps you and others maintain the set, keeping it free of bugs.

You're free to add any code notes you discover to any set without declaring intentions to work on the game. Just be careful to not delete previous notes added by someone else.

Handling Ticketslink

After you've published achievements be prepared for bug reports.

You're expected to keep your work bug free by appropriately resolving tickets. Respond to all tickets as soon as possible. The sooner you respond the better, cause the problem is fresh in the player's mind and you can use them to help you to resolve the problem.

While resolving tickets, leave a brief summary of what you did. If you have an indication of false report leave a message showing what conclusions you've made, and then close the ticket. Closing/Resolving a ticket without leaving any comments is an unwelcome attitude.

Do not declare your plans to work on a game if you have unaddressed tickets. A ticket is considered as addressed when the developer acknowledeged the ticket, commented on it explaning the situation but is unable to resolve the problem immediately due to reasons such as waiting for saves states or more information from the reporter.

If you want to resolve tickets or fix bugs on achievements made by another developer, it's always a good practice to try to contact them and check if they are still active before changing their work. An inactive developers is someone who have have 10 or more open tickets that are older than two months (you can see their open tickets from the Ticket Manager).

If the developer is active, you can assist them in the resolution.

If the developer is inactive you can freely resolve their tickets. If necessary, you may change the achievement description in order to clarify the objective or to match the logic that is present. However, do not deviate from an achievement's concept or objective in any way without an approved revision vote.

If a fellow developer has already started to handle a ticket thru action that can be proved with comment of intent, leave it to them. The user would be given a time of 7 days to handle the ticket after comment. Example: If USERA was fixing a ticket (having left a comment of intent) and then USERX came to undo the work or interrupt the work in progress this would be an issue.

Editing Leaderboardslink

  1. Before making updates to a leaderboard, you must backup each modified conditional line on the comment (if too long use Pastebin link)
  2. After editing a leaderboard, if you are fixing, adding, or removing entries, you must leave a comment about changes you have made and why.
  3. A leaderboard's concept/design should not be changed once players have begun submitting entries. Exceptions are as follows:

    A. If a leaderboard has a bug in which a correction would result in a discrepancy between between pre and post fix LB submissions, this would be considered a fundamental change and it may be most appropriate to "retire" the leaderboard and create a new corrected LB.

    B. If a protection needs to be added to the cancel field in a leaderboard, for example to eliminate point farming/leaching (Areas where a game generates an endless number of things, such as items, money, or enemies), it may be preferable to either “retire” or create an additional leaderboard. "Retiring" a leaderboard means preventing future submissions.

  4. If a developer wishes to create a new concept for a leaderboard, a new one should be added.

  5. If a developer wants to implement a fundamental change to a leaderboard while keeping it intact, a revision vote is required. “Fundamental changes” involve the following:

    A. Changes to how players submit scores.

    B. Changes to submission requirements that impact difficulty and or strategy.

  6. A Jr. Developer may only change, add, or remove a leaderboard with a code-reviewer that goes through the revision process with them.

Expiration of Developer Statuslink


The developer status will expire and account type will be set to [Registered] if the following conditions are met:

  • Developers: Inactivity as developer for 6 months or overall inactivity for 3 months.
  • Jr. Developers: Inactivity as developer for 3 months or overall inactivity for 1 month.

It is important for developers to remember that this is NOT a punishment and is only done for security reasons!

Inactivity as a developer will be defined as: - Has not made or renewed a set claim. - Has not created new achievements. - Has not performed maintenance on existing sets (revisions, rescores, badge changes, etc.) - Has not resolved, closed, or otherwise addressed any open tickets, theirs or otherwise.


Alternatively, developer status will be removed if the developer has 10 or more tickets that are at least 2 months old. If the developer has any active claims during this period, they will be given an additional 30 days or until the earliest claim renewal (whichever comes first) to resolve all 10 tickets. Not doing so will result in the developer falling into inactive status and the claim(s) being released.


If a user's developer status was removed due to inactivity and they wish to have it reinstated, they must contact Dev-Compliance. However, before doing so, it is recommended to review any changes that were made to the Developer Code of Conduct, updates to the achievement creation tools, and have a plan to address open tickets for their achievements, if applicable.

The steps involved in reinstatement will vary from user to user depending on the following: - The amount of time elapsed since developer status was removed. - The amount of tickets that may have been opened on their achievements. - Other QA issues that may have come up since developer status was removed. - Moderation warnings or actions the user may have received.

A user may be required to submit work to code reviewers if more than a year has passed since their developer status was removed or if they initially obtained developer status before the junior developer program existed (July 2018) and did not retroactively obtain the Junior Developer badge.

Note: Achievements edited by other developers will not count against a user seeking reinstatement.

Achievement Ownershiplink

When you publish your work you are giving it over to the community to be reviewed and reworked over time - see Achievement Set Revisions.

While the original developer does not own published achievements, they are still the caretaker in terms of bug fixing and maintenance. If another developer revises the achievement, they are the new caretaker of that achievement.

Changing Accountslink

If a user with either Developer or Jr. Developer status changes accounts, achievements and tickets under the old account will be re-authored and reassigned to the new account.

Feedback about the Developer Code of Conductlink

Although the Developer Code of Conduct is the result of an intense debate, it's not an immutable document. If you have suggestions for improvements, contact us on our Discord server or send a message to RAdmin.


Last 10 changes on this page:

  • [2023-05-29 20:42] The Mystical One: Adding in unwelcome concepts change.
  • [2023-05-11 08:00] The Mystical One: Adding an overuse clause per devcompliance voting on missable wording.
  • [2023-04-23 22:34] televandalist: ToC tweak
  • [2023-04-23 21:59] televandalist: Got rid of section that redirects to the "New Achievement Set Checklist" - which is info that's either already in the DevCoC, outdated, unnecessary, or being moved to the upcoming "Content Guidelines" sections.
  • [2023-01-29 13:05] Hotscrock: Cosmetic fix because I forgot to check the preview as always.
  • [2023-01-29 13:03] Hotscrock: Expanded "Expiration of Developer Status" section
  • [2023-01-06 09:08] pingus: Addition of jr devs/devs changing accounts names and the reauthor process for achievements & tickets passed by DevCompliance.
  • [2022-10-01 09:47] Hotscrock: Updated Developers Code of Conduct (markdown)
  • [2022-10-01 09:43] Hotscrock: Updated Developers Code of Conduct (markdown)
  • [2022-10-01 09:36] Hotscrock: Updated Developers Code of Conduct (markdown)