:Really, I also appreciate how tidy and organized you've been, even finishing the job with this enlightening summary, well done, this was a tough job ^^

+

:About the "deletion process", there are two possibilities: either redirect the pages as you suggest, or completely delete the titles; I'll go with the former, since those titles have been around for a while and they may have been linked from external resources; this way we're also keeping their history browseable by everybody.

Revision as of 17:23, 16 July 2013

Classification method

Currently, games are first divided in Free/Reimplemented/Commercial/Emulators/MMO and only then they are grouped by genre. I'd like to see the opposite, i.e. first group by genre (also in Template:Games navigation) and only inside each genre make the distinction between native/emulators, free/commercial and whatever distinction better suits that particular genre.

+1 -- when browsing games, one would logically search by genre first. The genre classification scheme is more consistent with the other Common Applications pages, too, where applications are organized by type first, then by UI/platform (graphical or console). -- pointone 12:25, 4 March 2012 (EST)

In my opinion the classification is really confusing (not very KISS! ;)) It's hard to guess whether a game should belong to Native - Reimplemented or Native - Commercial, or MMO (some of them are also commercial). There is a Humble Indie Bundle section, but a game cannot be categorized this way, since all HIB games are also sold by other means (like Steam - which also has its own section). Besides Native - Free is sorted by genre, but it's the only one. Some entries use the Application template, other do not, some entries are not even games (see the Quake part). All this can be treacherous because if you look only in the wrong sections, you might miss some games. So you end up using the browser search function... In the end sections become rather useless. My suggestion:

(Using # only supports simple lists, if you want to nest something you have to use <ol> and <li> for the whole list; anyway in this case it's easier to keep it simple and hard-code the numbers ;) (fixed, btw))

2/3. Ok, now I get what you mean with the Game template, and of course I agree with the observations you make in 3. Just to mention it, a further alternative could be using a sortable table with short labels representing the genres, if they are only a few (broad genres):

However using genre tags or a table would require modifying each entry in the list (big, almost irreversible job), so I'd say let's first try to restructure the current list by using simple sections for the various genres and see what it looks like after the job is finished; the games whose main genre is so hard to define can be temporarily put in a Miscellaneous, Other or Mixed section, and we'll see how many of them end up there: if they are not so many I think we can find a simpler solution than using tags (e.g. just arbitrarily choose one of the genres they would belong to). For the genre titles we can take inspiration from wikipedia:Video game genres.

Actually I was first thinking of a table, but I wasn't aware that MediaWiki had native support for sortable ones. Unfortunately this does not really solve the issue, because we cannot limit the number of genre. The Wikipedia article is endorsing my point: it lists 46 genres! I do not think it is possible to have a finite number of genre columns. Is there any chance a filter table would be available too? I mean the one with an edit field in the header row. This way there would be only one genre column with arbitrary, yet normalized content, which the reader can filter. That would be a much better solution in my opinion. And yes, it would require modifying the complete article, but I think it is easily feasible using external tools like Emacs and/or AWK (I'm currently editing this page from Emacs). -- Ambrevar (talk) 16:26, 5 July 2013 (UTC)

Of course the table method should make use of only a restricted number of categories, say the top ones in wikipedia:Video game genres; yes, it wouldn't allow people to add more categories (easily), this could be seen either as a disadvantage or an advantage... AFAIK there's no way we can have a filterable table :(

Anyway you've probably overlooked a bit the last part of my post: since with the tag idea we should first put all the games in a single list and reorder them alphabetically, I think it's really worth it to try to sort them in some genre sections first, and see how it goes: we don't have to use all the 46 sections in wikipedia:Video game genres, I guess the best way would be to start with the top-level categories, and then see how many games go into each of them; if a top category hosts "too many" games (20? 50? ...) it can be split in subcategories and so on. All the games whose main category is not obvious can be temporarily put in a separate section.

Sorry for the misunderstanding, I got your point, I was just meaning the Wikipedia's way to list genres is not trivial. Anyway, let's reach a consensus and move on: I'll merge the Netbook Games article, create a Game template based upon the App template, and put all game entries in their respective Genre section. Any thought about this?

After that we'll see what to do, whether to create a Game template, use a table, move the sections to separate subpages... I know you may think I'm being too conservative, however the truth is that I do like changes, but only as long as they are well planned in advance, I don't like the do-then-fix approach too much :P This is just to tell you that I really appreciate your will to help with this big restructuring! Thank you ^^

Alright, we may proceed at a more reasonable pace. Before proceeding I made some research on Linux game lists, and found this one: icculus.org. It is very up to date and complete; only a few games from Arch Wiki are not included there, but it has much more games overall. The list has filters! Besides they seem open to contribution. Since Icculus is a well established reference, I'm wondering if it is not more productive to contribute by adding the few missing games to Icculus rather than duplicating their amazing work in this Wiki. After all, this belongs to Arch philosophy: contribute upstream!

Following this direction, we would only need to replace all links to List of Applications/Games and Netbook Games with a redirection to Icculus. The emulators/steam/desura part can still be merged in Gaming. What do you think about it?

I'm always in favour of avoiding duplication of external resources, especially when they are very good ones like icculus.org's table. However in this case, like explained in Help:Style#Hypertext metaphor, our list is indeed giving Arch adaptations, i.e. it's linking to any existing articles for the games, and, even more importantly, to their package names/pages. That's why I'm against deleting it.

There may be some mistakes, but I'm tired of editing this page for now. The descriptions of the new entries are rather poor, but I wasn't in the mood.

You will notice that I didn't respect Wikipedia categorization for the genres. Actually I tried first, then I came to the conclusion that it would be a complete non-sense. I just couldn't figure out where more than half of the games should fit. So I decided to leave existing genres.

The obsolete pages are still there and complete. I've added a Delete template on all of them. I was wondering how the deletion process happens on Arch Wiki: do we just remove the content and add a #REDIRECT to the right place?

I updated all english pages that were linking to the obsolete pages.

There is still a lot of games to add, like those from the Humble Bundles or from Steam.

Really, I also appreciate how tidy and organized you've been, even finishing the job with this enlightening summary, well done, this was a tough job ^^

About the "deletion process", there are two possibilities: either redirect the pages as you suggest, or completely delete the titles; I'll go with the former, since those titles have been around for a while and they may have been linked from external resources; this way we're also keeping their history browseable by everybody.