User:Wuzzy/Proposal: Featured games: Difference between revisions

From Minetest
>Wuzzy
(Created page with "This is a proposed checklist for featured games. == Proposal == Before a game can be even considered to be featured, a game must fulfil many criteria in a list. There are thr...")
>Wuzzy
(Created page with "This is a proposed checklist for featured games. == Proposal == Before a game can be even considered to be featured, a game must fulfil many criteria in a list. There are thr...")
 
(No difference)

Latest revision as of 22:57, 20 March 2020

This is a proposed checklist for featured games.

Proposal

Before a game can be even considered to be featured, a game must fulfil many criteria in a list. There are three types of criteria:

  • “MUST”: These must absolutely be fulfilled, no exceptions!
  • “SHOULD”: Most of them should be fulfilled, if possible. Some of them can be left out if there's a reason
  • “CAN”: Can be fulfilled for bonus points, they are entirely optional

For a chance to get featured, a game must fulfill all “MUST” criteria and ideally as many “SHOULD” criteria as possible. The more, the better. A game that fulfills all MUST criteria but zero SHOULD criteria is probably not a good candidate. Thankfully, many criteria are trivial to fulfil. Note that ticking off all the boxes is not enough: Just because a game completes the checklist does not make it a good game. Other aspects of the game should be rated as well. See this list as a starting point, not as an exhaustive quality control.

General

  • MUST: Compatible with latest stable Minetest release
  • MUST: The author does not consider the game to be in a experimental development/alpha/beta development stage
  • MUST: There is at least 1 player (who is not involved in the project) that likes the game

Meta

  • MUST: Game name set in game.conf
  • MUST: Game description set in game.conf
  • MUST: Main menu icon and header image are used
  • SHOULD: Game screenshot.png is present and up-to-date
  • MUST: If screenshot.png is used, the aspect ratio is correct
  • MUST: Include a README file that includes at least:
    • Game name
    • Short game description
    • List of relevant links (download, bugtracker, etc.)
    • Pointers to other relevant files (like license)
    • Which Minetest version is expected

Political

  • MUST: It's 100% free software under free software license(s)
  • MUST: License files are included

Stability

  • MUST: No crashes
  • MUST: No error messages from the engine (e.g. missing textures)
  • MUST: No game-breaking bugs
  • MUST: Does not break when changing key minetest.conf settings
  • MUST: If any major setting (like enable_damage) is unsupported, game must deal with it appropriately (e.g. force-disable the setting)
  • MUST: No catastrophic map breakages (entire mapchunk destroyed, entire inventories destroyed, huge amounts of unknown nodes) in the past 2 months
  • MUST: Does not screw up Minetest
  • SHOULD: No major map breakages (many unknown nodes appeared, few or unimportant items destroyed, entities destroyed) in the past 2 months
  • SHOULD: No minor map breakages (unknown nodes) in the past month

Note: All map breakages before the first officially finished version are ignored.

Note: Any map breakage is excused immediately if “disaster relief” (i.e. tools to repair the damage) is available.

Usability

  • MUST: Works out-of-the-box (no weird setup or settings required)
  • MUST: Unsupported mapgens are disabled in game.conf
  • SHOULD: Passes the Beginner Test: A newbie to the game (but not Minetest) wouldn't get completely stuck within the first 5 minutes of playing
  • SHOULD: Has a crafting guide or something similar (unless not required)
    • MUST: If a crafting guide is used, it shows the correct output count
  • SHOULD: Documentation: Reasonably complete manual (or similar) somewhere or the game explains itself
  • SHOULD: All important (!) settings are in settingtypes.txt with description
  • SHOULD: All formspecs use listrings, where appropriate

Gameplay

  • CAN: Passes the Six Hour Test (only applies to sandbox games): The game doesn't run out of new content before the first 6 hours of playing
  • CAN: Players don't feel that something in the game is “lacking”

