Category Archives: Battle

If there were vague fears for the future itching in the depths of men’s minds…

Posted on by

The following is the list of outstanding items that are currently on my feature list. The intention is to add all of these over the next few releases. They all have a varying level of difficulty to implement and some will be quick wins. I’m not going to commit to an order or when as much will depend on me being on a roll or not, but I will place a marker against the ones I original intended for the Summer Solstice release. If you would like to discuss the items in any more detail, please feel free to following the links to my GitHub page for each item.

panel_select, panel_think – Add Next/Previous buttons for Desktop – Summer Solstice

panel_select and panel_think need an additional Next/Previous buttons for moving through the pages. The mobile pager is not always obvious.

Option – Don’t swap after successful approach – Summer Solstice

Give the option to stop the auto switch to the newly recruited lord after an approach. Maybe this could be Enable / Disable / Ask with default being Enabled.

Option – Auto Seek – Summer Solstice

Add option to auto seek when entering a location. Doomdark’s Revenge already does this as seek is not a player action. Maybe it could be?

Option – Auto Approach – Summer Solstice

Add an option to auto approach when entering a location in LoM or when trying to move in to a location DDR.

Game Difficulty – LOM/DDR – battle algorithms

Adjust battle algorithms to give Doomguard more success. This would be a difficulty option.

Game Difficulty – LOM – Armies

Add more armies tracking Luxor, Morkin in LoM. This would be a difficulty option.

Game Difficulty – LOM – IceFear / Moonring

The ice fear is calculated based on Morkin’s distance from the Ice Crown and the distance from the warm glow of luxor. The ice fear is then fed in to other calculations.

increase the falling rate of Invigorated/tired, bold/afraid, + effect on + distance to Moon ring. This would be a difficulty option.

LOM: Campaign for Novel

Create a campaign that would mirror changes made for the Novel.

  • Lord of Silence
  • Tarithel the Fey
  • Utarg changing sides
  • Tunnel to the Tower of Doom

LOM: Gameplay Rule – Varied start positions

Allow various different start positions for the lords. Needs some thought to whom this should affect.

LOM: Gameplay Rule – Replenish Cup of Dreams

LoM – Locations that have a Cup of Dreams have the ability to respawn after x amount of time. This could be altered by the difficulty mode. Other ‘things’ could also be respawned. This would not be dissimilar to how DDR works.

DDR: Gameplay Rule – Armies continue to fight after attacking.

Currently in Doomdark’s Revenge AI Lords have the habit of leaving a fight. This option would make them act like LoM and stay until death or other lords leave. Another potential option would be for them to leave if they consider they are losing… Could also be linked to difficulty.

DDR: Gameplay Rule – Armies attack when near an enemy

Currently AI lords have the habit of not attacking enemies that are close by, unlike LoM. This feature would make them act more like LoM. Could also be linked to difficulty.

DDR: Gameplay Rule – Adjust lord death rules – Summer Solstice

In Doomdark’s Revenge the death rules for Lords should be tweaked to be more like LoM, meaning that can’t die until their army is wiped out. And not if attacking a critter with an army.

panel_map: Add Pinch and Zoom

  1. Add Pinch and Zoom to map for Mobile
  2. Add Shift and Mouse move for Desktop

Add guide and novella to embedded browser

Rather than open in a external browser, open the novella and guide in a embedded browser.

Should we prepare to do battle against the wind and snow?

Posted on by

I was looking at a battle issue reported recently that battle reports were not always being displayed. I’ve had reports before that the AI Lords don’t appear to engage in battle the same as the original, but I have tested this many times and not been able to find an issue other than the AI being unpredictable and a little shaky.

I had recently done some testing while adding the new game rules in place and had my lords attacked, and indeed failed an approach of lord and been attacked, and attacked a lord and battle had commenced, so on the whole it seemed to be working.

I poured over the code again to check the AI conditions of battle and noticed something interesting. The rule is that if the lord can’t walk forward and it is dawn and they are not blocked, then there is a 50% chance of them staying in the current location and ending their turn.

Analysing that a little; blocked means exactly that, they cannot move in the direction they want to under any circumstances. This is usually because of Icy Wastes or there are too many people in the location. Can’t walk forward is usually a transitory check, something in the location they are in or entering could potentially stop them entering, but nothing that would break the game. The Dawn check is just helping to differentiate moving into a location during the turn from moving out of a location at the start of the turn.

The code that makes those decisions is separate from the code that is handling the AI Turns logic. So I went to look at that to check under what condition the lord could not walk forward, and the thing that caught my eyes was – if there is an enemy in the current location. Combine that with the checks in the AI Turns logic and what you have is, there is a 50% chance that a lord will leave a battle at the start of his turn, but if they enter a location with an enemy they will always stop to fight.

The problem was that this flag was being reset by another piece of logic which was actually more to do with the player and not the AI, and also some shared LoM logic. The net effect was, if you attack an enemy lord, or have a failed approach, then the enemy will pretty much always move on and not engage. Now, this seems counter to what my testing has shown, so I can only posit that there was something else happening in these situations that was keeping the enemy at the same location.

Once I realised this it was a quick fix to isolate the piece of code that was overwriting the can’t walk forward flag. However, this then highlighted another bigger issue, and that was that the lord was not considering the enemy as their enemy, and thus the trigger was not occuring.

Again, I checked out the area of the code that handles this, and clearly it was based on LoM, in that Luxor is the friend, and Doomdark/Shareth is the foe. But this does not take in to account the multi-race nature of DDR. So what in effect was happening is that the AI was not really considering the players lords as enemy, or indeed not always correctly considering the enemy AI lords as enemy, which means they would often over look them. Obviously there were fighting, but again I think other issues were causing them to stay in the location of another lord. And as long as multiple lords are in the same location, the battle algorithm would get the friend/enemy check correct and they would fight.

Now, this looks like it has always been wrong, ie: nearly 10 years since I released the games. But I suspect the problem is actually due to the merging of the code bases and likely crept in in the later stages of v1 and then rolled over in to v2.