World
Wide Guide | Knowledge Bank
| Kukushkin's Notebook |
Design Fundamentals
World
Wide Guide | Knowledge Bank
| Kukushkin's Notebook |
Design Fundamentals
Many authors design sceneries not just for personal
use, but also for sharing their creations with others, often as freeware
or e-mailware. Here, some my thoughts about distributing freeware sceneries
are presented. As you will notice, they are often based on my disappointments
from downloaded sceneries. This description reflects my personal opinion
on the topic, so these suggestions should not be interpreted as a must do.
However, I hope most of them are reasonable enough to be followed.
We want our creation to be available to as many people as possible at (almost) no cost. The best way of doing it is to upload the scenery onto an Internet site or some online service. We want to upload it to as many sites as possible, because this will ensure the widest availability.
In order to minimize communication fees and/or time, we want our uploaded file to be as short as possible. Also, while our scenery may contain many files, we want to upload it as one file in order to simplify its download. So we always use PKZIP to create an archive of all files belonging to the scenery and upload this single archive. PKZIP is preferable over other archivers because it is the most widely used one, so most users are able to unpack ZIP files. We NEVER upload our files in nonarchived form, even if our scenery contains only one file. Many people find non-archived uploads a bad taste and would not bother to download our creation.
We do not create a self-extracting archive. Because of the self-extractor, it would be bigger than a normal archive, thus forcing our users to download more. Also, many people are very suspicious about EXE files downloaded from the Internet because they fear viruses and trojans (I belong to them). For the same reason, we do not include any COM/EXE-files in our archive unless these files are really necessary for the installation and cannot be obtained otherwise.
We never create an archive with subdirectories. Many users who still use command-line utilities to deal with archives would forget the switch for extracting subdirectories anyway. Also, the archive is often first unzipped into a temporary directory in order to see what's inside. Having subdirectories would make it difficult to see what's inside and would also make it more difficult to move the directory structure to the final location. We can always include a batch file that would create necessary subdirs and move files there. Besides our archive, we also upload a small text file describing our creation (unless we are using an online service that allows to enter a lengthy description for the uploaded file). This will let our users know what our archive is all about before they download it. Downloading hundreds of kilobytes takes time and sometimes money. So our users want to be sure they want our archive before they download it.
We set creation times of all files we have created to the version of our scenery. For example, creation times for versions 1.0 resp. 4.3 should be 1:00am resp. 4:30am. Our creation times must be AM, because we do not want our European users to think it's version 13. "Round" creation times will give our users some confidence that the files were not modified underway. Also, they are very useful for identifying different versions of files with same names.
We do not change creation times of files that we did not create but simply borrowed from other archives, like common textures.
Unlike creation times, we leave creation dates of all files intact or set them to the release date. Our users want to know when that strange file in the SCENERY subdirectory was created. Again, we only modify creation dates for files we created.
Before actually uploading the archive, we unzip it once again in order to check its integrity. Also, it is a good idea to install the scenery into a "clean" version of FS5 and test it again. We could have forgotten some textures or other files from the main directory of FS5, and such problems can be detected only this way.
We upload the archive only in BINARY mode. After having uploaded it, we immediately download it again and compare it to the original archive. If files compare ok, we announce the upload.
Our scenery should always add an entry to the World|Airports menu because we want our users to know whether our scenery is active or not. Also, we add only one submenu, because the user also has other sceneries installed and the menu should not become overcrowded.
We add all major airports in our scenery to the World|Airports menu. If our scenery does not have airports, we add some location on the ground where our scenery is visible. We do this even if we supply situation files with our scenery, because moving the aircraft using World|Airports is much more convenient than loading situations. Also, all settings normally over-written when loading situations would be preserved this way.
Adding entries to the World|Airports menu should not discourage us from supplying situation and video files with the scenery.
If our scenery includes texture files, we do not compress them using ACSHRINK or other programs. PKZIP compresses uncompressed texture files much better than compressed ones, so compressing textures would in fact increase the length of our archive.
We never distribute texture files that came with FS5.1 or commercial sceneries because this could be a copyright violation. Also, we do not include texture files from scenery design packages (Airport, FSASM Airport Sign Toolkit, etc(?)) that are available online as separate archives, but instead tell our users where to download them. Our scenery is not the only one that uses these textures, so we do not want to make our users download the same files multiple times.
We always include documentation into our scenery. We never write it in capital letters because they are HARD TO READ. Also, we always write the docs in plain ASCII text. Not everyone has MS Word or WordPerfect installed, and some people are too lazy to start these apps only to read some docs. Without having read the docs, users may be dissatisfied with our scenery and would not be happy about it - as we wanted them to be.
We include a copyright statement in the documentation and also embed it into the scenery. We do not give any warranty, either expressed or implied of any kind, including but not limited to... We normally explicitly permit noncommercial redistribution of our creation. However, we do not permit uploading it to CompuServe FsForum, because its operator is known for misusing its compilation copyright and not respecting explicit permissions authors give for redistributing their work obtained from FsForum. We do not want to increase the worth of such a company with our creation.
While writing the documentation, we should keep in mind that (most of) our users know much less about our scenery and FS5 in general than we do. In particular, they often do not know how to install the scenery, so we provide a detailed description of the installation. We can also write a batch file that would do the installation. However, many users prefer not to run such batch files because they want to be in control of what happens on their hard disk. We never write EXE programs that would do the installation. Most users know that the installation can be done without any EXE program too. So they can become very suspicious about what our program is really about to do, and this may cause them to discard our scenery without even installing it.
We indicate clearly, which version(s) of FS (4, 5.0, 5.0a, 5.1-disk, 5.1-CD) our scenery is compatible with. If we were only able to test it with one version and not sure about other compatibilities, we indicate this too. There is always a possibility that our scenery will be compatible with other versions too, so the user should not be discouraged from experimenting.
We include our name and e-mail address into the documentation, because we want our users to be able to reach us. Also, we give credits to tools we used to create the scenery because we want to encourage their authors to continue their very important work.
Finally, we have to describe the scenery. We indicate the kind of our scenery (IFR, airports only, VFR scenery). Our users live in different parts of the world, so they may not be familiar with the area covered. For this reason, we include some background information on this area too, as well as interesting places to visit. We provide a list of _all_ airports and navaids. Also, it is a good idea to include an import file for Flight Shop if our scenery contains airports not already in the database.
Also, we describe some "technical" features of our scenery, like photorealism, revolutionary night lightning or protesters blocking the runway.