Note that there is the arch/dev directory for objects which are not currently being used, as well as for duplicate images, of which only one instance used. I do agree that their will be issues of preferance between people. While I agree that 'pretty and fun' is a good goal, those are very subjective definitions. In the longer run, I'm not sure how we'll deal with sets. Just playing with Peter's images a few days back, I prefer the monsters he has over the highly isomorphic look, but still like the 'new' png buildings. Even the older buildings still have an isomorphic look. The problem I realize is how to package this. I had previously discussed that the client could choose different image sets, but in this example, I basically want to choose specific images - some from set A, some from set B. And that gets very tricky. If we can basically support an unlimited number of image sets, then these decisions become much easier - the latest images can be put in the 'expiremental set', and people can play around with them a little while and then determine where they should end up. But I also think we should concentrate more and updating the current images as needed, and worry less about grabbing any image that may be usuable - There are probably thousands of potentially usuable images out there, and I think grabbing them/storing them because they may prove useful may not be worth the time and space. OTOH, if you run into an image which looks cool and would fit in (or is of something which crossfire does not have right now, but perhaps could get added), then perhaps storing it away in the dev directory is good idea.