I have the Idea of a "Time-Upgrade" like in popular games e.g. Empire-Earth.
Ahh, now
THAT I believe is a good idea. However, the correct feature to use would be
Subfactions, that's what they're designed for. And this is no pony ride! I believe this is a big one, so let's talk specifications.
First off, subfaction changes are triggered by Glest::ProducibleType (upgrade or unit) being produced. When you specify that a ProducableType will advance the subfaction, it can either trigger the advance as soon as you start producing (i.e, creating unit, building buildings or upgrading) or when it completes (see link to specification above). However, other units may be in the middle of important skills. How should this effect them?
- It interrupts their skill execution? probably not
- It allows them to continue executing their skill as long as they still have the skill after being auto-morphed?
- It allows them to continue even if they no longer have the skill?
For now, I say number 2 and leave that issue alone.
Next, what if you have units that exist in the current subfaction, but aren't available afterwards, what should you do to them?
- Nothing, allow them to continue on as normal.
- Kill them
- Morph them into something else
- Use the <subfaction-restrictions> tag to make a morph skill to do the morph only accessible from the new subfaction (they still have to morph it on their own)
- Adopt them out to a needy family
- Something else entirely
Well, right now, if you have a unit that doesn't exist in the current subfaction, their regeneration is decreased by some odd amount to cause them to die off within a few minutes (although it's not perfect). This isn't a one size fits all and I think we need a definition of what happens in the XML.
Should we morph units into new units or should units have something along the lines of "multiple aspects"? Thus, when a subfaction change occurs, new aspects of the unit are allowed to surface and possibly older aspects submerge, thus virtually morphing the unit, although they remain the same Glest::UnitType (and the same unit type name). It is already the case that a unit may get new commands (to execute skills that they've always had, but no command to access them prior) by adding the <subfaction-restrictions> tag to the command body. Thus, commands can be added and removed, but there is nothing like this for animations and sounds. My personal preference to this is to add functionality to allow "multiple aspects" of a unit type and the aspect is contingent upon the subfaction. Thus, the only changes needed would be to <sounds> and <animations>. Remember, this is for 0.3 and there is an <animations> tag that, like the Sound::Container class (<selection-sounds> and <command-sounds> tags under unit.xml/parameters and <sound> under unit.xml/skills/skill) contain a collection of sounds and a random one is chosen, so will the <animations> choose a random one each time a skill is executed. All we have to do is further enhance these containers to have separate pools of resources based upon the subfaction, then the models & animations can be changed when the subfaction changes, allowing you to virtually morph a unit, without actually morphing them.
However, I *also* think we should consider a more comprehensive subfaction definition, one that allows you to specify rules for what happens to various units. Example:
<subfactions>
<subfaction name="path_of_nature">
<sounds>
... some sounds ...
</sounds>
<morph unit-type="battlemage" new-unit="pot_smoking_battlemage" />
<morph unit-type="tower_of_souls" new-unit="flower_of_moles" />
<alter unit-type="initiate">
<static-modifiers>
<hp-regen value="-4"/>
</static-modifiers>
</alter>
<change-team unit-type="daemon" new-team="none" ai="fight_only_when_cornered"/>
<script>
# Some lua
</script>
</subfaction>
<subfaction name="path_of_corruption"/>
</subfactions>Finally, I think that we need a mechanism to play a sound when the subfaction advances. Yet, I don't think that the above specification is adequate (for sounds). We should be able to play a sound or have something else happen when any ProducibleType is completed, currently, this only happens when units finish building buildings. I'm not 100% sure where to put this, perhaps in the ProducibleType's definition (which would end up in unit.xml/unit/parameters as well as upgrade.xml/upgrade)
In conclusion, I think that this is what we should do for now:
- Alter SoundContainer and new Animations (will rename to AnimationContainer) to manage multiple internal collections associated with a subfaction. I'll do this by creating interfaces for each (maybe a templatized single interface that can be used for both sounds & animations) and then when we load the unit.xml, decide which class to use based upon rather or not multiple collections for various subfactions are specified. This will allow a faction to alter both the appearance and (with existing features) the behaviour of units that already exist.
- Maybe add some sounds to the <subfaction> definition and a lua event (when lua is integrated), but nothing else for now. If the modder wants to kill, morph or alter the unit automatically, we can restrict them to lua scripting for now. We should keep the idea open of later adding the proposed <morph> and <alter> functions later, however.
- For simplicity, do not interrupt any skills that units are currently executing, even if commands that make them available are removed with the subfaction change. Because they will remain the same unit type, access to the internal data objects for the skill should remain available and not cause any program errors.
- Remove code that currently causes units to degenerate when they exist outside of the subfaction(s) they are restricted to.
- Maybe add a <completion-sounds> to ProducibleType or to SkillType, so that we can have any abject sound played when a skill is completed (including an upgrade skill used to produce an upgrade that changes the subfaction. There may be a 3rd variation of how to implement it that will make it available for the completion of any skill and the production of any unit. Maybe even a <start-sounds> and <end-sounds>?
I think that keeps it short and sweet for now and adds a tremendous array of possibilities. I would personally like to alter the animations and sounds in the FPM tree when the subfactions advance.
Feedback please?
