Refactoring abilities & input
Mainly refactoring work this week, with the purpose of unifying the handling of abilities by the player or the AI. Concrete outcomes of this refactoring process:
- New WIP ability, usable by both player and AI: fireball.
- We need to select a target position
- It has an area of effect
- It's effect is "fire damage"
- It spawns a particle system, initialised with the positions of affected tiles
- Fireball itself is a projectile, so if it hits an obstacle, it will stop (and explode)
- We can setup the skill to be able to shoot multiple ones, homing ones, or both
- AI can use the fireball skill too, by evaluating the "score" of each possible tile, determined by the possibility to hit ourselves (-5 score), allies (-2 score each) and enemies (1 score each). A score greater than 1 means "good enough"
- AI applies a recency-based weight when choosing a skill to execute. So, a no-cooldown skill that was just executed will have 75% weighting which goes back to 100% after several standard actions. This is to avoid repetition of maximally scoring abilities, and make the AI hopefully feel less robotic.
- New WIP ability: magic missile.
- Like fireball, but does damage to a single tile
- Number of projectiles can be greater than one, and for each projectile we can select a different target. Homing missiles still need a clear path to a destination
- Reworked item transfer interface a bit, so that when transferring items between player/container or player/ground, we can select a number of items from container, a number of items from the player, and then click a button to make the transaction. So that with a standard action we can move e.g. 2 items to the container and pick 3 items up.
- Cleared up input/keys a bit (still far, far from final though). Now we have the following categories of actions:
- Ability-based: Fireball, melee attack, ranged attack, use item, etc. These typically need to be configured with some gui (which item? which direction? etc). Most of these would not appear in an input configuration file, as we have just too many. Instead, they'll be mapped to…
- Hotkeys: so that I can map any ability-based actions to hotkeys. Whereas the essential actions are limited (move in a direction, primary action, etc), most abilities have to be mapped via hotkeys.
- Actions that do not require a gui, e.g. quicksave, quickload, teleport, look.
- Press-and-hold actions, e.g. highlighting of creatures or objects, minimap view