I enjoyed reading the links. Yep, monster AI is fairly rudimentary in IVAN as it stands. Petrus standing around in a gas cloud is a recurring example that spurred the suggestion quoted above. Improving the AI is an area we can potentially get more gameplay bang for our coding buck. The code additions are often minimal, and are suitably self-contained.

Does anyone have more observations about AI behaviour that could potentially be improved upon, or AI that can be added to make improvements?

EDIT: AI improvements listed here:
* Banana growers getting stuck outside the shop
* Pets avoiding standing next to the player, get them to stand next to the player, or improve this for sci-talk purposes
* Monsters avoiding environmental dangers
* When an NPC is in StandIdleAI(), get them to move in response to hazards like gas clouds and return when the home square is safe
* Monsters using equipment, wands, throwables and rooting around in chests
* Social creatures, pack animals, simple group behaviour
* Ambushes

And allow stethoscopes to be applied to doors to gain info like whether it is booby trapped, or whether a monster is in the room.

Oh yeah, I didn't think of that. I really need to play more often. Maybe certain chests or lock types should have a flag which says whether they are encrypted or not. If not encrypted, then you can polymorph the lock.

If i was a first-time player I'd be inclined to think zapping a chest - or a door for that matter - would change the lock type. But that still wouldn't help to keep oct/hex locks secure.

How do we know the chest polymorph doesn't affect the items inside already? (I'm being purposefully ignorant by not looking at the code to check)

It'd be cool if there were puzzle rooms to break into.

That is probably the right way to handle this problem.

That's a nice exploit It's difficult to find fair ways to curb these exploits. There's a multitude of ways to fix it. Blaming item destruction on the player is one way, but as you rightly point out, how could the shopkeeper possibly know the earthquake was the player's fault? Another way might be to prevent the sale of mustard gas to shopkeepers, but then that would seem like an embargo against the player. Another way would be to prevent mustard gas grenades from exploding due to an earthquake, but again, why would gas grenades be spared from destruction? Or maybe when the gas grenade is sold to the shopkeeper, it gets sent to the inventory of a shop guard for safe keeping? Or maybe the gas grenade gets put in a safe box in the shop, a bit like a bookshelf, where items are safe from explosions and earthquakes? Maybe the gas grenade is kind of incomplete, and it should work like the holy hand grenade?

Here's a question: Can un-set mines lying on the dungeon floor explode due to earthquakes, or can only set mines do this?

I was wondering when that question would come up. I'm pretty sure Attnam is placed first, then the game searches for the shoreline with an open area of water nearby and then puts an island there with under water tunnels in between. I have historically been critical of this method, but looking harder at the world map generator has caused me to be humbled by the wisdom of the original devs. It is a simple and practical way of making sure that the core locations show up.

There's a list of candidate locations (yellow dots). I imagine what will happen is that we retain the old placement method for the original locations, with Attnam as one of the yellow dots. If the original locations (say UT exit) are in the same place as the candidates, then those candidate locations are eliminated from the list.
We would need to re-order the list with a nearest neighbor routine with Attnam at the centre, so subsequent locations are situated in a cluster about Attnam town.

They can be deeper in the wall than one square.

That's interesting. Do the attached images show how the character is reflected in the mirrors?


I have been plugging away today and I have used python to do some poisson disc sampling to create model for IVAN to place worldmap locations randomly but evenly spaced out. The first attached image shows the sampled field (red dots) overlayed on the world map. The second attached image shows where the red dots coincide with land, which become yellow dots. The yellow dots represent possible valid locations to put a dungeon entry point.