[PC-DOS] HEROQUEST by Gremlin (1991) REMASTERED, - Modding, Bugfixing e Traduzione ITA/ESP devlog Opzioni

[raul]

Evoluzione del codice di ricerca dei mostri:

1° Movimento dei nemici con trappole.
2° Movimento “infinito” dei nemici nei corridoi
3º Limitazione del movimento reale del nemico.
4º Inseguimento primitivo del nemico nei corridoi.
5º Migliorato il movimento dei mostri nei corridoi.
6º Disattivare le icone di ricerca nei corridoi con i mostri
7º Correzione delle indagini nei corridoi dei mostri

Messaggio modificato da raul il 27 Nov 2024, 20:00

[TheRuler]

Con questa modifica i mostri non dovrebbero più muovere di "infinito" ma solo del loro movimento.

0x27CD change to 79
0x2807 change to 79
0x2838 change to 79
0x2864 change to 79

La cosa incredibile è che il codice che recupera il movimento massimo dai profili dei mostri c'è! ESISTE! Avevano credo solo sbagliato la tipologia di salto condizionale.
Usavano jump if not carry (che vuol dire salta se non c'è resto), ma dovevano usare Jump if not sign (ovvero salta se è negativo).

Le mummie si muovono finalmente di 4!

La prossima sfida ora è quella di permettere ai mostri di avanzare comunque, anche se non riescono ad arrivare in corpo a corpo. Ci sarei già riuscito in teeoria ma non a bene, perché si avvicina, rimane a distanza ma attacca lo stesso

[raul]

Con questa modifica i mostri non dovrebbero più muovere di "infinito" ma solo del loro movimento.

Nel mio caso, finché non si risolve che i mostri ti inseguono, preferisco che abbiano un movimento “infinito”. Se una mummia ha un raggio d'azione di sole 4 tessere senza la possibilità di inseguire l'eroe, riduce notevolmente la sua area d'azione.

La cosa incredibile è che il codice che recupera il movimento massimo dai profili dei mostri c'è! ESISTE! Avevano credo solo sbagliato la tipologia di salto condizionale.
Usavano jump if not carry (che vuol dire salta se non c'è resto), ma dovevano usare Jump if not sign (ovvero salta se è negativo).

Devono essersi confusi o semplicemente averlo lasciato a metà. Un altro mistero nel favoloso mondo degli affari dell'azienda.

Le mummie si muovono finalmente di 4!

Questo movimento si traduce anche nelle stanze?

La prossima sfida ora è quella di permettere ai mostri di avanzare comunque, anche se non riescono ad arrivare in corpo a corpo. Ci sarei già riuscito in teeoria ma non a bene, perché si avvicina, rimane a distanza ma attacca lo stesso

Bene bene, a poco a poco state migliorando il codice dell'“IA” dei mostri e anche se ora è primitivo, sono sicuro che sarà sviluppato a poco a poco nella versione finale della caccia al tesoro.

Al momento il codice è diviso tra movimento nelle stanze e nei corridoi, ma anche se dovesse rimanere così, è un passo avanti davvero gigantesco in questo gioco. È bello vedere come si sta evolvendo il codice.

Potrebbe elencare l'evoluzione del codice della caccia al tesoro?

Messaggio modificato da raul il 18 Nov 2024, 07:10

[TheRuler]

Nel mio caso, finché non si risolve che i mostri ti inseguono, preferisco che abbiano un movimento “infinito”.

Puoi tenerlo così ma ricordati che se lasci un mostro in un corridoio e questo ha un percorso "positivo" (cioè senza che debba tornare indietro) può fare anche mezzo dungeon, e questo è un problema, perché nella porzione di memoria ha spazio solo per 32 passi. Quindi non farli correre troppe maratone.

Questo movimento si traduce anche nelle stanze?

Sì, quella parte del codice è globale.

Potrebbe elencare l'evoluzione del codice della caccia al tesoro?

intendi tutti cambiamenti delle versioni? dalla originale alla attuale?

[Nyerguds]

New code in action (monsters can attack and move across different corridor sections):

Oh, that's amazing.

Con questa modifica i mostri non dovrebbero più muovere di "infinito" ma solo del loro movimento.

0x27CD change to 79
0x2807 change to 79
0x2838 change to 79
0x2864 change to 79

La cosa incredibile è che il codice che recupera il movimento massimo dai profili dei mostri c'è! ESISTE! Avevano credo solo sbagliato la tipologia di salto condizionale.
Usavano jump if not carry (che vuol dire salta se non c'è resto), ma dovevano usare Jump if not sign (ovvero salta se è negativo).

Le mummie si muovono finalmente di 4!

So this is the thing that decides whether the player is in range? If they have enough steps to reach the player?

La prossima sfida ora è quella di permettere ai mostri di avanzare comunque, anche se non riescono ad arrivare in corpo a corpo. Ci sarei già riuscito in teeoria ma non a bene, perché si avvicina, rimane a distanza ma attacca lo stesso

Won't that make enemies all around the map move towards the players, instead of guarding their corridors? That might not really be good. Or does this only trigger when the monster is discovered?

---

This all reminds me of the HeroQuest-based little Java project I made in uni, where the AI response was actually based on line of sight; the enemy would only chase the player if they could see them, and if they could move that far. I didn't like the whole "battle mode" switch though, so instead you could run away during battles, and spend action points on either movement or attacks, and the enemy would chase after the player

(Note, this was caused by the fact the game rules we were given were incomplete and made no sense, and I never played the real HeroQuest. Enemies were supposed to be 100% static until engaged, and yet there were ranged weapons and spells... which you weren't supposed to use until you went into battle mode? It was nonsense.)

The funny thing was that due to the way the game functioned, you could only be "in battle" with one enemy, and so you could use the fact you were "in battle" with a lower-level enemy to sneak closer to big enemies without them being able to attack you. This was useful because this game actually had enemies with ranged magic attacks.

Then again, you kind of needed those tricks, since the AI in that game was pretty overengineered. The "battle" ended when line of sight between the player and enemy was broken, but with a clever twist: the enemy would remember the point where it last saw you before line of sight broke, and would still go to that point and then look around from there to see if it could still find you and continue the chase. Against high level melee enemies, this was extremely scary, since you'd usually take those on with ranged attacks and stay out of their melee range.

Messaggio modificato da Nyerguds il 18 Nov 2024, 12:32

[TheRuler]

So this is the thing that decides whether the player is in range? If they have enough steps to reach the player?

It seems so.
The coders actually didn't care, since no monster couldn't see or move outside his native section, whereas it was a room or a corridor.
When I broke that limit (simple room number comparision check) the movement problem arose. A monster could have travelled from a dungeon corner to the opposite one!
Obviously overwriting stuff in memory, since the maximum steps permitted is 32 (don't know why they left so much space in memory for the steps, cause the maximum would have been a range within a room).

Found in the making the logic that read the mosnter's path. In DS:40A2 is stored a sequence of words that specify directional movement:
00 01 = down
00 FF = up
FF 00 = left
01 00 = right

It's basically the path the monster will follow. Animated and updated in one shot by a single call.


Next step is to understand how that list is built, and make it less stupid (the code doesn't take into account to move further away from the hero to search for a viable path. It can only go towards the hero and only if X and Y differences are positive. Monsters cannot go around objects if the hero and the moster are on the same X or Y).

And for God's sake they cannot make magic or ranged attacks!

[Nyerguds]

Next step is to understand how that list is built, and make it less stupid (the code doesn't take into account to move further away from the hero to search for a viable path. It can only go towards the hero and only if X and Y differences are positive. Monsters cannot go around objects if the hero and the moster are on the same X or Y).

Oof. Pathfinding is not a trivial problem at all.

In the game I mentioned, I avoided needing real pathfinding, because A) there were no transparent objects like tables; just walls, and B) all movement was still in straight (though possibly diagonal) lines. It just relied on the "last seen position before losing line of sight" algorithm to chase players around corners.

But yea, something like A* search isn't really viable to implement in assembler.

Messaggio modificato da Nyerguds il 18 Nov 2024, 12:17

[TheRuler]

A* would be my goal. But I don't know if I have enough space and the right variables.

What do you think it'd be useful for the algorythm other thasn these locations?

3F9C = REMAINING STEPS
3F9F = MONSTER'S X position
3FA0 = MONSTER'S Y position
3FA1 = Horizontal distance Monster-hero
3FA2 = Vertical distance Monster-hero
3FA3-3FA4 (word) = next monster's step (see 40A2)
3FA5 = HERO'S X position
3FA6 = HERO'S Y position

What baffles me is thet they already did it for the hero! Hero's pathfinding uses an A* like algorytm!

[Nyerguds]

Oh, well, that changes things. If it already exists, that makes it a lot easier to somehow make the monsters use the same logic.

[TheRuler]

Oh, well, that changes things. If it already exists, that makes it a lot easier to somehow make the monsters use the same logic.

Different registers, different memory locations, completely different logic. It seems two different team programmed the two pathfindings. making one PERFECT and one DUMB AS HELL.
I swear I don't know how to make monsters use the hero's pathfinding, and for sure I don't have enough room to place a (even stripped down) working copy of it.

[TheRuler]

with this modification the monsters chase the heroes:

0x286F change to 00
0x2959 change to E896F4
0x1df2 change to 803e9c3fff7403e8b303c3

it works but it needs to be refined:

- The monster does not attack you when it moves exactly its max movement
- The monster makes one step more than its max movement

[raul]

Geniale è già un eufemismo... Creerò una religione e sarò il vostro primo profeta.

Devo assolutamente documentare l'evoluzione di questo codice, in modo che non avvenga come una caccia al tesoro.
Ho aggiunto queste due nuove liste al post principale, nella citazione chiamata “Post interessanti”. Se volete sistemare o ripulire la citazione lo lascio a voi.

Messaggio modificato da raul il 19 Nov 2024, 07:11

[raul]

it needs to be refined, but it works.

- The monster does not attack you when it moves exactly its max movement
- The monster makes one step more than its max movement

aggiungere che tutti i mostri devono avvicinarsi il più possibile all'eroe, come una linea. Un'altra possibilità è che solo un mostro insegua l'eroe, ma che una volta eliminato il mostro successivo insegua l'eroe.

Sarebbe interessante sapere come si comportano con più eroi.

Messaggio modificato da raul il 19 Nov 2024, 06:22

[TheRuler]

Sarebbe interessante sapere come si comportano con più eroi.

In teoria, se non hanno visibilità verso l'eroe più debole si dirigono verso il successivo.

- The monster does not attack you when it moves exactly its max movement
- The monster makes one step more than its max movement

queste sono le cose che ancora devo aggiustare, non vanno bene.


Ottima mossa il post tiepilogativo

[TheRuler]

- The monster does not attack you when it moves exactly its max movement
- The monster makes one step more than its max movement

questo dovrebbe risolvere in un solo colpo:

0x286B change to FE0EA93F90

Raul, quando puoi fai test.
Il movimento nei corridoi dovrebbe essere completo ora.

[raul]

Messaggio modificato da raul il 19 Nov 2024, 15:07

[raul]

Raul, quando puoi fai test.
Il movimento nei corridoi dovrebbe essere completo ora.

Confermo, ora è tutto a posto.


Potresti incorporare quello che ho detto sul fatto che TUTTI i mostri inseguono gli eroi e non solo uno?

[TheRuler]

Potresti incorporare quello che ho detto sul fatto che TUTTI i mostri inseguono gli eroi e non solo uno?

Ci sto lavorando. Quando la vista è bloccata quelli "dietro" non inseguono.
Riesco a fare avvicinare tutti, ma quando si fermano attaccano l'eroe, anche se sono a distanza! ;-) (si vede l'animazione del corpo a corpo).
Escogiterò qualcosa.

Per ora ho caricato la versione semi-definitiva al solito link

Il movimento dei mostri attraverso le stanze però la vedo più difficile. Come ti dicevo non posso usare la stessa intuizione perché con i corridoi funziona per via della loro caratteristica: sono in pratica delle stanze lineari tra altre stanze. Quindi posso facilmente dirgli di non mettere piede nelle stanze o nelle caselle 00.
Ma nelle stanze vere non posso usare questo trucco.

[raul]

Ci sto lavorando. Quando la vista è bloccata quelli "dietro" non inseguono.
Riesco a fare avvicinare tutti, ma quando si fermano attaccano l'eroe, anche se sono a distanza! ;-) (si vede l'animazione del corpo a corpo).
Escogiterò qualcosa.

Bene bene, a poco a poco ci si avvicina al codice finale.

Il movimento dei mostri attraverso le stanze però la vedo più difficile. Come ti dicevo non posso usare la stessa intuizione perché con i corridoi funziona per via della loro caratteristica: sono in pratica delle stanze lineari tra altre stanze. Quindi posso facilmente dirgli di non mettere piede nelle stanze o nelle caselle 00.
Ma nelle stanze vere non posso usare questo trucco.

Anche se il codice rimarrà così com'è ora, è già una conquista rispetto all'originale. Non preoccupatevi, sono sicuro che i piccoli progressi che faranno d'ora in poi li aiuteranno a imparare e a raggiungere un codice definitivo.

[raul]

Non so se può esservi utile, ma a volte sono due i mostri che inseguono l'eroe contemporaneamente e non uno solo.

[TheRuler]

Non so se può esservi utile, ma a volte sono due i mostri che inseguono l'eroe contemporaneamente e non uno solo.

Sì, l'ho notato, grazie. Se il mostro dietro ha abbastanza spazio per arrivare al suo movimento massimo si muove, altrimenti sta fermo.

[raul]

La verità è che è un piacere giocare, ora i corridoi sono diventati una trappola per mostri. Bisogna stare attenti ad avanzare e a scoprire un nuovo corridoio perché non si sa cosa si troverà, tenendo conto dei movimenti dei nemici, bisogna pianificare una strategia per cercare di essere i primi ad attaccare e non il contrario.

La difficoltà del gioco è stata aumentata. Forte!

EDIT: Idee per il nuovo codice.

1. i nemici possono passare attraverso altri nemici in modo da non accodarsi e limitare il movimento ai mostri con più mosse.
2. poter circondare gli eroi per attaccarli da tutti i punti possibili (orizzontali e verticali).

Messaggio modificato da raul il 19 Nov 2024, 20:34

[TheRuler]

1. i nemici possono passare attraverso altri nemici in modo da non accodarsi e limitare il movimento ai mostri con più mosse.

già pensato. Codice difficile ma non impossibile. Posso usare lo stratagemma già usato per far loro calpestare le trappole, ma bisogna fare in modo che il mostro non si fermi sopra ad un altro mostro (come può avvenire per le trappole). Devono fermarsi prima se il mostro precedente è già a contatto con l'eroe, o deve avere abbastanza movimento per superarlo.

2. poter circondare gli eroi per attaccarli da tutti i punti possibili (orizzontali e verticali).

Succede già, ma in casi particolari, ovvero se non devono aggirare ostacoli.

[raul]

Date un'occhiata all'elenco aggiornato dell'evoluzione del codice della caccia al tesoro. Se avete bisogno di modificare le descrizioni o di aggiungere/togliere punti, siete liberi di farlo. Mi manca il codice in cui si scartano anche le pozioni dal mazzo, ma non riesco a trovarlo.

https://www.oldgamesitalia.net/forum/index....st&p=390093

già pensato. Codice difficile ma non impossibile. Posso usare lo stratagemma già usato per far loro calpestare le trappole, ma bisogna fare in modo che il mostro non si fermi sopra ad un altro mostro (come può avvenire per le trappole). Devono fermarsi prima se il mostro precedente è già a contatto con l'eroe, o deve avere abbastanza movimento per superarlo.

Esattamente. Pensavo che ci stessi pensando, ma preferisco esserne sicuro.

Succede già, ma in casi particolari, ovvero se non devono aggirare ostacoli.

Questo non accade nelle stanze, che continuano a lasciare vuoti i possibili punti di attacco quando i mostri sono disponibili.

Messaggio modificato da raul il 19 Nov 2024, 22:10

[TheRuler]

Ho visto il "diario" della caccia al tesoro. Al momento è perfetto. Non mi vengono in mente altri punti.

Questo non accade nelle stanze, che continuano a lasciare vuoti i possibili punti di attacco quando i mostri sono disponibili.

Perché la IA fa ancora schifo ;-)
Devo trovare un modo intelligente per fargli aggirare gli ostacoli. Il problema non far è attaccare l'eroe da 4 mostri, ma è fare in modo che il mostro capisca dove andare senza sbagliarsi.

Al momento, l'ho detto ma provo a desciverlo meglio, non aggira gli ostacoli perché il movimento non considera l'opzione di spostarsi più lontano rispetto all'eroe.
 Screenshot_2024_11_19_220110.png ( 49.42k ) Numero di download: 0

Questo mostro sta fermo perché andare a destra per aggirare l'angolo, vorrebbe dire "allontanarsi dall'eroe (rispetto all'asse x), quindi l'unica sua opzione è andare in basso (e sbattere contro il muro).

Se sposto l'eroe a sinistra, le opzioni diventano due, ma rimane sempre fermo perché sbatte contro i due muri.
 Screenshot_2024_11_19_220610.png ( 54.05k ) Numero di download: 0


Sapevamo che il motore era stupido, ma non così tanto, eh?