GabryHadoken
-
Posts
467 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Posts posted by GabryHadoken
-
-
Ottimo. Tutto è migliorato.
Adesso ci vorrebbe secondo me solo la barra della vita (sì, sono più simile a un disco rotto che a un utente). Adesso è sicuramente più professionale.
Comunque, considerando che non si tratta di un classico rpg standard con bs a turni, qua ci starebbe benissimo un menu a eventi molto minimale. Non sarebbe difficilissimo da fare. Devi solo pensare a quali funzioni ti servono e che aspetto dargli.
grazie a te Arka ^^
si vorrei fare qualcosa di molto semplice (come dicevo riferendomi a "Sacred" come ispirazione ma in piccola, piccola scala) quindi una barra della vita e una di mana per attacchi magici e/o tecniche speciali, e poi un menu semplice semplice o una cosa da fare direttamente con hud on screen per richiamare inventario ed equipaggiamento.
per quanto mi èpossibile cercando di estraniarmi dalle meccaniche di default del tool. ad esempio le animazioni le voì editando man mano per richiamare sull'evento nemico o sul giocatore i danni hp subiti, e simili.
-
sporadicamente seguo questo topic, anche se non ci capisco nulla di programmazione in senso stretto...
avrei solo una domanda (più che altro giusto per curiosità), ho visto che il topic è stato aperto nel lontano 2008, son passati ben 8 anni da quel primo post, e da quel che mi pare di capire nel leggere negli ultimi aggiornamenti è ancora tutto in alto mare, inoltre sappiamo che nel mentre la tecnologia corre veloce, cambiano le versioni di DirectX cambia l'hardware dei sistemi con relative tecnologie.. è arrivato l'html5 e avete ricominciato il lavoro da zero, per capirci? oppure il progetto è stato sospeso per un lungo periodo in questi 8 anni?
un rpg maker in 3d sarebbe fantastico, invero. ma è fattibile? ossia, vedrà veramente la luce questo tool o finirà nel limbo come tanti altri progetti? nel qual caso, ha senso sbattersi di lavoro per inseguire una chimera? la mia non vuol essere una critica distruttiva solo volta a fare un punto della situazione "concreta fattibilità" della cosa, cioè della serie, dobbiamo "illuderci" a oltranza o possiamo aspettarci di sperare in tempi ragionevoli di poter provare qualcosa di questo tool?
a me onestamente sembra un lavoro in stallo, del resto voglio dire, avevo provato a scaricare e "lanciare" quella specie di APK tutto incuriosito e poi mi son ritrovato in mano.. il nulla, a parte un minutino di caricamento del... nulla.
cioè boh non so, forse è solo una mia impressione, ma se dopo 8 anni uno sta ancora a fare esperimenti su directX o openGL e non so il vostro caso particolare ma le librerie openGL ES non sono la scelta migliore per smartphone e tablet (chiedo visto che ho letto da qualche parte che si parla di tool crossplatform tipo MV..)
-
Grazie x l incoraggiamento Techno e soprattutto grazie a tutti x il supporto. Mi spiace un po che a intervenire siam sempre pochi
-
Videochiamamiiii XD
Pietre, sabbia per evocare un golem. .funghi x distillare veleni,
-
richiamo visto che c'è stato il cambiopagina
Potrebbe sembrare uguale in realtà la meccanica é stata ri-eventata in modo radicale. Ora il contatto del nemico e relativo attacco son calcolati su 2pp distinti mentre l attacco dell eroe avviene finalmente SOLO a chi si trova di fronte. Prima veniva fatto il tutto con un banalissimo "contatto evento"! Finalmente una base solida esente da difetti grossolani su cui poter continuare a lavorare
-
condizioni d'avvio e trigger son ok?
processi in parallelo all evento che potrebbero interferire?
-
ok ci siamo, piccolo antipasto sul nuovo "BS" messo finalmente a punto
la mole di lavoro a livello di eventi è aumentata di brutto, basti pensare che prima mi era sufficiente fare un copia incolla dell'evento/nemico per riempire una mappa di mostri, ora invece per ogni singolo nemico devo creare 3 variabili, uno switch non locale, e 2 processi paralleli dedicati più uno che possono condividere tutti i nemici per l'assegnazione degli HP iniziale... che dire, un lavoraccio però ora funziona finalmente tutto a dovere.
menzione ad honorem ad Arkady per avermi compilato praticamente la parte di codice relativa al processo parallelo che si occupa di fare il "tracking" di giocatore e nemico per "simulare" la collisione necessaria a far filare liscio il tutto. più un ringraziamento a tutti gli altri che con suggerimenti vari mi hanno indirizzato nel ragionamento e fornito le basi concettuali per approntare almeno almeno quello dove arrivavo..
ho inserito una piccola variante nella storia per armarsi prima di affrontare il mostro di prova iniziale, spero la troverete di vs gradimento ^^
ora sto lavorando al sogno famoso, di cui ho parlato qualche post più su XD
ORA FINALMENTE SI PICCHIA SOLO NELLA DIREZIONE IN CUI E' RIVOLTO E "SPINGE" IL GIOCATORE (prima il giocatore colpiva in tutte e 4 le direzioni contemporaneamente, quindi bastava stare fermi e schiacciare e chiunque s'avvicinasse subiva senza possibilità alcuna di danneggiare l'eroe, ora invece abbiamo un biesse stile mmorpg alla "Sacred", una mischia dove si picchia e si viene picchiati. per ora è spartano, generico, ma presto lavorerò ad approfondire il tutto con i calcoli su attacco e difesa di giocatore e nemici, e molti effettini grafici in tempo reale tipo il danno inflitto e quello ricevuto eccetera)
stay tuned ^_^
-
Succede di non capire qualche pezzo di codice e di trovare soluzioni a caso! XD Vai tranquillo, però, visto che hai appena iniziato. Il codice inizia in un punto e finisce su un altro, se vedi che seguendolo non capisci qualcosa prova a chiedere che ti si spiega meglio quel punto e cosa accade usando quel determinato comando.
^ ^
Per quanto riguarda il codice nei due screen...
- proprio come discutevamo sopra le attese e gli aspetta (solo nel caso in cui metti aspetta per tutto il muovi evento) negli eventi a contatto con evento/giocatore bloccano il movimento dell'eroe stesso. Quindi in quel caso è possibile che l'eroe stia un po' fermo, lasciali solo se vuoi appunto che faccia una pausa mentre sta attaccando e sempre calcolando il tempo di attacco con l'animazione, ma se non vuoi dovresti spostarli in un parallelo.
- per il problema della switch da mettere per bloccare i paralleli... capita, a volte si usano degli aspetta a fine evento parallelo, il fatto è che rpg maker non è tanto furbo da far finire le cose istantaneamente e potrebbe esserci codice che si ripete due volte (succede anche con i muovi evento a salto).
^ ^
Di base il contatto eroe e tasto diverso da azione ti costringe a tenere sempre la freccia direzionale premuta verso il nemico, non è una gran cosa, per me dovresti iniziare a cambiare da qui, è una scomodità bella grande per un action. Inoltre con quel tipo di codice si tratta di un tenere premuti i due tasti per fare un attacco continuo. Con un aspetta fuori dalla condizione se tasto premuto migliora, ma anche con quelli che tieni dentro, in quel caso vanno bene.
Infine da come hai impostato la cosa il nemico ti colpirà sempre non appena sarai vicino ad esso, non vi è gioco di toccata e fuga. Comunque visto che vuoi fare una cosa stile attacco di mmorpg potrebbe sicuramente starci.
^ ^
si Guardian magari dopo aggiorno il topic di progetto così spostiamo il discorso là, direi che questo topic sulle collisioni l'Arka l'ha risolto, io ci sto lucrando sopra ma non sono per niente contento, perchè ancora non ho sviluppato quella visione d'insieme dei processi probabilmente.. mah vediamo alla prossima, tanto di sicuro gli ostacoli lungo il cammino non mancheranno XD
Boh. Non so quale sia il problema.
Prova a creare una mappa nuova con solo il nemico come unico evento e con questo stesso codice (magari non lo sai, ma c'è qualche altro evento che interferisce in qualche modo).
Se continua a non funzionare, mandami una demo anche con solo quella mappa e vedo se trovo il problema
Arka ho risolto spostando l'attacco del nemico su processo parallelo dedicato. E ribadendo lo switch collision OFF con l'attacco del giocatore.
PEr tutto il resto il tuo sistema è impeccabile.
PEr me il topic qua è ok.
-
Boh, non so come mai hai quel problema. Potrei dare un'occhiata all'evento dell'attacco o alle demo (quella con la glitch e quella senza) per capire come mai in una funziona e l'altra no. Ma non avrò accesso a rpgmaker fino a stasera.
Come gestisci l'attacco? Deve essere lì il problema. Per caso è vincolato in qualche modo alla switch collision?
Nella correzione che ti ho proposto, in fondo, l'unica differenza è che quella switch va off, quindi non capisco perché dovrebbe bloccarti l'attacco.
Di preciso come lo gestisci? Un evento solo? Due? Potresti caricare gli screenshot dell'evento, così magari si capisce il problema?
mi limito a postare uno screen dell'ennesimo processo parallelo a cui ho dovuto delegare il mero attacco del nemico verso il giocatore (quello vincolato allo switch 52 collision famoso) con il quale sembra finalmente risolto l'arcano ovviamente unitamente al tuo codice.
ma sono moooooolto contrariato con me stesso per questo modo di lavorare metà pappa pronta e metà a "tentativi" perchè non ritengo serva a gran cosa.
io vorrei capirle le cose e trovare il modo di farle fare a tutti i costi. non fare copia incolla del tuo codice che per quanto spiegato bene non riesco a comprenderne ancora il senso pratico anche se funzionare funziona quindi suppongo la logica di fondo sia perfetta, ma io non l'ho ancora capita onestamente. e nemmeno "trovare" soluzioni a caso, come mi capita di fare ultimamente, ad esempio questo processo parallelo con cui ho risolto non sortiva gli stessi effetti se innestato come evento locale del parallelo delle coordinate (perchè mandava in stallo il medesimo portando la priorità sull'altra pagina) o come pagina a parte nell'evento nemico (dove a sua volta partendo in parallelo toglieva la possibilità di attivare il trigger contatto giocatore per l'attacco dell'eroe...) insomma un MACELLO...
non ti dico quante volte ho letto riletto il tuo codice ancora non mi è chiaro cosa cambia ai fini pratici.. si il discorso che nel mentre posso andare in Messico e somatizzare l'attacco a posteri mi è chiaro e l'ho sperimentato alla nausea girando in tondo di corsa o normale al nemico da ieri pomeriggio a stamattina
http://i67.tinypic.com/abqt1y.png
questo invece è l'evento sul nemico per l'attacco del giocatore
N.B. se non metto quello switch off alla fine (anche se nel parallelo delle coordinate ce ne sono a gogo) a fine combattimento cè un altro curioso glitch,
ossia il mostro invece di sparire si ripropone semi opaco in con la grafica d'attacco così bloccato sulla mappa o_O la cosa curiosa è che controllando con F9 lo stato dello switch in entrambi i casi risulta comunque OFF a nemico sconfitto, sia che lascio questo comando nella pagina dell'attacco eroe sia che lo rimuovo, ma nel primo caso fila tutto liscio, levandolo invece (e qui mi vien da pensare che l'off scaturisca dal parallelo coordinate) si verifica la glitch descritta
http://i68.tinypic.com/2qspcnb.png
-
@Gabry:
Mi ricordo male allora? Mi pareva che nella demo che avevi rilasciato l'eroe rimanesse bloccato per pochi istanti vicino al nemico quando lo ingaggiava uno. Se vuoi fare da solo per me va bene, comunque se pensi che non conosciamo qualcosa posta tutto il codice e ci diamo un'occhiata per vedere cosa non va.
ah ti riferivi alla demo, no no quella è storia ormai. son tutto assorto nel presente.
confermo il tasto azione deve rimanere per fare da tasto azione, ho assegnato un tasto dedicato per l'attacco.
confermo anche sui nemici, questi non son scemi, si voltano verso di te e ti attaccano appena li avvicini (almeno quelli standard, nulla mi vieta poi di diversificare con nemici tontoloni che magari sembran inattaccabili frontalmente ma puoi prendere alle spalle per riempirli di botte)
-
Considerando tutto il casino che state tirando su per fare questo sistema ora mi domando.. ma ne vale la pena?
non è stato ben chiarito quale sia il vantaggio di questo metodo
serve un parallelo per OGNI nemico, e OGNI nemico ha bisogno delle sue X e Y
in una mappa molto popolata le prestazioni cadrebbero a picco
Usando un contatto con l'evento, come avevo suggerito, si potrebbero fare tutte le verifiche su "chi guarda chi" o su "chi preme cosa" solo ed esclusivamente quando il contatto è avvenuto (zero eventi paralleli o switch) e se i calcoli non fossero in parallelo basterebbe una sola X e una sola Y per TUTTI i nemici
Qualcuno può spiegarmi in cosa questo metodo dovrebbe essere migliore? (scusate se insisto, ma davvero non l'ho capito)
non saprei Hrot al massimo l'ho provato con 3 nemici contemporanemente, e non laggava, quando risolvo il dilemma provo su mappa larga con una ventina di nemici e ti faccio sapere come va XD
essendo testardo e cocciuto non si tratta ora di cosa sia migliore o no ma solo di far funzionare questo sistema qua! non deve vincere il tool ma la caparbietà dell'eventatore ^^
se poi proprio non fosse fattibile proverò come stai dicendo te
@HROT: escludendo il progetto di Gabry alcuni dei vantaggi generali solitamente sono questi:
- te ed il nemico non dovete premere "la freccia direzionale" per fare danno, ma semplicemente stare sul tile adiacente ed avere l'avversario davanti per attaccare e quindi tutte le frequenze ed i movimenti personalizzati gestiti in proposito
- possibilità con lo stesso codice di fare armi che attaccano a due tile di distanza semplicemente modificando "gli uguali"
- possibilità (caso di Gabry) del nemico di girarsi notando l'eroe che gli fa le boccacce da dietro
- possibilità di considerare contemporaneamente più nemici intorno per tecniche ad area
- possibilità dei nemici di attaccare contemporaneamente l'eroe: il tocco evento non è un parallelo non funziona se già un altro evento a tocco è in funzione, quindi se 4 nemici raggiungono l'eroe ed ognuno ci mette un secondo ad attaccare col parallello in un secondo l'eroe riceve 4 attacchi, mentre con la collisione ci vogliono 4 secondi ed ogni evento attacca a turno
- se metti un aspetta per gestire i tempi il tuo eroe rimarrà bloccato finché l'aspetta non sarà terminato senza darti la possibilità di muoverti in maniera fluida.
Tra tutti il primo e l'ultimo mi paion le cose più problematiche: non è bello dover sempre tenere premuta una freccia verso il nemico per attaccare, al giocatore non sembra "responsivo" aver davanti il nemico e non fargli nulla da fermi anche se effettivamente la spada ci va sopra e, così, muoversi e venire anche per pochi frames bloccati dal nemico vicino mentre si sta correndo in maniera fluida.
^ ^
Gabry usa una strategia mista ed infatti soffre sia del problema della freccia direzionale che quella del nemico che blocca i movimenti (vecchia demo).
^ ^
@Gabry: non l'ho provata, ma la tecnica dei passi non dovrebbe essere prioritaria rispetto a quella delle coordinate, ti conviene cercare di aggiustare l'evento parallelo del danno. Prova anche la mia soluzione di mettere la switch OFF appena la condizione è verificata, ma non scordare il fatto che come ho detto qui sopra in questo messaggio a ROT il fatto di avere collisioni a tocco fa rimanere i problemi di eroe bloccato.
^ ^
no ma l'eroe non si blocca mai! è il nemico che si blocca ogni tanto, comunque fondamentalmente devo sbolognarmela io perchè voi conoscete parte del sistema giustamente non avete il panorama completo, anche se alla fine cè solo il trigger tocco giocatore sull'evento per l'attacco dell'eroe che leva tot hp alla variabile hp del nemico, non cè altro praticamente.
-
Forse sono io che mi spiego male o che prendo per scontato qualcosa che non è.
Allora, cerco di essere più comprensibile.
Gimmy ha calcolato le coordinate con un processo parallelo che fa unicamente questo a ripetizione: se il nemico si trova a una casella da te mette On la switch collision. Sempre, in qualsiasi istante, anche se la metti Off con un altro evento lui la rimette On immediasubito.
In un altro evento lui mette attese e controattese e poi parte l'attacco vero e proprio.
Di norma le attese dovrebbero prevenire i problemi, ma qui generano il paradosso che i problemi li creano loro. In un modo subdolo.
Normalmente che succede nel bs di Gimmy?
Evento 1: calcola la prossimità e mette On la switch.
Evento 2: se la switch è On, mette delle attese, fa partire l'attacco, Jordi subisce e la switch va Off.
E fin qui non c'è nessun problema: se tu sei vicino al nemico e stai fermo quello ti colpisce e fine.
Se invece arriva il pignolo di Arkady, questo rompiscatole fa cose strane: preme tasti vari per cercare di allontanarsi dal nemico prima di subire il danno. Il risultato è che Jordi riesce ad allontanarsi dal nemico di una o due caselle grazie alle attese che ho segnato in blu (possono trovarsi in un qualsiasi punto dell'evento prima dello switch off e ti daranno l'occasione di allontanarti). Siccome prima dell'attacco vero e proprio non c'è la condizione "se Jordi e il nemico sono vicini" il giocatore subirà l'attacco anche se già sarà arrivato in Messico nel frattempo, creando queste strane glitch (e sospetto che questa sia anche la causa della grafica che si inceppa di cui parlavi).
Io cosa proponevo?
Evento 1: calcola la prossimità e mette On la switch, ma al contempo la mette Off non appena ti allontani.
Evento 2: se la switch è On, mette delle attese, controlla se la switch è ancora On, fa partire l'attacco, Jordi subisce.
Perché ho fatto questo cambiamento? Perché l'evento 1 nel caso di Gimmy mette una volta la switch On e quella resta On finché non intervieni manualmente mettendola Off. Nel mio caso, l'evento 1 si accorge se nel frattempo ti allontani e in al caso la mette Off. L'evento 2 prima di far partire l'attacco adesso controlla se la switch è ancora On (se ti sei allontanato l'evento 1 l'avrà già messa Off) e se è Off l'attacco non parte e quindi se già hai preso la via del Messico non subisci.
Vai a ripescare il tuo evento e il mio.
Il tuo fa questo:
http://i64.tinypic.com/14d37rt.png
Se X è 0
-se Y è 1
--Switch On
-Fine
-se Y è -1
--Switch On
-Fine
Fine
Se Y è 0
-se X è 1
--Switch On
-Fine
-se X è -1
--Switch On
-Fine
Fine
Giusto?
Il mio fa questo:
http://i.imgur.com/rq13gL4.png
Se X è 0
-se Y è 1
--Switch On
-Altrimenti
--se Y è -1
---Switch On
--Altrimenti
---Switch Off
Altrimenti
-Se Y è 0
--se X è 1
---Switch On
--Altrimenti
--se X è -1
---Switch On
--Altrimenti
--Switch Off
Altrimenti
-Switch Off
-Fine
Fine
Lo traduciamo in italiano? (cavolo, tradurre in italiano è la cosa per cui mi pagano nella vita, quindi almeno questo dovrei saperlo fare
)Se la X è 0 allora controllo se la Y è 1.
Se è 1 metto la Switch On, altrimenti mi chiedo se la Y è -1.
Se è -1 metto la Switch On, altrimenti la metto Off.
Fermiamoci qui. Nella parte rossa ho concatenato le due condizioni create da te, nella parte blu ho aggiunto un altrimenti che prende in considerazione il caso in cui la X è 0 e la Y non è né 1 né -1, quindi la switch deve essere Off.
Poi continuo con un altrimenti legato a Se la X è 0. Significa che quello che c'è scritto nell'altrimenti viene preso in considerazione se la X non è 0. Quindi continuando da sopra abbiamo.
Se la X è 0 allora controllo se la Y è 1.
Se è 1 metto la Switch On, altrimenti mi chiedo se la Y è -1.
Se è -1 metto la Switch On, altrimenti la metto Off.
Altrimenti
Se la Y è 0 allora controllo se la X è 1.
Se è 1 metto la Switch On, altrimenti mi chiedo se la X è -1.
Se è -1 metto la Switch On, altrimenti la metto Off.
Qui ho unito l'altra metà del tuo evento alla parte superiore: se la X non è 0 allora mi chiedo se la Y è 0. E aggiungo un altrimenti switch Off nel caso in cui la Y sia 0 e la X non sia né 1 né -1
Infine ci vuole un ultimo altrimenti a Se la Y è 0 per dire al programma cosa fare quando sia la X che la Y sono diverse da 0.
Se la X è 0 allora controllo se la Y è 1.
Se è 1 metto la Switch On, altrimenti mi chiedo se la Y è -1.
Se è -1 metto la Switch On, altrimenti la metto Off.
Altrimenti
Se la Y è 0 allora controllo se la X è 1.
Se è 1 metto la Switch On, altrimenti mi chiedo se la X è -1.
Se è -1 metto la Switch On, altrimenti la metto Off.
Altrimenti la metto Off.
Fine
Nel secondo Evento ho aggiunto un controllo "se la switch è On" per assicurarmi che Jordi durante l'attesa non si sia spostato, perché in tal caso l'Evento 1 l'avrà messa Off.
Guarda, non so come essere più chiaro di così.
Ho usato anche i colori per distinguere le varie parti del codice e non fare confusione. Il problema vero e proprio è che spiegandole le cose diventano difficili e complicate, facendole sono molto più semplici.
allora Arka usando il tuo metodo il TRacking fila liscio come l'olio, nessun glitch legato a viaggi in Messico XD
tuttavia cè qualcosa che rovina l'attacco, io sto pensando a tutto quel switchare on/off su processo parallelo.. mi si blocca il nemico quando col trigger tocco giocatore provo ad attaccarlo e nemmeno subisce l'attacco, a volte si blocca perfino per poi risbloccarsi da solo ( il nemico) riesco a dargli un colpo una volta su dieci.. cè qualcosa che non va, come l'avevo fatto prima senza switch ma assegnando il colpo direttamente al posto dello switchare ON tutto il resto funzionava bene a parte la glitch famosa.
adesso riprovo con le variabili sui passi
-
come minimo si merita la miglior risposta infatti al "povero" Arka ho dato la best answer, se non altro per come ha eviscerato il problema fino in fondo, proponendo tra l'altro ultra dettagliate soluzioni pratiche e non solo intelligenti constatazioni teoriche, e la santa pazienza poi ^^
però il punto è che sono per natura un cocciuto quindi ci devo sbattere la testa per bene e poi cercare perlomeno di appellarmi a tutto quel che riesco perchè non mi si atrofizzi il cervello a elemosinare sempre la pappapronta, è un discorso di etica se così vogliamo chiamarla Arka, nulla dipersonale, anzi.
io ad esempio sto pensando di inserire una qualche condizione sfruttando la variabile passi del giocatore, cioè per farla semplice se dopo che il sistema acquisisce quei valori per le variabili di coordinate giocatore ed evento, se il giocatore ha fatto un passo non succede nulla. questo teoricamente mi sembra fattibile ed ora ci sto lavorando su, poi magari si rivela un altro vicolo cieco però ci devo almeno provare a far funzionare il cervello sennò tanto vale che rinuncio in partenza.
-
Non mi convincono quelle attese messe lì fra l'acquisizione della X e l'acquisizione della Y: sono platealmente buttate lì a caso.
Inoltre, non escludono la glitch di cui ti parlavo.
Durante queste due attese di 30/60 di secondo per un totale di 1 secondo Jordi ha benissimo il tempo di spostarsi di due caselle, ma Rpgmaker considererà la sua posizione prima dell'attesa e quindi se ti sei spostato nel frattempo continuerai a subire comunque il danno.
Comunque, ho il piccolo sospetto che io perdo tre quarti d'ora a scrivere questi lunghi post, ma alla fine tu preferisci sfornare qualcsoa di tuo a tutti i costi piuttosto che provare a capire cosa ti spiego.
Ieri ti ho spiegato le variabili per filo e per segno come anche un bambino avrebbe capito, e mi hai risposto "andrò a cercarmi un tutorial sulle variabili": che ti può dare un tutorial più di quello che ti ho scritto io, che te le ho spiegate per filo e per segno (e ti ho anche spiegato cose in più, come il calcolo di unità, decine, centinaia, ecc)?
In quest'ultimo post ti ho spiegato per quale motivo Jordi può subire danni se tu ti sposti abbastanza velocemente: ci sono quelle fottute attese e prima del danno non c'è un vero calcolo di prossimità: adesso sembrerebbe che tu abbia risolto il problema, ma con quelle attese hai invece peggiorato la situazione perché in un secondo la X e in mezzo secondo la Y di Jordi possono cambiare.
Poi, fai come vuoi. Non voglio pretendere di avere ragione, di dettarti cosa fare. Ti ho spiegato per filo e per segno qual è il problema e ti ho dato una soluzione che ho testato e mi ha funzionato alla perfezione.
Ripeto, fai come vuoi. Ma a un certo punto capisco che è inutile scriverti lunghi post quando non provi nemmeno a capirli e metterli in pratica.
hai perfettamente ragione è peggiorato XD
posso provare a sbrigarmela da solo? il più ormai mi pare sia fatto! poi semmai chiedo l'aiuto del pubblico ^^
-
http://i66.tinypic.com/15f6tzn.png
questo è l'evento modificato
-
La switch è durata poco ho messo direttamente l attacco del nemico come conseguenza delle condizioni di prossimità. Arka a me fa piacere che ti prendi tanto a cuore il mio caso ma più che la pappa pronta vorrei essere indirizzato e poi cercare di arrivarci. Il problema che mi hai segnalato l ho riscontrato e arginato con qualche attesa. Per il resto se vuoi ti mando il gioco e vedi come ho elaborato il tutto rispetto a prima perché ho cambiato parecchie cose negli eventi.
-
grande Lopp^^Ti voglio subito segnalare un bug:
Quando c'è lo scontro con il mostro iniziale puoi colpire l'ambiente circostante al mostro, magari il mostro è a sinistra e tu dovresti colpire verso sinistra giusto? se colpisci su o in altre direzioni, se sei su quei tiles li, il mostro viene colpito lo stesso
Anche quando va a dormire e si sveglia c'è un errore di grafica secondo me
Update sul bs: Io frontalmente non riesco ad attaccare i mostri (qualche attacco lo fa) :( solo se mi giro verso altre direzioni, in poche parole non puntandoli ...
Scappo a lavoro ora ^^ Ottimo lavoro per il resto, ma aspetto l'aggiornamento che sistema il bs per continuare ;)
il bug del tile a letto è per il fatto che avevo modificato l' Outside_B delle RTP che non avendo incluso nella demo (asinone) chiaramente non viene "richiamato" sui vostri PC
per tutto il resto, i punti deboli di un biesse terra terra ^^ grazie per averla provata comunque, ora rilascio gli aggiornamenti tecnici del caso ^^
PRIMA COSA, DEMO SOSPESA IN ATTESA DI FARVI COLLAUDARE IL NUOVISSIMO BATTLE SYSTEM CON LE VARIABILI (era ora dirà qualcuno eh si ^^)
QUINDI RINGRAZIO QUANTI HANNO PROVATO PER LE LORO SEGNALAZIONI CHE MI HANNO DATO QUELLA MARCIA IN PIU' PER PRODIGARMI A RISOLVERE...
brevemente elencherò come sto cambiando il BS nella sua meccanica di fondo:
- un processo ad "inizio automatico" assegna tramite variabili le HP ai vari nemici su mappa (alcuni ne avranno più tipo gli orchi, altri tipo pipistrelli di meno, ecc)
- enne processi (quanti sono i nemici) di tipo parallelo con condizione d'avvio vincolate alle HP dei suddetti (se maggiori o uguali a 1 per la precisione) tracciano in tempo reale le coordinate di nemici e giocatore confrontandole per verificare quando un nemico entra nel range di prossimità del nostro giocatore, o quando il nostro giocatore si avvicina accanto a un nemico, e quando ciò avviene provvedendo ad eseguire l'attacco del nemico che il nostro giocatore ovviamente subirà!
- l'evento danno al nemico invece sarà azionato dal trigger "tocco giocatore" (quindi potremo colpire solo & soltanto il nemico verso il quale direzioneremo e nessun altro) unitamente allo schiaccio del tasto relativo all'attacco, questa combinazione toglierà punti alla variabile del HP del nemico con condizione che se questa scende a 0 si attiva lo switch locale che ne decreta la morte ed al contempo inibisce l'evento parallelo per il "tracking" del nemico di cui sopra, altrimenti se non è ancora a zero subisce un altro colpo e così via.
a presto con qualche video di aggiornamento, grazie a tutti che mi avete aiutato nello sviluppo con supporto a 360° XD
-
eh altro che quella me ne son capitate, io le prove le faccio complete con gli attacchi i cambi grafica gli effetti sonori, tutti gli eventi insieme però alcune sono normali. prendi ad esempio i processo parallelo per le coordinate, se tu non gl idessi una pausa mi "aggancerebbe"il nemico finchè non esco dalla casella calcolata come adiacente, se metto la pausa troppo lunga invece e passo svelto vicino a lui posso ritrovarmi a somatizzare il danno due tre caselle dopo essergli passato accanto... son tutte cose con cui bisogna fare i conti..
cioè un controllo a distanza?
Edit mi é capitato ad esempio che si blocca il nemico o la grafica eppure tutto in ordine come eventing
-
wow cmq io non capisco come fai a lavorare a così tanti progetti insieme !!
per me è già da incubo riuscire a dedicarmi a uno
comunque potresti mettere item tipo stivali di gomma per rendere il party invulnerabie al tuono su acqua, e cose simili corazza d'amianto per il fuoco eccetera
-
Mmh, mi è sorto un dubbio. Quando ho provato a programmare il nemico che ti attacca di tanto in tanto mi capitava una glitch facile da risolvere, ma comunque fastidiosa.
Prendi un nemico più lento di te. Fai un modo che sia vicino a te. Poi fai avanti e indietro di corsa accanto a lui (se è alla tua sinistra fai su e giù di corsa). Inoltre prova anche ad allontanarti di corsa dal nemico verso il lato opposto al suo.
Ci sono occasioni in cui subisci l'attacco anche se già ti trovi lontano perché ti sei spostato appena in tempo? Può benissimo succedere perché non appena ti trovi a una casella da lui scatta l'evento dell'attacco, ma se sei abbastanza rapido riesci a passare in un'altra casella prima che l'animazione di attacco di presenti.
arka si fa quel che si puo' giocando con micro attese e vari accorgimenti, bisogna tener conto che alla fine si sta lavorando con un tool che con gi eventi ti permette di fare fino a un certo punto, quindi a meno che non si vada giù duro di script e/o plugin per forzare il programma bisogna sapersi anche accontentare
-
ah ma quindi intendi che puoi raccogliere gli elementi in giro da quel che trovi per poi scatenarli in battaglia. capisco il fuoco da campo ci può stare ma il ghiaccio da campo? poi un aquilone per catturare i fulmini XD
-
sverginiamo stò topic XD
a me l'idea, imho mi harba. la vedo più che altro dura nel senso in sintesi la strategia vincente è basata su quel che trovi nel terreno, quindi poi tutto dovrà essere a tema ma difficilmente mischiabile, esempio per attacchi di fuoco dovrai per forza inscenare in un ambiente vulcanico, per quelli di ghiaccio un ambientazione innevata.. a meno che tu non voglia mettere icebergs e pozze di lava in una foresta ^^
-
Avevo letto l'edit e non metto in dubbio il tuo lavoro, ma quello di rpgmaker (si crea da solo bug inspiegabili e non riproducibili). Non hai idea di quante glitch ho arginato con quel sistema che ti dicevo. Vediamo.
In ogni caso, una cosa base da aggiornare nel bs è il calcolo dei danni, sia inferto da te che dai nemici. Devi decidere una formula di calcolo di danno in base alla forza dell'eroe e alla difesa del nemico e viceversa. Altrimenti non ha senso salire di livello.
E quando hai tutto pronto, cerca di rendere più avvincente il sistema di battaglia
yess per quello ti dicevo che non potevo implementare il tuo sistema di HP basato sull'hp del biesse del tool, perchè voglio fare una cosa con le variabili da potermi gestire per conto mio. ovviamente dovrò tener conto di attacco e difesa e hp del giocatore e mostri per il danno subito e/o arrecato. comunque sto lavorando per qualcosa stile "Sacred" quindi in un combattimento si picchia e si incassa allo stesso tempo, se trovate un nemico che dopo avergli dato dieci colpi vi butta giù con due colpi significa che vi servirà un livello più alto ed armi ed armature più performanti ^^
-
mi cito che magari col cambio pagina non è stato letto
esatto Guardian quella switch attiva l'attacco del nemico nella cui pagina evento poi viene disattivata.
EDIT x Arka non cè bisogno che guardi l'eroe perchè nella stessa pagina dove poco dopo disattiva la switch famosa poco prima cè un comando che forza la "girata verso l'eroe" quindi attacca ^^
mi piace vincere facile ponzi ponzi pò pò pòòòòòòòòòò XD
sto testando funziona molto bene, ho fatto anche l'hp del nemico a variabili che goduriaaaaaaaaaaaaaaaa
5colpi e va ko
ora il biesse può finalmente andar bene, se sto fermo a schiacciare attacco non colpisco nessuno a meno che non mi muovo verso un bersaglio specifico, e nel qual caso danneggio sempre e solo quello con cui faccio contatto giocatore, tutti gli altri invece mi danneggiano con contatto evento.
prima se mi circondavano in 4 e stavo fermo schiacciando attacco li danneggiavo contemporaneamente tutti e 4
ribadisco già il fatto di aver in qualche modo "scisso" il contatto giocatore per l'attacco del giocatore, dal contatto evento per l'attacco dei nemici è per me una svolta EPOPALE XD. e sto cominciando a prendere confidenza con le variabbbbili ^^
su tutto il resto ora si puo lavorare come si vuole, ma mi pare di aver già raggiunto un buon compromesso nei test che sto facendo in questo preciso momento.
TRIP TRAP
in Progetti VX e VX-Ace
Posted
OMG!!!!!!!! fin TROPPO chiaro, praticamente hai già eventato il tutto, se vuoi ti passo il progetto ^ ^
scherzo ovviamente, dovrei cavarmela con le animazioni per i danni e cose simili spero con un processo parallelo e basta e file di animazione (per il discorso unità decine mi viene incontro il tool che permette di sovrapporre/affiancare 2 animazioni contemporanamente per crearne una, non uscirò dai 99 di danno comunque)
una cosa del genere? l ideale sarebbe mettere barra vita giocatore e nemici ogni volta che il pp rileva il contatto col nemico (quindi si sottintende che partirà la mischia ^^)
https://youtu.be/unbJ9y5rY-A