SSRG/Sonic Retro Documentation Guide for Hackers of Sonic Games

I feel that in order to submit hacks with parts of code done by other hackers, I should cite my sources to notify that I can't take all the credit. So, I am proposing the creation of a new reference style, the SSRG/Sonic Retro documentation format. This style of documentation is geared towards split and text disassemblies, and portions of ASM code done by other hackers and researchers. Essentially, SSRG/Sonic Retro Format will cite parts of code as given in web articles and text disassemblies in a manner that is similar to MLA. This, in effect, will allow future hackers to give credit to others without the careless plagiarism of others' work, which is a main cause of beginners (and I use that term, because I don't know a nicer way to label them) being expelled, or banned, from SSRG or Sonic Retro. I want to make this to establish and enforce a policy against plagiarism. I've seen members rant about hackers who forget to give credit to the other hackers' contributions. Ok, enough tangents, here is an example of works cited entry that must be put at the end of a game manuel or contest entry:


Citation of a disassembly file (.asm) for an orginal Sonic game:


Naka, Yuji and Naoto Oshima. "Sonic the Hedgehog." sonic1.asm. Rev. 00. Split Disassembly. Sonic Team. Tokyo: Sega, 23 June 1991.


The skeleton of the entry is:


Creator's Last Name, First Name and Co-creator's First and Last Name. "Title of Original Game." filename.asm (don't forget to italicize). Rev. 0X (the common .bin ROM revision number is usually 0, followed by a number). Type of disassembly used (Split or Text). Producers of the game. City of the game published: Publisher, Date of release (if region is (W) on ROM [if split disassembly is used], use earliest public release date).


Now for every disassembly file, whether it's text or split, should be noted as well. So here is another example for this situation:


Citation of a Split Disassembly:


Hivebrain. Sonic 1 Split Disassembly. Compressed Zip Folder. United Kingdom, June 2006.


Skeleton:


Creator's Username. Name of Split Disassembly. File Format when Downloaded. Country of Origin, Date of Initial Release.


Citation of a Text Disassembly:


drx. Sonic 2 Early Prototype. Compressed Zip Folder. Poland, 14 July 2007.


Skeleton:


Creator's Username. Name of Text Disassembly. File Format when Downloaded. Country of Origin, Date of Initial Release.


The original dissasembly citation always goes first. Then the split disassembly and text disassemblies, if applicable. Well, that's all the time I have, right now. Next time, we will talk about citations of code segments in a web article. Staff, I hope you take this into consideration. I would love your feedback about this new documentation style. Until later tonight, SMN is out, peace!

 

Your idea stands out good in my opinion, but the one thing I cannot get my head around is why (out of all forum sites related to Sonic rom modification of any kind) ...should SSRG be the only one to forcibly make sure credit is given where necessary, because the poster (or "hacker" as you refer to) is too lazy or inconsiderate to do so?


It seems like a waste of time modifying and altering the site for that.

 

Perhaps I should have called this the "SSRG/Sonic Retro Documentation Guide for Hackers of Sonic Games". However, I'm afraid to call it that, because I'm afraid that it will be something to heckle about to others. Put it this way, what if someone (say a moderator) criticized it for unoriginality, because of its similarity to MLA? What kind of Administrator will step up to give high ratings on it? Ok, enough questions, time to wrap up this guide.


If a section of code, an entire article, or a tutorial is used to modify the code, it would be unwise to not cite these sources in leiu of the above sources. Take Puto's SCHG How-to on fixing the Sega Sound, for example. Even though he's rarely around anymore, it might be considered unjust to not give him credit. So, here is how you enter the citation of the example source:


Puto. "SCHG How-to:Fix the SEGA Sound." Sonic Community Hacking Guide. Sonic Retro, 25 June 2010. Web. 12 Sept. 2010.


Original Author. "Title of Article" Database (if Sonic Community Hacking Guide is not considered a database, let me know). Provider or Domain of Location, Date Last Modified. Web. Date Accessed.


Note: If the citation takes more than one line, a hanging indent must be used every other line after one line is taken up.


Video tutorials are essentially important, especially if you are a visual learner. We will take one of Qjimbo's vid tutorials as an example:


Sonic 1 Split Disassembly Setup. Dir. Qjimbo. Video Tutorial: Setting up a Split Disassembly. Sonic Stuff Research Group, 24 Dec. 2004. Web. 12 Sept. 2010. <http://sonicresearch.org/vtut?vtut.s1.setting_up.flv>.


Title of Video Director or Author's Username. Site/Film Name. Sponsor. Date Created of Last Modified. Web. Date Accessed. <url if needed>.


Well, there you go. that wraps up this guide. And, I have decided to post this guide on Sonic Retro, whatever the cost may be.

 

This shit is so bad that it makes a floor of puke more interesting than this.

 

Here's the problems we face...


Credits can be given by the main director of the project, provided that person sees fit, if they feel inconsiderate enough to not thank the people who may have helped in some form, then there's nothing really anyone can or should do, we'll understand that they're just jerks and move on with life.


Credits can also be given on the guides and tools that are handed out, and there's nothing (on most, if not all) saying that people have to give credit for using said tools and guides, it has been provided publically for anyone to use at any time they wish from the kindness of the writor's heart, therefor we should see no reason in fourcing them to give credit.


There's no way of proving that any code did actually come from said guides, or that certain tools have been used, so you cannot really identify any of this.


No-body wants to fill out forms to show people some work they've done, really you'd just be creating more trouble and hassle than it's worth.


A nice idea, but maybe not for here.