RPGMAKER VX ACE miniTutorial sulla Gestione Collisione eventi

[NN81 597]

Queste righe di comando rappresentano un po' il "fulcro" del battle system ad eventi sul quale ho cominciato a lavorare da circa due mesi (tre mesi e mezzo fa presi in mano il tool per la prima volta in vita mia e da allora mi misi sotto per imparare ad eventare), ho pensato di condividerle per mettere a disposizione di chi fosse interessato o per chi volesse trovarvi una qualche forma di ispirazione, suggerimento per approciare il problema delle collisioni fra giocatore ed nemici su mappa...

questo è lo screen (ho dovuto fare un copia incolla veloce, quindi scusate se non viene perfetto..) di seguito darò una concisa spiegazione dei contenuti:

 

 

Ok, prima cosa, parlo soprattutto a chi potrebbe essere come me due mesi fa, guardando queste righe trovarsi spiazzato e confuso, tranquilli, è normalissimo! è solo questione di farci l'abitudine pian piano e poi il codice lo vedrete sotto un altra prospettiva molto più semplice dell'apparenza.

Si comincia impostando 4 variabili che contengono rispettivamente le coordinate XY dell'eroe su schermo (NON su mappa, ora vi spiego perchè...) e poi le coordinate XY sempre su schermo di un altro evento (nemico o quel che sia, di cui volete gestire la collisione).

Impostate le variabili si fa fare una semplice differenza tra le x e le y del nemico e quelle del nostro eroe in modo da "risalire" alla distanza in pixel fra gli stessi.

QUI occorre fare una doverosa puntualizzazione sul tipo di coordinate, quelle su mappa si riferiscono ai tiles del grid, quindi ad esempio il primo tile in alto a sinistra avrà coordinate 0,0 (in quanto partono da zero) il secondo tile a destra del primo ma sulla stessa X avrà coordinate 1,0 , quello immediatamente sotto avrà coordinate  1,1 e così via..

tali coordinate essendo riferite ai tiles hanno solo numeri interi, il "problema" dell'utilizzare le coordinate su mappa per la gestione delle collisioni è dovuto al fatto che il Tool calcola il variare di tali coordinate in "anticipo", ad esempio un evento in movimento che passa da un tile ad un altro, per il tool cambia coordinate nel momento stesso in cui fa per dirigersi nella casella accanto (immaginate una sorta di trigger contatto evento..) questo porta a far si che se noi utilizziamo tali coordinate per la gestione di una collisione, potremo avere la collisione quando ancora un evento sembra a un tile di distanza da noi (quindi molto brutto e strano da vedersi), per ovviare a questo problema usiamo le coordinate su schermo, perchè queste sono invece basate sui pixel contati partendo da un ipotetico centro del tile (a noi poco interessa perchè basando il ragionamento sulla distanza in tiles, ovunque siano eroe e nemici, la matematica non essendo un opinione, avremo sempre una differenza CERTA e sicura su cui improntare le nostre condizioni nel codice...). Un altra cosa ancora, se per caso decidete di usare un qualche script per il pixel movement, avere le coordinate su schermo vi faciliterà enormenmetnte la vita, e non solo, vi permetterà di poter "dosare" addirittura i pixel per fare una certa cosa in modo certosino, ad esempio se sono accanto e quindi a distanza di 32pixel (nè uno di più nè uno di meno) potrete usare un arma come un pugnale, se siete a distanza superiore a 32(non uguale altrimenti usa il pugnale) e inferiore a 50 potete usare la spada, se siete a una distanza superiore a50 (non uguale altrimenti usa la spada) e inferiore a 200 usa la magia eccetera eccetera...

OK, ora che abbiamo compreso perchè le coordinate su schermo han da essere preferite a quelle su mappa proseguiamo a disaminare la logica del discorso, il cui funzionamento in parte ho appena riassunto ^^

