Developer's Code of Conduct
This document lays out for developers the rights, responsibilities and rules for fairplay.
If you are not a dev check here how to become a developer.
See Also: Users Code of Conduct.
- Respect your fellow developer and communicate through any issues you have civilly.
- Make room for other developers to get a chance to work on games they like, in their own way.
- Anyone can become a developer if they put in the effort.
- All achievement sets are open for improvement.
tl;dr - Developers must do the following to keep in good standinglink
- When planning to work on a new game reserve it by announcing your basic plan in the forum on a new post.
- Only announce new plans when you are free of tickets. Follow other set reservations rules too.
- Wait 3 days after your plans have been posted to promote any achievements to core.
- Keep your work free from unwelcome concepts.
- Use protective code preventing potential cheating and exploits.
- Leave accurate code notes for each achievement condition you've used.
- For set revisions, follow the revision policy.
- Resolve tickets, and leave notes each time you do.
- Once you publish your work, you are giving it over to the community to be reviewed and reworked over time.
Before you Beginlink
Are you free of tickets?link
Before working on new games you must resolve all open tickets you have. Once you're free of tickets, then go ahead.
Is the game present on the database?link
Then ask for it to be added on Discord #help-me or on our forums and some dev will add it for you. It's essential you choose the right ROM(s) to work with. If you want to work on a ROM hack, check the achievements for ROM hacks doc first.
Good! Go ahead.
Does the game already have an achievement set?link
If there is an existing set, don't give up. You can still improve it, by adding/removing/reworking achievements, or make changes to titles and images, etc. However you'll need to go through the set revision process.
Look deeper. Often there are multiple entries in the database for the same game under different titles. Once you're sure, you'll need to check if there's another dev working on the game.
Note: Only one achievement set is allowed per game per console. For details see working with the right ROM.
Is another developer working on the game?link
To be sure if there's another dev working on a game, check the game's official forum topic (that's the official way to reserve a game to work on). This is needed to avoid conflicts between multiple devs working on the same game.
It may be possible that developer has stopped working on it. Developers are expected to renew their reservation every two months. Look at the time stamps to see when the developer posted a reservation for development. If the developer has not stated or renewed their reservation on the game after two months you can assume it has been abandoned and then you can post your plans to work.
Great! You're free to go ahead! The next step is to announce your plans to develop achievements for the game.
Announcing your plans to work on a gamelink
Announcing your achievement set plans is done by posting in the game's official forum topic what you have in mind for the set.
Posting your plans is is how to officially reserve a game for you to work on, however there are some rules about reserving listed below that you must be aware.
There's no need to leave a complete and detailed plan! Only a simple outline of what your intentions are (your plans will most likely evolve after researching the game's memory). Do this so the community can leave suggestions and provide feedback.
Try to be open to suggestions. If you don't agree with the feedback received, you can go ahead with your concept. But keep the following in mind:
- You must adhere to the Basic Achievement Design Guidelines, otherwise your set won't be approved.
- When you publish your work you are giving it over to the community to be reviewed and reworked over time.
If someone picked a game you're interested 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.
Rules on reserving games for developmentlink
These rules below exist to easily know who is working on what, define what's acceptable, prevent games from getting stuck in development, protect Developers from undue social pressure.
1. The only way to reserve a game is by posting your plan in the official forum topic of the game on a new post.link
- No other 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).
2. Maximum number of concurrent reserved games:link
- Junior Developer: 1.
- Developer: 4.
- Veteran Developer: 8 (a Veteran Developer is someone who is Developer for at least 18 months and has published at least 20 achievement sets).
- Note: Working on an approved revision or joining another developer in a cooperative effort does not reduce from this total.
3. Only reserve a game for development when you're really going to start working on it. In other words, do not reserve games just to block others from working on it.link
4. You can renew your reservation every two months (+/- 2 weeks) if you've not finished your set.link
- To renew the reservation, post about it on the official game's forum topic.
- Do not edit your previous declarations, but make a new post talking about your current progress.
- Avoid locking down a set indefinitely. If it appears a developer continues to delay development on a set with little or no progress the staff may intervene.
5. 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).link
6. Once you posted your plan, wait at least 72 hours before promoting any achievement to Core. This gives time for community review your plan and give feedback. This waiting period starts after your plan has been presented in its complete (or mostly complete) form.link
Basic Achievement Design Guidelineslink
You can (and should) be as creative as you can, but there are some concepts that are NOT welcome for achievements, such as:
- Require glitches (acceptable in Bonus sets).link
- Require two players.link
- Require perfection all game (maybe acceptable in Bonus Sets).link
- Dying (simply), or playing bad without any purpose.link
- NSFW content in text or image.link
- 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.)link
- Achievements obtainable with zero effort for no meaningful purpose (example: start the game as character X, collect one coin). It's acceptable if there's something fun/historical/interesting you want to address.link
- Require excessive repetitive grinding, such as reaching level 99 in an RPG, for no meaningful purpose (maybe acceptable in Bonus Sets).link
- 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.link
- "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.link
With every rule, there's an exception. This is especially true with unwelcome concepts. All unwelcome concepts have some wiggle room. when in doubt consult with the admin team.
Every Achievement Set MUST Havelink
Protection for situations where the players can get achievements without effort, such as:
- Demo mode;
- Ingame cheat codes;
- Battery saves;
Every Achievement Set SHOULD Havelink
- At least basic Rich Presence;
- Game Badges for each achievement;
- All game page information filled out, and game images uploaded.
Note: Rich Presence, Leaderboards, and game page images/information can only be added by full developers
Recommended but not required for any Achievement Setlink
- Leaderboards for scores and time challenges.
- Missable achievements flagged, especially for RPGs and long games.
[m]in the end of achievement's title to flag it as missable.
- An achievement guide. Guides can be created and posted here.
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.
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.
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 open tickets.
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. However you're only allowed to fix the achievement to match the description; do not change the intention of the achievement without going through the revision process.
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.
Feedback about the Developer's Code of Conductlink
Although the Developer's 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:
[2019-05-14 12:40] Kvon:made some headings linkable. (especially for citing rules.) If there's a better way to format these please go for it.
[2019-02-28 16:39] Kvon:The words "on a new post" for reservations is essential because sometimes devs will edit the top post and the change will not be noticed in forum activity.
[2019-02-27 10:01] Kvon:typo
[2019-02-27 09:59] Kvon:Added a note to explain that plans must be presented in a (mostly) complete form before the 72 h wait period for core starts.
[2019-02-25 21:53] meleu:oh! alright, the rule is about "wait 72 h before promoting Core"
[2019-02-25 21:46] meleu:add back the accepted exception "uploading to unofficial for the sake of utility such as collaborative help."
[2019-02-24 18:04] Kvon:typo
[2019-02-24 18:00] Kvon:Removed the requirement for waiting out the 72 hours for uploading to unofficial. And it's mostly an ineffective incentive under the current ruleset configuration
[2019-02-23 14:14] Kvon:typo
[2019-02-23 15:01] meleu:grammar