[url=http://mfgg.net/index.php?act=submit&param=01]The new submission guidelines[/url] went live a couple of days ago, and you might have noticed the announcement in the most recent mainsite update. And if you didn't notice, you'd be wise to take a look at the updated guidelines - they exist to help MFGGers submit quality work. Here's a recap of what's new or different: [b][u]Games[/b][/u] [list][*]The guidelines for submitting games are a bit tougher. Rushed edits of third-party engines, as well as games that end in an error message, won't be accepted. Games needn't be perfect, but we will decline games that are badly rushed or hopelessly broken. [*]The old guidelines were written when MFGG's size limit for games was much smaller than it is today. The new rules basically say, "Use high-quality audio and graphics if it boosts the gameplay experience, but don't waste space needlessly." [*]The Games section now expressly permits games that require commonly-used external libraries such as DirectX or XNA in order to run. Previously, the rules suggested that MFGG would only accept games that either run on their own or use just the plugins found in the Miscellaneous section (typically, the DLLs used by Clickteam-based games). On the other hand, if your game uses an obscure library or plugin, you still need to include it with your game - or at the very least, a static download link to the plugin your game requires. Moreover, MFGG is unlikely to accept games that require a separate program to run, such as SMBX episodes. In other words, if you want us to accept your game, the QC staffers need to be able to play it.[/list] [b][u]Graphics[/b][/u] [list][*]Originally, the graphics section was devoted almost exclusively to Clickteam libs; so much so, the heading was previously known as "Guidelines for Submitting Sprite Library Files". The new guidelines are designed to be relevant to both sprite sheets and libs. Since we get only a handful of libs every year, the specifications for libs have been loosened. While libs are no longer as popular, we'll still accept libs as long as they're well-made and relatively complete - the same standard we apply to sprite sheets. [*]The new guidelines place a bigger emphasis on submitting complete graphics: Incomplete sprite sheets will generally be declined. Custom tilesets should include any variety to make a simple level. The same goes for character sprites: If you make a single frame of Yoshi, copy ten palette swaps of the original Yoshi, and submit it, it will be declined because it's not enough frames to make a full animation. Similarly, we'll decline sheets where you spent two minutes recoloring someone else's work. Edits will only be accepted if they're carefully made and are useful to fangame makers. [*]There's finally a note about using space efficiently in sprite sheets. Try to optimize your sheets to cut down on vast expanses of blank space (and no, writing "BLANK SPACE!" in 72-point Comic Sans font doesn't count), and avoid obtrusive fan characters and watermarks, especially when they jut into the meat of the submission. [*]The old rules never reminded rip submitters to ensure that their submissions aren't redundant.[/list] [b][u]Other stuff[/b][/u] [list][*]Zero Kirby wrote some handy tips on writing helpful reviews. The old guidelines said nothing about reviews. [*]Tutorial guidelines are now a bit more indie-friendly. Previously, the guidelines encouraged tutorials to use Mario sprites, which is often discouraged today because of engine abuse. Engines still need to demonstrate concepts useful to fangame makers, but if they're helpful to indie developers, that's cool too. [*]We now expect tutorials to include sufficient commenting and to teach proper coding habits. Don't submit tutorials based on Drag & Drop! [*]I added a brief word on using the commenting system in a constructive, appropriate manner. [*]I also added a blurb about the reality that QC staffers have real lives and sometimes can't approve your submissions instantaneously.[/list] None of these changes represent a substantial shift in the way the Quality Control staff approves and declines submissions. Instead, these adjustments are designed to codify some of the "unwritten rules" that have built up over the years so that new members will have a firmer grasp of what makes a submission useful. It should also cut down on complaints of different QC staffers calling "balls and strikes" in different ways. The new guidelines are designed to be concise yet reasonably comprehensive. If we listed every possible reason a game might be declined, the submission guidelines would stretch on for several pages and no one would ever read them. As every submission is unique, there'll always be a certain amount of subjectivity in evaluating whether to accept or decline a particular submission. These rules should help reduce the degree of subjectivity, though. If you have any specific questions about the new guidelines, don't hesitate to buzz a mainsite administrator (like me!). If there are any major issues with the new guidelines, please let me know, but since updating these rules requires tinkering with the HTML, we're unlikely to change them without a good reason, at least for the near future. Lastly, here's a copy of the old submission guidelines, just in case anyone wants to compare:

Do you think the new comment rule disallows pure negativity and harshness? I keep on seeing negativity that Double Agent Luigifan made, so I think you can disallow it, too.

Negative critique isn't against the rules, and never has been. In fact, such criticism is often the most valuable kind of feedback for game makers. But if a comment is flaming or trolling someone ("This game stinks. Go die in a fire, you @#$% @#$%^!"), it will be removed. Since it's currently impossible for mainsite moderators to keep track of every comment posted on MFGG's thousands of submissions, you can help us out by reporting comments that are clearly breaking the rules.

Theres a difference between blunt and direct critique and just being a douche, if you say soemthing's bad you HAVE to go into detail why it's bad, you can't just go, "This @#$# is horrible". You have to do something more along the lines of, "This is a bad game, *and explain why it is and what the creator could possibly do to improve it"

Alright, I'll get hold of the report button and trash those flaming/trolling comments! Thanks Vinny.

[quote]We now expect tutorials to include sufficient commenting and to teach proper coding habits. Don't submit tutorials based on Drag & Drop![/quote] Does this mean that you can't submit MMF2/TGF/etc. tutorials? Because they're still useful tools and the event editor can be commentated.

[quote="Pedigree"][quote]We now expect tutorials to include sufficient commenting and to teach proper coding habits. Don't submit tutorials based on Drag & Drop![/quote] Does this mean that you can't submit MMF2/TGF/etc. tutorials? Because they're still useful tools and the event editor can be commentated.[/quote] Of course you can still submit those, as long as they are properly commentated. Perhaps "GM" should be added to that last segment though, since it is a GM specific dialogue. and "Drag & Drop" events in GM are really limited in their functionality.

Don't worry - we still accept Clickteam tutorials (and libs) as long as they're reasonably useful and well-made, just as we would accept tutorials for other platforms that meet these standards. I cited the Drag & Drop example because it's a coding faux pas in GM, since DnD is highly inflexible, hard to modify, and impossible to copy to text format. In regards to commenting: Include enough commenting so that your code is understandable. You're trying to teach users how to do something, not confuse them.