Graphics

  • MUST: Textures do not induce eye cancer or vomiting
  • MUST: No obvious GUI/HUD breakages
  • SHOULD: Graphical design is mostly consistent
  • CAN: Texture packs are supported normally

Sound effects

  • MUST: Sounds have no obvious artifacts like clicks or unintentional noise
  • MUST: All sounds sound OK with headphones, too
  • MUST: No nodes with unintentional sounds
  • SHOULD: Sounds are used
  • SHOULD: Sounds are normalized (more or less)

Quality Assurance

  • MUST: No flooding the console/log file with warnings
  • MUST: No duplicate crafting recipes
  • MUST: Highly experimental features are disabled by default
  • MUST: Experimental features are clearly marked as such
  • SHOULD: No unknown nodes/items/objects appear
  • SHOULD: No legacy API calls
  • SHOULD: No console warnings

Writing

  • MUST: All items that can be obtained in normal gameplay have description set
  • MUST: Game is not littered with typos or bad grammar (a few typos are OK but should be fixed, when found)
  • SHOULD: All items have unique names (items which disguise themselves as another item are excempt)
  • SHOULD: The writing style of all item names is grammatical and consistent
  • SHOULD: Texts do not look like as if a cat walked on the keyboard
  • SHOULD: Descriptions of things convey useful and meaningful information
  • CAN: Texts are written in clear and (if possible) simple language
  • CAN: Very technical language is avoided (unless hackers are the audience)
  • CAN: Game is translatable

Justifications

This checklist mostly checks simple, formal criteria. It's basically only about getting rid of common mistakes and glaring problems like crashes. Most criteria, like missing metadata, can be fixed quickly as well. Note the list is not exhaustive, so other, more subjective aspects of the game need to be checked before featuring it.

Here comes a list of justifications for each of the sections above:

  • General: Basically the barest possible minimum ever
  • Meta: Just a checklist to fill out all metadata about the game
  • Political: Minetest is a free software project, so it should go without saying that all featured games follow the same values as Minetest
  • Stability: It's fairly obvious, players expect functional games, not buggy games. The map breakage is included here well to encourage to maintain map compability as long as possible. Map breakage is not completely forbidden, however, because sometimes its easier for development to cut some ropes.
  • Usability: This is a fairly straight-forward list to check if the typical usability features of Minetest are used. Although crafting guides are specific to one type of game only, they are extremely common in those games and there's rarely an excuse to not have one. Requiring the player to just figure out all possible crafts by heart rarely ends up well, especially when there are more than billions of possibilities. Working out of the box is a MUST not only because of convenience, but also because the Content DB isn't prepraed for games that require advanced installation instructions, and players will not see them in Minetest. This list isn't nearly complete, there are other areas that this list doesn't test (yet)
  • Gameplay: This list is intentionally short, I don't want to restrict possible gameplay ideas. The idea behind the Six Hour Test is that if it takes you less than six hours to explore everything in a sandbox game, that's a sign the game is too shallow and just a big empty sandbox. I think a good sandbox game needs to offer the player a variety of things to do and try out to not become a big empty sandbox. Exceptions might still aply, therefore it's only a CAN criterion. The sense of “lack” is very subjective, but can be a sign of a problem if many players complain about this.
  • Graphics: Graphics are very subjective, and this list limits itself to rather simple things only
  • Sounds effects: Sound effects are optional (but strongly encouraged), but if they are used, they must definitely not be painful to hear. Very bad sound quality can ruin a game
  • Quality Assurance: None of this affects the game directly, it's more about cleaning up your own code. The idea is that by doing this, you might uncover bugs you wouldn't have seen before
  • Writing: Poor writing and spelling can ruin an otherwise fine game. It makes the whole game look bad and unpolished, even if everything else is literally perfect. Writing not only includes obvious things like correct grammar and spelling, but also useful, meaningful descriptions of things. If a player constantly needs to wonder what item X does, although there's a description meant to explain it, that's another sign of poor writing.