Read-only archive of the Armageddon Games Forums Archive (2000–2026) · About this archive

Magic Octroks can't find the bait

8 replies · 22,922 views · Started 28 December 2018

Hi! :smile-new:

If I put a bait on the screen, that octroks comes to it (as it should be). But if anything is between the bait and the octoroks, a tree, a stone or whatever, they can't find the way. And that even, if the bait is only two tiles away.

User posted image

It stays as seen on the screenshot: The right-sided octoroks stays on the right side of the tree and NEVER come to the bait.

What can I do (except removing all barriers)?

Normally they find the way to the bait:

User posted image

Pic 1: The enemies are anywhere.

Pic 2: I put the bait on the screen and they come from wherever they were before.

Pic 3: Normally it also works with octoroks (if hunger is set)

It all depends on pathing. ZC Enemy AI isn't that advanced. Remember that the screen layout is pretty much defining a 3D object, in a 2D space. That#s a tree, not a bush, and its intended scale is a depiction of a forest patch.

In ZC, even if the Octorock was attracted to the bait, it'd hit the solid combo, and change direction.

It would be possible to write more advanced pathing as an npc script, but believe me, writing realistic pathing routines is absolute hell.

You can try tinkering with both the enemy step speed, and the hunger value. One issue with high step, is that the read-ahead for a solidity check is at a greater distance.

ZoriaRPG wrote:writing realistic pathing routines is absolute hell.

What is the problem? The bait is anywhere and the enemies too (elsewhere). And between the enemies and the bait a tiles. Solids and others.

User posted image

Ok, a single fast way doesn't always exist, because it doesn't matter if the octrok for example goes down, left, left, left, down, left OR left, left, left down, left, down OR down, down, left, left, left, left... or whatever. The route is the goal.

A magic octorok can kill you in a few seconds, but a tree between the octorok is a problem? :smile-new:

The bait is to the left, so it tries to go left. It can't, so it goes down instead. Then it sees that the bait is above it, so it goes up. Then it sees that the bait is to the left, so it tries to go left, but it can't...

Proper pathfinding would be a lot of work, but randomly choosing between the vertical or horizontal direction when moving toward bait would be enough to mostly solve this simple case. I don't believe the NES version does anything like that, though. And a column of two or three trees could still be an issue.

Joeiiii wrote:What is the problem? The bait is anywhere and the enemies too (elsewhere). And between the enemies and the bait a tiles. Solids and others.

User posted image

Ok, a single fast way doesn't always exist, because it doesn't matter if the octrok for example goes down, left, left, left, down, left OR left, left, left down, left, down OR down, down, left, left, left, left... or whatever. The route is the goal.

A magic octorok can kill you in a few seconds, but a tree between the octorok is a problem? :smile-new:

In software logic, valid paths look more like this:

User posted image

Each of those arrows is a valid node, from which you derive coordinates, and movement to go from A to B. In theory, the object (circled) may never reach B, because it can walk an infinite path. That's where logic such as A* helps:

That's an algorithm to resolve stuff like this, but it isn't perfect, and implementing it is a complex process.

ZoriaRPG wrote:In software logic, valid paths look more like this:

User posted image


Where is the logic?

The command should be (and in the most causes it is so): There is a bait in the left corner. Find the fastest way and run like hell!

The last picture is an extreme example with 15 solid combos. It should bei never a problem, but in my quest a single tree is the problem.

OK! If it can't solved, it is so. :smug:

Another question: What does "duration = 768" in the bait-item means?

I believe this has been implemented in resources/include/std_zh/astar.zh:

[HTML]// Credits to Lejes for making the A* algorithm actually work in ZC! I probably wouldn't have ended up making my version (which is older than this) work without the assistance!
// Optimised for 2.55 on 24th May, 220 by ZoriaRPG. [/HTML]

I'm impressed that Zoria implemented this all the way back in 220 AD. Tell me, can I borrow your time machine?