You are free to submit content to MFGG, as long as it's kept within the rules. Any content violating these rules will not be accepted to MFGG.

Version 1.0.4 (last updated on: Jul 06, 2020)

1. General Rules of Thumb

1.1 - Do not steal content from others, as that would be highly unethical.

1.1.1 - We, as the staff of MFGG, have our own ways of determining whether if a piece of work is stolen from others or not, and will punish those who submit stolen work if proven. Anyone submitting stolen content will be banned from the site immediately.

1.1.2 - Please keep in mind that while rips from commericial games aren't technically being done with permission, they are permitted given the (rather obvious) circumstances.

1.1.3 - If your submission is based on someone else's work like edits/revamps, please make sure to include proper credits.

1.1.4 - You are NOT allowed to upload submissions made by other user unless with the author's explicit permission.

1.1.5 - Regardless of if credit was given or not, reuploads or slight modifications of others' work are not allowed, unless you're explicitly given permission by the original author.


1.2 - No inappropriate content, MFGG is meant to be kept SFW (Safe For Work) and generally family-friendly.

1.2.1 - Pornography, fetish art, and anything of sexually explicit nature are strictly not allowed.

1.2.2 - Keep swearing within your submission to a minimum. If you must, include a warning within your submission's description.

1.2.3 - Violence is acceptable as long as a content warning/discretion is provided within the description.

1.2.4 - Preview screenshots and thumbnails should not contain any NSFW content at all. This also applies to violence, and everything else mentioned as being acceptable within limitation.


1.3 - All content should demonstrate basic care and effort. Rushed or useless sprites, as well as rushed, empty games will be declined. Further explanation below. We will not tolerate lazy tile rips yanked directly from YY-CHR or similar applications.


1.4 - All submissions are required to be filtered by their respective franchise except reviews and hacks. We have the right to modify the submission if any of the tags fail to adhere to the content. However, we will notify the user if such action was taken. Repeated failure to properly tag your submissions may result in a warning and temporary ban from being allowed to submit content to the site, although such cases are very unlikely to occur.


1.5 - Animated submission thumbnail and/or screenshots are not accepted anymore, no exceptions.


1.6 - If you have a set of related submissions, it might be a better idea to upload them as one submission instead of submitting them one by one. Don't spam us with a dozen of submissions at once if they can fit in a single submission.


1.7 - All submissions that contain malware will be removed. If we determine that the malware was submitted maliciously, the submitter will be banned.


1.8 - The rules will apply to any submissions after the date the rules are updated. Any submissions prior to the update date will be excluded unless it is under special circumstances.


1.9 - Users who repeatedly submit low quality submissions while completely disregarding the rules and warnings, depending on the severity of the situation, may end up getting banned.



2. Guidelines for Games

2.1 - Any external files required to run the game must be included in its download, with the exception of commonly-used external libraries (such as DirectX or XNA Framework). That being said, certain older submissions might require files and converters that are listed under the Miscellaneous category of the site. Games that require the installation of game creation software such as Clickteam Fusion, RPG Maker, etc will be declined. As a general rule of thumb, the more effort we have to go through to play your game, the less likely it is to be accepted.


2.2 - Games that are packaged with installation mediums are not allowed due to security concerns. In some cases, some installers can easily hide malware, which is difficult to detect until it is already installed in the system - which could be too late to properly deal with.


2.3 - Levels packs, such as those for "Super Mario Bros. X" or similar games, will be declined automatically if submitted as a game. It is best to submit level files under our Miscellaneous category, just please make sure the category is set to "Levels" when doing so.


2.4 - There must be some tangible form of gameplay in games.

2.4.1 - Please try to ensure that your game is at least attempting to be an entertaining and productive contribution to the website. Games with little gameplay, lack of effort, or games made intentionally bad for the purpose of a joke are not allowed. When a game is bad on purpose, it's usually not fun for anyone, and your attempts at comedy will most likely come off as obnoxious.

2.4.2 - Games that lack in proper instructions to play will also likely be declined. If we can't figure out how to play your game, we can't accept it.

2.4.3 - Your game should be possible to complete, and not just a level you can only walk halfway through.

2.4.4 - Demos (or yet to be completed games) must contain at least one full-length level for a developed engine and at least two for a more basic one.


