Looking for utility to install and run gamefest demo files on Nix systems
I have what I think may be a useful project but which I many not find time to work on now. Even if I do, many can contribute to the project without putting in too much work. Anyway, maybe someone really likes this idea and will jump on it.
Build a download utility (a shell/perl/etc script most likely) that comes in various flavors to be used with the more popular distros.
The purpose will be to install or upgrade one or more of the gamefest games on the user's PC. With this task completed and/or verified, the utility procedes to download user specified demo files, if these are supported, into the proper folders so that they will be accessible to the user through the games' demo facilities. [This only applies to some games naturally.]
Along with the utility, documentation should explain the steps that the utility will take so that the user can make a judgement if to procede. The documentation would also explain how to access the demos.
If the demos can be run automatically by passing CLI parameters or environment variables along with an invocation of the game or if it can be done after modifying a configuration file (or through some other automated fashion) than a small script to accomplish this should also be provided.
This utility can ultimately become very polished and packaged (and maintained), but a crude version should not be too difficult to build and may be useful to current gamefest participants and visitors. Here is a bit of the logic I would try to code if I were doing a second draft of it. [**A first draft would be much cruder (and probably only work on my system).**]
Figure out what games are needed to be installed. The clues should come from the urls provided on the command line (or through some other means). Currently I know of .dem files for Nexuiz, but other games (like OA and others) may use similar facilities.
Query the platform. Try to find out if it looks like the games are installed. If not, what kind of (preferrably native) package management system is installed and are certain packages available. If this doesn't provide a way forward, test to see if various utilities exist with the aim to download source for a needed game (and/or game dependency) and then build the source.
To help with the above tasks, we can try to determine if we are using a known distro. Likely we'll then know what the package names necessary will be and how to get them installed. In this process, the script may find the need and may be able to fairly confidently ask the user to consider an update so that the proper packages would be accessible. If affirmative, then it can procede hopefully to the end without a hitch.
We could take advantage of internal lookup tables (eg, some arrays) so that once we know the system (eg, distro version X) we can guess at the best package management to attempt to find. Once there we may test for availability of packages (by name and version) and maybe even test for specific known good repos.
To test for a specific game (or for any other file really), we might query the package manager or else check the filesystem for specific files (name, size, and maybe hash or some other type of fingerprint). Some games may have a method to query for it without any obstructive side effects (eg, start with "dirpath/gameX --help | grep ...." assuming a suitable shell and proper grep exist).
If we could not confidently find and use a packaging application, access key packages, verify an installation worked, etc, then we try to go the tarball route. We make checks for a proper environment to build the game. We check for download utilities (we may check for the ability to download but this may be assumed unless it fails and ends the script). We try to get the needed utilities or dependencies and the game package. If all of this succeeds, we try and build and install. Along the way, we should let the user know what is going on and prompt before attempting some of the more intrusive options or to find out desired installation paths (defaulting to local dir).
At some point (either at the end or right before attempting build from source) we should provide the option to install platform neutral binaries (if these exist). Some people would prefer a binary before a source build. Others would prefer the exact opposite. Most that have a packaging system, however, would probably prefer to use that before either of the other cases.
The reason to document the steps clearly are so that the power user that may not be fluent with scripting can figure out if the script might damage the system or, should it fail, if it might be fixed through very simple minor changes. Damage" to the system can occur if you hack your system a lot. Maybe you move files around or have a very unorthodoxed setup for you package management or you think an installation from source may fail somehow or use the wrong libraries. A "simple fix" might be that you do have the game but have it under a different name, and rather than build from source, you can just create a symlink and re-run the utility.
A polished script would try to take as many odd scenarious into account. It would be very careful about creating any files. It would test for many files and do sanity checks on them. ETC. A polished utility would also provide a more elaborate and robust command line interface.
While the above is somewhat complex (unless you have experience doing it), a crude version can boil down to a few simple commands. And we can do a separate crude version for various popular distros. We can also have a crude version that installs pre-built platform neutral binaries.