no its not it's an interpreter(like AGS) for many text adventure engines and every single engine is done due reverse engineering.
I'm not a programming guy but afaik: emulators like dosbox run the orig. game binaries and interpreters replace those binaries with their own implementation, but instead of a compiled application you doesn't need to recompile the whole game code at the cost of a huge performance loss(which is totally irrelevant for that kind of games).
maybe we have a programming guy here that could clarify it? (=
Thanks, for the clarification, 100% agreed. You point the results of our last discussions out in a very comprehensive form. i think we can include that in our submission guidelines.
A little bit more specific for the NaCl discussion:
Not all NaCl games run on Linux and if the developer advertises Linux or a Linux distribution (e.g. Ubuntu) Point 5 of Curly Braces posts gets applied:
Simple => NO
Cool => GO
(please, forgive my simplistic view)
I've noticed there were many debates raised recently regarding game inclusion/exclusion policy, so I think I can bring my 5 cents.
First of all, I would like to remind anyone few things:
- This is not the first time such discussions appear.
- Each time most people agreed that LGDB has no 100% strict inclusion/exclusion policy.
- By examining those games already included in LGDB, other Linux gaming related websites, blogs, etc. it seems to be practically impossible to create such policy, which would allow to easily determine what needs to be included and what not (and make people happy at the same time).
- Hence, currently games are included according to some "general" guidelines, with exceptions being made for particular games.
- The ideas behind submission guidelines can be described as: do not flood the database with unrelated, poor quality games that has nothing to do with Linux (99% Flash & browser games); support Linux friendly developers; popularise Linux as a platform (make exceptions for good quality games, even if they are not really native); give people stuff they want to see here; popularise FOSS games and technologies. In other words, support Linux (hence, some "political" decisions can be made).
- If I remember correctly, we've also agreed to avoid where possible exclusion of those games that were added to DB (relatively) long time ago.
Regarding NaCl games - I'm not really fan of these (this is subjective opinion), but if they are already here, then we can go with this. Just keep the quality to be decent.
Forum topic: Not sure if I agree with this submission
They are completely different games! Unlike, say, PySolFC, it would just be unfair to say that these are single units, as they don't show up as one game on the desktop. Beyond the obvious fact that they are developed and played as individual games as well. Either way, I'm sure we can agree that they are not components of one game.
Also, they don't have to get updated at the same time; in fact, many of them don't as you would be aware if you follow KDE development. In the upcoming release (4.12), only KNetWalk received updates.
There is a core KDE games library but that's like saying that any game that uses SDL should be listed as a single game.
I'd suggest dividing these into several games. It's a chore, but remember, we are building the best database of Linux games in the world. =p
These are really browser games. NaCl is meant for browsers to run native code, not for operating systems (like Linux) to run them directly. So one might call them Chrome platform games, not Linux games.
They are exclusively available in the Chrome web store and cannot be played in other browsers. I don't see any other browsers adopting NaCl either since Firefox went with OdinMonkey.
It is also worth noting that none of those games are available native on any GNU/Linux platform.
ScummVM is a VM. Basically an emulator. If WINE is to be considered an emulator, a VM should certainly be considered an emulator... I don't think ScummVM-compatible games should be listed here either to be honest with you.
yeah but it works with ScummVM which includes a replacement engine/reimplemation, so I guess we can keep it