Vai al contenuto

Rilevato Ad-Blocker. Per favore disabilita il tuo adblocker quando navighi su makerando.com - Non c'è nessun annuncio invasivo.

  • Chatbox

    You don't have permission to chat.
    Load More
NN81

RPGMAKER VX ACE miniTutorial sulla Gestione Collisione eventi

Recommended Posts

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:

 

nbbriu.png

 

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 ^_^)

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti
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.

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti
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 ::rotfl::

 

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

 

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 :D

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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.

 



2Zih3y9.jpg

 

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.

 

 

kOSqfCS.png 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 :wacko:

 

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.

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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 da kaine
aggiornato link per download (Visualizza storico modifiche)

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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...

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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 ::rotfl::

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).

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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 da kaine (Visualizza storico modifiche)

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti
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 ::rotfl::

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 da .-lFCDl-. (Visualizza storico modifiche)

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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.

 

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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:

CjX7zAM.png

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 da kaine (Visualizza storico modifiche)

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

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. 

 

86vPOXr.png

Condividi questo messaggio


Link di questo messaggio
Condividi su altri siti

Crea un account o accedi per lasciare un commento

You need to be a member in order to leave a comment

Crea un account

Iscriviti per un nuovo account nella nostra comunità. È facile!

Registra un nuovo account

Accedi

Sei già registrato? Accedi qui.

