last updated 03/11/2011 - in case of problems or suggestions, please
contact the moderators.
for discussing these rules, please use
this thread.
CSDb release standards for cracks
The following rules were collected and assembled by the CSDb staff, with help
and acknowledgement of a few people which represent the active cracking scene
of today and/or have profound knowledge of the cracking scene of the past:
Preamble
In the past CSDb always tried to keep the philosophy "we shall not judge
release quality" and we relied on the self-awareness of our users to do just
that. However, the recent months showed us that this approach doesn't work
anymore for the cracking scene. Since there is no more "authority" (such as
countless disk mags in the past) that reviews and ranks cracks, which is
somewhat fundamental for the competitive nature of the cracking scene, more
and more sub standard releases surfaced, some of which we do not consider
scene releases at all anymore. And our users started to question wether all
and everything is considered a scene release these days, and demanded us
to put an end to all the flaming and crap releases.
So these rules were designed, loosely related to the old firstrelease rules
(which were valid for almost 3 decades) with some more stuff added, and some
other stuff changed to reflect the nature of CSDb (for example we do NOT only
consider actual firstreleases, nor do we keep out "fake" releases per se). In
some ways our rules are a lot less restrictive, and in other ways we demand
more. However we tried to make sure that stuff that we think is "ok" does not
clash with these rules, and that they aren't terribly unfair to newcomers
either.
We didn't design these rules to discriminate against newbies (or anyone else),
but instead we think that rules like this are a necessary element in the
learning process of every cracker.
Goals
- Motivate people to do more quality cracks. Quantity is nothing, quality is
all.
- More tension in the cracking scene.
- Reward skill and effort
- The best cracker should win. not the loudest, not the most annoying, not
the most persistant.
- Getting rid of rerereleases, 100%,101%,102% versions and similar nonsense.
- Motivate crackers to release games that were never released before and make
better versions than anyone before
And last but not least:
- Motivate people to upload more old cracks
General Rules
These rules are only valid for cracks (by our definition) released after
1/8-2008. whatever was released before must only comply with the old rules.
However, all old rules also apply to new cracks, with the following
additions and changes:
Definition of a crack
Until now a crack was loosely defined as "unauthorized modification" of a
program. these standards extend the definition as follows:
- A crack MUST be preceded by a crack intro, with the only exception of
tools, which most people prefer without intros.
- "frozen" games are NOT considered cracks.
- The crack MUST have substantial value over the original. linking
your intro infront of some freeware game aint cut it. We atleast expect
decent training and packing. If a game was released before, subsequent
releases must have substantial value over previous releases.
- The appearance of the game must NOT be altered in any way. No changing of
ingame texts into your groups name, no altering of the hiscore tables.
Altered hiscore tables are acceptable if the game has an option to restore
the original content.
- If the game has a hiscore table, we expect a hiscore saver. Hiscore savers
MUST be disabled when trainers are active.
- If there are docs available (which we might check on the net) then we
expect them to be included.
- Cracks should be pal/ntsc fixed, unless the game itself does not allow it.
Obviously, when the crack is pal/ntsc fixed then the intro MUST be fixed
too. Please notice that there is a strong emphasis on "should be fixed",
and games which are trivial to fix (such as many "oldies") MUST be fixed.
Also notice that unlike the traditional firstrelease rules, we demand *all*
cracks to comply with this rule, including previews and the like.
- Ingame text MUST be translated to english, with the only exception beeing
games which contain huge amounts of text. (such as adventures)
- Any crack added to CSDb must be a valid release according to these rules.
Whatever else will get deleted. "Oldschoolers" please notice that we do
NOT make a difference between "full" releases and "previews" etc as it is/
was commonly done in the firstrelease scene. We think that these days every
release deserves the same effort, preview or not.
- So called "recracking" is generally and strongly frowned upon. For this
reason each crack should somehow tell what kind of original was used (tape/
disk/cart ...). Recracks are only accepted if no original is available and
all existing cracks have bugs. (If in doubt, search harder for an original
or crack a different game.) In this case the release MUST state what other
crack was used. Credit where credit is due!
Notice that this rule was the most objected one by our reviewers, who most
of the time would like to see recracks completely banned. However, we don't
want to do that (yet) - but to stress it again: recracks should be a rare
exception!
- Games made with game makers such as SEUCK (Shoot Em Up Construction Kit),
GAC (Graphic Adventure Creator), RDK (Racing Destruction Kit), etc. are NOT
considered valid releases.
- Games that are written primarily in basic will NOT be considered a valid
release, unless significant effort has been put into it, such as translating
huge amount of text. Classic commercial titles such as "pirates!" are an
exception to this rule, while most magazine type-ins are not. if in doubt,
WE decide.
- Generally every group can only release ONE version of a certain release.
further updates are prohibited and will get deleted (see exceptions below).
The Grand Exception
If a crack is accepted at one of the C64 related FTP sites index by pokefinder, it will always be counted as a valid release on CSDb.
Note that uploading alone doesn't count, the release must be accepted by the particular site and be moved out of "incoming" for everyone to download.
Since the CSDb staff will not actively (or even regulary) check if releases are valid, but may need to do so on request of a user, you must add a valid download link (not pointing to "incoming") until 48h after adding the release entry. For releases of recent commercial games it is acceptable that you delete said link immediatly again (so it will not be publicly visible, but staff members can still see it if needed). Entries without such a link may get deleted without notice, don't complain.
This is an intentional "loophole" in these rules. if those sites accept a release, then we must consider it being a valid scene release, no matter what our own rules say. (Keep in mind though, that those sites by themselves may have rather strict rules on what they accept and what not)
The 48 hour rule
- After releasing a game, group A has 48 hours to release a possibly updated
and/or fixed version of the same release, and during this period is also
allowed to "silently" update its CSDb entry. Any updates after these 48h are
prohibited and will get deleted and the original file restored. Please notice
that this opportunity is meant for trivial fixes, such as a wrong filename, a
typo in a scroller etc, NOT for uploading improved versions (like additional
trainers). Also notice that if we notice that this rule will get abused we will
remove it completely. As a countermeasure every time a "silent" update is made
it must be stated in the comments, and explain what was changed.
- If a second group B releases a better version within 48h, it will "steal" the release
from group A who originally added it and the previous version from group A will
get deleted. then the clock will get restarted for group B
- If during these 48h someone is able to point out an older release of the same
game (which must exist in CSDb, so an entry must have been created and the release
must have been uploaded) which is better than the version that was just released,
the new version will get deleted.
- If within 48h anyone can prove that a release is a recrack, although the release
itself doesnt say so, the release in question will get deleted.
- If group C releases an even better version AFTER the 48h expired, it will NOT
"steal" the previous release, and both versions will stay.
How we judge if a release is "better" than another
- Onefiling. We expect cracks to be one in one file if it is possible.
- Size. Good packing is expected (that includes levelpacking multiload releases)
- Generally releases should work on a stock C64 with 1541 drive, everything else
is a bonus.
- The size of the main file should not exceed 202 blocks so it can be loaded
by stock kernal load.
- Filecopyable. track/sector loaders should be replaced so the crack can be
copied file by file.
- Amount of trainers. notice that so called "double trainers" will make your
release worse, not better. Every double trainer will DECREASE the number of
trainers we will count for your release. (so a release with "+2" as in "in-
finite lives player 1" and "infinite lives player 2" will not only be counted
as "+1", but instead be counted as if it had no trainer at all)
- Translation to english. Translating lots of text is a huge effort which will
always earn you a big plus. If there is only a little bit of text, such as a
score display and "get ready" stuff, then a translation is EXPECTED.
- Bugs. Bugs that exist in the crack but which do not exist in the original
will earn you a big minus. On the other hand, fixing bugs which are in the
original will give you a plus.
- Releases made from a real original will always count more than recracks,
obviously.
Strategy Guide
For those who are new to the cracking scene, here are some hints:
- Before you start with a crack, check what other versions of that game
exist. Don't crack it if you dont think you can make it better than all the
old versions. Do not rely only on CSDb for reference wether something has
already been released. There are a lot of games which have been released
that are not added to CSDb yet. Some sites you may want to check are:
Banana Republic - ftp://ftp.elysium.pl/
Antidote - antidote.hopto.org:23 (telnet BBS)
Gamebase - http://www.gamebase64.com
C64Games - http://c64games.de
The List - http://www.atlantis-prophecy.org/onslaught/thelist.html
- Use the original game (many are available for download on the net).
Recracking is generally frowned upon. Generally only consider extending or
fixing someone else's crack when no original can be found and existing cracks
all have flaws. And even then, maybe still find another game.
- Spend time on testing your release. Typically that would be considerably
more time that it took to make the actual crack. You are in no hurry, so
make sure everything works correctly.
- If you are into competition, wait until some group releases a game, and
then try to make a better version.
- If you want to make a first release, try to make it the best version ever,
so no other group will be able to beat you in 48h
- If you think all these rules are silly and you couldn't care less, you might want to consider uploading your release to one of the sites indexed by pokefinder.
Final Words
These rules will get updated and finetuned over time, especially when we see
that someone is trying to exploit them and find loopholes. Please realise that
WE have the final word, and that WE decide wether a certain exception on the
current rules will be made or not. if in doubt, choose a different release
platform than CSDb.
to make it clear once and for all (hopefully):
- the quality of the actual game is irrelevant, these rules only apply to the quality of the crack itself.
- moderators will not actively check all and every release. if there is a release that you think should not be here because it violates said rules, use the "discuss this release" feature and post why it should be deleted and the moderators will then verify it and take care of it. telling the reason in public is important so the releasers know what they did wrong and what they should improve. "OMG THIS IS CRAP" is NOT a valid reason, just like it is irrelevant who made the release in question.
that said, please understand that moderators will most likely ignore any requests or complaints related to releases which should be removed, unless they are posted in the forum with a valid reason. this is neither a witchhunt nor a bitching contest.
Last not least, nitpicking on the wording and interpretation is not tolerated.
If in doubt, ask and we might update the rules to make more clear what we
mean.
|
|
|
