:::::About 1. I wouldn't like to create new articles only for that; an alternative could be using nested tables instead, sorry for the quick example, we're still brainstorming after all:

+

{| class="wikitable sortable"

+

|-

+

! scope="col"| Name

+

! scope="col"| Package

+

! scope="col"| Released

+

! scope="col"| Updated

+

! scope="col"| License

+

! scope="col"| Description

+

|-

+

|AAA

+

|BBB

+

|CCC

+

|DDD

+

|EEE

+

|FFF

+

|-

+

| colspan="6" |

+

BBB

+

{| class="wikitable sortable" width="100%"

+

|-

+

! scope="col"| Name

+

! scope="col"| Package

+

! scope="col"| Released

+

! scope="col"| Updated

+

! scope="col"| License

+

! scope="col"| Description

+

|-

+

|AAA

+

|BBB

+

|CCC

+

|DDD

+

|EEE

+

|FFF

+

|-

+

|AAA

+

|BBB

+

|CCC

+

|DDD

+

|EEE

+

|FFF

+

|-

+

|}

+

|-

+

|CCC

+

|DDD

+

|EEE

+

|FFF

+

|GGG

+

|HHH

+

|-

+

|}

+

:::::About 2. you may even be right, but they don't bother me if they stay, honestly.

+

:::::About 3. and 4. I'd still tend to agree, but they would be a later problem, since even if we approve the change to a table layout, I'd like to keep the templates backward compatible with [[Template:App]] at least initially, so we would use the existing links for the first stage.

+

:::::Anyway, let's wait to see if there's somebody with a clearer position than mine.

Games - 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.

Thanks for the moral support! :p This was not easy, but not that hard either; it only took me a few hours. A good editor really helps (can't stand writing in a web browser anymore).

You may have noticed that the formatting is strange for sub-entries (this is new in fact) like for Doom. The link is not properly aligned. I've tried with '**' but this is worse. The 'App' template may need to be fixed to support indentation.

Unfortunately the App template won't support indentation, this was discussed in [1]. I guess the only viable alternatives are making subsections for Doom etc. or just wlisting the various spinoffs as normal applications (no indentation), I'll leave you the choice, unless you have other ideas. -- Kynikos (talk) 11:40, 18 July 2013 (UTC)

Yes! I'm always in favor for a single page, less dispersive. But this page will become a very big long list. Are you sure it's fair to mention the games are not in the official repositories or AUR. I think that in this page there must be only games available on Arch Linux. At most you can do a section called "steam" where to put only the weblink to the list of steam games. At the end this is the Arch Wiki. Veleno (talk) 21:35, 18 July 2013 (UTC)

Steam/Desura markets related

What about avoid all Steam/Desura/whatever game entries and just point to their Linux market link? After all their list is the most up to date. I am sure they are able to advertise their games better than us...
Something like:

This is a rather complicate problem that can be extended to the whole List of Applications and that comes from the fact that there's not a clear policy on what apps can be added or not. I can think of two possible policies, each with some disadvantages:

list everything that can be made to run on (Arch) Linux; this would leave the current steam entries where they are; the problem is that the list would lose focus on Arch Linux and risk duplicating other existing external lists

list only applications that have an official package, a PKGBUILD in the AUR or an article in the ArchWiki; this would let us remove the steam entries; the problem is that applications that don't have a package (yet) should be removed as well, search for example for the entries with "not packaged? (search in AUR)" in the list

Maybe we need a compromise policy; also, I think it's worth to split this discussion from the original one.

I think you have a point in saying that the problem is limited to games, so I'd say let's implement #Split games list and then apply there my proposal #2 policy. -- Kynikos (talk) 05:10, 4 September 2013 (UTC)

Split games list

I'd like to propose to move List of Applications/Games to List of Games and just link to it instead if transcluding it here. The various subpages of List of Applications are transcluded here mainly to make it easier to search for an application without knowing where it's been categorized; however, this doesn't give any advantage when searching for games, so they can be safely split. This would also make the list shorter and tidier. Finally, as proposed in #Steam/Desura markets related, games should probably be added to the list under special policies, and keeping them in a separate list would make it easier to enforce a different policy. -- Kynikos (talk) 05:10, 4 September 2013 (UTC)

For me it is ok, of course. -- Flu (talk) 18:28, 8 September 2013 (UTC)

This formatting would not violate any style rules, but it would break style consistency with List of applications. On the other hand, I have to agree that using tables would look neater, but this is still a personal feeling. However how would you adapt indented entries like those under List_of_games#Shooters_.28FPS.2C_Third_Person.29? Finally, I wouldn't include the "Updated" column, as it would be hard to maintain.

The problem with indented entries should still be solved. Then we'd probably need a field for a link to an ArchWiki article, if available (default to Wikipedia?).

Then, if approved, initially this change should be implemented with templates in a backward-compatible way that only needs to rename the existing templates from "App" to e.g. "Game", so that it would be easy to revert in case of too many negative feedbacks. A Template:Games start and Template:Games end should be used to start and end a table under a section, and Template:Game should create a wiki table row based on Template:App's parameters (this would delay the addition of the "Released" and "License" fields), so that it would be possible to simply replace * {{App with {{Game in order to update the page, and vice versa to restore the current formatting.

About 1. I wouldn't like to create new articles only for that; an alternative could be using nested tables instead, sorry for the quick example, we're still brainstorming after all:

Name

Package

Released

Updated

License

Description

AAA

BBB

CCC

DDD

EEE

FFF

BBB

Name

Package

Released

Updated

License

Description

AAA

BBB

CCC

DDD

EEE

FFF

AAA

BBB

CCC

DDD

EEE

FFF

CCC

DDD

EEE

FFF

GGG

HHH

About 2. you may even be right, but they don't bother me if they stay, honestly.

About 3. and 4. I'd still tend to agree, but they would be a later problem, since even if we approve the change to a table layout, I'd like to keep the templates backward compatible with Template:App at least initially, so we would use the existing links for the first stage.

Anyway, let's wait to see if there's somebody with a clearer position than mine.