Accedi Ora

  • Contenuti simili

    • Da Waldorf
      2D Áperdam
       
       
       
       

       
       
       
       
       
      Ecco qui, finalmente, la demo del mio primissimo progetto "Serio" ufficiale!
       
       
       
       
       
      Trama:
       
       
      La storia si svolge all'interno di un liceo, la scuola Áperdam, ed ha come centro focale la classe Seconda D.
       
       
      Questi ragazzi devono all'improvviso capire cosa fare di fronte allo strano comportamento dei professori, che li attaccano utilizzando strane tecniche prese dalle loro materie.
       
       
      Allo stesso tempo altri fatti strani si aggiungono, che spinge questi studenti ad indagare sull'accaduto, ma cercando lo stesso di seguire la loro routine scolastica.
       
       
       
       
       
      Gameplay:
       
       
      Come ogni RPG il gameplay è composto da 2 momenti:
       
       
       
       
       
      -Battaglia: Le battaglie, grazie ad un preciso utilizzo degli script di battaglia MOG, sono molto più dinamiche. Varie mosse infatti permettono l'esecuzione di particolari combo per poter eseguire un'altra mossa che complementa quella precedente. Inoltre altre mosse richiedono specifici tasti per essere lanciate. (vedi trailer)
       
       
       
       
       
      -Esplorazione: Una scuola, una sua succursale ed un intero giardino da esplorare, oltre a due bei dungeon da espugnare. Che volete di più?
       
       
      Gli incontri randomici dei mostri, in particolare, avvengono in seguito all'apparizione di un nemico su mappa, che va prontamente schivato con la pressione di una certa freccia direzionale.
       
       
       
       
       
      Difficoltà:
       
       
      La difficoltà nelle battaglie è autoregolata a seconda della vostra bravura nelle combo e nella tattica.
       
       
       
       
       
      Il punteggio va da 1 a 100 ed aumenta:
       
       
      -In seguito ad una combo corretta
       
       
      -Con la sconfitta di un boss
       
       
       
       
       
      Diminuisce:
       
       
      -Subendo gravi danni
       
       
      -Facendo svenire un compagno
       
       
      -Fuggendo
       
       
       
       
       
      Il tema scolastico:
       
       
      Il tema scolastico è rispecchiato su alcuni fattori del gameplay:
       
       
      -Per imparare tecniche, è necessario studiare dal menù, spendendo punti studio.
       
       
      -il KO qui è sostituito dalla bocciatura, l'avvelenamento dalla "Assenza di appunti"
       
       
      -Tutte le tecniche di battaglia provengono dalle materie scolastiche
       
       
      -Il salvataggio si esegue appoggiando il registro di classe su un tavolo
       
       
      -La modalità ricercA, per ritrovare, ehm... oggetti smarriti.
       
       
       
       
       
      Personaggi:
       
       
       
       
       
       
       
       
       
       
       
       
      Trailer:
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
      Download:
       
       
       
       
       
      https://rpgwaldorf.altervista.org/2d-aperdam-demo/
       
       
      Nota: richiede RTP
       
       
         
    • Da NotSuitableBunch
      Salve a tutti, vi presento il mio primo progetto in Rpg maker, realizzato dopo anni di fatiche e incentrato sul mio vecchio gruppo musicale.
      Visto il tempo che ci ho messo a realizzarlo e la lunghezza del gioco in sè, mi sembrava un peccato farlo giocare solo agli altri del gruppo e alcuni amici,
      spero mi possiate dare un pò di feedback al riguardo!
       
      Download:
      https://mega.nz/file/UQR3TT7R#uuB6QaC4rtpsCPO0DCexAypVZKNOeLA3yCcxTG9UxdA
       
       
      Introduzione
       
      Il gioco è innanzi tutto una parodia trash del genere Jrpg mixata con qualche aspetto di Gta.
      Seguirete le peripezie di un gruppo musicale di ubriaconi che cercano di salvare il loro paesello dalla minaccia di un "cattivo generico".
      Aspettatevi una comicità becera e a tratti offensiva, basata su battutacce, citazioni di videogame più belli, tentativi di satira, movimenti di intestino, infrangimento costante della 4a parete e bestemmie.
      (N.B. Il gioco presenta una forte componente anticlericale che potrebbe infastidire alcuni, e ha un paio di sporadiche scene di nudo, è quindi consigliato a un pubblico adulto.)
       
       

       
       
      In secondo luogo è un'opera molto personale che cerca di racchiudere e riassumere un decennio di suonate con un gruppo di amici. Il gioco è quindi costellato di riferimenti e citazioni che ci riguardano direttamente, per quanto poi esagerati a scopi comici. Spero di aver fatto un buon lavoro nel rendere i personaggi interessanti anche a un pubblico esterno.
       
       
       
      Sviluppo
       
      Il videogame è nato come sfondo per i nostri vecchi concerti nel 2015, proiettato mentre suonavamo e un amico lo giocava live.
      La prima parte di gioco (circa 2-4 ore iniziali) è ancora quella rudimentale Demo (ho inserito una scorciatoia per saltarla nel caso risulti troppo ostica a livello di enigmi, vi avvicinerete così alla parte open-world).
      Ho poi continuato ad espandere il gioco negli anni, a periodi alterni, aggiungendo le varie comparse tra amici e spettatori dei concerti e finendo gli "assets" che avevamo accumulato. Verso fine del 2021 ho iniziato la realizzazione delle quest e della trama del gioco principale; sacrificando buona parte del mio tempo libero sono riuscito a finire in poco più di un anno, dopodichè ho fatto testare il gioco agli altri membri del gruppo e ora, finalmente, direi che è finito.
      Inizio sviluppo Demo: Metà 2015 –> Fine gioco completo: Inizio 2023
       

       
       
       
      Grafica e Gameplay
       
      La grafica di gioco è ottenuta mixando (male) i classici asset di rpg maker con foto di persone e cose reali.
      L'ambientazione è quindi moderna, fatta di strade e case, con un approccio openworld che vuole provare a omaggiare Gta.
       
       

       
       
      Ogni personaggio giocabile e le comparse del gioco sono ottenute con delle foto, stessa cosa per le Animazioni delle mosse in battaglia.
      Per il resto, però, il gameplay di gioco è quello di un jrpg molto base.
      La parte interessante del combattimento è vedere le mosse improbabili dei personaggi.
       
       

       
       
      Una costante nel gioco sarà l'uso di alcolici, i quali rappresentano la fonte di cura del Party mentre girate per il paese.
      L'inizio della parte open world potrebbe essere un pò difficile... Non dimenticate di salvare!
       
       

       
       
      Come longevità il gioco è abbastanza lungo se volete finirlo al 100% (io che sono il programmatore ci metto 30 ore), per finire solo la quest principale invece dovrebbero bastare circa 10-15 ore.
       
       

       
       
       
      Sonoro
       
      La OST del gioco è composta dai brani del nostro gruppo, più i brani delle varie formazioni avute negli anni (con lo stesso gruppo di persone abbiamo fatto diversi progetti musicali).
      Quindi ci sono ore di colonna sonora originale, compresa tutta una sezione di pezzi 8-bittosi fatti da uno di noi appositamente per il gioco.
       

    • Da Hufflepoe
      Sto cercando di capire come consentire al giocatore di selezionare solo il corretto item dall'inventario degli oggetti per uno specifico evento. Faccio un esempio: l'eroe incontra un personaggio e deve consegnargli un oggetto selezionandolo tra quelli raccolti fino a quel momento. Ciò che accade ora è che viene consentito al giocatore di selezionare qualsiasi oggetto nell'inventario tra quelli utilizzabili sempre e che tutti quelli consumabili vengono rimossi dall'inventario una volta selezionati. Io invece vorrei che, nel caso in cui l'oggetto consegnato fosse quello sbagliato, gli altri non venissero rimossi dall'inventario, e che se l'oggetto consegnato fosse quello giusto, invece solo questo fosse rimosso. 
      Mi sembra un meccanismo semplice: se il giocatore sceglie tra i vari oggetti quello giusto e lo consegna, l'evento va a buon fine, altrimenti no. Eppure non riesco a trovare il modo per far girare questo meccanismo.
      Grazie in anticipo per l'aiuto!
       
×