3DGC:Design

3D Game Comparison - Game vs. game. No hype; just facts.™

Jump to: navigation, search

This page is MediaWiki-specific but see http://tnlc.com/eep/compare/database.html for general design ideas.

Originally designed for a database, conversion to MediaWiki presents some problems:

Contents

Classification

There are different ways of designing this "database"'s classification system using MediaWiki.

Categories

The most obvious is with categories. Unfortunately, these can quickly clutter up the bottom of pages if there are too many (if categories could be displayed in an organized way instead of by declaration or alphabetically...) Categories could be named like namespaces (i.e. Game:Tomb Raider) but why not just use namespaces then to reduce having to type the link (Category:Game:Tomb Raider vs. Game:Tomb Raider)?

Namespaces

Perhaps the next most obvious is with namespaces for games (game:), companies (company:), engines (engine:), characters (character:), effects (effect:), etc.

Subpages

Less obvious is using subpages (games/Tomb Raider) but they may be easier to manage than namespaces, although I'm not sure how DPL (see next section) can handle them. Additionally, subpages are automatically transcludable via template calls ({{/Tomb Raider}}).

Pages

Even less obvious is just using pages (Tomb Raider) and, with an extension like Dynamic Page Lists (DPL), categories really aren't necessary. Not having categories means not duplicating same-named pages/categories (or redirecting to one or the other) but explicitly require an extension like DPL or embedded Special:Whatlinkshere lists.

Wiki markup comparison

System Markup Advantages Disadvantages
Category/Page
  • Less typing
  • Default classification system with auto-generated lists
  • Mixing same-named articles and categories causes redundancy (redirect to categories only?)
  • Games with simple names (like Rune, Dirt, etc) can conflict with object names (like a "rune") or surface types (like "dirt"); engine names like Steam and Source can conflict with the "steam" effect and "source" of something (though rare; or short for "source code"). Lowercase names can help alleviate most of these conflicts but not these:
  • bow action -> bow weapon
  • Camera pan (view pan, camera pan?) -> object pan (pans?)
  • sprite (computer graphics) -> sprite (fantasy creature)
  • level (environment term) -> level object
  • map (environment term) -> map object
Combining a noun (object) with its verb (action) on the same page may just be easier.
Namespace
  • Name conflicts less likely
  • Less need to use complicated/confusing Semantic MediaWiki to establish relationships (links between games and features)
  • DPL can list links to specific namespace/subpages vs. to a page that can mean different things (noun vs. verb, action vs. object, etc)
  • More typing
  • Must use extension(s) to generate lists
Subpage

Extensions

Note: DPL and SMW appear to cause pages to load slower (lots of server calls, flashing the web browser statusbar like mad most of the time).

Dynamic Page List (DPL)

Using DPL, lists of pages linking to other pages (as well as pages in categories and namespaces) are possible. This may be the best option that will allow all classification schemes to be included/used.

Semantic MediaWiki (SMW)

This extension is similar to DPL in outputting lists of pages in categories and namespaces, but also allows more complex relationships between things. Unfortunately, it's a lot more complicated to use (even moreso than DPL), which makes it a last resort. Programmers still code for programmers, apparently...even if they claim to be "semantic"--try being "intuitive" and "user-friendly" instead.

Comparison table

So far I've tried 2 extensions for the comparison table. One (TemplateTable) is easy-to-use but very limited and the other (DPL) is more difficult to use but more customizable (yet still not enough for my needs).

Personal tools