no, they're defined by the base data pack (aka the original game conversion) :)

https://github.com/SFTtech/nyan/blob/master/doc/nyan.md says: "Defined in the game engine"
Maybe I'll change that there.
edit: changed that.

thx

The engine has to support animations, it therefore defines Animation and we have to instance VillagerWalking(Animation): image : ... and reference it here.

Maybe Ability() should get a member `animation : Animation'.
CooldownAbility does not need an Animation, but since every actual Ability will need an Animation, CooldownAbility can stay abstract. Right?

I don't think so. For example, castles don't have an attack animation. And if training units/researching techs/attack stances etc. also become abilities, neither do they.

if for example buildings have an ability without animation, they could reference to their static picture. Maybe that's a dirty workaround. The only alternative I see is to include an AnimatedAbility class.

I'd say the animation is a mixin, mainly used in abilities like Walking(Ability, Animation). If that ability becomes active, we can check in the engine if the ability also inherited from Animation, then activate and display the data specified there. That way, we can add custom animations for nearly everything we want but do not enforce it and can fall back to the standard walk animation etc.

Everything that has a (possibly varying) location ingame. Probably has a hp : float member.
Can't tell yet if we should add buildings as units as well or introduce another parent object for that.

We also have to think about if we wanna have a MoveAbility or simply create a engine-defined MovingUnit. The result is of course the same and i'm not sure if movement shall be done by some member value (the ability set) or by another base object. For nyan itselt it doesn't matter, depends how we wanna design the engine.

Everything that has a position has a look. So add an Animation or Sprite member?

I think so, yes. Each Unit needs its idle look.

References can be recursive of course, they can point to each other. But the carry ability would also be implemented in the engine i think, in a way that if the unit has the CarryAbility, nyan doesn't know about what the unit actually carries, but nyan only tells us it can carry 20 weight units, and that one unit type elephant will consume 5 weight units. That means each unit must define its weight :).
The engine then checks for each unit to board if current_weight + weight_of_new_unit_to_board >= max_weight and decides by that if it can board.

we have to tell somehow, what units can go inside: many units can garrison the castle, but not the towncenter.

Maybe we can define types of units: infantry, cavalry, ships, siege. this could help with the allowed_targets member in attackability and with the upgrades from research.

Exactly, the original game has those unit types available for us, we can represent it simply in the inheritance hierarchy. (Huskarl(Cavalry) e.g.)

The possibility of attacking buildings must also be implemented in the engine. Nyan provides the information n units (of size x?) can garrison in the building. Then those people can either regularly attack from there or the engine multiplies the attack damage for the building.

The damage info is a combination of nyan and the engine. The building itself must define a collapse threshold (in percent maybe) which the engine respects to send units out.

The relic gold is purely implemented in the engine which provides a "ResourceGenerator" object, which the relic inherits (Relic(ResourceGenerator)) and adds to the set(resource_type) += {Gold} and rate = 10. Nyan is not aware of the game mechanics, this is always the job of the engine (that was by the way the key enlightment i finally had to get a sufficient nyan design).

jup, the resource is part of the engine and the data pack can then create arbitrary resources.

This may be a very good idea. I've never really thought about the ui integration, but having another mixin for that may be the way.

we still need a way to keep all the elements in order and allow 'pages'.

I'd say the order and paging is done by categories first and addition order. If mods remove elements the layout won't get fucked up and we can also easily add new elements. If we use numbers for positioning things will always conflict. Tough thing, but just storing it via orderedsets is the easiest way i think.

In the original game, the relic thing is actually a new unit: "monk with relic". This is kinda stupid because it assumes only monks can carry relics, which is fine in age2 but very unsuitable for us.

So we can prepare the combination of a Carryable and some Unit in the sense that the carryable has to define its size and position, and we can then render the carryable in front of the unit. We can even define workaround replacement graphics that way in the sense that if it's a "known combination", the combination image is used (aka the monk with relic animation). How we model this in nyan I cannot tell right now (and haven't thought about it yet, so very good catch here).

The image metainformation should still be done in the good old .docx files as they're currently describing where a subimage is in one image. Things like animation speed, looping etc is defined in nyan though.
The engine will provide a nyan object Sprite which has a file member and others like the speed, etc. When this sprite is then required to be shown (e.g. because a unit uses it as its image) the engine will handle everything else internally, like parsing the subtexture information from the .docx, drawing it etc.

Should I rename the Animation class to Sprite?

I think animation is fine, we can extend it to a 3d model animation in a few years then hehehe.

I'd name them ResourceSpot, also defined by the engine (as it has to support giving out resources at that point).
Deer is a Animal which is a Unit i guess (so you can kill it), and if it's dead, like with all units it has to reference its dead form (to have the animations etc). So there is a DeadDeer(Animal, ResourceSpot) with hp = 0 and a resource type and amount. The gathering itself, the amount decay etcetc is done in the engine, just the decay rate is specified by nyan again.

I'm not sure why DeadDeer needs to inherit from from Animal. It needs:

1. A dying animation.
2. A rotting animation. After RessourceSpot.amount dropped to zero, play this and hold the last frame for like a minute, then remove this Unit completely.

Between 0 and 1 we need to decide if we want to hold the last frame from 0 or the first from 1. To me it looks like they're the same in the original assets.

My idea: We could add dying : animation to Unit. This is played when our unit dies. After that, create the referenced Deadunit(Unit). If it is a RessourceSpot, wait until RessourceSpot.amount dropped to zero.
Then play deadunit.dying (or deadunit.idle), which is the rotting animation.

yes, could also work. I think you're right that all units have a dying animation but many won't have one. also we somehow need to model that the living deer is not a resource spot.

Basically we have multiple possibilities to model this:

• store everything relevant for the dead deer in the living one already, aka rotting_animation and resource_decay and resource_type etcetc, this is the "bad" approach i'd say
• have a separate DeadDeer that inherits from (original deer, resource spot) and updates graphics etc. the original deer then references to that object as on_death_become : Unit = DeadDeer. this requires a forward declaration which will be allowed in the next revision of the nyan design.
• use abilities to test if the deer can even die. that ability then performs the death animation, another ability performs the resource collection, another one the decay.

I think the best approach is having an ability "being hunted" because it's different if a villager or a tribok killed it for the collectible food. That ability is implemented to change the unit type to DeadDeer once it is killed. The ability is included in the Deer abilities set, and also requires a forward declaration. It's the most overkill but also most extensible and awesome approach i'd say.

Heh. Tricky thing this. Basically in the original data there is a "magical color" which is then recolored. Our approach is to paint that magical color as blue with an alpha value of 254. The fragment shader checks if the alpha value is 254 at some point, then looks up the blue tone, then replaces it with the matching yellow or whatever tone, and draws it.

In the original game this was done in assembly, but we process it in opengl with the teamcolor shader.

this is called "decay" in the original, which i think is better.

as noted in the Deer-discussion above, not every unit has the ability to die. then we'd have to insert a placeholder or an empty value for dying, which we wanna avoid.

so, remove dying and death, right?

Probably an AnimatedBuilding, also the building annexes like the towncenter need to be modeled out of parts.
They have an ordered set of sprites (which may be animated) so the draw order is fixed.

we can either keep the current docx format or add a new one to just contain the frame positions and ids. i wouln't store information about the texture itself in nyan, the implicit reference to filename.anim or something might be better. the current docx approach is very simple and works well, we should load it on demand though and not on launch.

Probably must be split. Healing, Repairing and Healing_inside_a_building must be separate because its have different logic behind it (eg. repair has cost).

Healing_inside_a_building could also be megred with Garison.

It will always have the same sign, so better positive which can be stored in a unsigned int

• Friendly fire
• Min range
• Area of effect
• Consider projectiles

what do you mean with "consider projectiles" and "area of effect"?

Original game: Two different units: monk and monk with relic

I'd do it with the ability to carry things, and a relic is a Carryable (and ResourceProvider when garrisoned in the monastry). To solve the asset combination the thing to be carried could be able to provide a overall carrying graphic, so the monk-with-relic graphic is activated as soon as it is picked up.

ResourceProvider when garrisoned in the monastry

@TheJJ Now that you mention it, I'd even go further than that and regard the relic as some kind of BonusItem or BonusProvider. While it's true that AoE2 see relics only as another source for gold income, AoM's relics also provide boni like cheaper unit creation cost, faster research time. RoN has something similar, where rare resources on the map provide a bonus to the player who places a merchant on it (and rare resources can be controlled by multiple people). I think modders would also get very creative with this construct.

how would BonusProvider look like?

It would be similar to a ResourceProvider, but instead of giving a Resource, it provides a Bonus to the player who controls the BonusProvider. Boni could give stats upgrades (like 5% faster unit creation), area of effect buffs (like the generals in RoN), constant flow of resources (e.g. relics and feitoria in AoE2) or give a new ability to a hero who equips the Mighty Staff of Midgets, for example. Boni could also be temporary, permanent or tied to an item/unit/building.

In nyan a Bonus would probably be utilized as a nyan patch. Similar to the Tech() patch. BonusProvider on the other hand would be like a ResourceSpot:

Item():
     name : text

Bonus():
     timeout : float
     updates : set(NyanPatch)

ResourceBonus(Bonus):
     resources : Resource
     rate : float

BonusProvider():
    condition : Condition
    is_temporary : bool
    boni : set(Bonus)

# Content
Relic(Item, BonusProvider):
     name = "relic"
     
     condition = garrisoned
     is_temporary = false
     boni = {RelicBonus}

RelicBonus(ResourceBonus):
     resource = {Gold}
     timeout = -1.0
     rate = 1.0

     GoldBoost<resource>():
         amount += 2.0

     patches = {GoldBoost}

Or something like that. I hope i got the nyan syntax right.

• Cost
• Have limit (The max number of units of this type that a player can have at an instance)
• Had limit (The max number of units of this type that a player can create)

• Cost

what type should cost be?
orderedset(int) (what order?) or the unimplemented dict(Ressource, int) ?