Either "Description" or "Prototype" works for me. To be honest, this is the first thing that popped into my mind: The universal design pattern. You'll at least find it interesting, if you can wade through it.

I'd consider this a plain case of the Flyweight pattern; however, the "flyweights" are the pikemen Unit objects that reduce to position, residue hit points etc., not the shared read-only pikeman Archetype.

You are simply introducing a class to share some read-only data they have in common among a large number of objects of the same class to avoid redundancy, memory waste, and confusion between immutable and mutable data; I don't see any special requirement making your case fundamentally different from the textbook GoF example (factoring font glyphs and metrics out of self-drawing letter objects in a text editor).

Sticking to a data-driven design with a single Unit class (with or without a smart flyweight structure behind the scenes) instead of a pointless hierarchy of Pikeman, Archer etc. subclasses entailing complicated creational patterns is a separate, earlier design decision.

Maybe just "Properties." Pikeman has PikemanProperties, archer has ArcherProperties.

Quote:Original post by Antheus

Quote:Original post by Sol Blue
A text file describes the properties of different units, e.g:

Memento.

A Memento is supposed to contain data pertaining one object, not many sets of many objects; and to be used to recall or reconstruct formerly existing object states, while this file is simply an input.

Quote:A practical note - flyweight, despite algorithmically being better, will often work poorly in practice.

A copy-on-write is typically better.

Typically for what application? Not this one.

Quote: The observation is like this:
- majority of objects are not interesting and will not change or be customized (or are simpler to customize via templates)
- the few interesting objects will be heavily customized

A very strange idea. Every Unit instance is going to have his own position, current hit points, movement destination etc. and to share massive amounts of constants, Strategy objects etc. with other Units of the same type. Each Unit instance is equally interesting and it contains the same data fields as any other; there are no "customizations", since the templates contain shared read-only data, not defaults that can be overridden by copy-on-write mechanisms.

Quote:- overhead of per-property will be large (for ints it's almost not worth doing, for strings other caching techniques exist)

Quite the opposite: the single pointer or pseudo-pointer used by the Flyweight pattern has a fixed cost, with the same overhead regardless of what read-only fields have been factored away.
In fact, even an Archetype that doesn't contain any field is likely to be useful to compare Unit types (e.g. pikemen grouping themselves with other pikemen).

Quote:Flyweight is one of prime examples of a worthless *design* pattern. It's an implementation detail, which brings together worst of all - huge overhead in implementation and no absolutely design benefits. The text editor example for flyweight is mostly nonsensical, it's not where the problems really lie.

You are, evidently, not talking about the same Flyweight pattern that I, theOcelot, Sol Blue and the GoF book are discussing.

Quote:As far as saving resources
- for memory it does not matter (there will either be much too much of it or way too little)

Even if the memory usage can decrease from low to very low rather than from too much to acceptable, wasted main memory translates directly to wasted cache and thus decreased speed.

Quote:

Flyweight also introduces a potentially killer bug - what happens if something is loaded from stored state, but template has changed in between.

Do you mean something like initializing a level, creating Unit instances, then deciding that pikemen should have a speed of 15 instead of 12? A silly use case, which would nonetheless work correctly: you change the pikeman "Archetype", preferably not in the middle of an update, and next time a pikeman Unit accesses it, the new value is used.

Quote:
With full copy-on-write, interesting objects store their full state as it was when they were created. Uninteresting ones (those not touched) can change whenever, so they might as well use default template.

There are no "interesting" object with an extensive history of property changes: every unit is going to be processed uniformly. Maybe other sorts of game have complex units that don't share much with one another and work well with prototypes and COW references, but units in a RTS are highly standardized.

Quote:
Full flyweight also introduces the huge dependency (same problem as C++ compilation complexity). Changing the very base template means each and every object needs to be updated, which be prohibitive (imagine having to load entire database and update all objects ever created and even those destroyed by still tracked).

You are definitely misunderstanding both the Flyweight pattern and its application to the OP's needs.
There are only two classes (Unit and Archetype): altering either causes no dramatic consequence on code, as the changes are normally new features on Unit reading new fields in Archetype loaded from richer data files.
There are no bad dependencies between object instances either: in the unusual case that an Archetype instance is modified at runtime, Unit instances will access the altered Archetypes (which they are already linking to) at the first opportunity.
There is no database of redundant data to update: altering the rules in unit definitions invalidates saved games, which are the only place where Unit instances are persisted.