project-hiros's Issues
Implement flying versus walking creatures
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.
Remove dependence of stack size from action priority
The ordering in the priority queue should only depend on the unit speed, not on its stack size.
Research for featuring sounds
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.
Implement retaliation
Enemy unit tiles should not be walkable
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.
Implement ranged attackers
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%
Cursor wrong when attacking just outside of range
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?
Implement a proper combat log controller
Combat log should be updated once per turn (or if hero takes action), with relevant information about the action taken in the turn.
Dying animations loop even though they shouldn't
Implement terrain
The battlefield should be able to contain terrain tiles, i.e. tiles which are unwalkable and obstruct the range of walking creatures.
Initiative queue still slightly incorrect
It prioritises army position over player alternation, i.e. player 1 position 3 plays before player 2 position 4 (when at equal initiatives)
Introduce proper positioning of troops at battle start
They should be spread properly, put on proper y-positions, and the addition of formations should be later introduced.
Implement a breadth-first search as range calculator
It's a small adjustment from the current algorithm, but better be rewritten in a pure function.
Implement a proper "Action explainer" (Combat footer)
On button or tile hover, the combat footer should give information about the action that will be taken upon clicking on said element.
Implement attacking units right outside movement range
Enemy units one tile outside the movement range should also be attackable.
Rewrite the way action chains are handled
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.
Add implementation for the 'Wait' action
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.
Add and improve creature sprites
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
Implement large creatures
Some creatures take two tiles, and can be interacted with as such.
Add implementation for the 'Defend' action
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?).
Make the creatures follow their found path, instead of flying to their destination
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 .
Implement non-teleporting movement
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
Add different creature classes
There's only the swordsman now, gotta write some more creature classes
Add a little panel next to each creature with the size of the stack on it
Optionally, colouring it with a player-associated colour, to easily distinguish between different player troops
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.