cominciamo infatti con le nostre condizioni che vanno divise in due principali scaglioni, quello che succede quando giocatore e nemico sono sulla stessa ascissa (cioè hanno la stessa X, cioè Xnemico-Xgiocatore è pari a 0, cioè in pratica il giocatore e il nemico stanno uno sopra e l'altro sotto o viceversa comunque sulla stessa colonna..) a quel punto calcoliamo la distanza che hanno, se la distanza rientra in un certo range facciamo attivare determinati switch che ci abiliteranno a fare determinate cose, altrimenti mettiamo tali switch in OFF (importante non dimenticarsi mai di fare questo, diversamente uno switch rimarrebbe su ON anche se voi vi allontanate per esempio dalle condizioni di distanza di collisione)

si ripete quindi lo stesso discorso per quello che succede quando il nemico e giocatore sono sulla stessa ordinata (cioè hanno la stessa Y, cioè Xnemico-Xgiocatore è pari a 0, cioè in pratica giocatore e nemico stanno uno a destra dell'altro e/o viceversa comunque sulla stessa riga...) a quel punto di nuovo impostiamo le nostre condizioni, se sono sulla stessa riga cioè Y=0 dobbiamo solo impostare quando la distanza sulla X è "tot" e a quel punto attivare le switch (o fare qualunque cosa vogliamo) oppure metterla su OFF.

 

Se siete alle prime armi e volete cimentarvi in un qualcosa del genere vi suggerisco di cominciare con qualcosa di più semplice (quello che vedete che ho fatto io calcola ben 3 switches.. una distanza di 3 tiles per l'attacco magico, una di "63pixel" per l'attacco fisico dell'eroe (DIMENTICAVO, SE METTETE 32 LA CONDIZIONE AVVIENE QUANDO SONO EFFETTIVI I 32, il che si verifica esclusivamente QUANDO IL GIOCATORE NEMICO STANNO ESATTAMENTE UNO AFFIANCO ALL'ALTRO, PER AVERE UN MARGINE DI MOVIMENTO CONSIGLIO DI USARE QUESTO VALORE "LIMITE" di 63, se infatti mettete 64 passate automaticamente ad un tile in più (e quindi succede che avrete una "collisione" ad un tile intiero di distanza!!! ma con 63 parte la collisione dal momento in cui fate per varcare il tile, quindi è praticamente un piccolo anticipo sulla mossa ) ed un ultima di 32 SECCO per l'attacco del nemico..

Naturalmente ognuno è libero di variare modificare in base alle proprie esigenze! quello che ho eventato io qui sopra non ha la pretesa di fare da imperativo per nessuno e in nessun caso, ma solo un modo come un altro di sbrogliare la faccenda "collisioni"..

Notare anche che io ho messo la subcondition giocatore rivolto su, giù, destra e sinistra, in modo che lo switch che mi abilita l'attacco dell'eroe sia vincolato al fatto che l'eroe sia girato/rivolto esclusivamente verso l'evento/nemico in questione e non altrove (altrimenti potreste avere le condizioni favorevoli alla collisione anche standogli attaccato ma di spalle e non sarebbe verosimile danneggiare un nemico che ti sta dietro, menando un fendente davanti )

[Ryoku 737]

Ottimo tutorial! Non l'ho letto tutto ma lo farò con calma. 

 

Bel lavorozzo!!!

[NN81 597]

Ottimo tutorial! Non l'ho letto tutto ma lo farò con calma. 

 

Bel lavorozzo!!!

grazie Ryo

[.-lFCDl-. 48]

Il 30/1/2017 at 11:44, NN81 dice:

 

[...]

 

 

Oh, Mastro degli Eventi,

a lei che serpeggia con grazia tra righe di comandi, domando se ancor vi è in lei il disìo di voler acuire il suo vademecum, giacché i suoi insegnamenti collidono col mio studio e bramosa d'apprendere è la mia incolta persona.

[Ghost Rider 1887]

18 ore fa, .-lFCDl-. dice:

 

Oh, Mastro degli Eventi,

a lei che serpeggia con grazia tra righe di comandi, domando se ancor vi è in lei il disìo di voler acuire il suo vademecum, giacché i suoi insegnamenti collidono col mio studio e bramosa d'apprendere è la mia incolta persona.

 

mi spiace essere io a darti la brutta notizia, ma dubito che lo rivedrai più, in questi lidi

 

[.-lFCDl-. 48]

2 ore fa, Ghost Rider dice:

 

mi spiace essere io a darti la brutta notizia, ma dubito che lo rivedrai più, in questi lidi

 

 

 

No, davvero... Pare una sorta di complotto universale contro il mio progetto ._.

[.-lFCDl-. 48]

 

Il 30/1/2017 at 11:44, NN81 dice:

 

...

 

 

AGGIORNAMENTO (scrivo così perché non so se quando invierò il messaggio, questo si unirà all'ultimo inviato)

 

Anche se non so se tornerai sul forum, ti ringrazio TANTISSIMO per aver fatto questa piccola guida. Ci ho messo un po' per capire quello che hai fatto, ma alla fine hai risolto buona parte dei miei problemi. Grazie a te ho scoperto anche altre chicche che ho testato e funzionano meglio di quanto immaginassi. Devo solo impostare meglio le cose.

Gli eventi comuni sono una rogna all'inizio, ma una volta capiti sono anche divertenti da usare. Grazie mille e arrivederci 

[.-lFCDl-. 48]

Ragazzi, HALP.

 

So che purtroppo NN81 difficilmente si farà vivo di nuovo qui sul forum, ma confido in voi.

Ho un problema che non riesco a risolvere. Ho eseguito quello che NN81 ha spiegato, ottenendo un risultato soddisfacente per il tipo di soluzione che volevo. Però c'è un problema abbastanza strano quando provo a realizzare una sorta di combat system molto semplice. Vi spiego il problema.

 

 

Questo è quello che ho scritto per ottenere una cosa semplice. Praticamente se il giocatore si trova davanti all'evento, si deve sentire un suono. Questo funziona... però male.

 

 

 Y = Blu     X = Rosso

 

Se il giocatore si trova sopra o sotto l'evento, si sente il suono. Fin qui tutto ok. Ma se per esempio il giocatore si trova a destra e a sinistra, non si sente nulla. Tuttavia, se si sposta verso il basso si sente il suono. Questo perché, non riesco a capire per quale assurdo motivo, le coordinate di X si trovano esattamente sulla griglia, mentre quelle di Y si trovano al centro, tra una riga e l'altra. 

 

Ora, prima che ne esco pazzo, qualcuno riesce ad aiutarmi e a capire quel quale motivo si comporta in questo modo? Sto impazzendo 

 

P.S.: non ho messo un valore esatto di Y ed X perché volevo provare una cosa, prima... Ma ho dimenticato di modificare. In ogni caso, il problema si verifica ugualmente.

[kaine 1858]

ho provato sul 2k3 e funziona in questo modo:

[.-lFCDl-. 48]

 

5 minuti fa, kaine dice:

ho provato sul 2k3 e funziona in questo modo:

 

Purtroppo non ci capisco granché xD Cosa sono le etichette su 2k3?

[kaine 1858]

Son le stesse che ci stanno pure sull'ace XDDD

Comunque vengono usate per saltare da una parte all'altra del codice che scrivi, in modo da non avere ripetizioni(nel caso in cui devi ripetere porzioni di codice uguale) che lo porterebbero ad allungarsi.

 

Edit:

Ho fatto un tutorial passo per passo, in cui spiego che ho fatto... Ma inspiegabilmente sul VXAce non funziona!

L'ho mandato pure a @Ghost Rider per vedere se a lui funziona.

La cosa strana è che sul 2k3 funziona alla perfezione.

Ti lascio comunque il link con entrambi i progetti poi vediamo che mi risponde ghostino in merito al non funzionamento della versione per l'ace.  

Edit:

Link aggiornato alla versione funzionante:

http://www.mediafire.com/file/157a2ggb75pmvbq/Test+NSOE+2k3-VXACE.rar

Modificato December 19, 2017 da kaine
aggiornato link per download (Visualizza storico modifiche)

[.-lFCDl-. 48]

Grazie mille. L'unico problema è che poi dovrò "tradurre" tutto su mv, visto che sto lavorando su quello, ma è il male minore xD Ace non lo sto usando perché per certi versi mv mi piace di più. Ma questo problema è davvero inspiegabile... Perché ace e mv non funzionano come dovrebbero? I misteri...

[Ghost Rider 1887]

eventisticamente parlando, VXA e MV sono pressochè identici, cambia solo il linguaggio di scripting quindi non dovresti avere grossi problemi con la "traduzione".

 

Dunque ho testato i progetti di Kaine e anche a me quello su VXA non funge. Il motivo temo sia imputabile al modo in cui i diversi tool priorizzano la risoluzione degli eventi, in oltre voglio portare alla vostra attenzione una cosa banale...

 

visto che interagite con l'evento in questione premendo il tasto azione vicino ad esso... a che serve fare un sistema di collisione?

Il semplice fatto che siete vicino a lui e premete azione per risolvere l'evento, implica che siete adiacenti ad esso

per sfruttare al meglio questo tutorial sarebbe ideale che un evento comune o parallelo, in lontananza, gestisca il sistema prendendo le coordinate dei diversi eventi su mappa, che poi sarebbe il sistema che usavo io nella vecchia beta di resurrection quando era ancora sul 2003 (sull'ace ho usato un BS prefabbrcato a script, sticaxxi, non mi accosto proprio a smadonnare sugli eventi con un tool così limitato XDDDD), e che dovrebbe funzionare comunque anche sugli altri tool (sull' XP almeno funzionava).

[kaine 1858]

E si io l'ho ideato con l'idea di farlo funzionare in parallelo, ma comunque continuo a non spiegarmi il perché non funzioni su vx ace, nonostante si usino le stesse funzioni base del tool.

Per me è solo un motivo in più per restare ancorato al 2k3. 

Squadra che vince non si cambia! XDDDDD

Edit:

E poi c'è chi dice che l'ace è più semplice e bla bla bla ma cavolo manco gli eventi base girano ma che cazz... Questo boccone amaro non mi va proprio giù, mi ricorda la volta che usavo i cicli annidati e non funzionava il codice che avevo scritto, tutto il giorno a fare prove su prove in contatto con ghost.

Poi salta fuori a CULO cercando su google, che ci stava un bug che non permetteva il corretto funzionamento dei cicli.

Quindi ciò che avevo scritto sin dall'inizio era giusto e mi stavo dannando per nulla[poi ho risolto con una patch del buon cherry].

Modificato December 19, 2017 da kaine (Visualizza storico modifiche)

[.-lFCDl-. 48]

1 ora fa, Ghost Rider dice:

eventisticamente parlando, VXA e MV sono pressochè identici, cambia solo il linguaggio di scripting quindi non dovresti avere grossi problemi con la "traduzione".

 

Dunque ho testato i progetti di Kaine e anche a me quello su VXA non funge. Il motivo temo sia imputabile al modo in cui i diversi tool priorizzano la risoluzione degli eventi, in oltre voglio portare alla vostra attenzione una cosa banale...

 

visto che interagite con l'evento in questione premendo il tasto azione vicino ad esso... a che serve fare un sistema di collisione?

Il semplice fatto che siete vicino a lui e premete azione per risolvere l'evento, implica che siete adiacenti ad esso

per sfruttare al meglio questo tutorial sarebbe ideale che un evento comune o parallelo, in lontananza, gestisca il sistema prendendo le coordinate dei diversi eventi su mappa, che poi sarebbe il sistema che usavo io nella vecchia beta di resurrection quando era ancora sul 2003 (sull'ace ho usato un BS prefabbrcato a script, sticaxxi, non mi accosto proprio a smadonnare sugli eventi con un tool così limitato XDDDD), e che dovrebbe funzionare comunque anche sugli altri tool (sull' XP almeno funzionava).

 

Ma l'evento è in parallelo. Quello che ho scritto in spoiler è riportato in un evento che parte in parallelo (la fiamma rossa). Effettivamente ho dimenticato di specificarlo... <_<' Come ho detto, a me funziona, ma male. Le coordinate per l'asse X vengono calcolate in maniera differente rispetto a quelle dell'asse Y e non capisco perché. Proprio la posizione sembra essere errata. Almeno parlo di MV, non so se questo identico problema avviene con ace.

 

50 minuti fa, kaine dice:

E si io l'ho ideato con l'idea di farlo funzionare in parallelo, ma comunque continuo a non spiegarmi il perché non funzioni su vx ace, nonostante si usino le stesse funzioni base del tool.

Per me è solo un motivo in più per restare ancorato al 2k3. 

Squadra che vince non si cambia! XDDDDD

Edit:

E poi c'è chi dice che l'ace è più semplice e bla bla bla ma cavolo manco gli eventi base girano ma che cazz... Questo boccone amaro non mi va proprio giù, mi ricorda la volta che usavo i cicli annidati e non funzionava il codice che avevo scritto, tutto il giorno a fare prove su prove in contatto con ghost.

Poi salta fuori a CULO cercando su google, che ci stava un bug che non permetteva il corretto funzionamento dei cicli.

Quindi ciò che avevo scritto sin dall'inizio era giusto e mi stavo dannando per nulla[poi ho risolto con una patch del buon cherry].

 

Come hai trovato quel bug su internet? Potresti linkare la pagina del bug segnalato, così posso verificare se avviene lo stesso con MV? Perché non capisco cosa intendi per "non funziona su ace", nel senso che non capisco se non funziona per niente o in parte come nel mio caso su MV 

Modificato December 19, 2017 da .-lFCDl-. (Visualizza storico modifiche)

[kaine 1858]

Il bug di cui parlavo era per il 2k3(mi sa che ho postato pure la patch qui sul forum non appena la trovai) non per l'ace.

La demo che ho fatto su vx ace(Ho dato per scontato che stessi realizzando il tuo progetto su ace perché questo topic tratta proprio l'ace XD), quando mi avvicino all'evento e premo invio per avviarlo e quindi sentire l'effetto sonoro non fa praticamente "nulla" o meglio lo fa ma non esegue l'effetto sonoro, idem se metto l'evento in parallelo, per far si che l'effetto sonoro suoni in automatico, quando l'eroe sta a sinistra, destra, sopra o sotto l'evento senza dover stare a premere invio.

 

[kaine 1858]

Scusate il doppio post ma ho trovato il bug XDDDD

Dio benedica il tasto f9 che mi ha fatto notare cosa non andava, non so perché ma l'ace conta i tile per l'asse y dell'evento dal basso verso l'alto, mentre per l'asse y l'eroe dall'alto verso il basso.

Quindi anche se stavano l'uno di fianco all'altro mi trovavo due valori differenti in questo caso (Y evento=7) e (Y Eroe=5)

Screen esplicativo:

Edit:

Ho fatto altri test ed effettivamente è buggato l'asse Y per gli eventi a quanto pare, delle volte mi da le coordinate giuste, ma se sposto l'evento in un altra parte della mappa è probabile che l'asse Y non sia quello giusto.

Edit2:

 

RISOLTOOOOOO!!!!!

Dato che la lettura dell'asse y in tile è buggata, ho provato con le coordinate in pixel ed in quel modo son riuscito a farlo funzionare

http://www.mediafire.com/file/157a2ggb75pmvbq/Test+NSOE+2k3-VXACE.rar

Dimenticavo su MV invece di 32 e 64(capirai quando apri l'evento del vecchietto) devi usare 48 e 96

Modificato December 19, 2017 da kaine (Visualizza storico modifiche)

[Ghost Rider 1887]

2 ore fa, kaine dice:

Dato che la lettura dell'asse y in tile è buggata

 

Davvero Enterbrain? è__é

 

XDDD

[.-lFCDl-. 48]

Risolto anche io. Praticamente, siccome il mio problema era un po' diverso, ho usato il plugin "Console on boot" per MV ed ho visualizzato il valore della variabile "eventY - PlayerY". Nelle condizioni, invece di mettere Y = 0 ho messo Y = 6 come da screen, ed ora funge magnificamente. Grazie a tutti per aver risolto questo problema e per non avermi fatto arrivare alla follia.