[crossfire] Making maps easier to maintain, by creating custom archetypes for duplicated objects.

[Mark Wedel]

Alex Schultz wrote:
> Andrew Fuchs wrote:
>> There are several instances in the maps, where custom objects where
>> copied and pasted from other maps.  An example to this is the
>> guidebooks in the post offices.  Recently the guide books in Scorn's
>> post office where modified, but not the ones in other post offices.
>> This lead me to think about what requirements have to be met for it to
>> become practical to replace duplicated custom objects with new
>> archetypes.
>>   
> Seems like a good idea to me.
> 
>> I'm thinking that having two or more of similar objects that appear on
>> separate maps would be enough warrant a new archetype.
> I don't think that's good criteria, for one, what about floors set to
> no_magic? IMHO that isn't worth making new archetypes for. (However
> perhaps the editor should give an option to automatically set no_magic
> when placing floors? but that's another matter.). We would need to
> define how different the archetype would need to be from it's original
> arch, to trigger the map check warning.
> IMHO some good criteria would be highly similar objects being used on
> two or more maps, and at these criteria scoring at least 5:
> Score       Criteria
> 4              Objects have the same message, which is over 10
> characters long and different than the archetype.
> 2              Objects have same name, which is different than the
> archetype.
> 1              Objects have the same in some other attribute, different
> than the archetype
> 
> Or perhaps something similar to that table. In any case it seems we
> would need some sort of scoring system for how similar objects are, and
> how different from the archetype they are.

  I agree it gets complicated.

  Keep in mind in many cases, what probably happens is someone puts a modified 
object on a map - the first version of that object.  In that case, it should 
pretty clearly not be an archetype.

  Then someone else decides to copy it.  At that point, it may make sense to 
become an archetype, maybe not.

  My general thought was always that archetypes should be somewhat generic 
objects - in other words, objects that map makers would likely find use for in 
all sorts of maps.

  Thus, even a highly complex object (that scored really high in the above 
criteria) probably shouldn't be an archetype if there is very limited places 
they would be used.

  I'd think the criteria for something being an archetype would perhaps mean 5 
instances of such objects in the maps - that starts to suggest that there is 
some general value for those objects.  2 instances may not suggest much.

  How complex the object is is certainly somewhat reasonable - very complex 
objects would have more reason to be archetypes than simple objects (the no 
magic floor example).

  If we do have scripts to find equivalent objects in maps, I wonder if instead 
making archetypes that could/should be put in the map directory (tools directory 
or something), and thus could be used to find such duplicates.  So we don't 
necessarily need them to be archetypes, we just need to be able to easily find them.

  Making this archetypes could have unintended consequences.  Map maker A 
designs the object in just such a way for various reason (maybe for slaying 
fields, maybe to kill a specific monster in the dungeon, whatever).  If that is 
turned into an archetype, and at some point people go through and start 
adjusting balance of objects, you now get the danger of that object changing and 
thus not meeting its designed purpose anymore (maybe people say 'instead of 
attacktype A, it should have B', not realizing that the original instance had 
attacktype A becuase that would kill the monster in the dungeon, etc).