Re: [Freecol-developers] Type-classes

[Neil S. <cl...@di...>]

The XML configuration that was previously loaded using SAX is now loaded
using DOM and the readFromXmlElement approach.

Many references to Unit.FREE_COLONIST and its ilk remain and will
require significant work to replace with use of type classes as Michael
points out.

Some methods have been implemented on the type objects and they look
nice and tidy.

The temporary stand-in for the Rules class is the Specification class.

Abilities are implemented but as String rather than custom classes for
now.

- neil

> And now on to how the Type-classes can be implemented (using ideas from
> Neil, Bryce, Michael and myself):
> 
> 1. Use "toXMLElement" and "readFromXMLElement" in the same way as for
> "FreeColGameObject" so that Type-objects can easily be stored alongside
> with a savegame, scenario or a mod/TC definition.
> 
> 
> 
> 2. Remove all type-related constants (ex.: Unit.FREE_COLONIST) and have
> "static final" references to the Type-objects instead.
> 
> 
> 
> 3. Avoid using the type reference defined above and have methods operating
> on the Type-objects instead. Ideally the "static final"-references above
> should not really be needed.
> 
> 
> 
> 4. Create a new "Rules"-class with methods for getting all the possible
> Type-objects ("getUnitTypes()", "getTileTypes()" etc). This class will
> also be using the method described by no. 1 for serialization.
> 
> 
> 
> 5. Store the "GameOptions"-object as a child element to the "Rules"-class.
> We can still have the "getGameOptions()"-method on the "Game", but I think
> that the "GameOptions" belongs to the "Rules".
> 
> 
> 
> 6. I was thinking that each "UnitType" should have a list of the abilities
> each "Unit" of that type have, like for instance: build colonies, carry
> goods, use muskets, ability of carrying 4 units etc. A single ability can
> be represented by an object of an "Ability"-class and the different types
> of equipment, horses, muskets and tools, can be represented by a list of 
> "Equipment"-objects.
> 
> A single Unit's abilities would then be the union of the abilities gained
> by the unit type and the abilities of the equipment it is carrying.
> 
> This means: The "Unit" should still have methods like "isCarrier()", but
> those methods will only check if either the unit type, the unit itself or
> the equipment it is carrying have this ability. This would be a very
> useful feature for those who are interested in using FreeCol for making
> mods/TCs (for instance a "Master of Magic"-clone). We can also add the
> method "hasAbility(...)" to remove the need for methods like "isCarrier()"
> in the Unit-class altogether.
> 
> Objects of both the "Equipment"-class and the "Ability"-class should be
> specified by XML using the method described in no. 1.
> 
> Having "Ability"-objects for other Type-classes might also be a good idea,
> but I have not looked into this.
> 
> 
> 
> 7. I think that the units, settlements, goods and tiles should determine
> how they are displayed themselves. Not by returning the actual image, but
> by returning a "display-ID" which can be used by the view to determine the
> actual image to be displayed. The view could then locate the proper image
> by having an XML-file which links the "display-IDs" to actual images on
> the filesystem.
> 
> Each "UnitType"-instance should have it's own ID ("freeColonist" etc).
> This ID can then be used alongside with the equipment and the abilities in
> order to determine the "display-ID" of the unit. This link can preferably
> be defined by XML.
> 
> 
> 
> 8. Support multiple ".properties"-files in order to allow i18n for
> scenarios and mods.
> 
> 
> 
> The idea of the design sketched above is to create an implementation which
> allows easy customization. For example: it would be possible to create a
> new type of equipment like "Rifles", or to allow that pioneers also carry
> muskets/rifles, by only making small changes to an XML-file.
> 
> I am not saying that we should make all these changes at once, but I think
> it would be wise to decide the general direction before implementing the
> Type-classes.
> 
> 
> 
> What do you think?
> 
> - Stian Grenborgen