Linux native or Linux compatible games

What do you think? Should we include Linux compatible games or only Linux games?

Ok, let me clarify what I understand under both terms

Linux games:

- comes either as source package or as a pre-built binary
- these games are made for Linux
- needs to be downloaded and executed separately
- the most of them can run on many platforms

under reserve, because they could fit in both terms
- this includes Java SE applications (OK I know VM, but hasn't Quake 3 used some kind of a VM for it's network code?)
- Adobe AIR packages? (Ok I'm not sure about AIR, but AIR is dead)

Linux compatible:

- games that can run on Linux
- games that are made for a technology, which is available for Linux
- can be run trough browser plugins/technology's like: NaCl, HTML5, Flash, Java, AIR, Unity, Silverlight, WINElib, Panda, JavaScript etc.

And don't forget Linux itself is a multi-platform OS(Debian popcon ), but the most plugins are only available for a few platforms!

Maybe we could add an extra section(like the emulator section) for such games.

share your thoughts (=,


I mostly agree with your vision, but not entirely.

Java SE should be part of the second cathegory. "A part of the code" in a VM is not like "all code in a VM"

The second cathegory should be divided in at least two. Full linux support and partial linux support.
Flash, for example, doesn't have the GPU support it has on Win, making it so much more CPU hungry. Wine is a compatibility layer, the devs do not make games to work with wine (mostly). Wine evolves to run those games.

HTML5 NaCl and java games, aren't really native, but they are probably the best chance Linux will ever get on the compatibility/crossplattform wars. "you don't want to support linux? Google/html5/Java does, so screw you" kind of thing.

Generally speaking, I think that the quality and/or popularity of the game should have a bigger impact on the choice of what goes into the DB, than the way you run it.

>Full linux support and partial linux support.

Well I'm against to divide them further, it doesn't really matter how good they perform/work on a Linux box. By WINElib I mean applications that are build for the WINE API (

>I think that the quality and/or popularity of the game should have a bigger impact on the choice of what goes into the DB, than the way you run it.

right, that's why we have to decide: How we should list them? The biggest problem I see is If we list them together with native games, then it's only a matter of time before they get bad votings or such stupid comments like "Java/Flash/Mono... sucks or Ugh!, a java game"

Thats a problem, surely there are game lovers, and surely they protest mono java or wine.

I knew a guy who love gaming on linux, and he do not want to install mono or java, wine is fine though even if only for gaming.

Just for the record:
For me it's the opposite. I do have both Mono and Java on my computer (this are native Linux programs, mind you). I also do have wine installed, but don't support (= buy, use) games that only run in wine. There are exceptions, but in general a wine game is one that has not been made with Linux in mind, whereas Java and Mono games (and programs) mostly are. So I'd be biting the wrong hand not using those, but wine....

@pit i think sixsixfive made a very important differentiation between games that "can" run with wine and games are are build for wine (and might come bundled with it). the former games have there place in the winehq app database only the later might be listed here.

sixsixfive raised a veritable point when he pointed out that people might just down vote a game because of its dependencies. i think the most imported point here is information. but that is something we are good at. if you look at the system requirements of the games form the second category (Linux compatible) that are already in the database, you'll find dependencies like Java or Mono. If we keep it like this i don't see a problem listing those kind of games.
But the developer needs to advertise Linux support. I think this is very important because it shows that the developer somewhat cares about Linux.

I don't think there will be game developer build against winelib... They are probably not sure its compabality to general Windows users, or never heard about it until have a thought to port game to linux when it is too late.

There will always be people that downrate a game due to whatever reason. Because it's Java. Because it's commercial. Because there are no 64bit versions. If you only listed games that are true linux, available both in 32 and 64 bit (and probably also for ARM? SCNR) you'd have a quite castrated database.

Yes, the keypoint is information, and the very first information I want to get is 'there's a game that can be run in Linux' and then 'what do I need to run it'. LGDB fullfills this sufficiently, as you point out. Censoring Java/Mono/Emulator games would cut the wire already before the first plug, and I'd regard this as a Bad Thing(TM)

What about adding a new tag where every user can select what he want to see?

like the open/closed/any source radiobox here

>I don't think there will be game developer build against winelib...

Well, Arx Libertatis did this before their *nix-support was done

Honestly, I'm against including Wine, HTML5, JS, Silverlight, NaCl, etc. games, even if we do provide filter. IMO, the way we're going now (native + Java + Standalone Flash/Air + Mono + few exceptions) is good enough.