Let me first give some advantages of "collection of files & adding single terrain pieces":
- If I create a completely new style, then this is a huge project and I would be very willing to use special tools to compress this into a useable format. For single terrain pieces, that I need for one level and that might have potential use for other levels, this is way too much work. Simply putting it in some folder is much faster and easier. (Btw. this is precisely the reason why I haven't created any terrain pieces yet.)
- Using a collection of files, one can easily distinguish between current and old versions of one style (at least if the difference lies in addition of further terrain pieces; telling apart changes of images themselves is hard in any case). Telling apart - likely identically named - binary files is much harder.
- On a slightly different note: Assume the editor is telling me that purple_Nepster_SingleCell is missing. With a collection of files I can easily check whether a downloaded style folder contains this piece or not. With binary files, I have to load it into the editor and try loading the level until I know.
I've already mentioned several times that one potential problem is people ending up with mixed versions of a graphic set (ie: some pieces not up to date, some that are), or an incomplete version of it;
See my points 1a) and 1b)
here and your answer to it. Again if an error message says that purple_Nepster_SingleCell is missing, then this file is much easier to find in a collection of files instead of compressed binary ones. And with your strict naming rules for additional terrain pieces, merging style folders will be fast and easy compared to merging binary style files.
For arguments that binary style files have the same potential problem, see the rest of my post.
...and if multiple people are adding graphics to a single set, without it being a proper coordinated effort, this has huge potential to cause mess.
Much, much more so if they are adding to binary style files. A collection of files has the advantage that names of terrain pieces are very likely unique; in binaries everone will start with adding terrain piece "29" to the Purple style, which is guaranteed to create a huge mess.
Don't add to other ones (unless they're your own, or it's a widely-agreed change); create a new graphic set for your new pieces and use the two in combination.
OK, let's see what happens then: I create a new style Purple_Nepster_Addition containing exactly two terrain pieces. Then so does e.g. IchoTolot and GigaLems and we have suddenly four different styles one can load, each called Purple and most of them containing only one or two terrain pieces.
Next suppose I create a level using the traditional purple style and all three additions. Then I can either
- ship it with all three additional style files: But players will never know whether the IchoTolot and GigaLem ones are the current version (unlikely) or something very old (likely), so they cannot simply copy them into his folder.
- or rip IchoTolot's and GigaLem's style files and copy these pieces into my style addition: But even assuming other are fine with plagiarism of their terrain pieces, there will be a huge overlap between style files soon and why would we want this?
A few weeks later I require another terrain piece for Purple. The question is now: Do I create a new style file Purple_Nepster_Addition_2 or do I add the new pieces to Purple_Nepster_Addition? The first one has the same problems as with additions from other people, the second one has the problem to distinguish between current and old versions.
Putting all my additional terrain pieces (even for different style sets) into one Nepster_Addition is creating additional problems as well: First of all I do want to browse all purple style pieces in the same folder, not having to switch to other folders and not having to skip dozens of completely irrelevant terrain pieces for other styles. Secondly I want that other people are aware of my additional pieces and use them in their levels if that helps them. If I only have a single binary Nepster_Addition file, then they have to load it, go through all terrain pieces to see whether I have additional purple pieces or not. It is much better if they are already loaded automatically in the purple style, or at least collected in one Purple_Addition folder.
Apart from all of that, I do not see a difference between a new binary style file Purple_Nepster_Addition containing exactly one terrain piece and adding the terrain piece itself without all the style fluff around it. Well, except that creating a new binary style file is more work...
With a binary file, it's much more clear that such a method won't hold up for very long, and that making use of the multiple-sets-in-a-level feature is more effective.
Not sure what you are trying to tell me here.
Summary: If I only wanted to create completely new styles, then the current system would be fine for me. But making small additions to existing style sets is
precisely the big advantage of a collection of files.
Regardless of our decision here, all additions to styles have to be collected and be available at
one single location (i.e.not only posted somewhere on this forum). Otherwise we get compatibility issues.
PS: Sorry for turning this into a discussion yet again
.