32bit Graphics Development File Repository
Early March 2009 saw the release of a public file repository for the 32bit Graphics Development effort. The repo was written and is hosted and administered by User:Jupix. He takes suggestions and advice at tt-forums.
It began as a simple file hosting tool that took in uploads and printed lists of files for users. Since then more features have been implemented and it currently supports:
- adding, editing and removing file entries, obviously
- categorization of entries
- searching by one or more keywords or a phrase, or using filters on a list of everything hosted there
- forking entries into derivative works
Additionally, Jupix has written a few tools around the repository, including the 32bit automated nightly bundle compiler and a diff tool for squashing dupes.
For information on how to use the features at the repository, read the user manual.
Target audience: developers
The repository is for 32bit graphics developers. The point is to have a single place for all development files for the 32bit base set conversion project, and also free hosting for the rest of the 32bit development effort, based on the principle that sooner or later, all artists grow disinterested, and unless their work files can be found in a repository like this, they can never be properly improved again. All files being hosted in a central place also makes version management and distribution easier.
In other words, if you are an artist, you should upload absolutely everything that has to do with your works... Textures, models, sprites, plans, readme files, everything. And all versions, too. Works just started or in progress, testing releases and finals. The more content, the better for the project - if someone wants to change something, they suddely can! That's the spirit of an open game.
If you are worried you would be uploading "useless" or duplicate data, don't be - the administrators will keep the repository organized.
All tars should be packaged into the 32bit standard tar format and include sources, and z0, z1 and z2 sprites. The sources are deleted from release packages aimed at players.
Tars should contain individual models. This rule of thumb is based on the assumption that the target audience of the repository are developers looking to either change something in a model, or run pngcodec on a model. Therefore the more models in a bundle, the more downloading has to occur over a slow WAN connection, and the harder it is to find just the right .blend, for example.
Take a look at the iron ore mine by Zephyris. It is an example of a correct repository entry. Entry type and status is set correctly, licensing information is available an verifiable (via the wiki), notes are reasonably informative, screenshot is present and of good quality, everyone related to the development of the item has write rights, and most importantly, the file itself is a standard tar with sources and sprites for all zoom levels included.
Distributing content to players
Big bundles aimed at players will hopefully go into the game's internal content delivery system in the future. Currently, the 32bit automated nightly bundle provides a method for publishing graphics to the end user in an easy-to-use format. Bundles can also be built manually.
Become an administrator
Contributors are needed at the repository to do administrative tasks on entries. The content needs to be kept organised and format guidelines need to be enforced. Contact Jupix at tt-forums and he'll set you up.
Tasks for administrators
- Make sure entry information is up to date: license, status and notes.
- Browse entries with status="To be split up" and divide them into singular items. (The all files list / filters are useful features in this task)
- Download sources/sprites packages and combine them into the 32bit standard tar format.
- Make sure entries are filed in the correct category.