Batch Checking Reject Conditions: Difference between revisions

From Flashpoint Datahub
Jump to navigation Jump to search
No edit summary
mNo edit summary
 
(11 intermediate revisions by 3 users not shown)
Line 5: Line 5:
'''Title: ''' Has a notable significant difference from the logo. (Note: some games list titles that don't match the logo in question; ever played on a shitty portal with the wrong game name? They're more appropriate for Alternate Titles)
'''Title: ''' Has a notable significant difference from the logo. (Note: some games list titles that don't match the logo in question; ever played on a shitty portal with the wrong game name? They're more appropriate for Alternate Titles)


'''Alternate Titles: ''' Match the Title but with more text added. The long form title should always be first and foremost (and the shorter title doesn't need to exist)
'''Alternate Titles: ''' Match the Title but with more text added. The long form title should always be first and foremost (and the shorter title doesn't need to exist). If a game (such as a microsite) contains multiple games inside of it, the Alternate Titles can include these sub-games.


'''Library: ''' A Game in Animations, or an Animation in Games. This may be less relevant later on.
'''Library: ''' A Game in Animations, or an Animation in Games. This may be less relevant later on.
Line 15: Line 15:
'''Tags: ''' Inappropriate tags. Note that ''Extreme'' is a tag now in the form of ''LEGACY-Extreme''. While there may be a lack of tags, as long as there's one general purpose tag and one adult-content related tag for any Extreme titles on top, it isn't rejection worthy.
'''Tags: ''' Inappropriate tags. Note that ''Extreme'' is a tag now in the form of ''LEGACY-Extreme''. While there may be a lack of tags, as long as there's one general purpose tag and one adult-content related tag for any Extreme titles on top, it isn't rejection worthy.


'''Play Mode: ''' Wrong play mode. Remember Cooperative is two+ people working together, and Multiplayer is two+ people working against eachother. So a game of chess that two people can play against eachother, but also has one player vs AI, is "Singleplayer; Multiplayer"
'''Play Mode: ''' Wrong play mode. Remember Cooperative is two+ people working together, and Multiplayer is two+ people working against eachother. So a game of chess that two people can play against eachother, but also has one player vs AI, is "Single Player; Multiplayer"


'''Status: ''' Most of the time this should be Playable. If it's Partial, Hacked or Not Working, there needs to be a Note explaining why. If there isn't, reject.
'''Status: ''' Most of the time this should be Playable. If it's Partial, Hacked or Not Working, there needs to be a Note explaining why. If there isn't, reject.
Line 31: Line 31:
'''Application Path: ''' It should be really hard to fuck this up, but if it comes up yellow on import, it's probably wrong. This is not universally true though, try it first. If it doesn't work via the Run button, reject it.
'''Application Path: ''' It should be really hard to fuck this up, but if it comes up yellow on import, it's probably wrong. This is not universally true though, try it first. If it doesn't work via the Run button, reject it.


'''Launch Command: ''' It should also be really hard to fuck this up. Same applies as above. The biggest offender is when spaces in the Launch Command exist - they need to be replaced with %20, this is '''not''' reject worthy.
'''Launch Command: ''' It should also be really hard to fuck this up. Same applies as above - test first, reject if wrong. The biggest offender is when spaces in the Launch Command exist - they need to be replaced with %20, this is '''not''' reject worthy.


'''Notes: ''' Notes should be short, to the point, with no extraneous nonsense. Examples that should be rejected:
'''Notes: ''' Notes should be short, to the point, with no extraneous nonsense. Examples that should be rejected:
* Non-English notes.
  * Controls that are easy to figure out by hitting random buttons or are explained in game.
  * Controls that are easy to figure out by hitting random buttons or are explained in game.
  * Instructions that are along the same lines.
  * Instructions or walkthroughs that are along the same lines.
  * Shout-outs to persons or companies or political affiliations.
  * Shout-outs to persons or companies or political affiliations.
  * Notes that read like Original Descriptions. People tend to get them in the wrong fields sometimes.
  * Notes that read like Original Descriptions. People tend to get them in the wrong fields sometimes.
* Irrelevant notes about developers or publishers that aren't related to the entry in question.
  * Things that are irrelevant to the context of Flashpoint. Think links to other, related parts to the 'curation' but not the idea of Flash preservation, eg. a financial report.
  * Things that are irrelevant to the context of Flashpoint. Think links to other, related parts to the 'curation' but not the idea of Flash preservation, eg. a financial report.
  * Explanations as to why things are the way they are in Flashpoint that are irrelevant to the average user, i.e. "This game runs in Basilisk because"...
  * Explanations as to why things are the way they are in Flashpoint that are irrelevant to the average user, i.e. "This game runs in Basilisk because"...
Line 63: Line 65:


'''Content Files: ''' Keep your eye open for irrelevant files. Some people upload multiple single-game SWFs in one curation, sometimes. Play the game and see what happens.
'''Content Files: ''' Keep your eye open for irrelevant files. Some people upload multiple single-game SWFs in one curation, sometimes. Play the game and see what happens.
== After Checking ==


If a curation passes all of these conditions, it is a successful check.
If a curation passes all of these conditions, it is a successful check.
If it doesn't, mention the person in question and give them the opportunity to fix it up and resubmit it. If they don't respond within a reasonable amount of time (a day or so), fix and resubmit it yourself.
Once you have finished checking a batch, send a message in the #batch-checkers channel listing the batch you checked and the curations you rejected, if any. Rejected curations should also be reuploaded into #batch-rejects, following the instructions in the pinned post on said channel.
<noinclude>
[[Category:Curation Guides]]
</noinclude>

Latest revision as of 16:12, 14 October 2023

The following is a quick and dirty list of things to fail a curation for, field by field.

Logo and Screenshot: Poor cropping (buttons visible / not enough cropped in logo). Screenshot has things like the Adobe Flash Player window still visible on the edges/too much space on the outside. Logos that are taken from the game itself are not rejection worthy, even if there's a proper logo.

Title: Has a notable significant difference from the logo. (Note: some games list titles that don't match the logo in question; ever played on a shitty portal with the wrong game name? They're more appropriate for Alternate Titles)

Alternate Titles: Match the Title but with more text added. The long form title should always be first and foremost (and the shorter title doesn't need to exist). If a game (such as a microsite) contains multiple games inside of it, the Alternate Titles can include these sub-games.

Library: A Game in Animations, or an Animation in Games. This may be less relevant later on.

Series: Remember, it's a series relevant to web games not to the wider world. A Danny Phantom game would not have the series Danny Phantom but if there was a series of four Danny Phantom games you can use the title of that series as Series.

Developer / Publisher: Notably wrong or missing. It's okay for either to be missing if they aren't listed in-game.

Tags: Inappropriate tags. Note that Extreme is a tag now in the form of LEGACY-Extreme. While there may be a lack of tags, as long as there's one general purpose tag and one adult-content related tag for any Extreme titles on top, it isn't rejection worthy.

Play Mode: Wrong play mode. Remember Cooperative is two+ people working together, and Multiplayer is two+ people working against eachother. So a game of chess that two people can play against eachother, but also has one player vs AI, is "Single Player; Multiplayer"

Status: Most of the time this should be Playable. If it's Partial, Hacked or Not Working, there needs to be a Note explaining why. If there isn't, reject.

Version: Incorrect version. It's okay for this to be empty, though.

Release Date: Incorrect format - remember, the format is YYYY-MM-DD, although just YYYY or YYYY-MM is acceptable.

Language: Incorrect two letter codes. Reference: https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

Source: Incorrect source. The following are all acceptable: Source with no HTTP (newgrounds.com), Source with HTTP (https://newgrounds.com), Source a specific page (https://newgrounds.com/portal/play/696969). An easy way to check if something isn't right is to check the Launch Command compared to the Source, then follow up if there's an incongruence.

Platform: Wrong platform. Should always be Flash in #flash-game-curations. Should always NOT be Flash in #other-game-curations. If a Flash game is running in browser, it counts as Flash. If it's a mix of Flash and HTML, note how much Flash is used - if Flash is a major, required part of the game, it's Flash. If it's a Unity WebGL game, it's HTML5. (Run a Unity game if you don't know what this means, and right click the game - note the menu is different between the two).

Application Path: It should be really hard to fuck this up, but if it comes up yellow on import, it's probably wrong. This is not universally true though, try it first. If it doesn't work via the Run button, reject it.

Launch Command: It should also be really hard to fuck this up. Same applies as above - test first, reject if wrong. The biggest offender is when spaces in the Launch Command exist - they need to be replaced with %20, this is not reject worthy.

Notes: Notes should be short, to the point, with no extraneous nonsense. Examples that should be rejected:

* Non-English notes.
* Controls that are easy to figure out by hitting random buttons or are explained in game.
* Instructions or walkthroughs that are along the same lines.
* Shout-outs to persons or companies or political affiliations.
* Notes that read like Original Descriptions. People tend to get them in the wrong fields sometimes.
* Irrelevant notes about developers or publishers that aren't related to the entry in question.
* Things that are irrelevant to the context of Flashpoint. Think links to other, related parts to the 'curation' but not the idea of Flash preservation, eg. a financial report.
* Explanations as to why things are the way they are in Flashpoint that are irrelevant to the average user, i.e. "This game runs in Basilisk because"...
* Longwinded explanations as to things like hacked files, i.e. "Because XYZ doesn't work without ABC file being hacked, I hacked file ABC". If it can be shorter, make it shorter.

The following are allowed:

* Cheat codes
* Little notes about the game's origin if it was part of a jam (i.e. "This was part of Ludum Dare 23")
* Passwords if the game requires one to start
* Notes about what doesn't work (think online multiplayer, high score leaderboards, parts of the game that otherwise don't change anything)
* Lists of missing files for partial curations

Original Description: This can be a little tricky, as people can write their own Original Descriptions. If something seems off in one, check for an OD on the source site. If it's not there, reject. Don't blame yourself for missing some in a previous batch.

Curation Notes: These are really important, sometimes. If something needs to be done as listed (such as adding a site to exception.sites for Java curations) the notes should be added to your post in #batch-checkers. Remember that Curation Notes aren't imported as the game is, so things like "My first curation" aren't really harmful.

Extras: These should only be relevant to the idea of Flashpoint - preserving web things that would otherwise be lost. Things that shouldn't be extras include:

* Videos that can easily go on YouTube.
* Audio / soundtracks that are available on a site like Bandcamp or Soundcloud, even for free.
* Irrelevant files to the idea of web preservation. We can take a 'reward' like a wallpaper that was included on a site originally, but we don't need the financial report of a company that we're saving a banner ad for.
* Files that are already included. We don't need to have an Extra of photos from a photo gallery if we already have the gallery.

Exceptions can be made on a case-by-case basis.

Content Files: Keep your eye open for irrelevant files. Some people upload multiple single-game SWFs in one curation, sometimes. Play the game and see what happens.

After Checking

If a curation passes all of these conditions, it is a successful check.

If it doesn't, mention the person in question and give them the opportunity to fix it up and resubmit it. If they don't respond within a reasonable amount of time (a day or so), fix and resubmit it yourself.

Once you have finished checking a batch, send a message in the #batch-checkers channel listing the batch you checked and the curations you rejected, if any. Rejected curations should also be reuploaded into #batch-rejects, following the instructions in the pinned post on said channel.