Jump to content
Rpg²S Forum

eritiacoli

Utenti
  • Posts

    65
  • Joined

  • Last visited

Everything posted by eritiacoli

  1. Molto meglio! Forse potresti provare a rendere piú "organico" il passaggio tra capelli rosa e rossi? Se non avessi letto la tua spiegazione avrei pensato avesse dei rasta. XD Invece che mettere il bordo scuro per separarli contali come una ciocca intera, mantenendo ombre e luci nello stesso punto, solo che cambi la palette in quella dei capelli rossi dall'orecchio in giú.
  2. A seconda di quanto sei versatile nella pixel art ti consiglio o di cercare dei personaggi con capelli simili, staccarli e attaccarli su Erica per poi ricolorarli di marrone, come Ken: http://wiki.shoryuken.com/images/8/8c/Ken.png O, se il recolor non funziona, imitare lo stile grafico di Street Fighter. Chun Li ha una riga centrale ed una frangia laterale marroni che potrebbero aiutarti e capire come ombreggiare le ciocche ( dove mettere luci ed ombre, insomma ): http://www.fightersgeneration.com/characters/chunli434.png Nota come la palette di colori dei capelli è limitata a 6 colori: il più scuro funge da base, gli altri 5 vengono usati l'uno nell'altro, dal più scuro al più chiaro, per fare le luci. lavora su una ciocca partendo da una sagoma del colore più scuro, poi aggiungi i mezzi toni dove andrà a ricadere la luce ed infine i riflessi con i toni più chiari: http://i67.tinypic.com/mab6s7.png ( questo portrait ha l'ombra in basso a sinistra e la luce in alto a destra ) Poi, se ti va e vuoi combinare questi colori come si deve, prova a controllare come si effettua il "dithering" con la pixel art per le ombreggiature/luci: http://i.imgur.com/8lMX9X7.gif http://www.strandedsoft.com/contenidos/uploads/2014/04/Dithering-examples.png Spero che sia tutto chiaro, fammi saprere se hai dei dubbi!
  3. Molto bella l'intro per i personaggi ( mi piace tantissimo Erica ) e ottimo lavoro fatto sugli sprites. Come mai il portrait di Erica ha i capelli colorati in maniera molto meno dettagliata rispetto agli altri? E' un peccato, essendo il personaggio la "mascotte", da quello che ho capito.
  4. Grazie per il consiglio, rende il tutto molto più funzionale! Ho fatto le picture ed un evento comune per la ruota in battaglia: https://ibb.co/fv9O85 E creato l'altro evento comune che con tuuuuutte le variabili di ogni spicchio: https://ibb.co/dLYTak Ecco una singola mappa con l'evento: https://www.mediafire.com/?eft92sslz0bu51w Parlando con i personaggi dovrebbero cambiare gli spicchi della ruota. Devo ancora organizzarla come si deve, ma lo scheletro c'è
  5. Scusa per la risposta tardiva, ma questa settimana è stata piena di impegni ed ho avuto pochissimo tempo per lavorare sul progetto @.@ Allora: ho iniziato a sistemare degli eventi in parallelo per far muovere Navi e PowerUp se non fosse che sono sorti alcuni problemi. I power up, soprattutto quelli che dovrebbero riempire la barra del raggio per più di 2 unità bloccano fisicamente il giocatore. Una volta sfiorati danno il bonus ma il giocatore non si riesce più a muovere finchè non spara il raggio. Sono tutti su Phasing, quindi non capisco dove sia il problema @.@ Il Raggio Grande è impostato su 14 navi buttate giù ma ho notato che compare anche per quando il Raggio dovrebbe essere normale, nonstante tutti gli eventi che lo facciano partire ( sparo, contatore variabili e immagine stessa del Raggio ) siano impostate su 14. A questo punto non so se sono semplicemente io troppo cotta a furia di lavorare sulle stesse variabili che non noto nemmeno errori elementari, ma non capisco veramente quale sia il problema! ( ho aggiunto le Variabili EroeSopra e EroeSotto che corrispondono a Raggio +/-1 Y ) Oltretutto, avrei voluto aggiungere un sistema di conteggio punti e non ho trovato nulla per mantenere una finestra messaggio che mostri il valore di una variabile Punteggio ( con \v[iD] ) in sovraimpressione perchè mettendo una finestra in parallelo non posso far fare nulla al giocatore ( la finestra si apre e chiude ad infinitum ), quindi ho dovuto fare uno script: class Window_Punteggio < Window_Base def initialize super(30, 390, 150, 60) self.contents = Bitmap.new( width - 32, height - 32) self.opacity = 255 self.back_opacity = 240 self.contents_opacity = 255 self.contents.font.name = "Tahoma" refresh end def refresh self.contents.clear self.contents.font.color = Color.new(255, 255, 255, 255) self.contents.font.size = 24 self.contents.draw_text( 0, 0, 100, 30, "Punteggio = " + $game_variables[5].to_s, 0) end end Chiamato con Window_Punteggio.new ( è presente nella MAP001, lo stavo testando) che ha i suoi problemi, come ad esempio il refresh lentissimo del contenuto della finestra, ma almeno il suo lavoro lo fa xD Vorrei aggiungere la modifica di questa VariabilePunteggio a navi abbattute ( aumentano il punteggio ) e colpi subiti ( lo diminuiscono ): a tot punteggio alla fine della sequenza il giocatore riceverà dei premi ( in modo da rendere la sequenza non solo svago ma anche un metodo per ricompensare il giocatore ). Se mai riuscirò ad affinare questo script lo vorrei inserire nella sezione ScriptRGSS(XP), magari potrebbe essere utile a qualcuno. Questo è il progetto ( le Navi vanno ancora malino perchè non ho terminato il loro pattern ): https://www.mediafire.com/?bnaj9i2jb7nk6nv
  6. Non ho giocato Chrono Cross ma sì, è una cosa simile. Volevo un sistema dove il giocatore non potesse ignorare l'elemento magico, visto che il protagonista è l'ex Mago Nero. Delle volte negli RPG puoi ignorare la magia perchè ti basta quella statistica di attacco alta per far fuori tutto, in questo caso lasciar stare la Ruota avvantaggerà il nemico. Il livello sarebbe il numero della picture, giusto? Tipo numero 1 è quella che sta più sotto e la 2 è sopra? No aspetta, gli elementi sono 4, quindi 80 spicchi circa. Gli elementi speciali vanno a sostituire lo sfondo che da essere trasparente diventa il loro colore, dato che "prendono il posto" di quattro spicchi che in realtà non avranno semplicemente la picture elementale sopra. Sfondo Nero -> Com'è la Ruota normalmente -> Com'è con sfondo Nero e i 4 spicchi in meno: https://ibb.co/e64Yqk Per gli elementi speciali sostituirò gli sfondi, altrimenti dovrei modificare tutto il metodo di sottrazione ed addizione degli spicchi @.@ Cos'è un vettore di variabili? Come funziona? Questo è il menù delle variabili: https://ibb.co/cspSGQ E' qui da qualche parte? Come i simbolini degli elementi in Legend of Legacy. Devo ancora pensare ad un bel design, in effetti Assolutamente. Le basi prima! Appena finisco di sistemare lo shoop em up inizio a lavorare su questo: anche perchè devo pure capire come influenzare la potenza di una mossa a seconda delle variabili, avevo visto qualche topic a proposito sull'RPG Maker forum inglese e lo devo ritrovare. Ho chiesto a Testament cosa sia il metodo vettoriale, non ne ho mai sentito parlare Il metodo per chiamare picture e variabili negli script da quello che ho capito è letteralmente uguale ad un evento minus la convenienza di interfaccia...se non dà alcun vantaggio di lag non vedo il motivo di preferirlo al Common Event a questo punto Dato che le picture variano solo dopo un attacco potrebbe non far laggar troppo, grazie al cielo è un combattimento a turni. Il fatto di far scorrere tutto da sinistra a destra mi ha semplificato la vita e reso il tutto più un "puzzle" per il giocatore, spero di riuscire ad accocchiare le quattro variabili per usarlo xD Appena sistemo qualcosa di solido lo posto.
  7. Giustissimo, meglio qualcosa di più pacato, +2 fuoco -2 acqua magari Tipo che il bordo stesso sia composto da quattro frecce che si direzionano in senso orario: http://i66.tinypic.com/fa7ozc.png Per questo avevo paura di usarlo xD Le mie opzioni sono o un evento comune che contiene le variabili ( e facendo un calcolo veloce le picture che ci vogliono dovrebbero essere circa 84: 1 per lo sfondo normale (vuoto); 3 per gianni, pinotto e variabile speciale che, per semplificarmi la vita, agiranno da sfondo ( le prime due ) poichè sottraggono spicchi a quelle normali o immagine semitrasparente da mettere sopra; 80 per tutti gli elementi ( ognuno di loro va da 1 a 20, quindi 20 pictures ). ( sempre che la matematica non mi stia fregando, cosa possibile xD ) Poi devo decidere se ordinare le picture a spicchi che aumentano o a spicchi singoli che si spostano: https://ibb.co/gUoO6Q https://ibb.co/dVZwRQ Con il primo metodo avrò tra le 2 e le 5 picture su schermo, con il secondo 21 picture su schermo contemporaneamente, sempre. Ora non ricordo come funzioni l'accavallamento delle picture in RPG Maker, ma quale va "sopra"? L'ultima che viene mostrata? Perchè il motivo per cui non voglio usare il primo metodo è che anche se l'elemento terra coprisse l'acqua aumentando, poi basterebbe un aumento successivo dell'acqua per coprire pure il terra che è aumentato... Invece con il secondo metodo ho addizione a "sinistra" dell'elemento e sottrazione a destra: lo spicchio verrebbe eliminato volta per volta senza problemi. Se le picture son piccoline anche se ce ne sono 21 non danno fastidio vero? Poi il problema dell'impostazione delle variabili...è il motivo per cui ero indecisa tra script e common event. In commont event immagino dovrei fare una cosa del genere: settare che la somma di var acqua + var aria + var terra + var fuoco = 20. ( condizione normale senza gli altri due elementi ) settare ognuna di loro a 5 Far partire conditional branch per ognuna: Tipo: if var acqua <=19: - if var acqua + 3 -> var fuoco - 2 e var terra - 1; if var fuoco =1 -> var fuoco -1 e var terra -1 In quello precedente: if var fuoco =0 -> var terra-2 var aria-1; if var terra =1 -> var terra -1 e var aria -1; if var terra =0 -> var acqua -1, var aria -2; if var aria =1 -> var acqua -1, var aria -1 ( inserisco lo stesso per +2 e +1 ) if var acqua = 20 : - niente - E poi faccio lo stesso per ogni elemento? Ogni variazione di variabili è seguita dall'aggiunta di picture a sinistra del proprio elemento e rimzione di picture alla destra degli altri due . Invece con script dovrei avere un common event con call script che chiama una window in window_base tipo così: class Ruota_Elementi < Window_Base def initialize super( 150, 40, 100, 100) self.contents = Bitmap.new( width - 32, height - 32) self.back_opacity = 0 self.windowskin = RPG::Cache.windowskin(WINDOWSKINTRASPARENTE) refresh end def refresh self.contents.clear $game_variables[IDVARIABILEACQUA] = 5 $game_variables[IDVARIABILEFUOCO] = 5 $game_variables[IDVARIABILETERRA] = 5 $game_variables[IDVARIABILEARIA] = 5 $game_variables[IDVARIABILEFUOCO] + $game_variables[IDVARIABILEACQUA] + $game_variables[IDVARIABILETERRA] + $game_variables[IDVARIABILEARIA] = 20 self.contents.blt(X, Y, IMMAGINERUOTA, RECT, 255) IMMAGINERUOTA = Bitmap.new(Graphics/Pictures/NOMEIMMAGINE) RECT = Rect.new( 0, 0, IMMAGINERUOTA.width, IMMAGINERUOTA.height) case $game_variables[IDVARIABILEACQUA] if $game_variables[IDVARIABILEACQUA] <=19 when +3 $game_variables[IDVARIABILEFUOCO] -2,$game_variables[IDVARIABILEARIA] -1 if $game_variables[IDVARIABILEFUOCO] <= 1 $game_variables[IDVARIABILEFUOCO] -1,$game_variables[IDVARIABILEARIA] -1 if $game_variables[IDVARIABILEFUOCO] == 0 $game_variables[IDVARIABILEARIA] -2, $game_variables[IDVARIABILEACQUA] -1 if $game_variables[IDVARIABILEARIA] <=1 $game_variables[IDVARIABILEARIA] -1, $game_variables[IDVARIABILEACQUA] -2 end end when +2 etc etc etc end when +1 etc etc etc end case $game_variables[IDVARIABILEFUOCO] <= 19 etc etc etc end ( e ovviamente aggiungere l'IMMAGINERUOTA corrispondente ad ogni modifica. Insomma, sono metodi incasinati entrambi xD Conta che le skill avranno una descrizione tipo: Acqua +++ Fuoco-- Aria- e ci saranno i classici NPC che ti danno suggerimenti sul sistema + i primi nemici fanno da tutorial e il primo boss è un tutorial/prova finale per capire il funzionamento della ruota base. Carinissima l'idea di causare morte o ricevere premi extra tramite determinate percentuali! Se riesco a far funzionare tutta la roba ci proverò di certo!
  8. Ho deciso di evere la ruota a 20 spicchi ( 5 di partenza per ogni elemento ), ogni elemento è collegato ad una variabile che va da 0 (scompare dalla ruota ) a 20 ( riempie totalmente la ruota ). Gli elementi si influenzeranno a vicenda ma in ordine, in modo da evitare l'uso di troppe picture e rendere il tutto un sasso-carta-forbici piú intuitivo. Ogni spicchio rappresenta il 10% di potenza: la condizione iniziale standard ha quindi tutti gli elementi al 50% della loro potenza. Nel caso di terreni di combattimento particolari ( tipo un vulcano ) certi elementi partiranno con piú o meno spicchi ( fuoco + 4 e acqua -4, ad esempio ) La ruota avrá i quattro elementi sistemati in modo che quello contro cui siano superefficaci sia alla loro sinistra e il secondo contro cui sono "mediamente" efficaci di fronte. Gli elementi aumenteranno sempre in senso orario cosí. La ruota avrá: aria (ovest), terra (nord), acqua (est) e fuoco (sud). Gli elementi sottrarranno in ordine di preferenza ( superefficace -> meno efficace -> meno efficace ): Acqua = fuoco -> aria -> terra Fuoco = aria -> terra -> acqua Aria = terra -> acqua -> fuoco Terra = acqua -> fuoco -> aria Le variabili saranno cambiate dalle skill del giocatore per un massimo di +3 e un minimo di +1 ( i nemici/boss avranno certe mosse che potranno aumentarle di piú ). Acqua: +3 = fuoco -2 e aria -1 +2 = fuoco -2 +1 = fuoco -1 Fuoco: +3 = aria -2 e terra -1 +2 = aria -2 +1 = aria -1 Aria: +3 = terra -2 e acqua -1 +2 = terra -2 +1 = terra -1 Terra: +3 = acqua -2 e fuoco -1 +2 = acqua -2 +1 = acqua -1 Se l'elemento primario va a 0 scalano ( per esempio, nel caso dell'acqua: se fuoco è giá a zero e acqua va a +3 aria perderá -2 e terra -1 ). Se anche l'elemento secondario va a 0 scala ancora ma l'elemento terziaro può massimo diminuire di 2 ( stesso caso di prima, acqua +3 diventerá +2 e terra andrà a -2 ). Oltretutto ci sono delle condizioni "speciali" che si ottengono se si riempe la ruota, una per l'elemento superefficace ed una per quello opposto: Acqua= Variabile di fuoco diminuisce di 2 intanto che la ruota resta piena. Variabile di Terra è settata a 0 per una massimo di tre turni o finchè la ruota resta piena. Fuoco: idem ma con aria -2 e acqua settata a 0. Aria: idem ma con terra -2 e fuoco settato a 0. Terra: idem ma con acqua -2 e aria settata a 0. Queste sono le variabili per gli elementi "normali", quelli speciali che si incontraranno solo in determinate zone, invece: (Spoiler se qualcuno vuole scoprirle in game) ( Le chiamerò Gianni e Pinotto qui per evitare spoiler ) Gianni: è persente in 4 spicchi ad inizio battaglia, tutte le altre variabili sono diminuite equalmente di 1. Per rimuoverla è necessario settare il valore di ogni variabile elementale in modo diverso ( tipo 3/6/1/2 o 5/4/1/2 ). Nullificata ribilancerá le veriabili a 5 ed i nemici che ne facevano uso rimarranno storditi per tot turni. Pinotto: è presente in 4 spicchi ad inizio battaglia e sottrarrà 2 a fuoco, 1 a terra ed 1 ad aria. Per rimuoverla è necessario che tutte le variabili elementari abbiano lo stesso valore ( quindi 4 ). Una volta nullificatá manderá acqua a +2 e terra/aria a +1. Mostri che la usano rimarranno storditi per tot turni. C'è un altro variabile/elementon speciale che funziona in maniera ancora differente ma è unico di un boss: Partirá avendo la ruota piena ( quindi a 20 ) anche se è semitrasparente e si possono vedere gli elementi in partenza standard sotto ( quindi 5 l'uno ). Finchè questa variabile rimane in campo il boss sará immune ad ogni tipo di attacco ma le skill influenzeranno comunque il movimento degli spicchi della ruota. Starà al giocatore capire come eliminarla di volta in volta, perchè ogni volta che è nullificata vi è una finestra di tot turni per colpire il boss e poi viene reimpostata. Sará una battaglia piú puzzle che RPG. Ho scritto un papiro @.@ Spero abbia senso come sistema. Immagino che poi con varie prove vedrò se è ben bilanciato o meno.
  9. Il break prima nel loop ha funzionato alla grande! In pratica volevo le picture per l'animazione a inizio e fine sequenza ( quando si muove lo sfondo per far vedere il corpo di Cat ), mentre durante la sequenza tolgo le picture e rimane l'evento statico, che è separato dalla Strega. Hai ragione, tenerlo "attivato" per più tempo è meglio! Ho deciso di fare in modo che la "carica" del Raggio sia doppia: quando la sua variabile arriva a 7 è pronto ad essere sparato, ma può continuare ad accumulare fino a 14 ( con barra annessa che si carica sopra di un altro colore ). Se si spara con variabile da 7 a 13 si ha sempre il raggio normale e la viariabile torna a 0, mentre se si spara con la 14 fa il Raggio Speciale grande 3 tile. Così è più potente ma ne è anche più sporadico l'uso Colpa mia, pensavo che quel "wait tot frames" all'inizio le facesse apparire dopo No ho aggiunta un'altra tipo quella azzurra e le ho collegate ad un evento in parallelo che le attiva dopo tot frames. Devo lavorare su altri tipi di nemici ( tipo navi più piccole ma più rapide o mostri ) e variare il metodo di apparizione, l'idea di farne apparire altri tipi speciali solo dopo che ne hai distrutte alcune è buona Dici che è meglio tenerle KO per sempre una volta colpite? Non rischio di dover fare un sacco di eventi e variabili che appesantiscono tutto? Vorrei aumentare il loro "cooldown" dopo che la switch va ad off così magari riappaiono dopo mooooolto tempo ed intanto sono apparsi altri tipi di nemici e non sembrano ripetersi troppo. Però il problema che restano immobili rimane...onestamente non ho idea di come abbia fatto a fare in modo che si muovano solo quando sono tornate tutte, pensavo che seguissero il "wait tot frames" prima di riapparire, non ho ancor capito come farle riapparire da sole. Ho cambiato il colore delle loro grafiche e ho capito che si impallano tutte nella seconda pagina: https://ibb.co/bM7hY5 Il problema è dopo il secondo Proceed With Movement, perchè rimangono in quella fase per un sacco di tempo. Ma nessun comando successivo mi sembra dia loro fastidio @.@ Grazie per il consiglio! Un documento .txt mi sarebbe molto utile per tenerle tutte d'occhio. Ho anche aggiunto degli eventi simili ai Topomissili gestiti da un evento in parallelo che funzionano da Power Up e Cure! Ora sì che sta iniziando ad assomigliare ad uno shoot em up
  10. Grazie per averlo spostato! Immagino che uno scripter per RGSS1 ormai sia raro, ma sper che qualcuno possa notare cosa ho sbagliato. Allora, questa è la modifica fatta a Scene_Item per usare il tasto A (in update_item): # A ボタンが押された場合 if Input.trigger?(Input::A) # キャンセル SE を演奏 $game_system.se_play($data_system.decision_se) # メニュー画面に切り替え $scene = Description_Scene.new return end Questa è Description_Scene che chiama ( la devo ancora aggiustare, mi da sfrondo nero dietro la finestra aperta, invece che lasciare le altre visibili dietro ): class Description_Scene def main @item_descriptions = Fin_Des.new @target_window = Window_Target.new @target_window.visible = false @target_window.active = false # トランジション実行 Graphics.transition # メインループ loop do # ゲーム画面を更新 Graphics.update # 入力情報を更新 Input.update # フレーム更新 update # 画面が切り替わったらループを中断 if $scene != self break end end # トランジション準備 Graphics.freeze # ウィンドウを解放 @item_descriptions.dispose @target_window.dispose end def update @target_window.update if @target_window.active update_target return end if @item_descriptions.active update_descriptions return end end def update_descriptions if Input.trigger?(Input::B) $game_system.se_play($data_system.cancel_se) $scene = Scene_Item.new return end end def update_target if Input.trigger?(Input::B) $game_system.se_play($data_system.cancel_se) @target_window.visible = false @target_window.active = false $scene = Scene_Item.new return end end end Ed infine la finestra che dovrebbe contenere il tutto, Fin_Des, che per ora sto provando ad impostare almeno per gli strumenti ma con scarsi risultati: class Fin_Des < Window_Base def initialize super( 0, 0, 600, 400) self.contents = Bitmap.new( width - 32, height - 32) self.opacity = 240 self.back_opacity = 240 self.contents_opacity = 255 refresh end def item return @data[self.index] end def refresh self.contents.clear self.contents.font.size = 22 self.contents.draw_text( 0, 0, 550, 350, "Descrizione:", 1) draw_item end def draw_item self.contents.clear self.contents.font.size = 22 item = @data case item when RPG::Item number = $game_party.item_number(item.id) case item.id when item.id == 1 self.contents.draw_text( 20, 30, 550, 350, "Descrizione!!!b eebcfr45 ", 2) when item.id == 2 self.contents.draw_text( 20, 30, 550, 350, "kjcbejrcbre", 2) end self.contents.draw_text( 0, 0, 550, 350, text) end end end
  11. Ho sempre amato come Dark Souls o Drag on Dragoon inserissero lunghe descrizioni/storie per armi, armature ed oggetti, quindi ho cercato di fare lo stesso. Se non fosse che qualsiasi cosa provassi con un Common Event che chiamava anche solo una finestra di dialogo funzionava malissimo ( si apriva solo dopo l'ultilizzo dell'oggetto e fuori dal menú ); Quindi ho provato a lavorare con l'RGSS. Come primo tentativo avevo aggiunto una Scene chiamata da Scene_Item premendo C prima dell'uso dell'oggetto che apriva una Window_Command con tre opzioni: usa, leggi descrizione, indietro. La prima purtroppo mi portava ad un loop infinito perchè ho capito in seguito che il metodo per usare gli oggetti è gestito da variabili locali ( update e update_item ) contenuti in Scene_Item che ovviamente non passavano alla finestra di comando. Leggi Descrizione non funzionava ugualmente: apriva la nuova finestra ma non compariva nessun testo dentro (anche se credo di non aver capito io come fare). Come seconda opzione provai a far partire alla pressione del tasto A nello Scene_Menu la finestra della descrizione, ma anche se questa appariva rimaneva vuota per gli stessi problemi della Leggi Descrizione precedente ma almeno non incasinava gli altri comandi essendo chiamata da un tasto a parte. Cercando su internet credo di aver trovato lo script giusto, ma è per VX Ace: http://www.rpgmakercentral.com/topic/36877-longer-item-description/ Insomma, quello che vorrei fare è che alla pressione del tasto A su un oggetto/arma/armatura venga chiamata una finestra che riconosca l'ID dello strumento e riporti la descrizione corretta. Conoscete uno script simile o il modo per farlo? Se servono i miei script a metà brutti e buggosi per capire dove stessi sbagliando li posto.
  12. Ho aggiunto il raggio e l'ho impostato a Navi distrutte: è una meccanica molto più carina, in effetti! Ho fatto grafica per le munizioni nemiche, alleate e per il raggio ( I polli e tutta la vecchia fattoria hanno compiuto il loro dovere ): giusto la barra del raggio ogni tanto dà problemi perchè le ultime picture che chiama quando il raggio è utilizzabile sono in loop per dare un effetto animato e delle volte non riesce a togliere la picture in tempo per tornare alla picture del raggio vuoto quando è usato. Ho ridotto le dimensioni di Cat su schermo, anche se credo che gli darò un tile in più di collo per non fargli accavallare la testa con la Strega ( che ora fluttua sorretta da magia ) e nella parte introduttiva e finale gli darò un'animazione a picture in modo da evitare di fare eventi in più con altra grafica ed avere un'animazione più fluida (wip): https://ibb.co/c0u685 Purtroppo ho notato che ogni tanto le Navi si impallano quando "tornano" dalla loro SwitchOff. Si posizionano a sinistra dello schermo e rimangono lì, senza far nulla. Dopo parecchio ricominciano a muoversi e a sparare. Non capisco quale sia il motivo, oltretutto sono molto difficili da colpire quando si bloccano... Credo capiti soprattutto a quelle "normali", quella azzurra non l'ho mai vista impallarsi. Ah, adesso il Multipollo è efficientissimo, ma il raggio non prende mai nulla...sembra brutto avere una mossa speciale che non serve a nulla, ma non ho ancora capito come allargare il suo campo d'azione a tre tile! @.@ Capito, allora aspetterò di sistemare altre tipologie di nemici ed attacchi prima di inserirlo nel file del gioco vero e proprio Avrei proprio bisogno di organizzare la variabili/switch meglio, mi ritrovo già a riutilizzarle perchè ho paura di usarne troppe in elenco @.@ C'è un qualche modo per assegnarle con efficienza? Ho visto che su internet consigliano di dedicare intere pagine ( tipo da 1 a 25 ) di variabili/switch a determinate mappe, anche se lasciano spazi vuoti: è un buon metodo? Il gioco non si appensantisce? Link della nuova versione: https://www.mediafire.com/?7y4vn2s7yslysp7
  13. Forse dovrei sempre avere la torta da 100 ma avere le picture in proporzione: 1 spicchio = valori da 1 a 5. Però le picture sarebbero comunque parecchie ed potrebbe laggare. Il limite è di quante ce ne sono in contemporanea su schermo? Facendo "show picture" e dando loro lo stesso numero non si dovrebbero sovrascrivere di volta in volta? Cercherò qualche RGSS per tipo le barre degli HP, credo di aver bisogno di una cosa del genere.
  14. Esatto, il problema è che vorrei un sistema che sottragga a tutti gli altri tre in poporzione. Magari acqua toglierá poco a terra/aria ma molto a fuoco, ma con le picture mi trovo bloccata perchè dovrei farne una marea per tutte le variabili possibili.In pratica vorrei fare una ruota in percentuale, che vale 100 in totale e le quattro variabili da 25 se la spartiscono. È fattibile dal punto di vista degli eventi/variabili, ma complicato nella resa delle pictures, per questo ho pensato che dovrò usare gli RGSS... :C
  15. Ah, colpa mia che non ho spiegato bene, allora: chiunque faccia un attacco magico ( Strega, party members, nemici ) cambia le percentuali della ruota. Ovviamente i nemici tenteranno di usare certi attacchi per ricevere bonus dalla percentuale più elevata di un elemento ( come può fare anche il giocatore per i propri attacchi ) o cercare di "abbassare" la percentuale degli elementi a cui sono deboli. Forse avrebbe più senso il battle background? Ma in quel caso dovrei crearne una copia per ogni background + ogni combinazione possibile della ruota @.@ Nel database dà l'opzione di modificare gli eventi in battaglia, così ho caricato una picture: https://ibb.co/na9oMQ Comunque mi sembra che organizzarla a picture sarà un'impresa, probabilmente dovrei limitarla a 12 spicchi ( 3 per ogni elemento ) alla partenza della battaglia ed attaccare ogni elemento ad una variabile che viene modificata dalle altre e le modifica a sua volta. ( e non ci sono anche gli altri tre elementi "speciali" @.@ ) Tipo, inizio battaglia: var fuoco =4,var terra=4, var acqua=4, var aria=4. Viene usata skill d'acqua: var acqua=+2, var fuoco=-2. E certe skill funzionano in modo che se una variabile è uguale od oltre un certo numero ricevono bonus di attacco/status malevoli da infliggere al nemico.
  16. In che senso picture con sfondo/grafica di uno dei BS? (BS è battlers, vero? ) Io pensavo ad un Evento Comune come stavamo facendo con la Barra della Presa. Mi interessa molto il fatto che abbia un incipit simile, lo giocherò appena il tempo lo permetterà! Sì, la Strega senza aiuti "esterni" ( che siano armi o party members ) è piuttosto scarsa, so che al giocatore piace sentirsi non semplicemente il protagonista di una vicenda, ma anche l'Eroe di quest'ultima. Peccato che il mio maestro di masochismo nei videogiochi sia Yoko Taro, quindi niente Eroe qui! Io so che mi attacco molto al lato grafico, ma sono un'artista, le mappe coi livelli mi garbano troppo xD Più che altro è che so che se mi perdo in fronzoli poi il gioco non esce più: già solo per la parte di trama il lavoro sarà lungo.
  17. Forse i dialoghi ti possono apparire o "prolissi" o appartenenti a scene condensate sempre per mancanza di esperienza nel gestire il "pacing" dei capitoli: è difficile assegnare ad ogni scena e testo il tempo giusto. Se mai ti capiterà di fare un altro fumetto ti consiglio di lavorarci sopra partendo dai thumbnail. Purtroppo un problema dei webcomic è proprio riuscire a bilanciare la quantità con la qualità. Hai assolutamente ragione sul non voler pubblicare a capitoli, il pubblico di internet tende ad apprezzare di più update brevi ma più frequenti: non per questo, però, dovresti privare il tuo fumetto dell'avere tavole più impegnative. Dalle tue risposte mi sembra che consideri il medium come qualcosa che o corre per forza ( scene "sintetiche", "Per mantere l'attenzione del pubblico, in ogni pagina deve succedere molto" ) o non diventa interessante. Posso capire il tuo punto di vista, ma non riesco a trovarmi pienamente d'accordo: una pagina tantum che contiene "meno" ( dialoghi, azione, vignette. etc ) delle volte è necessaria per rallentare il pacing. Pensa anche a chi non solo segue il fumetto update per update ma anche a chi è arrivato dopo e sta leggendo un serie di azioni e dialoghi frenetichi che vanno avanti, e avanti, e avanti...! La "pausa" serve anche a rendere più eccitante una ripresa dell'azione. ( e ricorda che esistono altri generi oltre all'action, se hai difficoltà nel gestire i dialoghi prova qualche fumetto Noir. Ti consiglio Blacksad: non ti far fregare dai furry, perchè gli autori sono dei veri maestri di sceneggiatura e dialoghi, per non parlare dell'espressività dei personaggi. Certe cose che solo il fumetto europeo possiede. ) E non ho scelto per caso l'esempio di One Punch Man: è un manga parodistico del genere shonen che alterna la freneticità dei combattimenti a scene di vita quotidiana di Saitama e Genos: se non l'hai mai letto te lo consiglio caldamente, è ottimo sia dal punto di vista artistico che scritto: Yusuke Murata sperimenta in modo magnifico con le tavole, ci sono interi capitoli ideati solo per essere letti in formato digitale, come se fossero fotogrammi, che vengono interamente ridisegnati per i tankobon! E One ha idee geniali per trame, personaggi e gag; potrebbe esserti utile come spunto. Capisco la questione del tempo: ma esattamente come avete comunicato per la stesura del fumetto? Siete in due, giusto? Solitamente i "professionisti" non lavorano mai da soli, anzi, molto spesso la figura dello scripter e del disegnatore sono separate. Forse potrebbe aiutarvi leggere qualche articolo su come funzionano i team della Marvel/DC per la produzione. Spero non ci siano problemi con l'inglese, ma Wikipedia riassume bene i metodi Full Script Style, tipico di DC, e Plot Style, della Marvel. A seconda della bravura dello scripter nella fase del disegno dei thumbnail si può scegliere o l'una o l'altra. ( Io nello scorso post ti ho descritto il metodo di Peter David, che trovo molto solido e lascia poco ad indicazioni vaghe che potrebbero confondere il disegnatore ) Sia il testo che stai usando, che i baloon, non dovrebbero mai uscire dalla vignetta ( a meno che non abbia un'utilità, come ho detto prima ). I balloon non li definirei un dogma, ma sono senz'ombra di dubbio riconosciuti universalmente, quindi uno standard. Per non parlare della facilità con la quale esprimono pensieri, urla, bisbigli e "voci" particolari ( pensa come per radio e tv molto spesso si usano balloon squadrati, che ci comunicano immediatamente l'idea di "artificialità" del suono ). Lo "sfondo" del balloon non è lì per occupare spazio, ma per rendere reggibile e "pulito" l'aspetto della parte di tavola dove appare il testo. Visivamente c'è molta differenza tra parole con effetto stroke intorno ed un semplice balloon, come tutte le fastidiose tangenti che si evitano con una singola ellissi precisa. E stiamo dimenticando anche l'importanza della "coda" del balloon, che punta alla bocca del personaggio e fa immediatamente capire chi stia parlando! A tal proposito, un articolo molto utile sul lettering: (x) ( sempre in inglese, mi è difficile trovare tali argomenti in italiano, abitudine orz ) Il fatto che tu abbia dovuto ricorrere a "colorare il testo" ( pratica che, tra l'altro, rovina il lavoro fatto nello scegliere la palette dei colori per la pagina ) per far capire chi dica cosa, dovrebbe già farti intuire che è un metodo un po' fallace. E' come dire: ok, tutti i segnali stradali di divieto sono circolari, ma se io faccio il mio quadrato e ci scrivo sopra che è un "divieto" è altrettanto ovvio, no? Insomma, le persone riconoscono immediatamente la sagoma, poi il contenuto! Basta pensare che il "lettering" è un lavoro a parte fatto da una persona specifica! E' molto importante! Sta a voi decidere quale metodo usare per mostrare il testo, e capisco se preferiate optare per metodi più veloci per questo fumetto, ma spero comunque che questi link/tutorial vi siano utili per il futuro! Figurati, mi fa piacere condividere le mie conoscenze sul fumetto, è un medium che adoro tantissimo! Sentiti libero di chiedermi quello che vuoi quando vuoi!
  18. Benvenuto e bentornato! Su che RPG Maker lavori?
  19. Grazie! Un po' di ragioni, dettate da preferenze personali ed economiche: 1. E' l'engine che mi offre il migliore rapporto "roba che può fare" : prezzo; 2. Mi piace molto come funziona il mapping in XP, con i layers e tutto, cosa che, se non erro, VX non aveva e mi scoraggiò a passare all'engine successivo; 3. Non mi è mai piaciuta la grafica di VX/Ace, troppo "chibi" per i miei gusti, so che facendo sprites e tileset da 0 sì può bypassare ma fu un altro punto a sfavore per i nuovi engine xD; 4. Ho XP da anni ed ho quasi imparato come usare il suo RGSS e sono abbastanza competente con eventi e tutto, passare a quelli nuovi mi spaventa . So che è un po' una vecchia ciabatta rispetto agli engine più recenti, ma ci sono affezionata ed avevo già inizato a lavorare sul mio progetto cercando script e tutto. Se mai farò un nuovo gioco passerò a qualcosa di più recente, per ora mantengo XP. E' davvero così scattoso? Se non erro va a 40 fps che non è male, certo, ci sono certi punti dove mi dà dei lag spikes, tipo se deve caricare cambio di tonalità schermo + BGM diversa + altri eventi e gli volevo mettere l'anti-lag system per gli eventi fuori mappa per non appesantirlo, ma per ora non mi sta dando grossi problemi. Io e Guardian stiamo curando la sequenza shoot em up iniziale, appena sarà giocabile con grafiche fighe e tutto la vorrei postare come mini demo in questo topic proprio per ricevere feedback da più utenti e sapere se è scorrevole.
  20. Gli accorgimenti che hai fatto lo rendono molto più preciso, grazie mille! Cambiamenti che ho fatto: - ho spostato il tile di scorrimento al livello più alto della mappa perchè altrimenti il giocatore ci passava attraverso; - ho chiamato il common event della presa bar dall'Ev01 così compare dall'inizio; - ho modificato il timer perchè nella seconda pagina era rimasto var shootemup=10 che non funzionava e l'ho modificato in switch fine minigame=on ( ora l'evento non si protrae per un mucchio di tempo senza terminare le navi ed i polli ma finisce passati gli 1,5 secondi ); - ho reinserito la terza nave e le ho dato un pattern speculare alla prima, visto che le coordinate erano lì xD; - ho aggiunto l'evento raggio, è in due nuovi eventi, il primo è così ( l'ho associato al tasto Invio ): https://ibb.co/gvmrak Il secondo: https://ibb.co/eoNWak L'evento ha un cooldown di 100 frames ma lo aumenterò per il gioco. Le ultime pagine sono uguali alle switch fine gioco on -> erase event degli altri eventi. La Rana è stata posizionata nell'angolino a destra della mappa in 39:14 e ho dovuto cambiare il percorso delle navi per impedir loro di avvicinarsi alla parte bassa della mappa perchè la presenza della portentosa Rana le oneshottava all'istante. Ho anche aggiunto due tile impassabili dal bordo superiore e quello inferiore per impedire al giocatore di tagliare la grafica di Cat. Vorrei farti un paio di domande per capire meglio l'evento: - le variabili 14 e 17, impostate ad 1 dall'EV001, a cosa servono? Non riesco a trovarle in nessun altro evento. (le ho assegnate alla Y rana e allo shootrana ) - vorrei inserire un clue visivo per far capire che i proiettili sono stati usati/si sono ricaricati (idem per il raggio), il suono lo mantengo. Mi consigli di creare due picture (una per i polli ed una per il raggio) simile alla barra presa o quattro eventi? E dove dovrei inserirli? Nell'evento Controller Sparo Variabili, subito dopo l'inizio della Conditional Branch? ( Immagino che dovrò chiamarli con un common event come la barra per renderli meno pesanti ); - non ho ben capito il fatto delle dimensioni degli eventi: come posso renderli più grandi in modo da non doverne fare di più? Devo creare un nuovo file per lo sprite e crearlo in proporzione moltiplicandolo per 4? Tipo: tutto Cat è lungo 512 pixel, so lo volessi rendere un solo sprite dovrei moltiplicare tutto il suo file x4 e quindi avere un'immagine di 2048 pixel che conterebbe ogni 512 come un singolo sprite? - una voltre reinserita questa mappa nel gioco le variabili/switch rimarranno tali anche se le avevo già usate per altro o mi "incasineranno" il gioco? Se danno problemi le assegno subito a variabili/switch non usate così evito di farlo nel gioco stesso. Appena ho capito come fare gli eventi più grandi provo e posto la nuova versione migliorata!
  21. Bellissimo fumetto, adoro l'umorismo ed i personaggi! La parodia del genere shonen mista ad RPG Maker è molto carina ( e mi piace un sacco il personaggio di Alex xD ) Visto che stai facendo questo fumetto per migliorarti, spero non ti dispiacciano un po' di critiche sul tuo modo di comporre le tavole ( criticherò principalmente il Capitolo 6 essendo il più recente ): 1. Hai ragionissima a voler cambiare il font: Anime Ace è molto usato e anche non esattamente bello alla vista. Ti consiglio di fare un giro in questa sezione di dafont: http://www.dafont.com/it/theme.php?cat=102&page=1 Fatta apposta per font "fumettosi". Miraccomando a scegliere qualcosa che sia prima di tutto leggibile, poi pensa allo stile! 2. Dovresti variare la composizione dei tuo pannelli. Ho fatto delle miniature per mostrarti come appaiano tutte le pagine del capitolo 6: http://i63.tinypic.com/29y2osm.png Come puoi notare si ripetono sempre 3 righe e le dimensioni delle vignette non variano mai abbastanza, rendendo la composizione più adatta ad un fumetto basato su dialoghi, poca azione e pacing calmo ( pensa a a Topolino ) invece che ad un fumetto che tende all'action. Occhio a non fare l'errore di delegare ai dialoghi ( e quindi non alle mazzate, per intenderci ) pannelli poco interessanti e statici! Questo layout ripetuto è noioso per il lettore: ricordati che esistono storie non action che dedicano moltissima cura al posizionamento e alle dimensioni dei pannelli e trattano principalmente di dialoghi! Eccoti svariati esempi di Dylan Dog: nota come cambia il layout nonostante il tema della pagina non sia action: (1), (2), (3), (4), (5), Invece questi sono esempi di One Punch Man, che come ogni manga, va ancora ancora più "Over the top" con il layout, cosa che adoro: (1), (2), (3) Per comprendere come posizionare ( e che dimensione dare ) ai pannelli ti devi prima di tutto chiedere cosa debba contenere quel pannello. Le vignette di un fumetto non sono altro che il modo con il quale il medium comunica al lettore: 1. lo scorrimento del tempo e 2. cosa dovrebbe guardare. Se un'azione è repentina e di poco conto avrà un pannello piccolo! Se qualcosa deve attirare l'attenzione del lettore ( indrodurre una nuova scena o personaggio ) o serve per "rallentare" la lettura ne avrà uno più grande! Ad esempio: quando hai introdotto l'elementale di Magma sarebbe stato più adatto dargli una splash page o un pannello più grande, almeno di due righe: http://i63.tinypic.com/6ifva8.png Perdona le photoshoppate non esattamente fantastiche e la mia grafia: ricordati che puoi anche aggiungere linee dinamiche per intensificare l'azione. Ti consiglio di leggere attentamente i fumetti/manga che più ti piacciono e ricopiare in piccoli thumbnail le loro sequenze di pannelli per ogni pagina che ritieni "interessante", in modo da analizzarle e comprendere come funzionano per poi applicarle al tuo fumetto. 2.5 Le pose dei tuoi personaggi e le inquadrature nei pannelli hanno lo stesso problema del layout: sono busti o primi piani piuttosto statici, tenta di variare angolazione e pose! Una rapida guida di Wally Woods per afferrare il concetto: (x), se hai bisogno di più spiegazioni a proposito, chiedi pure. 3. Mi chiedevo perchè non usassi più i baloon e, cercando pagine addietro, ho trovato questa spiegazione: Ahia! Vedo un erroraccio grosso qui! Il fumetto è un'arte composta anche di testo, è parte integrante delle tavole, non un addendo successivo! Qui ti devo chiedere come esattamente organizzi il processo di produzione del fumetto. Solitamente si procede con il fare un piccolo riassunto della storia e poi un riassuntino di ciò che comprenderà ogni singolo capitolo e poi illustrarlo tramite thumbnail, in modo da aggiustare pacing, layout delle vignette e posizionamento dei baloon, in modo che, appunto, non "stiano in mezzo al disegno" ed infine si passa al bozzetto delle pagine vere e proprie. Così è come appare solitamente un thumbnail: (x). Come puoi notare è piccolo, poco dettagliato e scarabocchiato. Questo perchè serve per dare un'idea di come sarà la pagina prima di inizare anche solo il bozzetto della stessa. Con un capitolo fatto tutto così puoi ben da subito vedere dove hai bisogno di aggiustare vignette, pose e testo, senza la fatica di aggiustare una pagina intera ogni volta! Nota che i baloon per il testo sono già presenti sul thumbnail: in questo modo, quando disegnerai la pagina intera, saprai già dove lasciare gli "spazi" nei pannelli dove andrai ad inserire il baloon, senza timore di coprire teste e sfondi importanti! Ti consiglio di abbandonare il metodo che stai usando perchè: 1. Molte volte il tuo testo esce fuori dalla vignetta, accavallandosi sulle altre o prendendo lo spazio tra le vignette che dovrebbe essere invece dedicato a separarle: quindi va lasciato pulito a meno che il testo/baloon non esista per "collegarle"; 2. Copre molto spesso ed in ogni caso teste e sfondi; non avrà il cerchio più ingombrante dei baloon ma non è comunque piacevole per la tavola; 3. Ultimo, ma non per importanza: non è assolutamente professionale. I baloon che facevi prima ti apparivano "ingombranti" perchè ti mancavano le basi per eseguirli correttamente. Eccoti alcuni tutorial che potrebbero aiutarti a migliorarli: 1. Aggiustare la forma del baloon in modo da evitare che abbia eccessivo "spazio bianco" intorno al testo (richiede Photoshop): (x). 2. Posizionare baloon nella vignetta e tra di loro: (x), (x), (x). Questo sono ovviamente le basi per layout, vignette, baloon e lettering. Ho notato che sei molto bravo a mantenere il senso di lettura fluido nelle tavole, quindi volevo aiutarti a migliorare il resto. Tanta pratica ti aiuterà a comprendere il "flow" delle pagine e di come vanno posizionati personaggi, scene, baloon, etc. Esercitati di più su dei piccoli thumbnail invece che sulle pagine: guadagnerai più tempo e farai più prove. Ti consiglio di leggere tanti tutorial e fumetti professionali per aiutarti a migliorare e spero che queste critiche ti servano a tale scopo!
  22. OK! Non l'ho mai fatto, spero sia corretto ( ho creato il game disk senza criptarlo ): https://www.mediafire.com/?6oc3yfzm628ev58 Gli eventi sono sulla prima riga dal tile 1 al 10, sulla seconda dall'1 al 5 e sulla terza all'1. L'evento "punto" è in coordinate 12:8, la testa del mostro 18:8, il collo ( sopra il quale spawna il giocatore ) 22:8. Credo siano tutti quelli che non si vedono bene, dato che la mappa è bianca.
  23. Wow, sono dei title davvero bellissimi! Se uno degli obbiettivi di questo contest era far rivalutare l'impegno che andrebbe profuso nel title screen ( il "biglietto da visita", alla fin fine, di un gioco ), nel mio caso c'è riuscito appieno! Vorrei esprimere le mie opinioni/critiche su questi lavori: Alice Misaki - Calla Lily: Ottima atmosfera e scelta dell'animazione e musica! I carillon dà quel tocco di angoscia ed "innocenza" che non stona mai in un horror! Belli i disegni, annunciano un gioco dallo stile personale ed ispirato. Daemond - Ninja: Effetti sonori ed animazione azzeccatissimi per il tema trattato e idea carinissima di far apparire la stellina ninja sull'opzione prescelta! Giusto il font scelto/sfondo per il titolo trovo siano un po' troppo scontati/comuni, poichè fanno sì intuire la tematica del gioco ma non vi aggiungono nulla di unico che mi farebbe pensare: "Ah, riconosco quella schermata, è del gioco "x"!" Killveran89 - LupusInFabula: Che bella atmosfera e che bella mappa! L'idea di far scorrere la mappa con le opzioni la rende dinamica nonostante la sua staticità. E' quel tipo di title per cui passere quei secondi in più solo per ammirarne i dettagli. Nerghray - Chromawave e Saul - Spacecube: Adoro la scelta estetica e gli effetti/animazioni! Nerghray ha degli effetti sonori perfetti per un gioco musicale e Spacecube ha una fluidissima animazione per il movimento del cubo che si anima per mostrare le opzioni al giocatore. Old Pat - Einai Dorean: Questo è uno dei title che ho osservato più a lungo con tanti replay! E' esteticamente magnifico, originale, ottimo uso di musica ed effetti sonori ( i cerchi per caso prendono il suono da Metal Gear Solid?). L'effetto di "movimento della telecamera" che accompagna il mouse lo rende così dinamico! A mio modesto parere, però, ha due piccolissimi difetti: 1. Alla pressione del mouse, per raggiungere il menu vero e proprio, impiega 14 secondi, che potrebbe andare bene nel caso in cui stia nascondendo un caricamento, ma credo sia invece una scelta artistica per focalizzare l'attenzione del giocatore sulla bellissima animazione. 14 secondi non è tanto, ma non è nemmeno poco per un titolo per il titolo. Magari si potrebbe migliorare velocizzando l'intervallo tra i frame dell'animazione. 2. La posizione dei tre cerchi non è intuitiva: non mi fanno capire cosa aprano senza scorrerci sopra, se non fosse stata una dimostrazione avrei provato ad aprire il cerchio più in alto per avere il New Game, cercando mentalmente di ordinarli seguendo l'ordine di lettura nostrano ( da sinistra verso destra, poi da su a giù ) nonchè seguendo l'ordine di un Menu tipo ( New game sopra, poi Load e Esci sotto ). Owari - Obscurias: Grafica minimalista adatta ad un gioco horror che lascia molto all'immaginazione del giocatore, fa immediatamente pensare: "Mi domando quali cose terribili mi attendano in questo buio!" Belle animazioni ed estetica. Forse quel "seleziona" come consiglio non era necessario, rompe l'immersione ed immagino che il giocatore, per esperienza e non vedendo altre opzioni, avrebbe trafficato con i tasti. Oppure non inserire la scritta e lasciare solo le frecce come consiglio. RockyJoeRocchetta - Deep Sea: Carina l'idea di far apparire il titolo nel gioco usando la mappa stessa, ma forse il menu delle opzioni si sarebbe dovuto posizionare in basso, in modo da evitare di coprire proprio il lavoro fatto sulla mappa. Bella l'animazione delle stelle intorno all'opzione selezionata! Testament - The Last Chance: Il secondo title che ho fissato per minuti! Magifica l'atmosfera, la musica, la diavolessa sensualissima e ben animata! E' incredibile come un title, che solitamente si considera un'immagine statica, qui appaia così interattivo! Farei entra ed esci dalla partita solo per controllare tutte le animazioni e chicche che può fare e allo stesso tempo non vedrei l'ora di incontrare la suddetta diavolessa che trasuda di personalità e scoprire di cosa tratta il gioco! Spero assolutamente che le mie critiche non offendano nessuno, perchè questi lavori mi hanno mostrato quanto talentuosi siano i partecipanti ed ispirata a fare di meglio per il mio title set!
×
×
  • Create New...