Element definition

[donbonifacio]

We will assemble and represent elements on the arena (#3). Those elements can be puppets (#1), controlled by the API or by players. But there's also the environment: walls, floor, etc. This env elements may also have some logic, and we need a way to contemplate it.

Some use cases:

• A coordinate (coord x y) can have several elements, maybe placed on the Z level; however it would be nice to obtain the list of elements on a x,y coordinate
• When elements move into coordinates, the elements on that coordinate will do something. Will allow the move (basic floor) or prevent the move (walls); will kill the element (void/water?); will add some aura to the element (healing spree, damage boost zone, poison trap)
• Bullets and attacks overall may also be elements
• Stationary map elements that have simple logic (for example, a camp fire, where we need to change the sprites to make the animation

[jqmtor]

Although the idea of having a general concept of element is appealing, I feel it might be too generic.

• Scenario elements or stationary elements seem to have very different properties than attacks or other kinds of transient elements. For example, an attack looks like the kind of thing that is affected when entering a coordinate, and it doesn't have any effect on other elements. What I mean is that scenario related elements have a reactive behaviour, while attacks and so on have a proactive behaviour.
• I think we should consider not to use the Z coordinate to simply pile the elements. Maybe it should be possible to have multiple elements on the same exact coordinate, and use the Z coordinate with the semantic meaning of a physical dimension, just like the others, i.e. use it to allow catapult attacks, flying units and stuff like that. Using it to pile the elements would limit our possibilities and maybe if the wanted an element that affected the behaviour of only flying units, it would be more difficult to implement.
• I think we should try and not implement presentation/animation like logic of the elements. I understand the rationale and why it can be compelling to establish a relationship between the two. If an element is a camp fire that deals damage to units standing over it, the presentation should be set accordingly, and therefore, behaviour and logic are related. On the other hand, just separating the presentation completely from the behaviour would give us some flexibility, i.e, we could have multiple scenario elements that deal damage to characters standing over it and set completely different presentation elements (acid swamp, fire camp, cutting plants). My feeling is that we would win in separating these completely, even if we need to guarantee that the presentation reflects the behaviour of the element manually. I am not sure I understood you completely on this matter, and I am not sure I made myself completely clear, but hopefully we will clarify this as the discussion advances.

[jqmtor]

Oh, I forgot to mention something else. While it makes sense to evaluate all the effects of a reactive element when a proactive element enters it, I think it could make sense to have the concept of path. A path is represented by the collection of reactive elements that a proactive element has to pass in order to reach its destination (the target enemy of an attack, the destination location of a movement and so on). A path may be valid or invalid, according to the action and the reactive elements that belong to it. For example, a projectile attack is invalid if any of the reactive elements on the way blocks movement. Would this be better than to simply evaluate elements one by one and sequentially when an action is performed? This just came up to my mind and maybe it doesn't make much sense, but let me know what you think.