tihawk / project-hiros Goto Github PK

The movement on the grid has to follow a path-finding algorithm, instead of just flying to an empty cell. Obstacles have to include:

• any creature
• terrain obstacles
• walls turrets and closed gates

On button or tile hover, the combat footer should give information about the action that will be taken upon clicking on said element.

The pathfinding is implemented, but not used for actually calculating the path that the front-end object takes, only for back-end logic. Related to #13 .

The battlefield should be able to contain terrain tiles, i.e. tiles which are unwalkable and obstruct the range of walking creatures.

The ordering in the priority queue should only depend on the unit speed, not on its stack size.

There's only the swordsman now, gotta write some more creature classes

One can now attack enemies one tile outside of their range (which is a correct mechanic), but the cursor shown while doing so is wrong (not-allowed)

@Promtastic can you look into the logic tree here, and think about a solution?

In essence, change the range calculation for flying creatures to be only radius dependent, of course while still excluding populated tiles.

Potential issues:

• the path-finding algorithm has to not exclude non-empty tiles, while still not allowing for landing on populated tiles.

There's only the swordsman creature sprite. Sprites are wrongly centred, resulting in jerky animations. Adding more of these for the new creature classes will be slow and tedious, resulting in the same bad quality animations. Refer to issue #2

If a creature is told to defend, this automatically ends their turn, but gives them (20?)% bonus to defence until the next action (is that their next turn?).

https://heroes.v.thelazy.net/index.php/Retaliation

It prioritises army position over player alternation, i.e. player 1 position 3 plays before player 2 position 4 (when at equal initiatives)

Optionally, colouring it with a player-associated colour, to easily distinguish between different player troops

Combat log should be updated once per turn (or if hero takes action), with relevant information about the action taken in the turn.

#4

Research topics:

• whether dynamic sounds in the browser are sustainable in general
• how are sounds handled in react apps
• how and where to store these sounds (formats, archives, lazy loading and so on)

This list might be edited.
Post research results and references as comments here.

Some creatures take two tiles, and can be interacted with as such.

Due to enemy unit tiles being walkable, units are able to teleport beyond their range by attacking an enemy unit sitting in one of the furthermost tiles inside the walkable range from outside the range.

WAIT PHASE
Creatures play in increasing order of speed.
If there is a speed tie among opposing units then player's A unit will play first if player's B unit has
played just before and vice versa. Further turn order simply alternates between units of player's A
and B.
If there is a speed tie among units in the same army turn order is determined by left slot rule (so, not
opposite, but the same as in normal phase).
SPECIAL CASE: TOWN SIEGE WHEN FORT, CITADEL OR CASTLE BUILT
Turrets always play before the attacker’s Catapult; Artillery and Ballistics skills are irrelevant.
If the Turret waits it will take its turn in War Machine phase.
If the Catapult waits it will take its turn in War Machine phase.
PECULIARITIES
If the unit is unblinded/resurrected/unpetrified (no matter when it was blinded/killed/petrified) it
will take it’s turn as soon it is of highest speed if it is a normal phase, or of slowest speed if it is a wait
phase. Alternating and left slot rule apply normally.
If a unit makes a move (or gets bad morale) and is killed and resurrected it will not play again in the
same round.
Cloned unit will follow the alternating rule, but it will not follow the left slot rule: if there is a speed
tie between 2 or more stacks in the same army, and Clone is cast on either of them, cloned stack will
play after all other stacks have played.

ref:p31

Enemy units one tile outside the movement range should also be attackable.

Right now walking, attacking and so on are handled by time-interval promises in the server, after which the new state is send to the clients. This looks a lot like promise hell, and it would be beneficial to refactor this in a way where the responsibility for action chains is shared between server and client.

One option would be to aggregate an action chain in the server, and send it to the client. The client then deals with the action chain by animating the creatures, and finishing an item from the chain as an animation ends. Since it hasn't yet received an updated state, it can freely update its own, without it being overwritten by the server
At the time of finishing the chain, it emits a resolution to the server, and the server sends the new state to the client.
If the client fails to handle the chain withing a time-out period, the server can enforce a state update to that client.

It's a small adjustment from the current algorithm, but better be rewritten in a pure function.

They should be spread properly, put on proper y-positions, and the addition of formations should be later introduced.

Creatures with range attack capability would have to be able to perform it, and still use melee attack when adjacent to another creature. Range attackers have a finite amount of shots.
The following penalties apply:

• When range more than 10 hexes - range penalty (50%)
• When enemy behind wall (during siege) - obstacle penalty (50%)
• The two above are cumulative
• Melee attacks only deal 50%

Ranged attack
Range penalty
Obstacle penalty