2.5 - No engine clones! This is an extension of our "general effort" policy. For example, a game made with Hello Mario Engine with little to no graphical changes and no additional code will most likely be declined. Basically, if your game is an edit of an existing premade fangame engine that you didn't make, and does not do anything substantial to change the engine's features/presentation/etc., we will not accept it. Using a pre-existing engine is totally fine, but lazy engine edits are not worth preserving on the site.


2.6 - Games should have a defined beginning and end; games that end with an unintentional error message will most likely be declined


2.7 - MFGG now accepts game submissions that are as large as 100 megabytes in size. However, please do not abuse this privilege. Take care to keep game sizes manageable by removing unused resources and by encoding audio to minimize file sizes. For instance, if you submit a simple minigame that uses a 40-megabyte WAV file for background music, we will likely decline the submission for being needlessly large.



3. Guidelines for Hacks and Mods

3.1 - All ROM hacks must be submitted in a patch format, such as BPS, IPS, or Xdelta. We recommend using BPS patches if possible since we have an online BPS patcher that can be accessed from here. If your upload contains a ROM file, it will be declined, no exceptions. If your mod is intended to be run using a real-time file patching method, such as Riivolution, include all necessary files required to run in a ZIP archive - including, if applicable, the configuration file.


3.2 - All hacks are required to specify the base game (the one to apply the patch to), region, and hack types.


3.3 -If you're not too certain what kind of hack types to choose for your submission, this may help you:
  • Cosmetic: The game plays the same but looks different.
  • Tweak: Nearly the same game but with minor gameplay differences.
  • Full Conversion: Games with heavy/full modifications.

3.4 - Same to games, all hacks must demonstrate effort. For instance:

3.4.1 - A very basic cosmetic hack with changes only applying to the player or a few selected enemies will likely be declined unless there is a substantial reason for such a small change.

3.4.2 - Hacks should actually be beatable. Impassable final levels with no ending dialogues/messages will be declined.

3.4.3 - Levels/maps filled with random globs of tiles and/or glitched graphics are not acceptable.


3.5 - To play most hacks, find a ROM file of the base game (this will not be provided for you - consider yourself on your own, there; We advocate dumping your own ROMs) and patch it using either our online patcher or a patching program of your choice.



4. Guidelines for Graphics

4.1 - All graphics submissions must be in a proper format.

4.1.1 - We only accept submissions in lossless file formats (such as PNG and GIF) for sprites and backgrounds. We will not accept JPEG files, unless they are high resolution textures intended to be used within 3D games.

4.1.2 - If you have multiple sheets/backgrounds to submit, we highly encourage you to archive them in a compressed .ZIP file.

4.1.3 - All graphics submissions must be still images. Animated GIFs, APNGs, and any other animated format will be declined.

4.1.4 - We have are no longer accepting Clickteam (or Klik) libraries. That being said, we do acknowledge their historical significance to the website, and thus still keeping old Klik libraries still on the site.

4.1.5 - Sprites must be kept in a 1x pixel format. Any resized sprites will be declined.

4.1.6 - Make sure that your tilesets tile properly before you submit them. Any practical size is permitted for the tiles; 16x16 is a common one.

4.1.7 - Sprites are recommended to be submitted as a set. Any sprite submission with few frames unless noted would likely be declined. We do allow exceptions for sprites that do not fit in larger groups, but would still be considered useful (i.e. visual FX frames, unusual extra graphics, unused sprites, etc.)

4.1.8 - All sprite and tileset submissions must have a clean background, like single colored or transparent background. If your submission is difficult for people to use like a sprite sheet with gradient/textured background, they will be declined.


4.2 - Graphics submissions should be complete enough to be of use to fangame makers.

4.2.1 - A sprite sheet should include enough frames to comprise a complete animation.

4.2.2 - Custom-styled tilesets should generally provide enough content to design a simple level. Quick and small tilesets/sprites will not be accepted unless it's an addition to an existing set or style. An example for this would be additional decoration tiles in the style of SMB3.

4.2.3 - We will not accept submissions that will have no use in fangame development. Even if they are of decent/acceptable quality, sprites can still be entirely useless to others. A perfect example would be a sprite sheet for Super Saiya-jin Luigi holding a shotgun.

4.2.4 - Character sprites have to be of official characters respective to the franchise. Any OC, popular or otherwise will not be accepted (i.e. Bowsette, Hernesto, etc.). Content containing any of such sprites will not be accepted, even if they are high quality enough to be used in fangames.


