Developer's Code of Conduct
The 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
- State your intention to work on games on the game page.
- As soon as you have a plan for your set, post it on the forum.
- Keep your work free from unwelcome concepts.
- Use protective code preventing potential cheating and exploits.
- For set revisions, follow the revision policy.
- Resolve tickets, and leave notes each time you do.
- Once you publish a set you are giving it over to the community to be reviewed and reworked over time.
Before you Beginlink
If you find a game you'd like to create achievements for, find out:
Is the game present on the database?link
If no, ask for it to be added on Discord #help-me or on our forums and some dev will add it for you (or just add it if you're already a dev). It's essential you choose the right ROM(s) to work with, see working with the right ROM. If you want to work on a ROM hack, check the achievements for ROM hacks doc first.
If yes, good! Now check if it already has existing achievements.
Does the game already have an achievements?link
If yes, there is an existing set, don't give up. You can still improve it (add to it, remove from it, rework it, make changes to titles and images, etc.), but you'll need to go through the revision process.
If no, look deeper. Often there are multiple entries in the database for the same game under different titles. When you know there's no existing set for the game you just need to check if there's another dev working on the game.
Note: Only one achievement set is allowed per game per console. This is true in cases of existing official revisions, official and unofficial fix patches, and over language versions. For details see working with the right ROM.
Is another developer working on the game? (And how can you find out?)link
First, check the comments on the game. Then the game's official forum topic's recent posts. (You can find the link on the game's page.) You need to check to so we can avoid conflicts between multiple devs working on the same game at once without knowing about it.
If yes, it may be possible that the set has been abandoned (has been not worked on for ~2 months or more). Or maybe a developer is still at it. Either way, if you are interested in taking it over or joining the team you must post your desire to work on the set in the forum or in the Discord #dev channel, and then work it out with the existing developer. If the set is abandoned and dev doesn't answer you within a few days, you can go ahead. Rule of Thumb: When in doubt, consult a mod in Discord or send a message to RAdmin.
If no, great! You're free to work!
So, the game is free for you to worklink
Before doing any work you must:
- Leave a comment on the game's page declaring your plans on a set for it.
Once you've done this the set is locked down for you to work on it. If the time comes that you're no longer working on a set, please remove your declaration of plans.
As soon as you have a development plan:
- Post it on the official game's forum topic, so the community can leave suggestions and provide feedback. Be open!
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.
Basic Achievement Design Guidelineslink
You can (and should) be as creative as you can, but there are some concepts that are NOT welcome, such as:
- Achievements that require glitches (acceptable in Bonus sets).
- Achievements that require two players.
- Achievements that require perfection all game (maybe acceptable in Bonus Sets).
- Achievements for dying (simply), or playing bad without any purpose.
- Achievements with NSFW content in text or image.
- Achievements popping frequently with little effort from the player.
- 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.
- Achievements that require excessive repetitive grinding, such as reaching level 99 in an RPG, for no meaningful purpose (maybe acceptable in Bonus Sets).
- Achievements that 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.
- "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.
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, Game page information and images, and leaderboards cannot be added until you are a full developer.
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.
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 a set or 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, ideally within a week. This is important as the problem is fresh in the player's mind and you can use them to help discover and resolve the problem.
While resolving tickets, leave a brief summary of how you resolved the player's report. 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.
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 achievment.
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-01-04 20:04] Kvon:added a clarification about set ownership responsibility.
[2018-12-06 11:08] Kvon:This was intended to be removed in my last edit, (see comments) but was not
[2018-11-25 06:37] Kvon:removed "or allow two players where it could give an advantage". To allow for achievements with normal co-op to be acceptable. Added a line about concept wiggle room.
[2018-11-13 18:07] Kvon:updated tl;dr "state your intention" to match the rule in later in the doc.
[2018-10-22 14:51] Kvon:added rule we forgot to add about two player achievements.
[2018-09-17 17:56] meleu:case sensitiveness
[2018-09-10 15:17] Kvon:typo
[2018-09-09 21:11] Kvon:clarified unwelcome concepts, added info about 1 rom per console per game. Made links to working with the right rom
[2018-09-08 12:19] meleu:an item about "set ownership" on the TL;DR version.
[2018-09-08 07:20] meleu:moved "Unwelcome Concepts" to be the first item in "Basic Achievement Design Guidelines"