4.3 - All Sprites must demonstrate that effort was put into them. Recolors or other simple edits of existing sprites will be declined. Sprites that are not too recognizable of the respective character and/or object will also be declined. For example: Barely recognizable SMW Toad sprites that are based off from SMW Mario.


4.4 - Sprite sheets and tilesets should be easy to use; sheets with large amounts of wasted space or obtrusive watermarks will be declined.


4.5 - In the case of graphics ripped from official games, make sure that the graphics are not already available elsewhere on MFGG before you make a new submission. Redundant graphics rips will be declined unless the new submission provides additional content or substantially improved organization compared with any of existing rips.



5. Guidelines for Reviews

5.1 - A review is a critical analysis of the game you're reviewing, so it's a little more substantial than a comment on the page saying "This is great!!! 10/10." When writing a review, you're trying to help other people determine whether or not they should play the game. To that end, you need to be descriptive. Simple descriptions like "GREAT!" for gameplay and "Really really bad" for sound don't cut it. You need to explain why you think they deserve the scores you give them. For example, explaining the basics of the gameplay and then stating what works and what doesn't will help the reader not only get the gist of the game but influence their decision on whether or not to play it. The same goes for graphics and sound - although to a lesser amount, as they aren't quite as important.


5.2 - Ironically, your final words are the first thing the reader will see of your review on the game's page, so it should project your overall opinion of the game. Keep them short and to the point. Your final score should be determined by what you think is best - it does not have to be an average of the other scores or even a weighted average. It could be a score you simply feel the game deserves to have regardless of its individual qualities. Just do not make it too wildly different from the rest of your scores without good reason.


5.3 - All reviews should follow the basic guidelines of proper English. While occasional misspellings or punctuation errors won't affect whether or not if we will accept it, poorly written reviews will be declined regardless of your actual criticism.


5.4 - Comment rules still apply in reviews - don't be a jerk, be mature and unbiased in your analysis, and do not make reviews simply to troll the game's creator. Beyond that, feel free to be yourself in your review, injecting it with your humor and personality to make it an entertaining read.


5.5 - Don't even try to submit reviews outside of the 1-10 score range, they are only permitted on special occasions. Any of these reviews will be automatically readjusted.



6. Guidelines for Tutorials

6.1 - Tutorials should generally demonstrate an element or elements from games. MFGG also accepts general-purpose tutorials that demonstrate general-purpose game design information - for example, how to use external files in Game Maker or how to make an action RPG in Clickteam Fusion 2.5.


6.2 - We will allow tutorials for simple concepts if designed in a user-friendly and helpful manner, but tutorials for anything as simple as scrolling, which in most programs is one or two lines of code, will not be accepted. Simple problems like these are best addressed on the forums.


6.3 - Tutorials that focus on programming should be user-friendly and reasonably easy to understand. Such tutorials should teach proper coding habits and sufficient commenting that users can understand how the code works.


6.4 - Tutorials that are riddled with bugs are not allowed. Double check your work before submitting.



7. Guidelines for Sounds

7.1 - Sound files must be as high quality as possible. We will not accept poorly recorded or fuzzy sound effects that would not be useful in fangames.


7.2 - Please submit all recorded music in .OGG format. .WAV music can take a huge chunk of storage and they are not allowed. .MP3 format are highly discouraged due to compression loss.


7.3 - All submitted custom music must be your own composition and not taken from another website, even if you cannot find the original composer's name. This obviously does not apply to rips.


7.4 - The usefulness rule for graphics (see rule 4.2) also apply to sounds. The staff will determine which sound rips would be useful in fangames or not, but generally, most rips that aren't from very obscure games should be fine.


7.5 - We do not accept rips of licensed songs from video games, all music rips must be music that was originally composed for the said game.



8. Guidelines for Miscellaneous Files

8.1 - The Miscellaneous section is designed specifically for resources that prove helpful in either running or creating games. Feel free to submit resources such as fonts, 3D Models, system files, but not things like screensavers or wallpapers.


8.2 - Saved level files are also permitted in this category - when submitting levels, please put which game/level editor is it for in the description. Similar to hack rules, levels must demonstrate effort. For more details, please see Rule 3.4.



9. Other Things to Consider

9.1 - Remember that submissions must be checked by multiple main site moderators before they can appear on the site, and since MFGG staff have lives outside of the site, it may take a few weeks before a submission is accepted or declined.


9.2 - If you have any questions or issues with the guidelines or the interpretation thereof, please send a message to a main site moderator or administrator.